开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户;每位用户只能获得一次试用。


要用 AI 规划业务连续性桌面演练,先从获批的连续性计划中选择少量能力,写出可观察的演练目标,再让 AI 根据受控输入起草场景材料。演练负责人必须批准安全边界、评估证据和决定改进动作;模型不能认证准备度,也不能虚构恢复目标。
先采用负责任使用 AI 的通用流程:约束任务、保留来源,把重要决定交给人。桌面演练是结构化讨论,不是真实事故、完整连续性计划或技术恢复已经成功的证据。
关键要点
- 测试获批计划和具名能力,不凭空创造组织。
- 先写可衡量目标,再设计场景和 inject。
- 分开参与者、主持人、控制员、评估员和决定负责人。
- 建立无责学习环境、保密要求和停止条件。
- 先记录观察和证据,再起草发现与改进项。
- 重要变更必须复测,不能由一次讨论宣告就绪。
核心产物是绑定特定计划版本和范围的演练包,包括目标、假设、角色、场景时间线、受控 inject、主持问题、评估指南、观察记录和改进闭环。
FEMA HSEEP 提供演练项目管理、设计、实施、评估和改进规划的共同方法。[1]FEMA 培训材料也区分不同演练角色,并把规划周期与纠正措施相连。[2]组织可按行业、权限和风险调整这些原则,不应随意宣称正式符合 HSEEP。
| 字段 | 用途 |
|---|---|
| 演练 ID 与版本 | 唯一标识演练包 |
| 计划与被测能力 | 防止范围漂移 |
| 目标 ID | 关联可观察结果 |
| 场景假设 | 指明可接受的前提 |
| Inject ID、时间与来源 | 控制信息何时引入 |
| 目标接收人 | 指定接收 inject 的角色 |
| 预期讨论 | 指导评估,不替参与者作答 |
| 观察与证据 | 保存实际发生内容 |
| 评估人及置信度 | 保留责任与不确定性 |
| 发现 | 与证据关联的优势或缺口 |
| 整改负责人及期限 | 让改进任务可执行 |
| 批准与复测 | 通过授权审核闭环 |
列出演练发起人、规划负责人、主持人、控制员、评估员、参与团队和观察员。记录要测试的连续性计划、危机程序、依赖图、联系人或恢复手册版本。
两小时讨论无法覆盖所有威胁、地点、供应商和系统。选择管理层通知、备用办公点、关键供应商升级、手工订单处理或客户沟通等一个窄能力。除非另有获批的实操测试,禁止真实触发应急通知、生产切换、公开声明、执法联络或员工处分。
避免“验证计划”或“提高韧性”这样的目标。它们没有告诉评估人员要收集什么证据。可观察的目标应写明能力、条件、动作和评价依据。
示例包括:
恢复时间目标(RTO)、恢复点目标(RPO)、最低人员配置、财务容忍度和监管期限,必须来自获批的计划和业务影响分析。AI 不得因为场景看起来不完整就编造这些数字。
设计一个能对所选能力施加压力、但不会压垮参与者的场景。定义初始事件、运行背景、已知事实、未知信息、时间推进和被排除的复杂情况。除非政策允许使用受控的真实信息,否则使用虚构的组织、姓名、账户数据和标识。
CISA 的桌面演练资料使用场景模块、主持人问题和讨论式评估,帮助组织探讨网络安全事件。[3]值得借鉴的是其结构:分阶段释放信息,并让团队运用自己的计划。不要未经核实事实和权限是否相符,就把网络安全场景照搬到供应链、设施、健康或人力方面的演练中。
请 AI 提供两三个场景变体,再由策划团队剔除不合理的依赖、不安全的操作、隐含的假设,以及不服务于任何目标的戏剧性细节。真实感来自准确的组织约束,而不是一个精心编排的灾难故事。
| Inject 字段 | 示例 |
|---|---|
| Inject ID | INJ-04 |
| 触发条件 | 25 分钟后或作出升级决定后 |
| 消息 | 供应商报告延期两天,原因未知 |
| 接收人 | 采购连续性角色 |
| 目标关联 | 依赖升级处理 |
| 预期证据 | 已指定负责人、使用获批路径并记录不确定性 |
| 控制人备注 | 除非参与者请求核验,否则不提供原因 |
每条 inject 都应关联目标,指定投放时间或条件、接收角色、已知信息以及评估员要观察的证据。不能只为增加戏剧性而制造噪音。
例如“供应商报告延迟两天、原因未知”可测试团队是否找到依赖负责人、使用获批升级路线并把原因保留为未知。评估指南可以列出计划依据,但不能规定唯一“正确”的业务决定。
只提供获批的范围、计划摘录、目标表、角色说明、场景事实和输出结构。除非获批的环境和需要证明其合理,否则移除个人联系方式、机密的设施信息、凭据、客户数据和敏感的安全弱点。
只根据提供的演练控制起草场景和 inject 候选。
保留目标 ID、角色名称、计划引用、假设和未知项。
不要编造恢复目标、法律义务、联系人、系统行为或批准。
不要给参与者打分,也不要宣布组织已准备就绪。
返回缺乏依据的细节和目标缺口,交策划团队审阅。
NIST 的生成式 AI 配置文件强调了虚构内容、隐私、信息完整性和人机配置方面的风险。[4]保留原始草稿、审阅人的更正和最终获批的演练包,让之后的评估人员能够区分模型建议与演练证据。
规划团队应排练时间、inject 顺序、投放渠道、主持问题、控制员回答、评估分工、记录方式、休息、无障碍和停止条件。主持人要能让讨论围绕目标,而不是逼迫大家说出预设答案。
工作坊主持流程可帮助安排会议,但演练控制与普通参与不同。dry run 还应测试参与者索取未定义事实、质疑假设和提前发现真实缺陷时如何处理。
开场说明目的、范围、无责原则、保密、角色、安全边界,以及演练时间与真实时间的区别。请参与者说明哪个计划章节、角色、依赖或决定权限支持某项动作。
记录带时间戳的观察,而不是对人的评判。“团队在 12 分钟后找到了供应商联系人信息”是可观察的;“采购部门没有准备”是一个结论,可能既不公平,也缺乏依据。记录相互矛盾的说法和缺失的证据,留待之后复核。
不要使用 AI 监控个人表现,也不要让它从记录中推断压力、能力、意图或责任。如果获准使用转录或摘要,就要告知参与者、尽量减少访问、设定保留期限,并核实每一句被归属的发言。
先把控制人员日志、评估人员笔记、参与者反馈、决定和引用的计划章节对齐。然后起草发现,每项发现都附上证据定位、受影响的目标或能力、影响、不确定性和建议的负责人。
经验复盘流程可以帮助区分观察与改进。一项发现不应仅仅因为模型预期了不同的答案而存在。它必须有演练记录的支持,并经负责该能力的人员复核。
对每一项获批的纠正措施,按组织政策记录优先级、负责人、期限、资源或依赖、完成证据、批准人和复测方法。把进度或职责方面的风险纳入风险登记册,但不要把接受风险与修复控制混为一谈。
选择与变更相称的验证方法。更正后的联络树可能需要一次受控的通知演练;改写后的角色说明可能需要一次走查;技术恢复方面的变更则可能需要在安全环境中进行获授权的功能测试。
把改进工作关联到普通的项目计划,同时保留演练证据。只有当所需证据和批准人齐备时,才把措施标为完成;只有在执行了既定测试之后,才把能力标为已复测。
一次顺利的桌面演练并不能证明恢复性能。讨论式演练能揭示假设和协调上的缺口;功能演练、全规模演练、技术测试和真实事件提供的是不同的证据。请准确报告哪些内容经过了演练,哪些没有。
它能依据获批输入起草材料,但规划团队必须核对组织事实、安全、目标、inject、权限、评价标准和无障碍安排。
不等同。桌面演练测试讨论和协作,不能证明系统、设施、供应商或人员会在真实恢复中正常工作。
采用在可用时间和参与角色内能够充分讨论、收集证据的最小集合。目标太多会削弱每项评估。
应告知目的、范围、准备材料、保密和安全规则。是否透露具体 inject 取决于设计,但不能用危险或惩罚性惊吓制造真实性。
不应推断个人能力、意图、压力或责任。应由获授权评估员根据可观察证据评价计划和能力。
记录决定,询问证据与权限,并只在控制规则内调整场景。意外推理可能暴露重要假设。
不需要。负责人应先判断它是优势、缺口、已接受风险、信息问题还是超出范围,并保存理由。
会议会按计划结束,但改进周期还包括证据审核、动作批准、完成核验和复测,不能因会议结束就宣称就绪。
免责声明: 本文只提供一般业务连续性和 AI 治理信息,不替代应急、安全、法律、监管、劳动、行业或组织要求。
Sources checked 2026 年 9 月 6 日。
注册即可免费体验全部高级功能。
*仅限新用户;每位用户只能获得一次试用。