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

> 一条日志若无法把审计人员引向测试集、人工审核人和漂移告警，上线日期就会推迟。

原文: https://fdetimes.net/zh/guides/audit-evidence-trace-ai-decision/

设想这样一个场景：距离上线还有两周，你为一家银行搭建的贷款申请评估辅助 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 清单中列出的仪表盘和漂移告警结合在一起。

## 追溯一个决策

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

```json
{
  "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 系统”。要写明你设计了可追溯的日志和审计证据包，让系统在上线前通过了内部审计。

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

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

**本周动手试试:**

- 从你正在做的系统中挑一个真实决策，计时看看找到它的模型版本、评测套件和审核人需要多久。
- 为当前项目填写“审计问题 → 证据 → 存放位置 → 负责人”表格，把每个空格标成红色。
- 为你的系统写半页“已知局限”，发给客户方的业务负责人阅读。

## 信源

- [Article 12: Record-keeping | AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12)

- [Article 26: Obligations of deployers of high-risk AI systems | AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26)

- [Article 11: Technical Documentation](https://artificialintelligenceact.eu/article/11/)

- [The IIA's Artificial Intelligence Auditing Framework](https://www.theiia.org/en/content/tools/professional/2023/the-iias-updated-ai-auditing-framework/)

- [Measure - AIRC (NIST AI Resource Center)](https://airc.nist.gov/airmf-resources/playbook/measure/)

- [NIST AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook)

- [AI Audit Checklist: A Practical Guide to Auditing AI Systems (ISMS.online)](https://www.isms.online/iso-42001/ai-audit-checklist/)