AI 审计证据链、可解释追责与责任边界全景图

从一次请求、一条工具动作、一次发布和一次事故里保留足够证据，让 AI 系统可复现、可归因、可追责、可改进

阅读定位: 这一页不是泛泛讲合规，也不是替代 LLMOps、发布闸门、灰度回滚、事故响应或权限边界。它专门回答一个生产问题：当用户、老板、安全、法务或事故复盘问“这个 AI 为什么这样回答、为什么能执行这个动作、谁批准了、能不能复现、下一版怎么防住”时，系统是否留下了完整证据链。字段总表回读 AI 证据包索引，单次请求排障回读请求 Trace / 排障模板。

一、审计证据链的主链路

请求身份
用户 / 租户 / 权限

→

上下文证据
Prompt / RAG / Memory

→

模型决策
Model / Route / Decode

→

工具与动作
Tool / HITL / State

→

输出与影响
Answer / Side Effect

→

评测与发布
Eval / Gate / Canary

→

复盘改进
Incident / Feedback

证据段	必须能回答的问题	最小字段	缺失后果
请求身份	谁以什么角色发起，属于哪个租户和功能入口？	request_id、tenant、user_id / role、feature、region、permission snapshot	无法判断越权、成本归属和合规范围
上下文证据	模型当时看到了哪些系统指令、历史、检索片段和记忆？	prompt_version、messages hash、retrieved_doc_id、chunk_id、memory_id、context size	无法复现幻觉、引用错误、隐私泄露和上下文污染
模型决策	为什么选这个模型、路由和解码配置？	model_id、router_policy、fallback_reason、temperature、max_tokens、seed / deterministic flag	质量、成本、延迟变化无法归因
工具与动作	模型提出什么动作，系统如何校验、谁批准、是否真的执行？	tool_name、args、schema_version、permission decision、approval record、idempotency key、result	Agent 事故无法判断责任和恢复范围
输出与影响	用户看到了什么，是否被后处理改写，产生了什么业务影响？	raw_output hash、final_output、guardrail decision、delivery status、business object id	用户投诉、监管询问和事故影响面无法还原
评测与发布	这次改动凭什么上线，上线后是否符合预期？	eval_run_id、release_gate_id、canary cohort、rollback condition、owner approval	发布回归只能靠记忆和聊天记录复盘
复盘改进	问题归因到哪一层，进入哪个修复、评测和发布闭环？	incident_id、severity、root cause layer、eval_case_id、fixed_version、postmortem link	坏例停在日志里，无法变成系统改进

审计不是“把所有内容都存下来”

好的证据链是最小充分、可关联、可脱敏、可复现。敏感原文可以做权限隔离、加密、脱敏或哈希，但关键版本、决策、结果和责任边界必须能被串起来。

二、四类场景的证据包

一次普通请求

保留用户场景、Prompt 版本、模型版本、RAG 片段、输出和反馈
重点用于质量归因、成本归因和坏例回放
回读一次 LLM 请求的一生

一次工具动作

保留模型意图、参数、权限裁决、人工确认、执行身份和副作用结果
重点用于判断模型只是建议，还是系统真的执行了动作
回读 Tool Calling / 执行协议

一次 AI 发布

保留变更对象、版本快照、Eval 结果、审批、Canary 指标和回滚条件
重点用于回答“为什么允许上线，为什么没有阻断”
回读 AI 发布 / 灰度 / 回滚

一次 AI 事故

保留影响面、时间线、触发样本、版本快照、止血动作、恢复验证和复盘结论
重点用于监管、客户沟通、内部追责和回归防复发
回读 AI 事故响应 / Runbook

三、Trace、Eval、Release 怎样接成证据流

阶段	输入证据	判断动作	输出证据
Trace	请求、上下文、模型、检索、工具、输出、成本、反馈	分层归因：Prompt、RAG、Tool、Route、Model、Safety、UX	坏例、指标切片、风险标签、问题 owner
Review	坏例、用户反馈、人工复核、业务影响	判断严重度、可复现性、是否进入事故或普通改进	标注结果、严重度、复现步骤、期望行为
Eval	坏例、Golden Set、红队样本、Judge Prompt、人工校准	验证修复是否覆盖原问题，是否引入新回归	eval_run_id、切片分数、失败差异、阻断 / 放行建议
Release Gate	Eval、成本延迟、安全结果、变更说明、风险豁免	决定上线、灰度、阻断、人工审批或高风险豁免	release_gate_id、审批记录、灰度范围、回滚条件
Post-release	Canary 指标、用户反馈、事故告警、版本对比	继续扩量、暂停扩量、降级、回滚或转事故响应	线上验证结论、回滚记录、复盘输入、下一轮 Eval 样本

证据链的价值在于跨阶段可追踪

一个 request_id 最终可能变成 eval_case_id、release_gate_id、incident_id 和 fixed_version。只要中间断了，组织就会回到“大家凭印象争论模型到底有没有变好”。字段口径可以对齐 AI 证据包索引，请求级回放可以对齐请求 Trace / 排障模板。

3.1 证据 ID 血缘：从请求到修复版本

起点 ID	生成下游 ID	继承的证据	证明什么
request_id	failure_tag、eval_case_id、incident_candidate_id	身份、上下文、模型、RAG、工具、护栏、输出、反馈	单次坏例不是孤立截图，而是可回放的生产请求
eval_case_id	eval_run_id、regression_slice_id	输入、期望行为、评分 rubric、人工标签、风险等级	坏例已经进入回归集，并能在候选版本上重复验证
eval_run_id	release_gate_id、blocked_change_id	样本集版本、切片结果、Judge / 人工校准、失败差异	发布决策有评测证据，而不是只看主观感觉
release_gate_id	canary_cohort_id、evidence_pack_id	放行 / 阻断理由、审批、灰度范围、停止条件、回滚点	线上结果能回到当时的发布判断和责任边界
incident_id	postmortem_id、fixed_version、new_eval_case_id	影响面、时间线、止血动作、根因、证据包、恢复验证	事故不是只被关闭，而是被转成修复版本和防复发样本

ID 血缘比长日志更重要

日志可以很多，但如果 request、eval、release、canary、incident 和 fixed version 之间没有血缘关系，团队仍然无法证明问题从哪里来、由谁放行、怎样修复、是否防住复发。

四、责任边界：模型、系统和人分别负责什么

主体	负责什么	不应该背什么锅	需要留下的证据
模型	根据输入上下文生成文本、结构化调用意图或判断建议	不应被视为权限系统、事实数据库或审批人	model_id、输入上下文、raw_output、解码配置
应用系统	选择上下文、路由模型、校验输出、执行工具、展示结果	不能把错误都归因给模型黑箱	prompt、router、parser、tool runtime、guardrail、final_output
权限系统	判断用户、租户、数据和工具动作是否被允许	不能让模型文本声明替代服务端授权	permission snapshot、policy version、allow / deny reason
人工审批者	对高风险动作、豁免和发布放行承担明确确认责任	不应审批看不懂、没有证据或范围不清的动作	approval record、scope、risk note、timestamp、operator
平台团队	提供日志、追踪、评测、发布、回滚和事故响应底座	不应替业务定义所有正确答案和风险阈值	trace schema、dashboard、gate config、retention policy
业务 owner	定义任务成功、业务影响、风险等级和用户补救动作	不能只要求“模型更准”，却不给验收标准	acceptance criteria、risk tier、human review rule、SLO

五、不同风险等级需要不同审计强度

风险等级	典型场景	审计强度	上线要求
L1 低风险辅助	摘要、草稿、内部检索、非关键分类	请求级 trace、版本和反馈即可	基础 Eval、成本延迟可见、用户可纠错
L2 业务影响	客服建议、销售线索、知识库问答、运营辅助	加引用、人工抽检、坏例入库和灰度观测	切片 Eval、Canary、回滚条件和 owner
L3 敏感数据 / 工具动作	读取客户资料、写业务系统、发邮件、创建工单	权限快照、工具参数、审批、幂等和副作用记录	工具风险分级、HITL、审计查询和事故 Runbook
L4 高风险决策	医疗、金融、法律、人事、权限变更、生产发版	完整证据包、双人复核、风险豁免、保留期限和外部审计准备	高风险评审、红队 / 安全 Eval、强制人工责任人和上线委员会

六、审计数据的治理边界

保留期限

不同字段保留时间不同：请求指标可以长期聚合，敏感原文应更短、隔离或脱敏；高风险审批和事故证据需要按合规要求保留。

脱敏与最小必要

证据链不等于全量复制用户隐私。可以保存哈希、文档 ID、权限快照、片段引用和加密快照，把敏感原文放进受控取证路径。

跨租户隔离

LLMOps Dashboard、坏例池、人工审核台和调试工具都必须遵守租户与权限边界，不能因为排障方便而越权查看。

可查询但不可滥用

审计查询本身也要被审计。谁查了哪个 request、为什么查、导出了什么证据，都应留下记录。

七、常见误区

误区	为什么危险	更稳的做法
只存最终回答	无法知道答案来自哪个 Prompt、检索片段、工具结果或模型版本	至少保留版本快照和关键链路事件
只记录模型输入输出	Agent 和 RAG 的关键风险常发生在工具、权限、检索和后处理层	Trace 跨模型、检索、工具、策略和业务对象
把审计当成合规团队的事	工程链路没有字段，合规再想追也追不回来	在产品设计、网关、工具运行时和发布流程中内建证据字段
为了审计全量保存敏感原文	排障能力提高了一点，但隐私和泄露风险大幅上升	按风险分级保存摘要、哈希、加密快照和受控取证路径
没有 owner 和状态	坏例、事故、风险豁免和发布回归会停在面板里无人处理	每条高价值证据都有 owner、severity、status 和下一步动作

八、最小落地清单

落地点	先做什么	完成标准
Trace Schema	统一 request_id、version、routing、RAG、tool、guardrail、feedback 字段	一次请求能跨日志、评测、发布和事故系统关联
证据分级	按 L1-L4 定义字段、保留期限、脱敏和审批要求	低风险不过度记录，高风险不漏关键证据
发布绑定	把 eval_run_id、release_gate_id 和 canary cohort 写入线上版本	线上异常能回到具体评测和放行记录
工具审计	为高风险工具记录参数、权限、确认、幂等键和执行结果	能判断副作用来自哪次模型意图和哪次系统执行
事故证据包	定义自动拉取 request、版本、权限、工具、影响面和止血动作的模板	P0/P1 事故不用临时拼日志
审计查询治理	审计后台也接入 IAM、审批、脱敏和访问日志	排障人员可查必要证据，但不能越权浏览敏感内容

九、回到 AI 主干

AI 全景 → AI 阅读路线 → 一次请求的一生 → Tool Calling → Workflow / HITL → LLMOps → 发布闸门 → 灰度回滚 → 事故响应 → 权限 / 租户 → 治理 / 合规

这张图在主线里的位置

一次请求的一生回答“运行时发生了什么”，LLMOps 回答“怎样观测和评测”，发布治理回答“怎样安全上线”，事故响应回答“出事后怎么止血复盘”。本页把这些页面串成证据链，专门处理审计、复现、追责和责任边界。