EU AI Act 审计准备：你的 AI 运行时能交出证据吗

先给结论：审计查的不是你的模型，而是你的运行时能否为每个 AI 动作交出“谁授权、动了什么、证据在哪”——而可审计性补不上，只能在动作发生时就记下。

设想一个会议室。

一家在欧洲展业的保险公司，请了外部审计做 AI Act 的合规预演。审计员坐下，打开电脑，没有寒暄，问了第一个问题：

“把上个月那笔被 AI 自动标记为’高欺诈风险’、因而被拒赔的理赔，完整经过调出来给我看——谁触发的、AI 依据哪些数据、用了哪条规则、谁复核了、客户申诉走了什么流程。”

然后房间安静了。

不是因为这笔拒赔一定错了，而是因为这笔决定里 AI 参与的那一段，在系统里没有一个完整、连续、不可抵赖的地方能调出来。理赔数据在一个系统，AI 的打分服务在另一个，复核记录在第三个，而且和人工操作不在一本账上。要拼出审计员要的那条线，得三个团队翻三天日志，还不保证拼得齐。

这家公司当时没被罚——那只是预演。但 AI Act 对高风险 AI 系统的罚则，是按全球营业额的百分比计的，量级足以让任何一家公司认真对待。而预演暴露的问题，是几周后真审计会原样再问一遍的。

这个安静的会议室，就是很多企业在 AI 治理审计中会面对的场景。

倒计时是真的，而且很近

按欧盟官方时间线，AI Act 于 2024 年 8 月 1 日生效，多数规则将在 2026 年 8 月 2 日开始适用；部分义务按系统类型和条款分阶段推进。对在欧洲有业务、或服务欧洲客户的企业，关键不是背日期，而是先问：如果今天抽查一笔 AI 参与的业务动作，你能不能把证据链当场调出来？

很多团队不是不想合规，而是真到那个会议室里，答不上来。

审计查的不是模型，是运行时

很多团队为合规做的第一件事是评估模型——有没有认证、会不会输出有害内容。这些重要，但不是审计的主战场。监管真正要的，是你能否为每一次 AI 触碰业务的动作说清三件事：

审计员会问	它在查什么	答不上来的后果
这些数据处理得合法吗？	数据在哪、谁能读、有没有出过欧盟	数据驻留违规，CLOUD Act 暴露
这个动作谁授权 AI 做的？	拒赔、放款这类动作按谁的权限算	责任无法归属，动作不可控
AI 参与的那步留痕了吗？	能否拿出完整、不可抵赖的证据链	审计直接失败

没有一个问题是关于模型的。它们全都关于模型之外那一层——承载数据、强制权限、记录证据的运行时。

AI Act 对”高风险系统”到底要什么

这不是抽象的”要合规”。AI Act 对高风险 AI 系统（理赔、信贷、招聘、关键基础设施这类）点名列了几项硬义务，值得一条条对照——因为它们几乎全部落在运行时，不在模型：

AI Act 的要求	落在哪一层	模型能提供吗
自动记录事件日志（可追溯）	运行时的审计账	不能，模型不留痕
人类监督（关键决策可介入、可推翻）	运行时的审批与流程	不能，要靠流程强制
决策可解释（依据了什么）	运行时记录的输入与规则	部分，但不可抵赖的记录在运行时
数据治理（来源、权限、驻留）	运行时的权限与部署	不能

你会发现，模型再强，这张表它一栏都打不了勾。这正是那么多团队”模型选得很认真、合规却过不了”的根因——他们在错的那一层用功。监管要的东西，结构性地长在运行时上。

买个合规工具不就行了？

最自然的反应是：市面上有一堆”AI Act 合规平台”，供应商也都在宣传自己合规，签个 DPA、拿份认证，不就把这事外包了？

这条路能解决一部分，但解决不了那个会议室里的问题。

合规工具和认证做的是记录与背书：它告诉监管”我们有流程、有文档、有数据处理协议”。但审计员要的不是”你有没有流程”，是”把这一笔的完整经过调出来”。文档证明不了某一次具体动作的合法性，DPA 也回答不了’这笔拒赔是 AI 依据哪条权限做的、谁复核的’。 这类证据只能由真正执行那个动作的运行时，在动作发生的当下记下来。买工具能帮你管住”制度层”，管不住”动作层”——而审计追到最后，问的总是某一个具体动作。

可审计性，是补不上的

这就引出一个很多人没意识到的硬道理：合规不是一份你在 Q3 赶出来的文档，而是一个系统要么具备、要么不具备的属性。

那条审计员想要的证据链，必须在动作发生的那一刻就被记下来。如果运行时当时没记，8 月之前再怎么突击，也变不出上个月那笔拒赔的真实经过——你只能”重建”，而重建出来的记录，审计员一眼就知道不能采信。

这就是为什么”先上 AI、合规以后再说”在 2026 年是个危险赌注：你赌的是审计不会问到那些当时没记的动作。一旦问到，那段时间的所有 AI 决策就成了一片无法举证的空白。

去审计室之前，先用这五个问题自查——任何一个答不出”是”，那一项就是你的风险点：

随便挑一笔 AI 参与的业务动作，能不能当场调出它的完整经过？
权限是运行时强制的，还是写在提示词里的？
人和 agent 的动作，是不是记在同一本审计账上？
这些数据和处理过程，落在谁的管辖权之下？
出了问题，能不能一键停下某个 agent 或某类动作？

为什么”把规则写进提示词”过不了这一关

不少团队其实做了治理，只是做错了地方——写进了提示词。“你只能查当前用户有权限的数据""高风险理赔要人工复核”，平时看着也管用。但它过不了审计，两条原因都致命：

第一，提示词是建议，不是控制。 它靠模型”愿意听话”生效，一次越狱、一个没覆盖的边界就被绕过。审计员问”你怎么保证某类理赔一定经过人工复核”，“我们在提示词里写了”不是能签字的答案。

第二，提示词不产生记录。 审计要的是结构化、不可抵赖的证据，提示词给不了。

合规真正要求的，是把治理从”提示词里的建议”挪到”执行引擎里的强制”——权限在每次读写时被运行时核验，审计是动作的天然副产品。

CADA 之后，“数据在哪”成了硬指标——但自托管不是免罪符

欧盟围绕云、AI 和数据主权的讨论，把另一件事推到台前：你的数据和 AI 处理过程，究竟在谁的管辖权之下？这一问直接指向部署形态。把读取真实业务数据的 AI 运行时交给一个你无法审视内部的外部 SaaS，合规签字会变得更难。自托管能改善数据驻留、第三方暴露和可见性——要自托管的不一定是模型，而是承载对象、权限、工具、审批和审计证据的那个运行时。

但要诚实地说一句：自托管不是免罪符，它是一笔交易。 当运行时跑在你自己的基础设施上，打补丁、轮换密钥、保证日志不丢、出事一键熔断——这些操作和举证责任，也一起落到你头上。你换来的是控制权，代价是责任。反过来，若你希望让别人替你担这份责任，通常意味着把数据也交给他。这笔账没有白拿的一边，得看哪边的代价你担得起、签得了字。

一个能被签字的运行时，长什么样

把上面的要求倒过来，就是验收清单。最直接的检验，不是看产品介绍，是看它能不能当场吐出审计员要的那条记录。在 ObjectOS 上，开头那笔拒赔调出来是这样一条：

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → 必须人工复核", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

这条记录里，谁、做了什么、AI 依据什么、命中哪条权限、谁复核的、何时——全在。它不是事后补的工程，是 agent 以受监督身份调用受治理工具时，运行时顺手落下的一笔。人和 agent 走同一套权限引擎、记同一本账。业务定义（对象、权限、复核流程）则是你仓库里可 diff、可追溯的元数据——审计员问”哪类理赔必须人工复核”，答案不在某人脑子里，在流程定义里写着。

结语

离 2026 年 8 月 2 日已经很近。回到那个会议室：如果审计员现在就坐下，问你要上个月某笔 AI 决策的完整经过，你的系统能不能在那一刻、不靠三个团队翻三天日志，把它吐出来？

答不上来，几乎从不是因为模型不行，而是因为治理被放错了层——放进了提示词、外包给了制度文档，而不是落进运行时。把它挪回运行时，那条证据链才会在你需要之前就已经在那里。这件事补不上，只能现在就让它成立。

npm i -g @objectstack/cli && os start

让一个 agent 以某个用户的身份去改一条数据，然后翻开审计记录——你会看到审计员想要的那条线，本来就在。