第九章 风险可控——你自己做比外包更容易控

第九章 风险可控——你自己做比外包更容易控

核心结论：让财务人员自己写代码做工具，出了错怎么办？数据安全怎么办？答案很清楚：本地部署 + 人在环中 + 自建工具 = 你比任何第三方外包都更能控制风险。真正的风险是把控制权交给别人。

---

风险：自己做比交给别人更可控

跟企业主聊到最后，顾虑通常集中在一个问题：让财务人员自己写代码做工具，出了错谁负责？

做一个对比就清楚了。

哪个风险更大？

真正的风险是把控制权交给别人，出了问题只能等别人修。本地部署 + 自建工具 = 你的数据、你的规则、你的代码、你的控制权。出了问题不需要联系客服、不需要等厂商回复——你的财务人员自己就能定位问题、修改逻辑、重新运行。

---

风险怎么应对

财务 AI 面临三类风险。第一类（技术风险）最需要担心，后两类（数据风险和制度风险）的核心防线跟第四章一样。

技术风险：幻觉、计算错误、结果不确定性

大模型可能产生幻觉（给出看似合理但错误的回答），计算脚本可能存在逻辑错误，预测结果可能不准确。

人在环中是防幻觉的第一道防线。 工具的使用者就是开发者本人——他知道工具的逻辑是什么、输入是什么、输出应该是什么样子。工具给出一个异常的结果，他一眼就能发现。因为他每天都在做这个工作。

脚本可审查、可测试、可直接验证。 你的财务人员写了一个报销校验脚本，对不对？用上个月已经审过的 500 笔报销运行一次，跟人工审核结果对比——哪里有差异一目了然。不需要猜测「模型内部在做什么」。

预测不准确通常是数据问题。 现金流预测误差大，最可能的原因是数据源不干净，不是模型不够先进。你的财务人员自己整理数据、自己跑模型——他比任何人都清楚数据哪里有问题。

应对策略：所有工具上线前先用历史数据跑一遍，对照确认逻辑正确。工具跑起来了，但结果不对——改脚本，几分钟的事。

数据风险和制度风险：跟第四章一样

数据风险和制度风险，核心防线跟第四章一样——本地部署和规则驱动核心计算，前面说过了，这里不重复。

---

业务自建工具的治理框架

随着团队的工具越来越多，需要一个轻量的治理框架。不需要复杂到需要专人维护，但需要做到以下几点：

版本管理

所有脚本纳入版本管理。最简单的方式：用 Git 建一个仓库，每个脚本的每次修改都留有记录。

为什么需要：改了一个规则发现效果不对，可以回滚到上一个版本。同事想复用你的脚本，可以直接从仓库里拿。

有多复杂：不复杂。Git 的基本操作（add、commit、push）10 分钟能学会。AI 编程工具甚至可以直接帮你做这些操作。

变更记录

每次修改脚本逻辑，必须记录「改了哪里、为什么改、谁批准的」。

为什么需要：审计追溯。如果脚本生成的某笔凭证被审计质疑，你需要说清楚"这个脚本当时的逻辑是什么"。

有多复杂：不复杂。在脚本文件顶部加一段注释，或者在一个共享文档里记录。不需要系统。

运行日志

脚本的每次运行，保留输入、输出和时间戳。

为什么需要：对账追溯。三个月后发现某笔差异，你需要能查出"当时脚本生成了什么"。

有多复杂：在脚本里加几行日志代码——AI 编程工具可以帮你写。日志文件统一存放在一个目录里，定期清理。

权限控制

谁可以运行什么工具、处理什么数据，需要明确。

为什么需要：职责分离。做预算的人不应该能运行付款脚本。

有多复杂：取决于你的企业规模和工具数量。小企业口头约定就行。大企业需要在部署时配置权限。

---

风险总结

FDE 化不是零风险，但它是你能选择的风险最小的路径。因为数据在你手里，代码在你手里，规则在你手里，控制权在你手里。

---

第九章小结：技术风险的防线是「人在环中」——工具的使用者就是开发者，发现异常最快。数据风险和制度风险的防线跟第四章一样——本地部署和规则驱动核心计算。治理风险靠轻量框架——版本管理、变更记录、运行日志、权限控制。最后一章：现在就开始。