核心结论是：把 AI 风险清单从“评审表”变成流水线里的自动检查。技术负责人不需要再追问“这次改动有没有重新评审”，而是让 CI/CD 在发布前强制验证提示词变更、工具权限、数据边界和输出约束。任一项不通过，Agent 就不能上线。
为什么风险清单会失效
很多团队已经有完整的 AI 风险清单，列了提示词注入、幻觉、敏感数据泄露、越权工具调用、模型供应商变更。问题不在于风险没被识别，而在于清单只活在文档里。
当业务进入周级甚至天级迭代，典型情况是：开发者改了一段 system prompt，前端打开了 HTML 渲染，后端给 Agent 接了一个新的内部接口，或者模型供应商调整了默认输出。这些变化很少再次触发安全评审。
技术负责人真正要解决的不是“再写一份更全的清单”，而是让清单变成发布条件。治理对象必须从文档转到代码，从人工提醒转到流水线阻断。
适合做这件事的企业通常有三个特征：已经有 Agent 或 AI 应用在生产环境运行；发布频率已经让安全评审跟不上；企业有 GitLab CI、Jenkins、GitHub Actions 或类似流水线，能够承载检查任务。
上线门禁应该检查什么
不是所有风险都能自动检查，但大部分高风险项可以。建议从四类最容易被工程化验证的风险开始。
提示词与行为约束是否被改坏
每次 Agent 项目合并前，自动比对 system prompt 与上一版本。检查是否删除了拒绝指令、是否新增了未声明的外部数据引用、是否出现“忽略之前的限制”“无条件执行”等模式。重点不是做语义理解，而是做差异扫描和规则匹配。
同时可以把安全要求抽成单独的策略文件，要求提示词、工具说明、输出模板必须引用该文件。CI 检查策略文件是否存在、是否被绕过。
Agent 工具权限是否越界
为每个工具建立权限声明，明确它能访问哪些系统、哪些数据范围、是否需要人工确认。流水线在发布前比对代码中实际调用的工具清单与权限声明。新增工具但没有声明、声明范围和代码实现不一致，直接阻断。
这一步对财务、合同、客户数据、人事系统尤其关键。一个客服 Agent 突然接入了包含客户联系方式的内部接口，应该被门禁拦下，而不是靠代码评审发现。
知识库与数据边界是否被突破
Agent 回答往往依赖知识库。CI 阶段可以验证知识库引用配置是否包含未授权数据集，尤其是合同、报价、员工信息、未成年人相关数据。涉及个人微信、电话外呼、客户联系信息时，必须走人工确认流程，不能由 Agent 自动处理。
如果知识库已按单文件或分组设置权限，门禁要检查 Agent 所用的检索范围是否与权限规则一致。员工无权看的合同，不应出现在 AI 的回答和引用里。
输出与前端渲染是否安全
Agent 输出如果会在网页、邮件或企业微信中渲染，CI 需要加入输出安全策略检查。例如是否允许富文本、是否过滤可执行内容、是否要求输出前脱敏。前端开启新的渲染方式，必须同步更新输出检查规则。
怎么把清单改造成门禁
第一步，选一个真实在跑、风险最高的 Agent 试点。不要一开始覆盖所有 AI 应用。
第二步，把风险清单中可自动判定的项抽出来，写成检查规则。能确定的规则写进流水线，不能确定的人工项保留为发布审批条件。
第三步，在 CI/CD 中增加一个 AI 发布检查阶段。它的作用是生成证据并做出通过或阻断判断，而不是给建议。检查结果写入发布记录，谁改了什么、哪条规则没过、阻断原因是什么，全部留痕。
第四步，把三类变化强制纳入检查范围：系统提示词变更、工具与 API 调用变更、知识库与数据源变更。任何一类没有检查记录，不允许进入生产。
第五步，建立失败处理路径。门禁阻断后，要么返回修复，要么走有明确审批人的例外流程。例外不能是默认动作。
常见误区
最大的误区是把门禁做成“扫描加报告”。报告不会阻止发布，只有当不通过就不能上线时，门禁才有治理意义。
第二个误区是一开始追求大而全。幻觉检测、模型行为评估这类任务并不适合在流水线里做重模型判断，应该先管住确定性强的问题：工具权限、提示词变更、数据边界。
第三个误区是只检查 Agent 运行时，不检查发布物。真正有效的做法是把检查放在合并或发布前，让问题在进入生产前暴露。
第四个误区是安全团队不参与门禁设计，最后变成了开发团队自我检查。规则应由安全或治理负责人定义，工程团队负责实现和签名。
交付成果与验收方式
一个可运行的 AI 上线门禁，交付物通常包括：可机器执行的检查规则库、集成到 CI/CD 的检查阶段、每次发布的检查记录和阻断日志、例外审批流程、以及针对提示词、工具权限、知识库引用的策略文件模板。
验收方式是做一次真实变更测试：故意修改 system prompt 或新增一个未声明工具，看门禁是否在发布前阻断，并输出明确证据。能拦住，才算完成从文档治理到代码治理的切换。
智未来 AI 的团队在企业 AI 落地中处理过知识库权限、Agent 工具边界和发布治理的工程问题。如果您正在设计这类门禁，可以从 企业知识库与 AI 调用权限 的实际边界确认开始，先保证 Agent 用的数据是可控的，再往上叠加发布检查。需要更完整的项目实施支持，可以联系智未来（上海）智能科技有限公司。
常见问题
我们还没有专业安全团队，能先做上线门禁吗？
可以。先选一个风险最高的 Agent，把工具权限和提示词变更检查做起来。这两类规则不需要复杂安全背景，工程团队在一到两周内可以跑通第一个版本，后续再逐步扩展。
CI/CD 门禁能拦住大模型“乱说话”吗？
不能完全拦住。幻觉和不确定性输出不适合在流水线里做重模型判断。门禁更适合解决确定性问题，比如工具越权、数据越界、约束被删除。输出质量问题要配合评估样本和人工抽检，不是上线门禁的核心任务。
我们用的是低代码平台搭的 Agent，没有 CI/CD 怎么办？
先确认平台是否提供发布 API、版本对比或审计日志。如果完全没有，可以从导出配置加差异检查开始，把人工审批变成有证据的审批，再逐步推进到自动阻断。关键是让每一次发布都有可追溯的风险验证记录。
上线门禁会不会拖慢业务迭代？
如果只检查四到五类高风险项，单次检查通常只增加几分钟。真正拖慢迭代的是发布后出现事故再回滚。门禁的价值不是让人更慢，而是让高风险变更少返工。
智未来 AI 能帮我们做到什么程度？
智未来 AI 可以帮助技术团队梳理现有 AI 风险清单，把可自动判定的风险转化成 CI/CD 检查规则，设计工具权限声明和知识库引用边界，并交付第一套可运行的门禁与发布证据链。已经内部跑过 AI 应用、需要把治理落到工程流程的企业更适合从这类项目切入。