边界一：确定性要求
金额计算、税率适用、资质判定这类必须百分之百确定的结果，不适合交给生成式模型。怎么处理：把规则写成确定性代码，模型只负责抽取与解释；若一定要用模型，也要加校验层与人工复核，不能直接对外。
边界二：事实与责任
模型会自信地给出错误引用，而责任仍由使用方承担。怎么划：对外发布的事实性内容必须有可核来源，涉及法律意见、审减结论、中标判断的，由持证人员复核签认；我方不替代签章，也不承诺结论。这条边界要写进合同。
边界三：数据边界
数据不能出内网、不能上传第三方的场景，公有云接口直接不可用。怎么评估：先做数据分级，再看能否本地部署或专有环境；本地部署要评估算力、运维与更新责任，别只看模型效果，否则上线即失控。
边界四：简单高频任务
字段校验、固定模板填充、关键词匹配这类任务，规则或小模型更快更稳。怎么判断：如果任务可以用一张规则表写清、且错误代价明确，就不必上大模型；把预算留给真正需要语言理解的环节更划算。
适用与不适用
适合谁
- 正在判断某场景该不该用大模型的企业
- 有明确合规与数据边界要求的行业客户
- 希望把预算花在关键环节的负责人
不适合谁
- 希望用模型替代审计、法务或造价判断的项目
- 要求模型输出百分之百确定结果的场景
典型场景
某医药企业想让模型自动判定报销单据是否合规。评估后发现判定规则明确、错误代价高，于是改为规则引擎做判定、模型只做票据字段抽取与异常说明；判定结果仍由财务复核，模型输出全程留痕，供事后抽查，保存期限由合规部门确定。
可执行步骤
- 先判断任务结果能否用规则写清，以及出错后要付出多大代价来纠正
- 对确定性要求高的环节，保留代码校验，并安排固定岗位做人工复核
- 做数据分级，确认哪些数据可以出内网、哪些只能本地处理，逐项列出
- 逐条记录模型输出与人工结论，供事后追溯与责任界定，保存期限写进制度
常见坑
- 把合规判定交给模型，出错后无法界定责任，整改成本极高，往往只能整体回退，客户也很难交代。
- 模型引用了不存在的条款，业务方未核对就对外发布，引发投诉，责任仍落在使用方身上。
- 未做数据分级就把图纸与报价上传第三方接口，事后被问起时说不清数据流向，也拿不出台账。
- 简单字段校验也上大模型，延迟与成本一起上升，准确率反而不如一条规则，投入并不划算。
自检与验收清单
- 任务是否可以用规则写清，错误代价是否评估过
- 确定性要求高的环节是否保留代码校验与复核岗
- 是否完成数据分级，并取得书面的授权与留存记录
- 对外发布的事实性内容是否都标注了可核来源
- 模型输出与人工结论是否逐条留痕，便于追溯
常见问题
模型能不能做合规初筛？
可以做初筛与提示，不能做最终判定。让模型标出疑似问题并给出依据，由合规人员复核；这样既提高效率，也保留责任链条。若直接对外出具结论，一旦出错很难解释，也不符合执业要求。
本地部署是不是更安全？
边界更清楚，但安全取决于运维。本地部署要管好账号、日志、模型更新与算力扩容；若运维能力不足，反而容易出现无审计的调用。先评估团队能否长期维护，再决定部署方式。
小模型够用吗？
很多任务够用。分类、抽取、固定格式生成用小模型往往更快更稳，成本也低；复杂推理与长文理解再上大模型。建议先用小模型打底，把大模型留给确实需要的那部分请求。不必一刀切。