当您的 AI 代理泄露数据时,谁该负责?2026 年的法律现实

在过去十年的大部分时间里,各组织对 AI 提出的问题是运营层面的:*这个工具能为我们做什么?* 到了 2026 年,第二个问题变得同样重要,而且明显更让人不安:*如果我们的 AI 对公司数据做出了错误的处理,谁该负责?*

从法庭和监管机构目前得出的简短答案,并非大多数团队所假设的那样。责任主体越来越多地指向部署 AI 的公司——而不仅仅是构建它的供应商。

本文用通俗的语言梳理了发生了哪些变化,以及一个切实可行的应对方式是什么样的。这是科普性内容,并非法律建议;如需针对您具体情况的建议,请咨询您自己的法律顾问。

旧假设:“这是供应商的问题”

直觉上的思维模式是:如果你购买了一款 AI 产品,而它出了问题,那么制造方应当承担责任。这一假设正同时受到两方面的挑战。

首先,法院已开始将 AI 系统视为使用它的企业的代理人——这恰恰是法律长期以来处理代表公司行事的员工和承包商的方式。其次,你与 AI 供应商签订的合同越来越多地限制其责任上限,并要求你对其进行赔偿。这种组合有时被称为*责任挤压*(liability squeeze):问责范围向部署方扩大,而合同风险则向客户回转。

实际后果是,部署 AI 的组织可能最终要为自己既未设计、也无法完全审查的行为负责。这是一个令人不安的处境——这正是为何可证明的治理措施已经从一种良好实践变成了真正的必要条件。

判例究竟说明了什么

这里需要精确一些。目前还没有任何一项判决宣称公司必须对 AI 所做的一切always承担责任。近期一系列进展所确立的内容范围更窄,但也更为持久:部署方可能被追究责任,而通常用来免责的手段比人们想象的要脆弱得多。

Mobley v. Workday(美国)。 美国一家联邦法院允许一起就业歧视案件依据*代理理论*(agency theory)针对一家 AI 供应商继续审理——即认为该 AI 筛选工具是使用它的雇主的代理人。2025 年 5 月,法院批准了一项全国性集体诉讼的有条件认证。其重要意义在于其法律推理:如果 AI 系统可以被视为代理人,那么部署它的各方也就成为问责链条中的一部分。

德国哈姆高等地区法院(OLG Hamm)。 德国一家高等地区法院处理了 AI 聊天机器人对客户所作陈述由谁负责的问题。对每一位部署方都适用的结论是:一份泛泛的免责声明——“回答不作担保”——本身并不能解决你的 AI 向他人所说内容的责任归属问题。

《欧盟人工智能法案》与《产品责任指令》。 《欧盟人工智能法案》中的高风险义务将在 2026 年至 2027 年间分阶段生效,罚款最高可达 €35M 或全球年营业额的 7%。另外,修订后的《产品责任指令》将软件和 AI 系统视为“产品”,将严格责任原则扩展到将其推向市场的整个链条;欧盟成员国须在 2026 年 12 月前将其转化为本国法律。

美国州级监管。 科罗拉多州《人工智能法案》(2026 年生效)、纽约市《144 号地方法》(Local Law 144),以及在约二十多个州采纳的 NAIC 示范公告(NAIC Model Bulletin),正逐渐汇聚成一套共同的预期标准:披露、影响评估、偏见审计,以及可供审计的决策日志。

这些判例和法规单独看都不是“世界末日”式的定论。但它们共同描绘出一个难以误判的发展方向——而这个方向指向的正是部署方。

为什么免责声明和合同的保护作用有限

有两种看似牢靠的防御手段,如今正变得越来越靠不住。

免责声明告知用户不要依赖该 AI。但在 OLG Hamm 一类案件中,法院已表明,一份泛泛的“不作担保”声明并不能免除公司对其选择呈现给客户的 AI 所承担的责任。免责声明能管理预期,但本身并不能管理责任。

供应商合同可以在资金层面进行转移,但它不会改变外部世界认定的责任主体。监管机构和原告会直接找到部署该系统的组织,并追问:你做了什么来治理它? 如果实际责任和声誉责任最终仍落在你身上,一条赔偿条款所能提供的安慰十分有限——而依据该条款获得赔偿本身往往是一个缓慢且充满争议的过程,在此期间对平息舆论毫无帮助。

影子 AI 的作用

还有一个复杂因素让这一切变得更加棘手:大多数组织甚至无法完整列出已经接触到自身数据的 AI。多项调查一致发现,绝大多数员工在未经 IT 部门批准的情况下使用 AI 工具,而*影子 AI*(shadow AI)——通过普通 OAuth 授权连接的未经批准的工具——会显著提高数据泄露的成本。你无法治理、也无法证明自己治理了一个你根本不知道存在的集成。发现这一隐藏的接触面通常是迈向可辩护立场的第一步真正行动。我们在2026 年 AI 治理审计指南中更深入地探讨了发现环节。

真正决定结果的问题

剥去种种细节,几乎所有 AI 问责场景最终都归结为一个单一的问题,无论提出者是监管机构、审计师、客户的安全团队,还是对方的律师:

你能证明自己治理了 AI 对你数据的访问吗?

关键就在“*证明*”这个词。一份声称 AI 使用受到治理的政策文件是必要的,但并不充分。真正有分量的是证据:记录你能看到什么、你控制了什么,以及当出现异常情况时你是如何应对的。这正是“声称自己已尽职”和“证明自己已尽职”之间的区别。

“可证明的治理”在实践中是什么样子

对于一家使用连接到 Google Workspace 等平台的 AI 助手和代理的公司而言,可证明的治理包含几个具体组成部分:

• 可见性。 一份最新的清单,列出所有能够访问你数据的 AI 代理、服务账户和第三方应用。你无法治理——也无法证明自己治理了——你从未察觉到的东西。
• 控制。 有文档记录的决策和规则,能够针对高风险访问采取实际行动,而不仅仅是提供观察用的仪表盘。治理是一个动词。
• 证据。 一份不可篡改、可导出的访问决策及其随时间变化的日志,并具备生成审计师和审阅人员实际要求的文档的能力——且这些文档要对应到公认的控制框架。
• 响应。 一份记录,能够证明你检测到了与 AI 相关的风险,并采取了行动。尽职调查是一条时间线,而不是一张快照。

这正是 8200.dev 所致力于扮演的角色。它以只读方式连接到你的 Google Workspace,列出所有能够访问你数据的 AI 代理和 OAuth 授权清单,对风险进行评分,让你能够执行治理措施,并生成支持你履行尽责义务的、可供审计的证据。它是一个证据层和记录系统——不是法律屏障,也不对任何合规结果作出保证。它带给你的是用证据而非侥幸来回答那一个问题的能力。你可以在功能页面上查看完整的能力集。

从何处开始

迈出第一步并不需要一整套治理项目。你需要的,是看清目前已经存在的情况。

最有用的第一步,就是发现当前有哪些 AI 代理和第三方应用能够访问你的 Workspace 数据,以及每一个能触及到什么。仅仅这一份成果——一份清晰、有日期记录的清单——既是运营层面的一次“大开眼界”,也是证据链的起点。你可以免费查看究竟有哪些 AI 代理可以访问你的数据,并在我们的AI 问责概览中阅读更多关于这一更广泛转变的内容。

*本文仅供一般信息参考,并非法律建议。法律结果取决于具体事实和管辖区域。请就您自身的义务咨询您自己的法律顾问。*