如何在 Data (Use and Access) Act 2025 框架下构建合规的 AI 工作流

你的运营经理正盯着 Xero 的屏幕。一张供应商发票刚刚自动入账、自动审批，并排队等待付款。全程没经过任何人的手。

六个月前，你可能会觉得这是个巨大的胜利。但现在，根据《2025 年数据（使用与访问）法案》（DUAA），这可能是一场迫在眉睫的合规灾难。

关于自动化决策的规则刚刚变了。你现在确实可以用 AI 来做决定，但你必须证明有「人在回路」（human in the loop）。

得是一个大活人，做出了真实的决策。而不是某个初级助理在下班前随手点一下「全部批准」。以下是你真正构建合规系统的方法。

「橡皮图章」的幻觉

所谓的「橡皮图章」幻觉，就是误以为只要让人在 AI 生成的结果上点个「批准」，就满足了法律对「有意义的人工干预」的要求。现在这种现象在英国企业里随处可见。系统标记了一笔交易，人点一下 OK，公司就觉得自己合规了。

DUAA 2025 全面放宽了对自动化决策的限制，但这种自由是建立在严格的算法透明度要求之上的 [来源](https://www.comparethecloud.net/articles/uk-ai-ethics-and-governance-framework-2025-comprehensive-guide-for-british-businesses/)。你不再需要为每一个自动化选择都征得明确同意，这为中小企业释放了巨大的运营空间。

但这种自由伴随着严格的保障措施。你必须提供一条真正的人工审查路径，而且你的治理框架必须足够严密，能证明这一点 [来源](https://www.dpocentre.com/data-protection-ai-governance-2025-2026/)。人不能只是一个被动的观察者，他们必须有权力和足够的上下文信息来改变结果。

这就是幻觉产生的地方。SaaS 厂商把「人在回路」当成一个简单的勾选项来卖。你买了个工具，它把一个客户申请标记为高风险，你的财务助理看了看标记，觉得 AI 肯定比自己懂，于是点了确认。

信息专员办公室（ICO）把这叫做「自动化偏见」。当审计找上门时，你的系统日志显示一个人在 12 分钟内处理了 400 项审批。那不叫监督，那叫盖橡皮图章。它只能证明人当时在场，但没法证明人动了脑子。

如果客户根据新规对自动化拒绝提出异议，你必须证明为什么要这么决定。一份显示「盲目批准」的日志保不了你。你需要一个能强迫人类去思考的系统。

为什么 Zapier 的延迟步骤没用

Zapier 的延迟步骤之所以行不通，是因为它记录的只是一个二元化的按钮点击，而不是合规所需的实际人类推理过程。

大多数中小企业试图用这种简单的自动化补丁来解决监督问题。他们建立一个由 Outlook 新邮件触发的工作流，动作是一个 ChatGPT 提示词，用来提取数据并判断退款是否有效。

为了加入要求的人工监督，他们插入了一个带有「点击批准」按钮的 Slack 消息步骤。这看起来是个完美的方案：AI 干重活，人做最后定夺。

但加个 Slack 按钮并不等于人工监督，它只会制造「告警疲劳」。实际操作中是这样的：

Zapier 的 webhook 触发了，Slack 频道响了。头两天，你的团队还会仔细看 JSON 负载。到了第三天，运营经理忙得不可开交，看到绿按钮就点。Zapier 继续运行。

这里的工具行为是纯粹二元的。Slack 集成只向工作流传回「真」或「假」的状态。它不记录推理过程，不记录人类提供的上下文。Webhook 仅仅记录了按钮被按下了。

如果你面临合规检查，你的审计追踪只会显示「14:02 点击了 Slack 按钮」。这过不了 DUAA 关于「有意义干预」的测试。你证明不了审查员看过原始数据。

根据我的经验，大多数尝试这种方法的中小企业都会撞上同一堵墙。系统会悄无声息地从「人工监督」退化为「肌肉记忆」。技术运行得天衣无缝，但运营设计却让员工注定失败。你必须设计一个让「无脑点击」在物理上行不通的工作流。

构建「强制上下文网关」

强制上下文网关：必须手动校验数据并选择推理逻辑，才能解锁提交按钮。

所谓「强制上下文网关」，就是一个内部仪表盘，它会强行中断自动化工作流，直到人工审查员输入特定的、有记录的决策理由。你需要一个要求员工参与、而不仅仅是扫一眼的界面。

举个实际的例子：一份供应商合同续约邮件发到了 Gmail 公用邮箱。你希望 AI 阅读它，标记涨价情况，并排队等待审批。

首先，一个 n8n webhook 触发 Claude API 调用。你使用严格的 JSON schema 强迫 Claude 提取续约条款、涨价百分比和终止条款。

关键点在于：n8n 不会直接把这些发给 Xero 或 Slack。它把结构化数据推送到 Supabase PostgreSQL 数据库。自动化到此停止。AI 做了建议，但它没有执行权。

接着，你搭一个简单的 Retool 仪表盘。这是你的运营经理登录的地方。当他们打开仪表盘时，看到的不是一个简单的「批准」按钮，而是 AI 提取的数据和原始 PDF 并排摆在一起。

界面强迫他们采取行动。要批准续约，他们必须从下拉菜单中选择一个特定的理由。如果拒绝，他们必须打一小段字解释原因。在提供这些上下文之前，「提交」按钮是禁用的。

这样一个系统大概需要 2-3 周的开发时间。根据你现有集成的混乱程度，预计支出在 £6k 到 £12k 之间。

这里最常见的失败模式是 AI 对不存在的条款产生「幻觉」。因为 Retool 仪表盘并排显示了源文件和提取的 JSON，人一眼就能发现错误。他们在 Retool 里修正字段，干净的数据才会继续流转。

数据库会记录确切的用户 ID、时间戳、原始 AI 建议以及人工输入的理由。当监管机构索要合规日志时，你只需导出 Supabase 表格。它能清楚地显示是谁做的决定，以及为什么这么做。

你从数学上证明了你的公司不存在「橡皮图章」幻觉。人掌握着绝对的控制权。

强制上下文网关在什么时候会失效

如果你的输入数据被困在老旧格式里，迫使人工审查员去纠正原始文本而不是评估业务逻辑，那么强制上下文网关就会失效。这种方法对干净的数据很有效，但不是万灵药。在开始构建之前，你需要检查你的数据质量。

如果你的供应商发票是来自老旧会计平台的扫描版 TIFF 文件，你得先加一层 OCR。一旦在 LLM 之前加入 OCR，错误率会从 1% 飙升到 12% 左右。

当错误率这么高时，人工审查员就不再是在审查决策了。他们最后变成了在纠正原始文本。仪表盘变成了数据录入屏幕。监督流程会崩溃，因为人忙着改错别字，根本没心思思考实际的业务逻辑。

你还需要检查你的交易量。如果你每天处理 50 个决策，Retool 仪表盘非常完美。如果你每天处理 5,000 个，你的人工审查员不出一周就会崩溃。

在这种规模下，你需要对风险进行分层。低价值的决策应该自动通过——前提是它们不会触发 DUAA 中关于「重大影响」的规则。然后你配置数据库，只把超过 £5,000 的交易路由到人工网关。

这样可以保持人工工作量在可控范围内，并确保他们的注意力集中在合规风险最高的地方。

要避免的三个错误

应对新的 AI 治理规则需要自律。在构建监督工作流时，请记住这些坑：

1. 不要依赖 SaaS 原生的审计日志。 大多数现成工具记录的是结果，而不是过程。它们记录了一张发票被批准了，但不会记录当时人眼在屏幕上到底看到了什么。如果平台更新了界面，你就失去了历史上下文。你需要记录人在做选择那一刻数据的确切状态。把日志存在你自己的数据库里。
2. 不要让 AI 直接写最终的拒绝邮件。 如果你的系统拒绝了一个客户申请，AI 应该起草理由供人工审查。在没有人工检查的情况下，绝对不要通过 Gmail API 发送消息。如果 LLM 对拒绝理由产生了歧视性的幻觉，你就制造了一个巨大的法律责任。最终的对外沟通必须由人来把关。
3. 不要对审查员隐藏源数据。 如果审查员只看到 AI 的摘要，他们就无法验证 AI 的决策。如果系统标记某个合同条款有风险，审查员必须能读到原始段落。如果强迫他们打开另一个系统去找源文件，我保证他们会跳过检查。把原始文本和 AI 输出放在同一个屏幕上。