在当前这波AI应用浪潮兴起之前，灾难恢复工作的重心在于备份和恢复企业应用、数据库以及传统IT基础设施的各类组件。

时至今日，这一核心任务依然存在，但企业还必须将AI模型、提示词和智能体纳入考量范围。这些资源能否被恢复？恢复之后，企业又如何验证它们仍然值得信赖？

"说实话，大多数组织在这一领域的灾难恢复计划，比AI实际应用落后了好几年。"Quest Software首席信息官Greg Sarich如此表示。

如果CIO和CISO想帮助企业迎头赶上，就必须着手更新灾难恢复计划，并在真实事故发生之前完成演练测试。

AI时代的"灾难"意味着什么

当企业在当今这个AI深度融合的环境中遭遇安全事件或服务中断时，灾难恢复团队需要应对的挑战远比以往复杂。

要获得回答上述问题所需的全面可见性，本身就是一大难题——AI已经渗透到企业技术栈的各个角落。

"如果你在使用Claude，它可能同时接触到你的Salesforce系统、SharePoint……你的Outlook系统，以及你存放在Snowflake等平台上的业务关键数据。"Sarich以此说明AI如何在企业内部构建起一张错综复杂的依赖关系网络。

"需要保护的不只是那些系统本身，还有AI在获取数据、生成结果过程中所触及的每一个交叉节点。"他补充道。

随着AI日益深入地嵌入业务流程，企业面临运营停摆的风险——尤其是当团队已无法回退到人工操作方式的时候。

"一旦AI助手、副驾驶或聊天机器人宕机，员工所依赖的机构知识就会随之断流。"德勤网络AI负责人、董事Mehdi Houdaigui说。

即便AI资源在事故后恢复运行，风险并未就此消散。企业必须验证这些资源的完整性，但涉及底层数据、提示词或模型的泄露往往难以察觉。

"我们看到的挑战在于，AI可能仍然可以正常运行。在外行人看来，它依然在自信地给出答案——但这些答案可能是错误的、不完整的，甚至是被人为篡改过的。"Houdaigui说道。

举例来说，企业或许能够恢复一个聊天机器人，但如果人们基于它提供的受损信息采取行动，灾难实际上仍在持续。

当智能体加入其中，影响范围会进一步扩大。"智能体越复杂，它需要接触的系统就越多，它能够触达并潜在影响的系统范围也就越广。"Houdaigui补充道。

即便灾难恢复团队清理了在多个系统中运行的受损智能体，损害也可能持续很长时间。

"一旦员工、组织对这些工具本身失去信心，后续的持续推广就会面临巨大障碍。"Sarich说。

如何构建AI灾难恢复计划

CIO和CISO在思考如何针对AI演进灾难恢复计划时，可以从以下几个基础步骤入手：

梳理AI资产清单

随着AI在各业务部门蔓延，加上影子AI带来的额外复杂性，全面掌握工具的使用情况并非易事。

"从AI资产清单做起。如果还没有，就必须尽快建立。你无法恢复一个从未被记录在案的东西。"Sarich说。

评估每项资产的业务关键性

"凡是与AI相关、或以AI为基础支撑业务运营的系统，都应该被列为一级优先或红色级别。"Hitachi Vantara全球数据与网络韧性解决方案负责人Chris Millington表示。Sarich也指出，面向客户的工具以及影响营收的系统应优先处理。

梳理依赖关系

AI已深度融入企业工作流程，因此厘清其依赖关系至关重要。"它使用哪些数据？依赖哪个模型？涉及哪些供应商？能访问哪些系统？最关键的是，它使用哪些凭据？"Houdaigui追问道。

评估权限管理

为实现有效恢复，IT和安全负责人需要了解AI智能体和工具所拥有的权限，并能够及时撤销凭据、终止特定任务。此后，在恢复并重新授予权限之前，还需对AI资产进行审查评估。

"在智能体重新上线之前，验证它是否在我们所定义的合规边界内运行，这从灾难恢复的角度来看至关重要。"Houdaigui说。

明确恢复目标

Houdaigui指出，组织需要定义恢复时间目标（RTO）和恢复点目标（RPO）。企业在AI资产方面，能承受多少数据损失和停机时间？模型、提示词和数据的最后可信版本是哪个？

灾难恢复计划还需明确在AI基础设施恢复上线前所必须经历的测试与验证步骤。

"AI系统涉及的步骤要复杂得多，这种复杂性来自于系统本身的概率性特质。"Houdaigui解释道。

测试与验证

一份从不演练、只在事故发生时才被翻出来的灾难恢复计划，实际上毫无价值。测试是关键，但鉴于AI变化的速度，每年或每季度一次的测试频率远远不够。新工具、新依赖关系和新风险，是AI时代的常态。

在演练过程中，企业需要找出灾难恢复计划中所有潜在的漏洞并加以弥补。

"要问清楚：如果知识库被篡改怎么办？如果无法访问某个大语言模型怎么办？如果API因故不可用怎么办？如果智能体出现异常行为怎么办？如果我们怀疑日志已不可信怎么办？"Houdaigui说，"这些演练将有助于快速暴露漏洞。"

灾难来临时该怎么做

尽管AI正在深刻改变业务运营，但网络安全领域那句老话依然成立："问题不是会不会发生，而是什么时候发生。"如果AI的部署速度持续超过治理能力，由智能体和工具引发的事故迟早会出现。

Proofpoint近期的研究调查了1,400名安全专业人员，发现其中42%曾遭遇与AI相关的安全事件（无论是疑似还是已确认）。此外，52%的受访者表示，他们对所在组织的安全控制措施能否检测出受损的AI系统并不具备完全信心。

企业已经在应对影响AI资源的各类事故，Sarich预计，一场重大事件迟早会将AI灾难恢复推向公众视野的聚光灯下。

"我相信，在不远的将来，我们一定会看到某个重大事件的发生。"他说。

无论是否演变为大规模公共事件，企业都终将不得不启动灾难恢复计划，执行应对流程，并在事后进行复盘，以便让计划在下一次事故中更加完善。Millington表示，企业团队需要追问的核心问题包括："我们恢复到了哪个时间点？这个结果是否可以接受？还有没有进一步优化的空间？"

AI韧性中缺失的那块拼图

随着灾难恢复策略不断成熟、应对企业AI的复杂性，一个关键问题仍悬而未决：

企业能否量化AI资源遭遇中断、泄露或其他事故所带来的损失？

Houdaigui认为，业界目前尚未就如何量化网络安全风险达成共识，更遑论AI相关损失。"整个行业都有机会认真思考：这些系统究竟带来多大的可量化损失敞口或风险影响？"他补充道。

随着企业对AI相关事故的运营和财务后果有了更清晰的认识，灾难恢复与韧性建设的成本投入，或许才能真正追上AI部署的步伐。

Q&A

Q1：为什么当前企业的AI灾难恢复计划普遍落后？

A：根据Quest Software首席信息官Greg Sarich的说法，大多数组织在AI灾难恢复方面的规划，比AI实际应用落后了好几年。主要原因在于AI已渗透到企业技术栈的各个层面，形成复杂的依赖关系网络，传统灾难恢复计划并未覆盖AI模型、提示词和智能体等新型资源，加之AI治理体系尚不完善，使得全面的灾难恢复规划难以跟上AI部署的速度。

Q2：企业应该如何构建针对AI的灾难恢复计划？

A：构建AI灾难恢复计划需要从以下几个关键步骤入手：首先建立完整的AI资产清单；其次评估每项资产的业务关键性，将核心AI系统列为最高优先级；第三，梳理AI所涉及的数据、模型、供应商和访问权限等依赖关系；第四，明确恢复时间目标和恢复点目标；最后，定期进行测试演练，找出并填补计划中的漏洞，而非等到真实事故发生时才启动。

Q3：AI资源恢复上线后，如何验证其安全性与可信度？

A：这是当前行业面临的一大难题。德勤网络AI负责人Houdaigui指出，受损的AI系统恢复后可能表现正常，但给出的答案可能是错误的、不完整的，甚至是被篡改过的，普通用户难以察觉。因此，在AI资产重新上线之前，必须验证智能体是否在合规边界内运行，并评估底层数据、提示词和模型是否完整可信。这需要制定明确的测试与验证流程，作为灾难恢复计划的必要组成部分。