让 AI 接进经营的设计
规则、权限、口径存成带版本的数据，模型起草的每一步走同一套审批与留痕
企业只接一个对话框，改变不了经营。SZV 先把规则、权限和统计口径存成带版本的数据，再让模型接进来：模型缺省关闭，开启后起草的每一步都走同一套权限、审批和留痕，所以它能经手涉及钱的单据，又不会越过任何一道关。规则极少且多年不动，或判定依赖大量实时外部量的业务，不适合这样做。
取舍与各项业务的关系
这些取舍属于核心经营系统，与各项业务不是一一对应。
图里与这些取舍相连的，只有核心经营系统本身；硬件设计没有连线。
| 业务 | 与这些取舍的关系 |
|---|---|
| 核心经营系统 | 载体。以下每条取舍都在它里面 |
| 私有部署 | 决定这套系统跑在谁的机房、数据怎样进出。敏感分类的模型调用只许走本地推理，见私有部署概览 |
| 经营咨询 | 上游输入。两周诊断交出的企业全貌、改造清单、权责清单，到设计阶段成为规则表、签核位与权责安排的依据，见诊断交付 |
| 硬件设计 | 另一条线，从需求到打样，不涉及这些取舍，见硬件设计概览 |
模型接进来以后
- 模型缺省关闭。开启后，它的输出只能成为待审批的草案，经过权限、审批、留痕才写入业务。
- 金额、是否需要审批这类判定用的值，取自规则表，不取自模型。
- 模型起草的单据走的是同一套权限、审批链与规则，没有为模型另开的通道。
- 规则、权限、口径都是带版本的数据，模型每次调用用了哪一版投影，都记在留痕里。
模型能碰什么、碰不到什么，见模型能碰什么 不能碰什么。
缺了什么都按拒绝处理
贯穿所有机制的做法是失败即关（fail-closed）：缺少输入时，系统停在拒绝的一侧。
| 缺了什么 | 系统怎么办 | 详见 |
|---|---|---|
| 能力字段、可见范围、规则命中行 | 当作空能力、空集、拒绝 | 谁能做什么 |
| 规则取值的键 | 拒绝，不回落到代码里的缺省值 | 规则写成带版本的数据 |
| 签字（超时、位空缺） | 单据停在待签，提醒、代签，不自动批准也不自动驳回；个别申请类单据到期失效，须重新申请 | 人工批准与规则免审 |
| 留痕写不进去 | 不交付：导出不交文件，模型调用回退到规则生成的文本 | 留痕与证据链 |
| 模型的开关与输出校验 | 开关缺省关；校验不过，回到规则文本并转人工 | 模型能碰什么 不能碰什么 |
系统偏向「做不了」，是为了让问题自己暴露：做不了事的人会来报告，多放出去的权限和多批掉的单，往往没人发现。代价是误拒与积压，各页写了缓解办法，也写了缓解不掉的部分。
按要核对的事选页
| 要核对 | 先读 |
|---|---|
| 谁能做什么 | 谁能做什么 |
| 改一条规则要过什么 | 修改规则参数的唯一入口 |
| 一张旧单能否原样复现 | 重放一张旧单的判定 |
| 出事后查什么 | 留痕与证据链 |
| 模型能碰什么 | 模型能碰什么 不能碰什么 |
各项取舍与限制
| 取舍 | 主张 | 代价 | 不适用的情形 |
|---|---|---|---|
| 规则写成带版本的数据 | 制度条款存成带版本的行，用已有判据改参数时不改代码，按时点可查 | 解释器仍在程序里，新判据种类要发版；规则要审查 | 判据结构常变；规则极少且多年不动 |
| 重放一张旧单的判定 | 建单时冻结输入、规则行、判据版本，旧单原样重放 | 每张单带快照，旧判据版本要保留 | 判定依赖进不了快照的实时外部量 |
| 修改规则参数的唯一入口 | 运行时改规则参数只经一个写入入口，只接受已批准的单；金额档位与单型注册表随版本发布追加新行 | 改规则变慢，批准前不生效，批准只一人 | 高频的业务单据录入 |
| 谁能做什么 | 判断一个人能不能做某件事，问同一个入口，拒绝先于允许，答案带依据 | 撤权与会话快照之间有时间差 | 授权关系本身是一张图 |
| 留痕与证据链 | 导出与模型调用里，留痕与动作同事务，写不进则不交付；统一审计事件带链式哈希，能发现局部改删 | 同一条链上的写入要排队；防业务账号与误操作，不防数据库管理员重写整条链 | 要对抗数据库管理员时，须把链头锚到库外 |
| 人工批准与规则免审 | 单据通过来自某人在某位上的签字，或有依据的规则行、金额档的免审线允许免签 | 单据可能积压 | 延误的损失高于错放的损失 |
| 模型能碰什么 不能碰什么 | 模型缺省关，只拿聚合数与令牌；网关内对输出只做结构校验；只产草案，不直接写业务 | 模型能做的事被收窄 | 要让模型读合同、邮件原文或调用工具 |
与常见做法对照
| 取舍 | 常见做法 | 与 SZV 的差别 |
|---|---|---|
| 授权 | Cedar：默认拒绝，forbid 压过 permit；OpenFGA：按关系授权 | SZV 的策略行按主体（角色、职位、任命）与范围匹配；授权关系是图时应改用关系型 |
| 规则 | DMN 决策表：多行命中由命中策略决定 | SZV 按序首条命中，相当于 FIRST；判据含义在解释器里 |
| 重放 | Temporal：重放事件历史，代码必须确定 | SZV 重放的是一张单的一次判定，靠冻结的快照 |
| 变更 | NIST SP 800-53 的 AC-5 职责分离 | 提议与批准分在两人手里，批准只一人 |
| 留痕 | RFC 9162：透明日志用 Merkle 树、签名树头与一致性证明 | 单库里的哈希链不具备外部见证 |
| 模型 | OWASP 大模型应用十大风险 | 把提示注入、不当输出处理、过度代理分开处理 |
其他做法
| 做法 | 它解决什么 | 为什么不用 |
|---|---|---|
| 每个功能各自判断权限与规则 | 写起来最快 | 同一条判据被抄成多份，改一处漏一处；问「这个人为什么能批这笔款」，没有一个地方答得出 |
| 超时自动通过，或模型输出直接当通过的依据 | 单据不积压，省人工 | 通过没有依据，事后找不到负责的人 |
验收时可以问的问题
- 规则内容、签核位、兜底表（事先按职位排好的代签人名单）由企业在设计阶段配置，由谁维护，请在合同中约定。
- 失败即关的每一处，积压或误拒由谁处理、期限多久，请在合同中约定。
- 一次发布之后，旧单重放与留痕校验分别由谁来跑、多久一次，请在合同中约定。
相关页
- 规则写成带版本的数据：取舍的起点，规则怎样存成带版本的行。
- 修改规则参数的唯一入口：运行时改规则参数怎样只经一个写入入口。
- 核心经营系统概览：一笔单据从进入到留痕的全过程。
- 安全边界：防谁、不防谁的整体边界。