Sitaram Srivatsavai 是一位 CRM 工程领域的思想领袖,拥有 18+ 年的经验,跨越 CRM、iOS 和 web 平台。领导全球团队交付大规模企业软件,重点关注架构审查、自动化现代化和确保可靠性、法规遵从性和可扩展性能。
问题不在于组织没有人工智能政策,而在于这些政策实际上没有任何作用。在整齐格式的PDF和部署的模型之间,意图逐渐消失。团队即兴发挥。例外情况逐渐积累。治理从一个系统变成了谈判——在医疗和生命科学等受监管的行业中,这个差距不仅仅是尴尬的,它是一个运营上的责任。解决方案不是更多的文档,而是像对待软件一样对待治理。治理差距已经可以衡量人工智能的采用速度加快,而治理基础设施却没有跟上。2025年9月的一项由安永进行的研究发现,只有10%的公司完全准备好审计人工智能系统。与此同时,Ponemon研究发现,92%的组织表示,生成式人工智能已经改变了员工访问和共享信息的方式,但只有18%的组织已经完全将人工智能治理纳入内部风险计划中。这种模式是持续的:人工智能已经嵌入到日常工作中。监督仍然在赶上。治理停留在文档形式中,差距就会变得越来越大。可交付的治理这个概念看似简单:如果一个治理要求不能阻止构建,就不能保护生产。真正的治理具有输入、输出、执行点和可观察的结果。它持续运行——不是季度运行。并且,关键的是,它会在工作过程中产生证据,而不是作为一个单独的合规性仪式附加在后面。运行模型如下:政策 → 控制 → 证据 → 指标政策定义意图。控制执行行为。证据证明执行。指标验证结果。这不是一个新想法——它正是成熟的安全和合规系统已经在运行的方式。转变是将同样的逻辑应用于人工智能。控制不是建议。证据不是文档。如果一个控制需要手动努力来产生证据,那就不是控制,而是希望。风险等级,而不是风险剧场并非所有人工智能系统都值得同样的审查。将低风险的内部工具与临床决策支持模型同等对待,这是组织停滞不前或不必要地暴露自己的一种方式。2023年发布的NIST人工智能风险管理框架为思考这一问题提供了基础结构——将人工智能风险映射到四个功能:治理、映射、测量和管理。一个功能性的企业治理模型建立在这一逻辑之上,具有实用的风险等级: 等级 范围 控制 最小 内部工具,无敏感数据 注册,轻量级检查 有限 面向用户,中等风险 文档,提示审查,安全测试 高 受监管或高影响决策 正式风险评估,审计日志,严格变更控制 禁止 不可接受的用例 在设计和部署中被阻止 这为工程团队提供了他们从治理流程中很少得到的东西:清晰度。不是“我们应该做什么?”而是“这是哪个等级,它会触发什么?” 好的治理消除了模糊性。优秀的治理消除了辩论。代码中的政策:从建议到可执行在文档中编写的政策是建议性的。在管道中编码的政策是可执行的。与基础设施在部署前验证类似,人工智能系统可以通过自动检查来验证用例是否注册,所需文档是否存在,评估结果是否达到定义的阈值,是否遵循最小特权访问敏感数据。这些检查在CI/CD中运行。它们不需要委员会。它们不依赖于任何人的记忆或善意。Open Policy Agent——一个毕业的云原生计算基金会项目——展示了规则如何被版本化、审查和在工程生态系统中一致执行。这种模式是可以理解的。差距在于人工智能团队没有应用它。最安全的人工智能系统不是拥有最好的政策的那个,而是技术上无法违反政策的那个。LLM特定控制:事情变得有趣的地方生成式人工智能引入了一类传统治理框架没有设计的风险——提示注入、输出操纵、工具滥用。这些不是边缘情况。它们是LLM工作的结构性属性,正如Unite.AI关于代理人工智能治理的报道所注意到的,随着人工智能系统从回答问题转向采取行动,治理差距变得更加明显。针对GenAI系统的有效治理需要专门为LLM行为构建的控制:系统指令和用户输入的严格分离,受控的工具访问和允许列表,在执行前输出验证,防止数据外泄的防护措施,以及安全默认值以实现优雅的故障。这些直接映射到OWASP...