青骥原创 l 浅谈人工智能的安全

AI相关项定义

想象一下当初我们如何做汽车信息安全，第一步那必须是先做整车级别相关项定义，基于数据流能让我们更加全面、系统的了解业务，识别风险点。毕竟，安全并非孤立存在，而是依赖于业务，并最终为业务提供坚实保障。那回到AI，它的“整车”数据流是啥样呢？

我们以目前大家比较熟悉的大语言模型为例，

1.用户通过网页版或工具版的AI应用输入自己的提示词，如“帮我制定一份后天去上海的出差计划”；

2.AI应用（可以当作一个agent）在收到用户输入后，会分别通过MCP、RAG、A2A来丰富上下文

1. 对于MCP，在AI应用获取到用户输入后

• 将本地支持的工具列表和用户输入打包给到LLM

• LLM会从工具表挑选出需要使用的工具并填充参数，同时反馈给到AI应用；由于是出差，LLM可能会挑选出天气查询的工具，参数为时间加地点

• AI应用调用基于选择的工具和参数，调用工具完成查询操作

• AI应用将查询的结果给到LLM

b .对于RAG，在AI应用获取到用户输入后

• 9.向本地知识库进行检索

• 10.检索完成后生成增强后的内容

• 11.将增强后的内容反馈给AI应用，使其丰富上下文

c.对于复杂任务，有时候还需要通过A2A完成多个agent的协同，单个的agent也有可能通过MCP或RAG完成特定的操作

3.LLM使用丰富的上下文经过推理后生成回复；

4.AI应用对LLM的回复进行检查后输出给用户

此时，我们不禁产生疑问：LLM如何基于输入的上下文进行推理并生成输出？RAG系统又是如何实现检索增强的？这是否与ECU级别的相关项定义颇为相似？我们完成整车相关项定义和TARA分析后，派生出整车安全需求。ECU承接整车安全需求后，需要进一步做ECU级别的相关项定义和TARA分析，进而派生出ECU级别安全需求。对于大模型应用的场景，也是如此，只是对象不一样。

拿RAG为例，我们进一步拆开分析数据流：

• 在提前之前

1.数据准备，搜索本地关联的文档；

2.文档的分片处理可基于段落、字数、章节或页码等标准进行。

3.将分片后数据向量化，此处会用到一个embedding模型

4.将向量化后的数据存储到向量数据库

• 在提问之后

1.将用户输入进行向量化

2.召回操作，挑选出相似度最高的n个片段，一般是基于向量数据库完成向量相似度计算，如余弦相似度、欧式距离、点积等。这一过程类似于简历的初步筛选，强调快速高效；

3.重排操作，将n个片段再继续挑选出m个片段，一般是基于cross-encoder完成。这一步骤则类似于后续的多轮面试，旨在实现精准匹配；

4.返回重排后的结果

AI安全总览

经过上面的介绍，我们大致了解了AI运作的流程，此刻我们就可以大致勾勒出AI安全的总览图了。

l流程层面，我们需要将安全融入到AI的全生命周期，包括概念设计阶段、设计与研发阶段、测试验证阶段、供应链管理阶段、部署阶段、运维及监控阶段、更新及下线阶段，为后面AI的治理和合规做准备。

l技术层面，AI系统的运行一样依赖于硬件、软件和通信，在此技术上我们需要考虑

• 模型安全，即模型自身的安全性，需关注模型在训练、推理及使用过程中可能遭遇的信息泄露、偏见决策、错误决策、鲁棒性不足以及模型被窃取等风险。

• 应用安全，AI应用生态中的各类agent、应用框架，自研或第三方插件和工具，关注工具不安全输出、错误执行、过度资源消耗的风险

• 数据安全，AI系统全生命周期的数据安全，包括模型训练数据、模型微调数据，用户使用数据，用户知识库数据，关注数据在收集、标注、存储、传输中不安全使用、泄露、违规风险

• 基础系统安全作为AI系统的基石，涵盖了AI基础设施、基础软件框架及其依赖项，如训练框架、推理框架、计算平台、操作系统及第三方依赖库等，需关注基础设施服务不可用、网络中断、软件漏洞等风险，这与传统安全领域的要求保持一致。

AI部署和使用场景

整个AI安全生态非常庞大，那么责任如何划分呢？其实这直接由我们的部署和使用场景有关。在不同的使用场景和部署环境下，不同的决策主体需承担相应的责任。至于具体承担什么责任，面对什么样的威胁，采取什么样的安全措施，在后面的文章我们会一步步介绍。

使用场景

参考AWS的分类标准，我们将使用场景划分为以下五类：参考AWS，将使用场景可以分为5类：

Scope1：消费者应用

定义：用户使用公开的第三方生成式AI服务（无论免费或付费），但不拥有或接触训练数据及模型本身，亦无法对模型进行修改或增强。用户仅通过API调用或直接使用应用，并需遵守服务提供商的相关条款。

示例：使用生成式AI聊天工具，为即将开展的营销活动生成创意。

Scope2：企业应用

定义：企业采用嵌入生成式AI功能的第三方企业级应用，并与供应商建立商业合作关系。通常，组织以整体名义采购生成式AI应用的使用权限，其定价和合同条款与个人消费级应用存在差异，通常为该组织专属，而非面向普通零售消费者的标准条款。

示例：使用某第三方企业日程管理软件，其内置生成式AI功能可帮助起草会议议程

Scope 3：预训练模型

定义：企业基于现有的第三方预训练基础模型，开发自身应用，并通过API直接集成至业务系统中。

示例：利用Anthropic Claude 基础模型（通过 Amazon Bedrock API），开发一个客户支持聊天机器人。

Scope 4：微调模型

定义：企业基于第三方基础模型，利用企业专属数据进行微调，以生成一个更契合自身业务需求的优化模型。

示例：通过API调用基础模型，为营销团队构建一个能生成符合公司产品和服务特点的营销材料的应用。

Scope5：自训练模型

定义：企业完全自主训练生成式AI模型，利用自有或获取的数据，并拥有模型的全部控制权，但此过程成本高昂且复杂。

示例：企业希望训练一个仅基于深度行业数据的模型，并授权给该行业的其他公司，从而打造一个全新的大语言模型（LLM）

部署场景

• 端侧部署，即将大模型直接集成至用户的终端设备中，如智能手机、个人电脑或专业工作站等。该模式的核心优势在于能够提供高度个性化的用户体验，同时由于计算在本地完成，可最大程度地减少数据传输延迟，提升响应速度。此模式特别适用于对隐私保护和实时性要求极高的场景，例如离线语音识别、即时翻译以及全知个人助理等应用。

• 边缘计算，即将大模型部署在靠近用户但非端侧设备的边缘服务器上。该模式融合了云计算的强大处理能力与端侧部署的低延迟优势，适用于处理对计算和数据要求较高且需快速响应的应用程序。此外，由于数据无需传输至远端云服务器，边缘计算还能有效降低带宽需求并增强数据安全性。

• 云平台服务，借助云端基础设施来运行和管理大模型。云服务为大模型供应了充足的存储与计算资源，使其能够运行复杂算法，处理海量数据。云平台的模型服务（MaaS）为模型的升级与维护提供了灵活性，并且保证了用户在任何地点都能便捷地访问模型。不过，这种模式可能会遭遇网络延迟和数据隐私方面的问题，这就需要通过合理的系统设计与策略来进行缓解。

总结

今天我们对AI系统的组成、使用和部署场景、安全做了初步的介绍，我们大致了解了AI安全的各大板块，但本文没有详细的描述AI的安全威胁和防护策略，这个后面会逐步介绍，青骥会推出AI安全威胁、AI安全防本系列文章旨在探讨生成式人工智能的安全防护。

参考

• 人工智能安全标准体系-V1.0-征求意见稿

• Part 1 – Securing Generative AI: An introduction to the Generative AI Security Scoping Matrix

• Part 3 – Securing Generative AI: Applying relevant security controls

说明：本公众号为青骥信息安全小组所有，不隶属于任何商业机构，部分信息为网络收集，版权归原作者所有，文中观点仅供分享交流，不代表本公众号立场。如涉及版权等问题，请您联系[email protected]告知，以便及时处理，谢谢！