AI 应用进入真实业务后，“给出一个看起来合理的答案”远远不够。尤其在风控、财务和审批场景中，系统还必须回答另外三个问题：结论依据什么？哪条规则产生了影响？同样的输入能否复现同样的结果？

可审计不是在结果页多放一段解释，而是从数据进入系统开始，就保留每一步的输入、决策和版本。

把事实和判断分开

一条稳定的 AI 决策链路，首先要区分“事实”和“判断”。

事实是可以回到原始材料核对的信息，例如交易日期、金额、摘要和对方名称。判断则是对这些事实的解释，例如“这是经营性支出”或“需要人工复核”。

在数据模型中，两者应该分层保存：

decision_record = {
    "facts": {
        "transaction_date": "2026-07-01",
        "amount": "12800.00",
        "summary": "服务费",
    },
    "judgement": {
        "category": "operating_expense",
        "needs_review": True,
    },
}

这样做的直接价值是：当规则改变时，可以重算判断，而不需要重新解析原始文件。

为规则命中留下证据

只保存最终分类不足以支撑审计。每一次规则命中，至少应保留：

  • rule_id：稳定、可查找的规则标识。
  • rule_name：给人阅读的规则名称。
  • matched_field：命中的字段。
  • matched_value：实际触发判断的值。
  • rule_version：执行时的配置版本。

这些信息应该和业务结果一起进入报表，而不是只存在开发日志里。日志会轮转，报表才是业务用户真正能拿到的证据。

让 AI 负责表达，不负责篡改事实

大模型擅长把结构化结果组织成可读的语言，但不应让它自由发明金额、比例或风险等级。更可靠的分工是：

  1. Python 负责解析、计算和规则判断。
  2. 程序把经过校验的事实作为约束输入交给模型。
  3. 模型只生成说明、建议和阅读友好的摘要。
  4. 输出后再检查数字与关键结论是否来自事实集。

AI 的价值不在于替代事实层，而在于帮助人更高效地理解事实。

上线前的最小检查清单

  • 原始输入能否通过唯一标识回溯？
  • 规则是否有稳定 ID 和版本？
  • 一条结论能否列出它使用的事实？
  • 模型输出中的数字是否可以和程序计算结果逐项对齐？
  • 历史结果是否记录了当时的配置？

当这些问题都有明确答案时，AI 应用才从“能演示”走向“可交付”。