当AI智能体开始拥有“生产环境写权限”,企业真正的风险已不再是技术能力,而是失控后的责任与恢复机制。Replit AI误删生产数据库事件,暴露出一个残酷现实:很多企业已经把“整栋大楼的钥匙”交给AI,却没有明确谁负责、如何叫停、如何回滚。

如果AI智能体删了你的数据库,谁来背锅?在把整个公司的钥匙交给自主运行的机器人之前,你需要明确的护栏机制和一套”撤销”策略。

去年,一个Replit AI编程智能体在代码冻结期间,删除了一家公司的线上生产数据库。”这是我方的灾难性失误,”它轻描淡写地承认道,”我在几秒钟内毁掉了几个月的工作成果。”虽然数据最终通过回滚得以恢复,但该智能体认为破坏是永久性的,而且它自身并没有内置任何撤销操作的机制。

对CIO而言,这不仅仅是一次技术故障,更是企业问责体系的全面崩塌。当一个智能体造成如此大的损失时,甩锅通常在三方之间打转:提出使用该工具的业务部门、授予其写入权限的工程师,以及签字放行的安全团队。

光靠软件本身是无法承担责任的,而根据麦肯锡的数据,AI采用率已达到88%的企业中,许多企业仍然无法明确回答:谁该为后果负责。Rubrik Zero Labs的一份新报告凸显了这一问题:86%的IT和安全负责人预计,AI智能体将在未来一年内超出其组织安全护栏的管控能力。

IT必须牵头降低智能体风险

那些将AI智能体视为实验而非核心基础设施的企业,承担着更高的风险,这种做法之所以在规模化时失败,不是因为技术能力不足,而是因为运营成熟度不够。MIT的一项调查显示,95%的生成式AI试点项目未能带来可衡量的业务价值,往往是因为它们被强行塞进了现有流程,却缺乏一套合理的管理框架。

我与许多IT负责人交流过,他们都提到了这个问题。团队用智能体做数据分析或客户服务的实验,但一旦出了问题,第一个障碍就是搞清楚谁来协调响应,部分困惑源于对这些智能体本质的误解。与标准的SaaS API不同——后者专为狭窄、特定的功能而构建,需要频繁重新认证——AI智能体可以是部分自主甚至完全自主的。

借助模型上下文协议(Model Context Protocol,MCP),智能体可以与整个SaaS平台交互,而不仅仅是一扇”门”。本质上,你只需认证一次,智能体就拿到了整栋大楼的钥匙,可以在工作流中调取它所需的任何资源。从功能隔离到全平台自主的转变,正是旧有治理规则不再适用的原因。

责任共担框架

在Rubrik,我们通过AI卓越中心(CoE)采用责任共担模型。为了领导这项工作,我们制定了一套明确的角色与职责矩阵来管控AI战略,我们的CTO与总法律顾问、CFO以及我本人共同担任高层决策者。高级策略团队包括CISO、总法律顾问和全球架构负责人,其下是IT、信息安全和法务部门的架构师及跨职能负责人,他们负责实际的培训、工具审批和执行。

我们的方法聚焦于三大支柱:安全地采用和治理Claude等第三方工具、建设我们自身的内部AI能力、以及将AI集成到核心产品中。在这个CoE之下,我们应用与管理任何企业技术相同的原则,但明确了各部门的权责。

IT负责架构和部署标准,信息安全团队提供持续评估,排查提示注入风险和漏洞,法务部门为数据处理和自动化决策划定护栏,最后,业务团队作为消费者,利用AI来改造运营。CoE的存在就是为他们服务,确保如果他们不遵守这些标准,就不会因错位而引入风险。

让治理落地可行

我们要快,但不能鲁莽。如果现有护栏包含强有力的治理和可恢复性机制,那么授权智能体执行写操作就不应是一个令人恐惧的决定。我们的流程确保:当团队识别出对智能体的需求时,有一条从初始申请到技术和安全审查、再到受监控的生产环境的直通路径。

我们在自身的内部AI部署中亲身体会到了这一需求,随着我们推出越来越多的工具,每一个都有自己的一套条款和规范,我们一度陷入了混乱,没有一个全局性的方式来建立保障措施。通过采用智能体云框架,我们实现了全面的可观测性和 remediation(修复),并在智能体层面自动执行了安全策略。

例如,当我们在内部测试环境中扩大使用Claude Code时,发现了一类无法干净地映射到现有控制措施的安全问题。为了控制这类行为,我们定义了一条策略边界:禁止将数据从智能体环境传输到外部代码仓库、论坛和其他面向公众的平台。

恢复时间问题

这些故障带来的运营风险正在上升,根据Rubrik Zero Labs的报告,近九成负责人表示,随着智能体驱动的威胁增加,他们对能否达成恢复目标感到担忧,此外,88%的人表示,如果不造成系统中断,他们无法回滚智能体的操作。当智能体故障与安全或数据完整性问题叠加时,如果没有一个框架,恢复就变得不可能。

在实践中,检测通常从消费者端开始。例如,我们使用了一个”PTO Agent”(请假智能体),它扫描日历并与HR系统交叉比对,以确保请假请求一致。我最近收到了这个智能体发来的一条Slack提醒,指出我四月有OOO(外出)时间并要求记录,尽管我已经批准过了。虽然只是一次轻微的”幻觉”,但它测试了我们的流程:问题流转到IT服务台,自动通知AI交付团队和业务负责人。目前,我们的团队人工对这些错误进行分类处理,修复bug后重新部署,但我们的路线图计划引入人在回路(human-in-the-loop)组件来实现这一分类的自动化。

AI智能体:从创新走向运营

正式建立AI治理的企业,将其AI效率提升的27%归功于这些护栏。许多AI治理的失败归根结底是企业在急于部署时跳过了两件事:

• 将智能体视为一等身份。大多数”失控”行为本质上都是权限失败,如果一个智能体没有以严格的最小权限原则集成到你的身份提供商中,也没有清晰的审计轨迹,那它就不应该出现在你的网络上。我们必须像对待员工一样对待智能体:它们在系统中需要一个”管理者”,以及一个可以被即时撤销的身份。

• 要求架构可逆性。传统环境依赖”撤销”按钮和版本控制,AI智能体在线上生产环境中运行,而”撤销”往往是不可见的。在智能体走出试点阶段之前,你的架构审查必须回答:如果这个智能体做了一个未授权的更改,我们如何在不中断业务的情况下精准地撤销它?智能体可逆性需要以意图为驱动、上下文丰富的AI治理引擎来维持管控。

企业必须拥有正确的策略来保障智能体的安全运营,逐步构建模型。从IT主导的关键功能监管开始,随着经验积累逐步扩展。现在就建立运营问责机制的企业,将能够有效地规模化AI,而那些继续零散、无治理地部署的企业,将在每次出问题时继续玩”谁来负责?”的游戏。

文章来自:51CTO

Loading

作者 yinhua

发表回复