Arvind Parthasarathi, 首席执行官和创始人，CYGNVS Arvind Parthasarathi 首席执行官和创始人，CYGNVS

AI事件正在成为运营危机，我们需要像对待传统危机一样对待它们

过去几年，大多数组织都在使用治理的语言来讨论AI风险。模型是否准确？是否公平？数据是否获得批准？我们是否遵守了新兴的法规？这些都是重要的问题，但它们并不是唯一的问题。更紧迫的问题是，当事情出错时会发生什么？当一个AI代理采取了它从未打算采取的行动时会发生什么？当一个模型泄露敏感数据时会发生什么？当一个产生幻觉的答案造成法律责任，或者自动决策影响客户、员工、患者或合作伙伴时会发生什么？最实用的问题是：组织在哪里协调响应？这是正在发生的转变。AI风险正成为一个运营韧性问题，而不仅仅是一个治理问题。AI正在从实验转移到企业的工作机制中。它正在被嵌入到客户支持、软件开发、财务运营、医疗工作流、招聘、索赔处理、供应链和内部自动化中。随着AI变得更加与业务相关，AI故障变得更加严重。OECD AI事件监测器跟踪了596个AI事件，仅2026年1月就增长了200%。像OECD AI事件监测器和AI事件数据库这样的努力记录了AI系统的负面或有害结果，以便行业可以从经验中学习，就像航空和网络安全行业多年来所做的那样。这种比较很重要。成熟的行业会问如何防止故障以及如何在故障发生时做出响应。AI事件与传统软件错误不同传统软件错误通常有一个相对清晰的边界。某些东西坏了，工程师调查，团队重现问题，修复代码，并发布补丁。然而，AI事件更复杂。它们可能是概率性的、间歇性的，并且来自模型、提示、检索系统、插件、代理、用户和下游业务流程之间的交互。有时AI系统按照设计运行，但设计不完整，导致响应更加具有挑战性。一个消费者聊天机器人中的幻觉是一种问题。在法律、金融、临床或人力资源工作流中，幻觉是另一种问题。在测试中出现偏见输出是严重的。在生产中运行的决策过程是另一回事。一个可以草拟电子邮件的AI助手是一件事，但一个可以更改权限、发出退款、更新记录、触发工作流或执行代码的代理是一个完全不同的风险类别。MIT AI风险存储库捕获了广泛的AI风险，包括虚假或误导性信息、隐私和安全故障、歧视、滥用和系统安全问题。 OWASP的LLM应用程序前10名 同样强调了诸如提示注入、敏感信息披露、不安全的输出处理和过度代理等风险。这些是实际的故障模式，而不是抽象的技术问题。 如果AI代理拥有太多权威，它可能会采取人类从未打算的行动。如果提示注入成功，系统可能会披露信息或遵循敌对指令。如果敏感数据通过模型或检索系统泄露，响应具有法律、监管、客户和声誉影响。因此，AI治理的语言有时会变得过于被动。治理告诉我们应该是什么。事件响应告诉我们当现实比政策移动得更快时该怎么办。响应将是跨职能的事件响应的一个最大教训来自网络安全：事件很少保持在安全团队内。在开始时，事件可能看起来很技术化。很快，它就涉及法律、沟通、业务领导、合规、客户团队、外部顾问、保险公司、法医专家和有时董事会。 AI事件将遵循相同的模式。想象一个暴露敏感客户信息的模型。安全和隐私团队需要了解发生了什么。法律需要评估义务。沟通可能需要为客户、监管机构或媒体做准备。工程可能需要禁用或回滚系统。业务领导者可能需要权衡连续性与控制。或者，想象一个开始在企业系统中采取意外行动的AI代理。技术团队可能能够关闭它，但组织仍然需要知道它做了什么、谁受到影响、什么决定被做出、是否触发了合同义务以及如何在未来防止同样的故障。这些不能由AI团队单独解决。组织应该在需要之前建立跨职能的肌肉记忆。这意味着清晰的升级触发器、清晰的角色、清晰的决策权、清晰的沟通路径、清晰的文档和练习。在危机中，协调是基础设施，而不仅仅是一种软技能。被调查的AI不应控制响应组织需要考虑的另一个问题是，如果被调查的AI系统可以访问用于协调响应的相同通信、文档、工作流或自动化，组织就有问题。在网络安全中，这是一个熟悉的原则。如果勒索软件已经损害了公司网络，你不会在攻击者可能能够读取、破坏或操纵的系统上协调响应。你需要脱离常规。你需要将事件与响应分开。同样的逻辑也适用于AI。AI系统可能不是人类意义上的恶意的，但如果它可以看到响应计划、总结响应会议、影响工作流、推荐下一步或在相同的环境中运行被用于包含它，那么组织就没有真正隔离响应。这在代理AI中变得更加重要。Google的安全AI框架强调了诸如提示注入、数据中毒和流氓行为等风险，并将它们映射到AI生命周期中的控制。这种是正确的框架。随着AI系统变得更加能够跨工具、数据和工作流运行，组织需要思考模型安全和运营分离。可以这样想：调查一场火灾。你不会希望洒水控制器与你试图诊断的故障系统相连。准备、练习、响应、报告AI事件准备的一个有用的框架与网络安全中成熟的框架相同：准备、练习、响应、报告。准备意味着在事件发生之前定义事件类型，如偏见、幻觉、数据泄露、模型漂移、提示注入、代理失控、未经授权的工具使用和第三方模型故障。每种都需要不同的利益相关者和不同的决策。一个好的剧本不应该是一个放在文件夹中的200页文档。没有人在危机期间打开第137页。一个好的剧本是基于角色的、可访问的和可执行的。法律知道法律需要做什么。工程知道工程需要做什么。沟通知道何时需要参与。董事会知道何时管理会升级。练习意味着运行桌面演练。不仅仅是一年一次作为一个复选框，而是经常足以建立肌肉记忆。董事会第一次讨论AI事件不应该是在真正的AI事件期间发生。法律、工程、隐私、安全和沟通第一次一起处理AI故障不应该是在客户已经在询问时发生。响应意味着以纪律的方式协调现场事件。谁在房间里？什么事实是已知的？什么事实仍然不确定？什么决定被做出？谁批准了它们？在第12个小时和第48个小时之间发生了什么变化?报告意味着认识到AI监管正在变得更加具体。 EU AI法案包括对某些高风险AI系统提供商的严重事件报告义务。细节将根据管辖权、行业和用例而有所不同，但方向是明确的。AI事件将越来越多地需要对发生了什么、什么是已知的、采取了什么行动以及何时采取行动的有理有据的记录。AI可以帮助，但不能取代判断有一个诱惑去认为AI事件响应应该是完全自动化的。我认为这是错误的框架。AI可以提供巨大的帮助。它可以总结事实。它可以识别缺失的信息。它可以将事件与先前的模式进行比较。它可以草拟事后报告。它可以帮助绘制监管义务。它可以在人们处于压力下时减少行政负担。但在严重事件中，人类仍然是不可或缺的。有人需要决定事实是否足够。有人需要权衡客户影响。有人需要决定是否暂停系统。有人需要确定组织是否越过了报告阈值。有人需要以责任感和同理心进行沟通。AI在事件响应中的正确角色不是取代危机团队。它是给危机团队更好的背景、更快的速度。NIST的AI风险管理框架是有用的，因为它将AI风险管理围绕四个功能：治理、映射、测量和管理。对于事件响应，我会添加一个实用的扩展：排练。一个从未被测试的计划不是真正的计划。它是一个理论。董事会也需要一个剧本AI风险正在成为一个董事会级别的话题，但董事会的参与不能仅限于监督幻灯片。董事会需要在危机发生之前了解他们的角色。什么时候会通知董事会？什么决定需要董事会的输入？管理层将提供什么信息？如何评估重要性、客户影响、法律风险、监管义务和运营中断?许多组织都有安全剧本、隐私剧本、沟通剧本和法律剧本。然而，很少有组织有AI事件的董事会剧本。这个差距将随着AI系统进入监管、收入产生和客户面向的工作流程而变得更加明显。董事会的角色是帮助组织在压力下做出更好的决策，而不是变得更加技术化。值得信赖的AI需要运营韧性关于值得信赖的AI，有很多对话。这种愿望是正确的，但信任不是由原则创造的。信任是当组织能够展示他们如何准备、如何检测问题、如何响应、如何沟通、如何记录决策以及如何改进时创造的。网络安全已经经历了这种演变。组织花了多年时间投资于预防，他们应该继续这样做。但是，成熟的组织最终学会了预防是不够的。你还需要韧性。AI正在进入同样的阶段。我们绝对应该建立更安全的模型、更强的控制、更好的评估、更好的红队和更好的治理，但我们也应该接受这样一个事实：事件将会发生。模型将会失败，代理将会表现出意外的行为，数据将会泄露，人类将会滥用系统，供应商将会犯错误，监管将会演变。问题是，当事件发生时，组织是否能够以速度、协调性、判断力和责任感做出响应。这就是AI从实验转变为可靠基础设施的方式，也是韧性成为文化的方式。