如何在 Agentic AI 工作流中避开「责任幻觉」陷阱

你把一个新的 AI 智能体（Agent）连到了公司的客服公共邮箱。你给它写了提示词（Prompt），让它读取来信、去 Shopify 查订单状态，然后起草回复。

这招挺灵。收件箱自动清空了。你看着发件箱里塞满了礼貌且准确的回信，感觉自己每个月只花 £40 就雇了个超人般的财务助理。

但你错了。你其实是给自己造了一个「法律责任引擎」。

这个智能体每打开一封邮件、解析一个客户的隐私数据并传给 API，它都在代表你处理数据。它压根不知道什么是 GDPR（通用数据保护条例）。它也不在乎自己会不会在抄送邮件时，不小心把某个客户的家庭住址发出去。

它只管执行。当它不可避免地违反了隐私规则时，罚单可不会寄给软件厂商。它们会直接拍在你的办公桌上。

法律责任幻觉

所谓「法律责任幻觉」，就是误以为部署一个自动化的 AI 智能体，就能把法律和监管风险转嫁给软件厂商。

你买了一个工具，对方承诺能端到端地处理客服收件箱。它读邮件、查 Shopify 后台、办退款。感觉你把整个部门都外包出去了。

其实没有。你外包的只是敲键盘的动作。法律责任依然全在你的资产负债表上。

英国信息专员办公室（ICO）在最近的《智能体 AI 报告》[来源](https://www.navex.com/blog/article/ico-report-agentic-ai-opportunities-and-risks/)中说得非常直白：AI 的自主性并不意味着人类（以及背后的组织）可以甩掉数据处理的责任。

如果你那个新来的智能体产生了「幻觉」，把客户的账单记录发错了邮箱，ICO 才不管是不是智能体「发疯」了。他们在乎的是你作为「数据控制者」的身份。系统是你建的，泄密了就得你扛。

这个问题是结构性的，因为技术扩张的速度远超你的管理能力。一个人类财务助理可能看错一张发票，导致一次小的数据泄露。但一个拥有 Microsoft 365 全局 API 访问权限的智能体，一小时能处理 10,000 封邮件。

如果指令有误，它会以光速制造一场 GDPR 灾难。法律责任幻觉让老板们觉得每月 £50 的 SaaS 订阅费能买来合规。想得美。

厂商把这些工具包装成「数字员工」。但真正的员工有法律人格和问责制。AI 智能体只是一个极快、极不可预测的计算器。

为什么现成的智能体过不了合规关

市面上现成的智能体过不了合规关，是因为它们的底层架构默认就会把未经脱敏的数据广播给第三方服务器。

我经常看到这种模式：老板们在现成的 Zapier 流程上加个手动审批步骤；或者干脆买个通用的 AI 客服，觉得只要厂商贴了安全标签就万事大吉了。

那是厂商的合规，不是你的合规。

如果你依赖基础的 Zapier 集成来处理客户数据，实际情况是这样的：你在 Gmail 里设了个新邮件触发器，把邮件正文传给 ChatGPT 步骤来总结问题，然后把总结发到 Slack。

听起来没啥。但 Zapier 是把整封原始邮件直接扔给了 OpenAI 的服务器。这包括邮件签名、手机号，甚至可能还有敏感的健康或财务数据。

除非你签了专门的企业级协议，否则你刚才就是把未经脱敏的客户数据广播给了第三方大模型。智能体不知道什么是「数据最小化原则」，你喂它什么，它就读什么。

一个反直觉的事实是：在 AI 流程里加个「人工审核」其实是个很烂的合规策略。一个人每天点 500 次「批准」自动化摘要，那不叫监督，那叫「橡皮图章」。

人是会疲劳的。慢慢地，人就不看原文了，只管相信智能体的输出。

每月 £25 的 ChatGPT 订阅替代不了一个年薪 £35k 的合规官，原理在这儿：大模型是概率性的文本生成器，不是确定性的规则引擎。它们无法可靠地执行 GDPR 原则，因为它们压根不理解这些原则。它们只是在预测下一个词。

当一个现成的智能体遇到复杂的数据请求时，它不会停下来翻翻你的隐私政策。它会靠猜。这确实挺烦人的。但当这个「猜」的结果违反了数据保护法，它就成了法律危机。

你没法靠写个更好的提示词来修补这个问题。告诉大模型要「遵守 GDPR」，就像告诉 Excel 表格要「讲道德」一样。架构本身就从根本上排斥严格的数据边界。

构建有法律边界的智能体工作流

法律合规的工作流：n8n 拦截数据，通过 Claude 强制执行 JSON 架构，仅将非敏感变量传给 Xero。

一个有法律边界的智能体工作流，会将 AI 隔离在一个受限的沙盒中，强迫它只提取特定数据，而不给它执行动作的权力。

如果你想要智能体的高效，又不想陷入法律噩梦，你就得自己建这种工作流。我搭 these 系统时，绝不会把数据库的钥匙交给 AI。我会给它一个高度受限的沙盒。

举个处理供应商进项发票的例子：

Outlook 收到一封带 PDF 发票附件的邮件。不要把整个 PDF 喂给通用智能体，而是用 n8n 的 webhook 触发流程。n8n 先用确定性的 OCR 工具（而不是大模型）提取 PDF 文字。

然后调用 Claude API。这是关键：你不要让 Claude 去「处理」发票，而是使用严格的 JSON schema（模式）。

提示词要求 Claude 只提取三个字段：发票号、总金额、供应商名称。

提示词明确告诉 Claude 忽略所有其他文字。不要银行账号，不要个人姓名，不要邮箱地址。Claude 返回一个干净的 JSON 对象。接着 n8n 把这个 JSON 推送到 Xero 的草稿发票里。

这套设置在数据进入你的永久记录之前，就把个人隐私剥离了。AI 没权力给供应商发邮件，也没权力批准付款。它只负责提取三个有边界的字段。

搭这么一套系统大概需要 2-3 周。根据你现有集成的复杂程度和供应商数据的混乱程度，预算大概在 £6k 到 £12k 之间。

但你得为失败情况做打算。万一 Claude 幻觉出了一个错的发票号怎么办？

你在 n8n 里加一个确定性的校验步骤就能截住它。在推送到 Xero 之前，让 n8n 检查一下是否已经存在该供应商和该号码的发票。

如果金额超过 £5,000，n8n 就把 JSON 发到 Slack 频道，让运营经理手动审核。

Webhook 会解析 JSON。如果没通过 schema 校验，工作流会立即中断并提醒你的团队。

这才是交付能通过审计的真实系统的方法。用 AI 处理混乱的非结构化数据提取，用写死的、确定性的软件来处理逻辑和路由。AI 只是个齿轮，不是引擎。

通过在物理上隔离「提取」和「执行」，你就打破了法律责任幻觉。你对什么数据流向哪里拥有绝对的控制权。

当有边界的智能体撞墙时

当有边界的智能体被迫处理非结构化的陈旧格式，或需要做主观的政策决策时，它们就会撞墙。

这种方法处理现代的、数字化优先的数据效果极佳。但它不是万灵药。在开始构建之前，你需要审计你的输入源。

如果你的发票是老旧会计系统扫出来的 TIFF 图片，你得先做 OCR，错误率会从 1% 飙升到 12% 左右。大模型在识别模糊、手写或低分辨率文档方面表现很差。

如果你的供应链依赖手写的送货单，AI 智能体会为了填补空白而胡编乱造数据。你花在修错上的时间，比手动录入还要多。

另一个极端情况是嵌套或高度多变的数据结构。Zapier 的查找步骤（Find steps）没法嵌套，所以当你的 Xero 供应商有一个两层深的自定义联系人字段时，自动化会静默地写入空值（null），你可能到月底才会发现。

如果你的工作流需要 AI 做判断，那就别自动化。决定一个客户投诉该全额退款还是部分退款，这是一个政策决策。有边界的智能体是用来提取和格式化的，不是用来做决策的。

一旦你跨过了「自主决策」那条线，你的 GDPR 法律风险就会暴增。ICO 要求对影响个人的自动化决策采取严格的保护措施 [来源](https://www.navex.com/blog/article/ico-report-agentic-ai-opportunities-and-risks/)。如果你解释不清为什么智能体做了某个特定决定，你就不能部署它。没得商量。

现在该做什么

锁定你的 AI 风险敞口，需要审计你活跃的 API 连接，并对现有工作流强制执行严格的数据边界。

在你把下一个自动化智能体连到业务数据之前，先做这几件事：

1. 审计活跃的 API 连接。打开你的 Google Workspace 或 Microsoft 365 管理后台。看看哪些第三方应用有权读取你的公共邮箱。如果你看到一个三个月前试用过但早忘了的 AI 工具，立刻撤销它的访问权限。
2. 梳理数据路径。挑一个你最常用的、调用了 ChatGPT 的 Zapier 或 Make 工作流。追踪提示词里到底传了什么数据。如果你在传原始邮件正文，在调用 AI 之前加一个文本解析步骤，把手机号和地址剥离掉。
3. 切换到严格的 JSON 输出。如果你在用 Claude 或 OpenAI 的 API，更新你的提示词，要求必须符合 JSON schema。明确告诉模型允许返回哪些字段。如果它返回了别的东西，配置你的 webhook 直接丢弃该数据包。
4. 设置财务「断路器」。打开你的 n8n 或 Make 路由逻辑。加一条硬性规则：任何涉及超过 £500 交易的 AI 生成动作，必须路由到 Slack 频道进行人工审批。永远不要让智能体独自执行最后一步。