拥有一份包含AI风险的电子表格固然不错，但当模型真正崩溃时，它既无法告诉团队该做什么，也无法明确谁能按下紧急停止开关。
一位安全分析师正在审查一张工单，该工单报告某个内部AI工具在实时业务工作流中输出了错误的建议，风险不再只是停留在理论层面。有人想知道，这究竟是一起安全事件、模型问题、隐私问题、供应商问题，还是仅仅属于“AI自己犯的毛病”。风险登记册里确实有一行关于输出不准确的条目，甚至可能还有一个严重性评级。
但它唯独没有回答大家现在都在问的问题：究竟谁有权力停掉这东西?
这正是许多AI治理计划仍需弥补的差距，各企业在识别AI风险、归档记录以及归类治理方面做得越来越好，然而，当AI风险演变成必须进行调查、遏制和解释的真实事件时，他们在操作层面的准备往往显得不足。
在安全计划中，这种区别至关重要。风险登记册可以记录顾虑，但它无法保存证据、通知领导层、评估影响，也无法决定AI系统是否应该继续运行。安全主管需要的不是另一份写着“AI可能会失灵”的电子表格，他们需要的是一套在AI失灵时可执行的应急响应模型。
清单不等于应急响应
风险登记册之所以有用，是因为它创造了可见性，它能帮助企业明确风险名称、比较严重程度、指定责任人，并向领导层汇报顾虑。在AI应用的早期阶段，可见性非常重要，因为许多企业仍在摸索AI具体被用在了何处、涉及哪些数据，以及哪些业务流程可能会受到影响。
但风险登记册并不是一种控制措施，安全团队在其他领域早已明白这个道理：漏洞清单不等于漏洞管理计划，第三方风险清单也不等于供应商风险管理功能，清单仅仅是这项工作的开端。
AI风险引发了同样的问题，一个写着“模型输出可能不准确”的风险条目，并没有指定谁来监控输出质量、多大程度的误差是可以接受的、应该保存哪些证据，或者谁可以暂停系统。一个写着“敏感数据可能会泄露”的风险条目，也没有说明提示词是否被记录、输出是否经过审核、供应商是否可以使用提交的数据，或者该事件是否应该触发隐私、法律或安全层面的升级上报。
正是在这一点上，AI治理表面看起来可能比实际要强大。企业可能拥有政策、委员会、接入表单和风险登记册，但这些产物并不能自动转化为运维准备就绪状态。当事情发生时，真正的考验在于企业是否知道下一步该怎么做。
AI事件的表象未必像数据泄露
挑战的一部分在于，AI事件的表象往往不像传统的网络安全事件。数据泄露有人们熟悉的模式：未授权访问、数据外泄、恶意软件、凭据篡改或系统中的异常活动，而AI故障可能会更加混乱，因为它们最初可能表现为一个糟糕的建议、误导性的总结、不安全的自动化操作、有缺陷的分类，或者是默默改变了某项决策的输出内容。
这并不意味着它们不重要，用于安全工作流中的AI工具可能会对告警产生误判，生成式AI助手可能会在回复中泄露敏感信息，内嵌在业务流程中的模型可能会随着时间推移发生漂移，从而产生不可靠的建议，供应商管理的AI功能可能会在一次未经企业全面审查的更新后改变行为模式。
安全团队需要一种实用的方法来对这些事件分类，并非每一个AI错误都需要被当作严重的安全事件来对待。即便如此，任何在核心工作流中使用AI的企业，都应该清楚与AI相关的事件是如何被汇报、分流和升级上报的。如果没有这种架构，团队可能会在影响持续扩大的同时，把时间浪费在争论责任归属上。
第一步是明确什么才算作“AI事件”，该定义应该足够宽泛，以涵盖安全、隐私、合规、运维和法规遵循方面的顾虑，但又要足够具体，让员工知道何时应该进行汇报。一个令人困惑的聊天机器人回答可能不需要与数据泄露事件同等的响应级别，但两者都应该有复核的路径。
调查之前必须先有证据
事件响应依赖于证据，这在网络安全领域是显而易见的，但在AI治理的讨论中却经常被忽视。如果一个企业无法复原发生了什么、谁使用了系统、涉及了哪些数据以及输出了什么内容，它将很难调查该事件或为其响应措施提供合理辩护。
AI系统可能会使这种证据链变得复杂，提示词可能没有被记录，输出可能没有被保留，供应商工具提供的可见性可能很有限，模型版本可能会发生变化，用户可能会将AI生成的内容复制到其他系统中而没有保留其来源，业务团队可能会将AI输出视为普通建议而非系统事件。
安全主管应该在AI系统投入生产环境之前就推动明确证据要求，企业至少应该清楚有哪些日志可用、日志保留多久、谁可以访问这些日志，以及它们是否足以支撑调查。对于较高风险的使用场景，团队可能还需要保留模型版本、提示词历史、输出历史、用户操作、数据源以及下游决策的记录。
这并不意味着每次AI交互都需要严密监控，监控应该与风险成正比，企业仍需尊重隐私、法律和员工层面的考量。核心要点很简单：如果AI系统重要到足以影响实际工作，那么当出现问题时，它就重要到必须留下证据链。
所有权不能靠暗指
AI的所有权往往是碎片化的，业务部门可能是该使用场景的发起方，数据科学团队可能负责配置模型，IT部门可能管理平台，安全部门负责评估风险，而供应商可能提供底层能力。每个人都参与其中，但在上线部署后，可能没有任何人能全面负责。
这种模糊性在发生事件时会变得非常危险，如果一个AI工具开始产生不可靠的输出，企业需要明确谁拥有该系统、谁拥有该业务流程，以及谁拥有决定继续还是停止使用的决策权。治理委员会可以提供监督，但它通常无法担任每个已部署AI能力的运维所有者。
安全计划应坚持明确AI系统的具名所有者，尤其是那些用于敏感或高影响工作流的系统。所有权应包括监控、特例处理、用户指导、供应商协调和事件升级上报的责任，它还应该包括决策权，因为没有权力的问责不过是电子表格里的一个名字罢了。
最难回答的问题往往是暂停权：当风险超出承受能力时，谁可以暂停、限制、回滚或停用AI系统?如果这个问题在部署前没有得到解决，企业可能被迫在巨大的压力下仓促应对。
安全主管需要一份AI响应剧本
AI响应手册不需要很复杂，但必须实用，它应该说明员工如何汇报AI顾虑、事件如何分流、保留哪些证据、由谁进行调查、何时引入法律或隐私团队，以及谁可以做出运维决策，它还应该明确何时需要通知高管层。
剧本应该体现出所涉及的AI系统类型，低风险的内部生产力工具可能只需要轻量级的复核路径，而支持安全运营、受监管决策、客户沟通、医疗工作流或财务流程的AI系统，则需要更强的监控和升级上报机制，响应模型应当匹配具体使用场景的风险等级。
这正是安全团队可以在不把AI治理变成官僚主义的前提下增加规范约束的地方，安全团队早已懂得如何建立升级上报路径、保存证据、开展事件复盘并在故障后改进控制措施。现在的时机在于，趁着事件尚未逼迫企业就范，将这种运营能力延伸到AI治理中。
企业还应对有实质影响的AI事件开展事后复盘，目标不应是指责，而应是学习：监控生效了吗?所有者明确吗?证据充分吗?供应商响应了吗?用户对合规使用方式感到困惑吗?企业知道谁能做出决策吗?
治理必须具备可执行性
AI治理常常被作为政策、伦理或合规方面的挑战来讨论，它确实包含所有这些层面，但一旦AI系统进入生产环境，它就同时变成了一个安全执行力方面的挑战。风险必须被监控，事件必须被调查，而且必须有人能够采取行动。
这就是为什么迈向成熟的下一步不仅仅是完善文档，企业需要的是在系统上线、决策具有时效性且事实尚不完整时依然能发挥作用的治理机制。在那个时刻，风险登记册或许有助于解释企业的预期，但它无法替你执行响应。
安全主管不应等待AI治理从企业内部的其他部门凭空完美呈现，他们现在就应该协助塑造这套运营模型，因为此时许多企业尚处于早期阶段，完全来得及纠正方向。目标并不是要包揽每一个AI风险，而是要确保一旦AI投入运营，其风险能够得到妥善管理。
风险登记册可以告诉领导者可能会出什么问题，而事件响应计划能告诉人们当问题发生时该怎么做。要让AI治理在安全计划中真正发挥作用，企业两者不可或缺。
