别掉进 AI Agent 编排里的 Article 22 陷阱

你在 Make 里拉了一个 OpenAI 的 API 节点。你把它对准了客户服务的收件箱。你告诉它去读取发进来的退款申请，去 Stripe 查一下交易记录，如果金额在 £50 以下，就直接退款。

跑起来简直完美。工单全消失了。你的运营经理再也不用每天花三个小时在那儿点“批准”了。你觉得自己终于搞出了一个“无人驾驶”的公司。

然后，有个客户投诉说他们因为邮编原因被拒绝退款了。你查了下日志。那个大语言模型（LLM）凭空捏造了一条政策。你在没有任何人工干预的情况下，做了一个自动化的决定。

英国信息专员办公室（ICO）管这叫违反英国 GDPR。你管这叫运营事故。你们都没说错。

第 22 条陷阱

所谓“第 22 条陷阱”，是指当 AI 智能体在没有经过实质性人工审查的情况下，对个人做出最终决定时，你所触发的法律责任。

根据英国 GDPR，如果一个决定仅仅基于自动化处理，且产生了法律效力或类似的重大影响，个人有权不受该决定的约束。以前 AI 只是写写营销文案，避开这条很容易。但现在有了智能体（Agentic AI），界限变得模糊了。

你把 Claude 连到了你的 Pipedrive CRM 上。你让它给进来的潜在客户打分，并自动给那些不合适的客户发拒绝邮件。得，你刚亲手搭了一个自动化决策引擎。

ICO 最近调查了招聘领域的 AI 使用情况，发现问题一大堆。他们的成果报告强调，很多系统根本没提供实质性的人工监督。ICO 才不在乎你的提示词工程（Prompt Engineering）玩得有多溜。他们在乎的是控制权在哪儿。

如果一个系统刷掉了一个应聘者，或者拒绝了一项服务，法律要求必须有人对这个结果产生实际影响。这意味着，必须有一个人拥有权限和背景信息去推翻机器的决定。

这可不是大企业才要担心的假设性风险。一家用 AI 筛选司机申请的 30 人物流公司，或者一家根据用户习惯自动封禁账号的 SaaS 公司，全都适用。

正如 Kaizen AI 所指出的，建立信任需要的是主动治理，而不是买个工具然后求神拜佛。你需要一套能证明“有人参与其中”的系统。

如果你的系统在没有人工明确说“行”的情况下就执行了最后一步，你就暴露在风险中了。第 22 条陷阱专抓那些把运营速度误认为是法律合规的创始人。

为什么“仅通知”的工作流行不通

“仅通知”的工作流之所以失败，是因为在 AI 智能体采取行动后发一条 Slack 消息，那叫“知情”，不叫“监督”。

大多数中小企业试图通过增加一个通知步骤来解决监督问题。他们用 Zapier 搭了一个流：让 ChatGPT 评估供应商申请，在 HubSpot 里更新状态，然后发送拒绝邮件。最后他们加了一步：往 Slack 的运营频道发条消息，说这个供应商被拒了。

他们觉得这就算万无一失了。其实压根不是。

这是一个虚假的安全网。ICO 不在乎你是否“知道”这个决定发生了。他们在乎的是你是否“授权”了它。

问题的核心在于 API 调用的顺序。在标准的 Zapier 设置中，动作节点在人看到任何东西之前就已经执行了。等你运营经理读到那条 Slack 消息时，邮件早就躺在申请人的收件箱里了。自动化决策已经做完了。Webhook 已经触发了。烂摊子已经造成了。

我在运营审计中经常看到这种情况。创始人觉得既然有 AI 操作日志，自己就是合规的。但日志只是你违规的收据。你这是在后视镜里看车祸。

现在的流行建议是让 AI 自主运行以节省时间。供应商也怂恿你把人彻底踢出去。但当涉及个人权利时，法律限制的恰恰就是这种“自主性”。你没法用一个只读的 Slack 提醒来修补结构性的法律要求。

如果 AI 正在做一个会影响到人的决定，工作流必须停下来。必须等。通知不等于授权。

强制性的“人机协作”架构

用两阶段 webhook 替代线性自动化，给工作流加个物理暂停，让你成为最后一道人工断路器。

强制性的“人机协作”（Human-in-the-loop）架构会在执行最终动作之前暂停自动化流程，强迫人工明确批准或拒绝 AI 的建议。

在招聘筛选流程中，这事儿实际操作起来是这样的：应聘者通过网页表单提交简历。Webhook 传给 n8n。n8n 把 PDF 传给 Claude API，并带上严格的 JSON 模式，要求它提取五项特定技能并给应聘者打分（满分 10 分）。

普通的做法到这就跑偏了：直接把 Claude 的输出对接 Gmail 节点发拒绝信。它假设 AI 永远是对的。

正确的做法是，n8n 把应聘者详情、AI 评分和一段简短的理由说明更新到 Airtable 数据库里。然后，n8n 调用 Slack API 向你的 HR 频道发送一条交互式消息。消息里包含摘要和两个按钮：一个写着“批准面试”，另一个写着“拒绝”。

工作流停止。等待。在人工干预之前，它什么都不干。

当你的 HR 经理点击“拒绝”时，Slack 会把数据发回给第二个 n8n Webhook。第二个工作流找到对应的 Airtable 记录，标记为“人工已审”，最后才触发 Gmail 节点发送拒绝邮件。

人就是那个断路器。AI 扮演的是一个速度极快的初级分析师，负责整理文件并给出建议。人来做决定。

搭这么一套东西大概需要两到三周。根据你现有的应聘者跟踪系统有多乱，预算大概在 £6,000 到 £12,000 之间。

这里最常见的失败模式是“按钮疲劳”。如果你每天发 400 条 Slack 提醒，你的员工看都不看就会开始点“批准”。你可以通过追踪 Slack 消息到达和点击按钮之间的时间来发现这个问题。如果他们在 3 秒内就点了批准，那你这儿根本没有实质性的人工监督。你这叫条件反射。

解决按钮疲劳的方法是批量审批。n8n 不再发实时提醒，而是在 Notion 里汇总一份每日简报。运营经理在下午 3 点查看表格，勾选每一行，然后定时任务会处理所有已批准的动作。

断路器失效的情况

当你把“人机协作”工作流用在高频、低影响的决策上，导致员工不堪重负时，断路器就失效了。

如果你每天收到 2,000 个基础的客服咨询，强迫人工去点每一个 AI 草拟的回信，那你的服务水平协议（SLA）就完蛋了。你的团队会淹没在 Slack 通知里。你最后等于花了一份全职薪水雇人去点个按钮。

你需要根据风险对决策进行分类。法律适用于具有法律效力或类似重大影响的决定。拒绝退款、刷掉应聘者或取消合同都属于这一类。但回答一个关于营业时间的问题就不算。

在你搭交互式审批流之前，先审计一下这个动作的影响。如果 AI 只是在 Outlook 里给邮件打个标签，或者在 Zendesk 里把工单分派给正确的部门，那就让它自动跑。如果它改变了商业关系，或者拒绝了某人的服务，你就得设个暂停键。

如果底层数据是一堆垃圾，也别费劲搭什么暂停机制。如果你供应商传进来的数据是老旧财务软件扫出来的 TIFF 图片，你得先搞定 OCR。错误率会从 1% 飙升到 12%。你的人工审核员花在修复 AI 提取错误上的时间，比他们手动干活的时间还多。在搭审批层之前，先解决数据录入问题。烂数据进快管道，只会让你错得更快。

留给你的三个问题

1. 当你的 AI 工具做出影响客户或应聘者的选择时，是有人在执行前主动批准，还是在执行后才收到个通知？
2. 如果英国信息专员办公室要求你证明自动化拒绝经过了实质性的人工监督，你能拿出一份带时间戳的人工审批审计日志吗？
3. 你的员工是不是因为提醒太多，就在那儿盲目点击 AI 建议的“批准”，把你的“人机协作”变成了一个走形式的橡皮图章？