AI 建议并非批准：合成支付调查演示中的三项控制措施

我开发了 FinSentry AI，这是一个独立的业余项目，旨在探索 AI 辅助支付调查。我是开发者；演示使用的是预先录制的合成沙盒数据。关键区别在于：生成解释与拥有更改案件的权限是两回事。智能体运行完成不应在无声无息中变成采取行动的许可。文档中列出的技术栈：React/TypeScript、FastAPI、LangGraph 和 PostgreSQL。领域服务负责管理案件状态和审批；智能体运行时协调提供建议的调查步骤，API 则强制执行授权检查。演示展示了三项具体控制措施：证据缺失意味着不作判断。当必需的筛查输入不可用时，建议流程会选择不作判断。不能仅仅因为模型能生成看似合理的解释，就把证据缺失视为可以放行。请求不等于批准。经办/复核工作流包含禁止自我审批的限制。请求者与有权批准的人必须保持可区分；仅有“人在回路中”的标签并不能确保这种职责分离。批准的是明确的具体操作，而不是模糊的结果。演示中的批准维持了现有的资金冻结措施。它并未释放资金，审计记录也表明案件仍处于调查中。除非读者能够看清哪些内容发生了变化、哪些没有，否则“已批准”这一表述就不完整。对于生产版本，我会分别测试必填输入缺失、同一用户尝试审批、请求提交后证据发生变化，以及重复执行的情况。这些是拟议的验收检查，并非声称录制演示已经通过的测试。接下来我会测试的一个边界情况是审批失效：如果证据在请求提交与复核之间发生变化，是任何变化都应使请求失效，还是只有与该操作相关的变化才应使其失效？录制演示（4 分 20 秒，MP4 下载）架构与演示局限性 公开发布的资料包包含文档和媒体文件，不包含应用程序源代码。这段录制演示并非付费客户部署，也不能证明已获得监管认证、已具备生产就绪条件，或已通过完整的集成测试/测试套件。披露：本文草稿使用了 AI 辅助撰写。