立项：先判适用与影响
立项阶段要写清服务对象、内容形态与数据范围，据此判断适用条款，并完成一次 AI 影响评估。评估不必厚重，但要覆盖用途合理性、受影响人群、可能的误用与缓解措施，作为后续设计输入，而不是上线前的追认。为什么放在立项：越晚判断，改动成本越高。
设计：把边界画进方案
在方案里明确哪些环节由模型做、哪些必须人工、异常怎么兜底、标识放在哪里。设计阶段不写清接管条件，开发阶段就会默认全自动，上线后再加人工复核，成本要高出一个量级，工期也会被动延长。
开发：字段与权限先行
开发阶段落实字段级最小化、脱敏规则、权限矩阵与日志埋点。这些改动越晚做越贵，尤其是日志，往往需要改数据模型。建议把日志字段写进接口契约，随接口一起评审，避免上线前才发现采不到数据。边界在于日志字段属于接口契约，不是上线后的附加项。
上线：四份材料齐备
上线前应有影响评估结论、标识与兜底方案、应急预案、供应商条款四份材料，缺一项就不排期。材料由业务、合规、IT 分别签认，形成可追溯的上线决定，而不是一句口头同意。为什么不能由一人代签：签字对应的是判断责任，代签等于没有人真正判断过。
运营：抽检与复盘
上线后按周期抽检回答质量、标识在位率与投诉闭环，把发现的问题回灌到提示词与知识库。运营阶段最容易断档，建议把抽检纳入现有质量例会，而不是另开一套会议，否则三个月后基本没人执行。为什么纳入例会：另开一套会议很难长期维持。
适用与不适用
适合谁
- 正在推进 AI 项目的业务与技术负责人
- 需要把合规写进项目计划的项目经理
- 有多项目并行、需要统一检查口径的 PMO
不适合谁
- 已上线、只做补救的存量系统，更适合走审计路径
- 项目边界不清、需求持续漂移的团队
典型场景
某物流企业要上线运单问答助手，项目经理在立项会上确认服务对象为内部调度员，设计阶段写明异常转人工规则，开发阶段把对话摘要与模型版本写入接口契约，上线前收齐四份材料并由三方签认，运营三个月后按抽检结果补充了地址识别的兜底话术。
可执行步骤
- 立项会确认服务对象、内容形态与数据范围，据此判定适用条款，形成一页书面结论
- 完成 AI 影响评估，把结论作为设计输入并留档，至少覆盖用途、受影响人群与误用场景
- 在方案中写清人机分工、接管条件与异常兜底路径，并明确每个环节的责任人
- 把日志与脱敏字段写进接口契约，随接口一起评审，避免上线后为补日志再改数据模型
- 上线前收齐四份材料，由业务、合规与 IT 分别签认，缺项不排期，签认记录归档
常见坑
- 立项不判适用，开发到一半才发现要改架构，工期与预算同时失控，返工往往拖到项目后期，预算也被动追加
- 方案只写功能不写兜底，异常全部落到一线人工，使用率很快下滑，最终还要回头补设计，工期二次延长
- 日志字段后补，需要改数据模型并重跑测试，上线后才发现采不到数据，期间的处理无法审计，责任归属说不清楚
- 上线材料由一人代签，责任无法追溯，出问题时找不到判断依据，复盘缺材料，追责更无从谈起，材料也补不回来
自检与验收清单
- 立项是否已判定适用条款与影响范围，有结论文件
- 方案是否写清人机分工与接管条件，责任到人，可查可验
- 日志与脱敏字段是否进接口契约，并随接口评审
- 四份上线材料是否齐备并分别签认，缺项是否拦住
- 运营抽检是否纳入既有质量例会，有固定频次，并有记录
常见问题
小项目也要走完整五阶段吗？
可以裁剪但不能跳过判断。小项目至少保留立项适用判断、上线材料与运营抽检三项，影响评估可压缩为一页，日志先用网关默认字段，随规模扩大再补充，避免一开始就按大项目铺开。
影响评估由谁来做？
由业务牵头，合规与方法人员参与。业务最清楚用途与受影响人群，合规判断条款与风险等级，结论要有人签认。不能由供应商单独出具，否则既缺独立性，也无法约束后续变更。
上线后发现评估不足怎么办？
立即缩小开放范围或增加人工复核，补充评估并按结论整改，同时记录事件经过与处置。把补救过程留痕，比事后重写一份看起来完整的评估更有说服力，也便于下次复盘。