为AI推理接口加一层问责记录，出问题时能查到是谁做的决定
AI 问责机制配置要解决的问题很具体：当模型输出错误、违规或造成业务损失时，团队能查清是哪个模型版本、哪次请求、哪段输入导致的，以及谁批准了这个模型上线。
它不需要重构整套系统，通常是在现有推理接口前后增加审计日志和复核记录。
下面按“先定字段、再写入、最后验证”的顺序说明一个可落地的最小方案，适用于已经通过 HTTP 接口调用模型的自建服务。
先确认哪些请求需要留痕
不是所有调用都要记录完整内容。
先按业务风险分级：
- 面向外部用户的生成、审核、评分类接口，必须记录输入摘要、输出全文、模型名称和版本。
- 内部调试或低风险查询接口，可以只记录请求 ID、调用人和时间戳，不保存完整对话内容。
- 涉及个人信息的字段，写入审计表前要做脱敏或加密，审计表访问权限应比业务表更严格。
需要提前准备的东西：
- 一个独立的审计存储，可以是单独的 MySQL 表、Elasticsearch 索引或对象存储日志文件。
- 推理接口能拿到调用方身份，例如网关注入的用户 ID 或内部服务名。
- 模型版本号的来源，例如启动参数、环境变量或模型注册表中的版本字段。
审计记录应该包含哪些字段
最小可用字段如下，缺一项都会让事后追溯变困难：
request_id：每次请求唯一，建议用 UUID，方便串联业务日志。caller_id：调用方标识，来自认证层，不要由请求体自行传入。model_name和model_version：模型标识与版本，必须与实际加载的权重一致。input_digest：输入内容的哈希或脱敏摘要；需要完整输入时另存加密字段。output_text：模型原始输出，保留到复核流程结束。decision：本次输出是否被自动拦截、人工复核或直接放行。created_at：服务端时间，不要用客户端时间。
如果团队有模型上线审批流程，再加一个 approval_ref 字段，指向上线工单编号，这样追责时能对应到批准人。
把记录动作放在推理之后、返回之前
推荐在推理服务内部完成写入，而不是依赖上游业务系统补记。
流程是：收到请求 → 调用模型 → 拿到输出 → 写审计记录 → 返回响应。
这样即使上游漏记，审计表里也有完整记录。
以 Python 服务为例，在返回响应前插入一段写入逻辑：
import uuid, hashlib, time
def audit_record(caller_id, model_name, model_version, prompt, output, decision):
return {
"request_id": str(uuid.uuid4()),
"caller_id": caller_id,
"model_name": model_name,
"model_version": model_version,
"input_digest": hashlib.sha256(prompt.encode()).hexdigest(),
"output_text": output,
"decision": decision,
"created_at": int(time.time())
}写入方式根据量级选择：低并发直接同步写数据库；
高并发先写本地日志文件，再由采集器异步入库。审计写入失败时不应静默忽略，至少记录一条错误日志并触发告警，否则问责链路会断在写入环节。
复核流程要落到人和状态上
只有日志没有复核动作，问责机制仍然不完整。
建议在审计表上增加两个字段：review_status 和 reviewer_id。
当输出被自动规则拦截，或用户投诉某次输出时，由值班人员把对应记录标记为待复核，复核完成后填写结论。
判断条件可以简化成三条：
- 自动拦截命中敏感词或越权内容：必须人工复核，复核前该记录不得删除。
- 用户投诉具体输出：按
request_id定位记录，核对输入和模型版本后给出处理结论。 - 定期抽样：每周抽取一定比例的正常输出，检查是否存在系统性偏差。
复核记录本身也要保留修改历史，避免事后改状态。
验证配置是否真的生效
配置完成后，用一次真实请求做端到端检查：
- 调用推理接口，拿到返回结果。
- 用返回头或日志中的
request_id查询审计表，确认记录存在。 - 核对
model_version与当前部署的模型版本是否一致。 - 模拟一次写入失败，例如临时关闭审计表写入权限，观察是否产生告警。
如果查不到记录，优先检查写入逻辑是否在异常分支中被跳过，以及审计存储的连接配置是否指向了测试库。
容易踩的坑
- 把调用方身份交给请求体传入，导致追责时无法确认真实调用者。
- 只记录输出不记录模型版本，模型更新后旧问题无法复现。
- 审计表与业务表共用数据库账号，业务侧误删会连带丢失审计记录。
- 为了省空间只保留七天日志，但投诉往往在数周后才出现。保留周期应结合业务风险确定，并在配置中写明。
AI 问责机制配置的重点不是多复杂的工具，而是把“谁在什么时间用哪个模型对什么输入产生了什么输出、由谁复核”这条链路固定下来。
先保证字段完整、写入可靠、复核有人负责，再考虑接入更细的权限审计和自动化告警。
