1. 课程导入
在开始学习具体方法之前，需要先建立一个清晰的认识：AI合规与风险审计工程不是“读法规、写报告”的文书工作，而是一项把法律要求、技术事实与审计证据连接起来的工程活动。它的核心难点在于——法规条文描述的是“应当满足什么”，而AI系统运行的是“参数、数据、模型、接口、日志”，两者之间存在一条需要被工程化填补的鸿沟。
一、定义：把合规要求翻译成可验证的工程对象
AI合规与风险审计工程，是指围绕人工智能系统的全生命周期，将外部法规、标准与内部治理要求，转化为可识别、可度量、可取证、可复核的技术控制与审计流程的工程实践。它包含三个不可分割的层面：
- 合规层：确定适用义务，例如透明度告知、人工监督、数据最小化、风险评估与记录留存。
- 风险层：识别AI特有风险，如偏见放大、幻觉输出、提示注入、模型漂移、供应链依赖。
- 审计层：用证据回答“控制是否存在、是否运行、是否有效”，并形成可追溯的结论。
三者关系可以概括为：合规给出“应然”，风险给出“可能出错的地方”，审计给出“实际是否做到”的证据链。缺少任何一层，合规就会退化为口号，审计就会退化为形式检查。
二、边界：哪些属于本课程，哪些不属于
明确边界能避免学习目标发散。本课程聚焦于“可工程化、可审计”的部分：控制项设计、证据采集、测试方法、指标与阈值、审计底稿与结论。以下内容属于相邻领域，本课程只做必要衔接，不深入展开：纯法律解释与诉讼策略、模型算法本身的学术创新、IT基础设施的通用运维、以及不涉及AI特性的传统财务审计程序。
一个实用的边界判断标准是：如果一项工作最终能落到“某个控制点 + 某类证据 + 某个判定规则”，它就属于本课程范围；如果只能停留在原则宣示，则不属于。
三、核心术语：先统一语言，再谈方法
AI合规审计中最常见的沟通障碍，是同一词汇在不同角色口中含义不同。以下术语需要在课程开始时统一：
| 术语 | 工程含义 | 常见误区 |
|---|---|---|
| 控制点 | 可被设计、执行和测试的具体措施，如“输出附带AI生成标识” | 把“遵守法规”当成控制点 |
| 证据 | 能独立支撑结论的客观材料，如日志、配置快照、测试记录 | 把口头说明当证据 |
| 风险 | 不确定事件及其影响，需有触发条件与后果描述 | 把风险写成“存在合规风险” |
| 阈值 | 判定是否触发处置的量化边界，如偏见差异>10% | 只设指标不设阈值 |
| 可追溯性 | 从输出能回溯到模型版本、数据版本与决策路径 | 只保留最终结果 |
四、学习地图：从要求到证据的六段链路
本课程后续章节将沿着一条主线展开：法规与标准 → 风险识别 → 控制设计 → 证据采集 → 测试与判定 → 审计结论与整改。这条链路不是线性流程，而是一个可迭代的闭环。下面的SVG展示了这条主线的结构关系，以及每一段的核心输入与输出。
五、工程化思维：把“合规”变成可运行的系统
工程化思维的核心是四个可操作原则。第一，可编号：每个控制点应有唯一标识，例如“CTL-TRANS-001 输出标识控制”，便于在测试、证据和整改之间建立引用关系。第二，可度量：把“应当透明”转化为“输出中AI标识覆盖率≥99%”这类可统计指标。第三，可取证：在设计控制时就同步设计证据形式，而不是事后补材料。第四，可迭代：审计结论必须回写到风险登记册和控制矩阵，形成闭环。
举一个教学示例（以下参数为合理假设，用于说明方法，非实测结果）：某客服AI系统需要满足“用户应被告知正在与AI交互”的要求。工程化做法是：控制点编号CTL-TRANS-001，控制描述为“会话首条回复包含AI身份声明”，证据形式为“会话日志中首条消息文本快照”，测试方法为“随机抽取200条会话，检查首条消息是否包含声明关键词”，判定阈值为“覆盖率≥99%，且无遗漏场景”。若测试结果为197/200，覆盖率98.5%，则触发偏差处置：分析3条遗漏是否集中在特定入口，并决定是修复代码还是调整抽样范围。这个过程就是本课程要反复训练的基本功。
接下来的章节将沿着上述六段链路逐一展开，每一段都会给出可操作的方法、示例参数与判定依据。你需要带着一个具体系统或场景进入学习，边学边把控制点、证据和阈值填进自己的审计框架中，这样才能真正把知识转化为可执行的工程能力。