审计人员不读代码，只追溯一个 AI 决策

设想这样一个场景：距离上线还有两周，你为一家银行搭建的贷款申请评估辅助 AI 系统在预发环境运行顺利。这时内部审计发来一封邮件，想了解系统是怎么测试的、由谁监督、日志存放在哪里。

很多前线部署工程师（FDE）把这封邮件当成文书工作，转给客户的合规团队，然后回去写代码。这是个错误。对受监管行业的 AI 系统来说，所需的审计证据大多只有构建系统的人才能拿出来，而等问题来了再准备，就已经晚了。

本指南介绍如何把审计人员的问题当作一份技术规格来读。从一开始就按这些问题来设计，审计会议上只需打开对应的文档；拖到最后一刻，证据里的每个缺口都可能让上线日期往后推。

审计人员沿着线索走，不读代码

想准备充分，先要弄清提问者用的是什么视角。国际内部审计师协会（IIA）有一套 AI 审计框架（AI Auditing Framework），协会将其描述为面向内部审计人员的实用指南，涵盖 AI 的治理、管理和审计。

这套框架以三道防线模型（Three Lines Model）为基础，所以第一个问题通常是：每道防线上由谁负责这个系统——先是业务部门，然后是风险管理与合规，最后是审计。

他们的工作方法同样具体。ISMS.online 的一份 ISO 42001 审计清单建议，抽查范围内的两个 AI 系统，跟踪每个系统的影响评估从起草到审批的全过程，以及每一项已关闭的纠正措施。

审计人员不会什么都看。他们挑出一根线头，然后往外拉。

他们期望看到的证据，大部分由系统自身生成。同一份清单列出了访问日志、监控输出、模型性能仪表盘、漂移告警和事件工单。这些都在你的工作范围之内。

法律对日志和文档有什么要求？

如果系统在欧盟 AI 法案（EU AI Act）下属于高风险系统，部分问题已经由法律定好。第 12 条要求高风险系统在技术上支持在整个生命周期内自动记录事件。

这些日志必须服务于三个目的：识别风险情形、上市后监测和运行监控。

第 26 条规定了部署方（也就是你的客户）的义务。在日志处于其控制范围内的前提下，部署方必须保存系统自动生成的日志至少六个月，除非其他法律另有规定。

部署方还必须把人工监督交给具备必要能力、培训和权限的人员。

“处于其控制范围内”这几个字，正是 FDE 需要留意的地方。如果日志只存在供应商的云账号里，客户就无法保存。

第 11 条还要求技术文档在系统投入使用前编制完成，并保持更新。根据该法的概要页面，附件 III 系统的适用日期为 2027 年 12 月 2 日，附件 I 系统为 2028 年 8 月 2 日。

在欧洲以外，NIST AI RMF Playbook 是常用的参考。NIST 明确表示，该框架和 Playbook 都是自愿采用的，因此应把它当作一份可供挑选的证据菜单，而不是强制清单。

对照表：每个问题都有对应的证据

能带进会议室的最有用的工具，是一张表：把每个审计问题对应到具体的证据、存放位置和负责人。

审计问题	证据	存放位置	负责人
系统是怎么测试的？	用于测试、评估、验证和确认（TEVV，参见 NIST MEASURE 2.1）的测试集、指标和工具	项目文档仓库，与每次发布绑定	FDE、工程团队
上线后如何监控质量？	性能仪表盘、阈值和漂移告警	客户基础设施上的监控系统	FDE 交付，客户运维接手
系统不应在哪些场景使用？	“已知局限”章节，写明系统未经测试的条件	技术文档，按版本更新	FDE 撰写，业务方签字确认
由谁监督，权限是否足够？	审核人名单、培训记录、推翻决策的权限	客户的人事和培训记录	客户第一道防线
决策能否追溯？	与事件工单关联的事件日志	客户的日志基础设施，保存至少六个月	FDE 设计，客户保存

第一行和第三行来自 NIST Playbook：MEASURE 职能要求记录测试集、指标和工具，以及系统在开发条件之外使用时的局限。第二行把 NIST 关于部署后如何监控准确率等指标的问题，与 ISO 42001 清单中列出的仪表盘和漂移告警结合在一起。

追溯一个决策

回到那家银行。审计人员挑出一份申请，系统对它给出的建议是“转交核保人员复核”，然后问为什么。只有日志记录大致长成下面这样，你才答得上来：

{
  "event_id": "evt_000123",
  "system": "credit-assist",
  "model_version": "credit-assist-v1.4",
  "prompt_template": "tpl-appraisal-v3",
  "eval_suite": "eval-v7",
  "input_ref": "application/8812",
  "output": { "recommendation": "refer", "score": 0.62 },
  "reviewer_id": "u_lan",
  "reviewer_action": "override_approve",
  "reason_code": "income_verified"
}

通过 model_version 和 eval_suite，你可以打开 eval-v7 报告，说明这个版本通过了哪些测试、达到了什么指标。

通过 reviewer_id，客户可以说明审核人是谁、接受过什么培训。input_ref 只是指向申请的指针，日志里并没有复制个人数据，因此日志可以长期保存，而不会变成第二个敏感数据存储。

现在设想这条记录缺了 eval_suite。你知道跑的是哪个模型，却无法证明它通过了哪些测试，链条在第二步就断了。审计人员记下一项发现，上线要等到这项发现关闭之后。

在别人问起之前，先做好五件事

第一，在需求调研周就问客户：每道防线上由谁负责这个系统。这个问题常常会暴露出根本没人被指派负责监督。第一周发现，还有时间补救；最后一周发现，它就成了进度延误的原因。

第二，在写第一个接口之前设计好日志模式，让每个决策都带上模型版本、提示词版本、评测套件和审核人。把日志发送到客户的基础设施上，让他们能保存至少六个月。第三，把评测套件当作有版本、与每次发布绑定的制品，而不是跑一次就丢下的 notebook。

第四，用业务语言写出已知局限，例如“未在企业申请上测试，仅在个人申请上测试”。最后，在正式会议之前，自己先扮演一次审计人员：随机挑两个决策，按照上面的表格逐步往回追溯。

通常在哪里出问题

一种常见的问题是：幻灯片上有一个准确率数字，背后却没有测试集或工具支撑，谁都复现不出来。

另一种是：仪表盘有了，却没有告警阈值，也没有任何工单能证明告警曾被处理过。

更隐蔽的一种，是把 NIST Playbook 当成清单，试图填满每一项。结果是一大摞文档，彼此之间没有线索相连。审计人员需要的文档更少，但每一份都要能从头追到尾。

把这项技能变成职业优势

如果一份 FDE 招聘启事提到金融、医疗、保险或“受监管行业”，你很可能要和内部审计打交道。去面试之前，先把追溯一个决策的练习做熟。

简历上不要只写“部署过 AI 系统”。要写明你设计了可追溯的日志和审计证据包，让系统在上线前通过了内部审计。

面试时，说清楚一条日志记录需要哪些字段、每个字段为什么存在，而不是泛泛地谈“合规”。

对这类客户来说，系统运行正确还不足以上线。你还要向那些永远不会读代码的人证明这一点，这同样是交付的一部分。