# LLM 的责任共担：谁负责保护什么

> 云计算的责任共担如何适用于 LLM：Microsoft 和 CSA 的模型、欧盟《人工智能法》对模型提供者和部署者规定的义务，以及一张针对 API 使用场景的分工表。

FireAI Security & Research Team (HisnLabs) · Published 2026-09-30
Canonical: https://hisnlabs.com/zh/blog/llm-zeren-gongdan-shei-baohu-shenme

基于托管语言模型进行构建的组织，从厂商那里获得经过安全训练的模型和平台，但仍要对围绕模型构建的应用负责。Microsoft、云安全联盟和欧盟《人工智能法》各自在模型提供者与部署方之间划分工作，所用术语和法律效力各不相同。本文比较这三者，并针对通过 API 使用模型这一常见情形提出一种实用的分工。本文是[《Anthropic 如何对 Claude 进行红队测试，以及它把什么留给了你》](https://hisnlabs.com/en/blog/how-anthropic-red-teams-claude)的配套文章，后者以一个已公开的案例考察了分界线上提供者的一侧。

## 背景：延伸到 AI 的云模型

云计算的责任共担模型根据服务类型，把每项控制措施分配给提供者或客户：软件即服务（SaaS）、平台即服务（PaaS）或基础设施即服务（IaaS）。Microsoft 和云安全联盟（CSA）都把这一思路延伸到生成式 AI。这种延伸改变的更多是术语而非逻辑：客户在技术栈中构建的层次越低，自己负责的控制措施就越多。

## 厂商模型

### Microsoft：平台、应用和使用

Microsoft 的 AI 责任共担模型把一个启用 AI 的应用描述为三层：AI 平台、AI 应用和 AI 使用。平台层通过 API 提供模型，并包含一个过滤有害输入和输出的安全系统。应用层是用户使用的界面，带有知识接地（grounding）、插件和数据连接器，它需要自己的应用安全系统。使用层涵盖人们如何使用这项能力，Microsoft 在此提到身份和访问控制、可接受使用政策以及用户教育。[[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

客户对每一层承担多少责任，取决于部署类型。该页面说明，责任在 SaaS、PaaS 和 IaaS 之间有所不同，并建议从 Copilot 等 SaaS 产品开始，只有在现成能力不适用时才转向 Azure OpenAI Service 等 PaaS 服务，而定制模型的构建应留给具有深厚专业能力的组织。该页面还说明，这份指导是示例性的，是在治理意义上使用的，并不修改与 Microsoft 之间的任何协议。[[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

### Microsoft：针对智能体的扩展

Microsoft 的第二个页面涉及智能体，并将其与单纯的模型区分开来，因为智能体无需人类逐步批准即可行动，会进行规划和循环，拥有记忆和自己的身份，并能与其他智能体组合。它增加了三层：智能体编排、工具与操作，以及记忆与状态。在其责任矩阵中，在 PaaS 情形下，智能体的指令和范围、按工具的权限以及高影响操作的人工批准由客户负责，而运行时和编排器平台归 Microsoft 负责。[[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

该页面列出了客户始终保留的责任：数据、身份与最小权限、操作授权、人工监督，以及可接受使用与治理。它还指出，自主性从不减轻问责。[[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

### 云安全联盟：一份 2023 年的提案

在一篇日期为 2023 年 7 月 28 日的博客文章中，一位 CSA 研究员提出了一个包含三方的模型：AI 服务提供者、构建应用的 AI 服务用户，以及该应用的企业或最终用户。根据该提案，IaaS 提供者提供基础设施和基础模型，用户负责训练、数据验证、提示过滤和应用安全；在 PaaS 情形下，用户提供上下文和应用安全；在 SaaS 情形下，用户管理知识接地、提示过滤和知识产权保护。该文章把这作为一份划分职责的提案提出，而不是一项标准。[[3]](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)

## 法律：欧盟《人工智能法》按角色划分义务

欧盟《人工智能法》按角色分配义务。根据欧盟委员会指南的常见问题解答，通用 AI 模型的提供者是开发该模型或委托他人开发该模型、并以自己的名义将其投放市场的实体。提供者的义务包括技术文档、面向下游开发者的关于能力和局限的文档、版权合规政策，以及训练内容的公开摘要。这些义务自 2025 年 8 月 2 日起适用。被推定具有系统性风险的模型，即训练计算量达到或超过 10^25 次浮点运算的模型，还须承担更多义务，包括对抗性测试和网络安全保障。[[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

同一份常见问题解答给出，对这些提供者的执法（包括罚款）自 2026 年 8 月 2 日起适用，而 2025 年 8 月 2 日之前投放市场的模型的截止日期为 2027 年 8 月 2 日。它还说明，修改模型的下游开发者只有在特殊情况下才会成为提供者，例如使用了超过原始训练计算量三分之一的计算量，因此大多数微调不会改变提供者角色。[[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

部署者，即使用 AI 系统的组织，承担另一组义务。一份日期为 2026 年 7 月 24 日的律师事务所分析列出，自 2026 年 8 月 2 日起，部署者的义务包括披露深度伪造内容，以及就情绪识别和生物特征分类告知相关个人。对于高风险系统，它列出了称职的人工监督、告知个人正在使用 AI 以及征询员工意见。[[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) 欧盟委员会的时间表页面补充说，系统投放市场后，部署者必须确保人工监督和监测，并报告严重事件。[[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

### Digital Omnibus 带来的推迟

高风险相关的截止日期已经推迟。欧盟委员会的时间表页面列出，生物特征识别、就业和执法等敏感领域的高风险系统为 2027 年 12 月 2 日，嵌入受监管产品中的高风险系统为 2028 年 8 月 2 日，并将此归因于 Digital Omnibus on AI，称其于 2026 年 7 月生效。[[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) Norton Rose Fulbright 的分析报告了同样的两个日期，并说明该 Omnibus 已在欧盟法规汇编中公布。[[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) 因此，两个独立来源一致认为，这一推迟已获通过，而不仅仅是提议。通用模型提供者的义务以及上述透明度义务，并不因这两个日期而推迟。

## 通过 API 使用模型时如何分工

对于应用调用托管模型的 PaaS 情形，上述资料来源支持以下分工。与 Microsoft 相关的各行遵循上文描述的平台层和应用层；关于前沿风险测试、系统文档和披露渠道的各行，反映了欧盟指南中的提供者义务以及模型厂商公布的做法。该表是 FireAI 的归纳整理，并非出自任何资料来源的原文。

| 领域 | 提供者一方 | 你的一方 |
| --- | --- | --- |
| 模型行为 | 模型的安全训练和对齐 | 系统提示和应用防护措施 |
| 风险测试 | 对模型本身的前沿风险测试 | 测试你的应用，包括其提示、数据和工具 |
| 平台 | 平台安全以及基础的输入和输出过滤 | 针对内容、插件和连接器的应用安全检查 |
| 文档 | 系统卡和面向下游开发者的文档 | 阅读这些文档，并记录你部署的模型和版本 |
| 数据和工具 | 除 API 契约外无 | RAG 数据、工具、智能体及其权限 |
| 输出 | 返回生成的文本 | 在下游处理输出：验证、转义、人工批准 |
| 运营 | 模型的漏洞披露渠道 | 应用的日志记录、监控和事件响应 |
| 人员 | 使用政策条款 | 你自己的使用政策和用户培训 |

*以托管 API（PaaS）方式使用模型时的责任分工。由 FireAI 归纳整理。*

有两个领域是严格意义上共担的。第一是提示注入：提供者训练模型抵御注入的指令，部署者则通过工具权限和数据访问来限制注入指令能够达成的效果。Microsoft 的智能体页面描述了同样的分工，要求客户把检索到的内容、工具输出和其他智能体的消息视为不受信任，并对高影响操作设置把关。[[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent) 第二是数据隐私：提供者设定数据保留和训练条款，部署者则决定哪些数据从一开始就进入提示或检索索引。

> FireAI 是 HisnLabs 开发的 macOS 设备端防火墙，它控制 Mac 上哪些 App 可以访问网络，并在 Activity 中列出每一个连接。出站控制位于分界线上部署者的一侧。 [Download FireAI for Mac](https://hisnlabs.com/en/download)

## 建议

1. 首先确定部署类型（SaaS、PaaS 或自托管），并写明上述分工中哪些行由本组织负责。
2. 直接测试部署者一方：系统提示、检索数据、工具权限和输出处理。厂商对模型的测试并不覆盖这些内容。
3. 在采用某个模型之前，阅读提供者的系统卡及其数据保留和训练条款，并找到其漏洞披露渠道。
4. 限制注入指令能做的事：最小权限的工具、限定范围的数据访问，以及对不可逆操作的人工批准。
5. 决定哪些数据可以进入提示，并保留足以重建事件经过的日志。
6. 关于框架和红队测试的学习资料，请参阅 [FireAI University 的 AI 安全框架与红队测试课程](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming)。

## 与 FireAI 的关系

调用模型 API 的本地 App 或智能体就是 Mac 上的一个 App，它的目的地对 FireAI 可见。[Activity](https://hisnlabs.com/zh/docs/activity-and-connection-history) 列出了哪些 App 联网，[Rules](https://hisnlabs.com/zh/docs/per-app-rules) 让用户可以允许或拦截某个 App 或某个特定目的地。这是部署者一方在单台 Mac 上的一项控制措施。FireAI 不检查提示、不评判模型输出、不检测提示注入，也不评估提供者是否履行了任何法律义务。

## 局限

- Microsoft 的页面是针对 Azure 产品的厂商指导，自称是示例性的，不改变合同条款。CSA 的文本是一份 2023 年的提案。
- 本文不构成法律意见。一个组织在欧盟《人工智能法》下是提供者、部署者还是高风险运营者，取决于本文未作评估的事实，各国主管机关对该法的解释也可能不同。
- Digital Omnibus 的相关日期来自欧盟委员会的时间表页面和一份律师事务所分析。本文未查阅该法规本身的文本。
- API 分工表是归纳整理的结果，个别提供者在其条款中对某些行的归属有不同安排。

## FireAI 和 HisnLabs 在其中扮演的角色

分界线上你的一侧包括离开 Mac 的内容。FireAI 让你看到它，并由你决定。

FireAI 是 HisnLabs 自己的产品：一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接，并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行，因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（FireAI Pilot 功能）——这一切都不会离开你的 Mac。

你可以阅读它背后的技术决策，或试用 FireAI 17 天：[HisnLabs 出品的 FireAI](https://hisnlabs.com/zh/download)。

## Sources

- [Microsoft Learn: Artificial intelligence shared responsibility model (page dated 24 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)
- [Microsoft Learn: AI agent shared responsibility model (page dated 26 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)
- [Cloud Security Alliance: Generative AI: a proposed shared responsibility model (28 July 2023)](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)
- [European Commission: Guidelines on the obligations of general-purpose AI model providers (FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)
- [European Commission: AI Act regulatory framework and application timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [Norton Rose Fulbright, Data Protection Report: The EU AI Act, when does it become enforceable now? (24 July 2026)](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/)
- [FireAI docs: Rules: app, website, domain, IP or a range](https://hisnlabs.com/en/docs/per-app-rules)
- [FireAI docs: Activity: every app that went online](https://hisnlabs.com/en/docs/activity-and-connection-history)
- [FireAI University: AI security frameworks and red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming)