自动化决策，一旦影响到客户、员工或业务结果，迟早会被问到同一个问题：这个结论依据什么得出。能不能答上来，不取决于模型多先进，而取决于决策发生的那一刻留下了哪些记录。本文从国内法规要求出发，列出一条决策记录应该包含的七类信息，并讨论规则与大模型怎么分工、开源的可解释工具怎么评估。
- 《个人信息保护法》第二十四条规定：通过自动化决策作出对个人权益有重大影响的决定，个人有权要求说明，并有权拒绝仅通过自动化决策作出决定。
- 同法第五十五条要求这类处理事前做个人信息保护影响评估并记录处理情况，第五十六条要求评估报告和处理情况记录至少保存三年。
- 系统日志记录“发生了什么”，决策记录要回答“依据什么”，两者不能互相替代。
- 一条可复核的决策记录至少包含七类信息：决策对象与时间、输入快照、规则及版本、模型及版本、模型原始输出、最终结论与动作、人工复核。
- 大模型写出的“理由”是生成文本，不能当作它得出结论的真实过程；需要复现的判定应交给确定性规则。
自动化决策，法规要求能说明什么
国内对这件事最直接的依据是《个人信息保护法》。第二十四条要求利用个人信息进行自动化决策时，保证决策的透明度和结果公平、公正；对个人权益有重大影响的决定，个人有权要求说明，并有权拒绝仅通过自动化决策作出的决定。条文原文可在国家网信办发布的法律全文中查阅。
第五十五条把“利用个人信息进行自动化决策”列为必须事前做个人信息保护影响评估、并对处理情况进行记录的情形之一；第五十六条要求影响评估报告和处理情况记录至少保存三年。
对企业来说，这几条落到操作层面是三件事：事后要说得清单次决定的依据；要留有人工介入的途径；相关记录要能保存并调取。即使某个场景不涉及个人信息，内部审计和监管检查问的也往往是同一个问题。
说明：本文是对公开法条的业务解读，不构成法律意见。具体场景是否属于“对个人权益有重大影响”，以及所在行业是否有更严格的记录保存要求，请以法务或外部律师的判断为准。
日志为什么不够
很多团队的第一反应是：系统日志都在，出了问题再查就行。问题在于日志和决策记录回答的是两类问题。
| 对比项 | 系统日志 | 决策记录 |
|---|---|---|
| 回答的问题 | 什么时间发生了什么事件 | 依据哪些数据、哪条规则、哪个模型得出了什么结论 |
| 记录粒度 | 请求、报错、耗时等技术事件 | 一笔业务对应一条完整记录 |
| 输入数据 | 通常只有标识，不含当时的取值 | 保存决策时刻读到的值 |
| 规则与模型版本 | 一般不记录 | 必须记录，否则规则改过之后说不清当时的依据 |
| 保存周期 | 按运维需要设置轮转周期，到期清理 | 按合规要求保存，个人信息相关的至少三年 |
最典型的困境是：客户半年后投诉，数据库里的客户资料已经更新过，规则也调过两次。日志能证明“那天系统确实跑过”，但还原不出当时读到的是什么、按哪一版规则判的。这类信息不在决策发生时采集，事后无法补做。
自动化决策：一条记录要留七类信息
下面的清单按“审计问询时会被追问什么”倒推整理，适用于规则系统、机器学习模型和大模型参与的决策。字段名称可以按各自系统调整，类别建议保持完整。
| 类别 | 记录什么 | 缺了会怎样 |
|---|---|---|
| 1 决策对象与时间 | 业务单号、对象标识、决策时间、触发来源 | 无法把投诉或问询对应到具体哪一次决策 |
| 2 输入快照 | 决策时刻实际读到的字段取值，而不是现在库里的值 | 数据被更新后，还原不出当时的判断条件 |
| 3 规则及版本 | 命中了哪些规则、规则版本号、阈值参数 | 规则调整过之后，说不清当时按哪一版判的 |
| 4 模型及版本 | 模型名称与版本；使用大模型时另记提示词版本和主要参数 | 同样的输入今天重跑结果不同，无法解释差异来源 |
| 5 模型原始输出 | 得分、分类结果或大模型返回的原文 | 只剩最终结论，看不出模型建议与最终动作是否一致 |
| 6 最终结论与动作 | 系统给出的结论、实际执行的动作，两者不一致时记录原因 | 人工改判的情况无从追溯 |
| 7 人工复核 | 复核人、复核意见、复核时间；未复核也要记录“未复核” | 无法证明对重大决定提供了人工介入 |
两条配套要求同样重要。第一，记录写入后不应被修改，常见做法是只追加写入，或对每条记录保存校验值。第二，记录要能按对象和时间段检索：审计员说“把某个账户在这两个日期之间的所有决定调出来”，应该是一次查询，而不是一个项目。
规则与大模型怎么分工
大模型进入决策流程之后，可解释性的难度明显上升。原因很具体：同样的输入可能得到不同输出，而模型写出来的“理由”是生成的文本，不能当作它得出结论的真实过程。自动化决策，要想事后说得清，就得先想清楚哪一部分交给谁。
| 判断类型 | 更适合交给 | 例子 |
|---|---|---|
| 有明确条款或阈值 | 确定性规则 | 单笔金额超过审批权限、收款方命中名单、同一发票号重复报销 |
| 需要先读懂文本 | 大模型抽取，规则判定 | 从合同中抽取付款条件，再按制度比对是否超出授权 |
| 影响重大或边界模糊 | 模型或规则给建议，人工决定 | 拒绝授信、认定违规、终止合作 |
一个实用的划分方式：让大模型负责“读”，让规则负责“判”，让人负责“定”。每一段都有自己的记录，合起来就是一条完整的决策链。
这样分工的附带好处是，规则部分可以单独测试和版本管理，大模型的不确定性被限制在“抽取”这一步，抽取结果还能抽样人工核对。关于模型可解释性的更多背景，可以参考可解释的人工智能一文。
自动化决策：开源工具怎么评估
市面上已经出现专门处理决策留痕的开源项目。评估这类工具时，建议逐项问下面五个问题：
- 记录模型是否覆盖上面七类信息，尤其是规则版本和输入快照。
- 能否导出标准格式，例如 W3C PROV-O 溯源本体，法务与外部审计才能用通用工具处理。
- 能否在内网部署，决策记录里往往含有个人信息与业务敏感数据。
- 安全更新是否活跃，记录系统本身被篡改或越权访问，比没有记录更糟。
- 事实正确性由谁负责，工具能复现“当时怎么推出来的”，不代表输入的事实本身是对的。
以 Semantica 为例（核实日期 2026-09-15）。按其 GitHub 项目说明，它把每个决策作为可追溯、带因果链接的一等对象，为每条事实提供 W3C PROV-O 溯源并支持导出为 JSON、CSV 或 RDF，推理方式包括前向链、Rete 网络、Datalog 和 SPARQL；项目采用 MIT 许可，可以自托管。
限制同样要看清楚。第三方评测指出，它的确定性图遍历和规则可以根据存储的输入复现解释，但无法证明抽取出的事实或智能体写下的理由是正确的；0.6.5 版修复了严重的认证与注入漏洞，评测建议使用 0.6.7 或更新版本并自行做安全评审。换句话说，它解决的是“记录与复现”，输入质量和安全加固仍然是使用方自己的责任。
在分析工作流里落地
不少企业的决策逻辑并不在独立的 AI 系统里，而是散在数据分析流程中：审计抽样规则、异常筛查条件、风险打分口径。这类场景用可视化工作流落地，有一个天然的好处：每一步数据处理都是画布上可以点开查看的节点，流程文件本身就记录了“怎么算出来的”。
具体做法上，判定条件可以写在 Rule Engine 规则节点里，规则的修改随流程文件一起保存；需要读文本的环节，iModel 可以在工作流中调用企业本地部署的大模型处理合同、工单等非结构化内容。
需要说清楚的是，工作流记录的是处理步骤，不会自动生成上面那张七类信息的决策记录表。这张表要在设计流程时专门规划：把每次运行的输入快照、命中规则、模型输出和最终结论写进一张记录表，再通过数据库连接节点写入企业自己的数据库。审计场景的更多做法见审计数据分析方案与审计分析用户用例。
关键事实
| 事项 | 内容 |
|---|---|
| 个人说明权 | 《个人信息保护法》第二十四条：对个人权益有重大影响的自动化决定，个人有权要求说明，并有权拒绝仅通过自动化决策作出决定 |
| 影响评估 | 第五十五条第（二）项：利用个人信息进行自动化决策，应当事前进行个人信息保护影响评估并记录处理情况 |
| 记录保存 | 第五十六条：影响评估报告和处理情况记录至少保存三年 |
| 决策记录类别 | 决策对象与时间、输入快照、规则及版本、模型及版本、模型原始输出、最终结论与动作、人工复核 |
| 标准溯源格式 | W3C PROV-O 溯源本体 |
| Semantica 许可 | MIT，可自托管 |
| Semantica 推理方式 | 前向链、Rete 网络、Datalog、SPARQL |
| 核实日期 | 2026-09-15 |
常见问题
自动化决策一定要人工复核吗？
不是所有决定都要。按《个人信息保护法》第二十四条，对个人权益有重大影响的决定，个人有权拒绝仅通过自动化决策作出，因此这类决定应当提供人工介入的途径。其他场景是否复核，按企业内部制度与风险等级确定，并在记录里注明是否经过复核。
已经有系统日志，还需要单独的决策记录吗？
需要。日志记录的是技术事件，通常不保存决策时刻的输入取值，也不记录规则和模型版本。这些信息事后无法从日志还原，必须在决策发生时同步写入决策记录。
大模型给出的理由，能作为决策依据存档吗？
可以存档，但不能当作决策的真实推理过程。模型写出的理由是生成文本，同样的输入可能给出不同表述。需要复现和解释的判定应交给确定性规则，大模型的输出作为“原始输出”一类单独留存。
决策记录要保存多久？
涉及个人信息的，《个人信息保护法》第五十六条要求影响评估报告和处理情况记录至少保存三年。金融等行业可能另有业务档案保存要求，以所在行业规定和法务意见为准。
开源的决策溯源工具可以直接用于生产吗？
可以作为基础组件评估，但不宜直接上线。上线前至少要核对三件事：记录内容是否覆盖所需字段、是否已升级到修复安全漏洞的版本、输入事实的正确性由哪个环节负责校验。
从一条现有的筛查规则开始，把输入、判定条件和输出记录串成一条可以复核的流程，比一次性建设完整平台更容易见效。
想先自己动手试，可以看 Rule Engine 节点说明 或 数据分析教程。
