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进行分诊、检索或响应的团队，都应在本季度自问：是否真正测试了团队所依赖的系统，而非仅测试了人员。
Q&A
为什么AI融入事件响应后，传统的桌面演练不再适用？
传统桌面演练假设工具是静态的，只测试人员变量。但AI现在在事件响应中执行实际工作（如分诊、检索剧本），成为系统的一部分，因此必须测试AI层，否则演练只覆盖了一半的真实系统。
AI在事件响应中可能以哪些方式失效？
AI可能自信地给出错误或不完整的答案（如幻觉根因、检索过时剧本）、系统不可用、护栏在压力下被绕过、人员手动操作能力退化、人机交接点不清晰。
如何设计针对AI层的桌面演练注入？
编写专门针对AI层的注入，例如让AI分诊步骤幻觉根因、剧本查找返回过时文档、AI系统不可用、护栏被绕过、手动技能退化、交接点模糊等，并让AI开发者参与演练。
为什么需要让AI开发者参与桌面演练？
AI开发者通常最了解值得注入的失效模式，参与演练能促使他们思考这些失效，并帮助团队更好地测试AI层。
为什么“我们测试过一次”是不够的？
AI系统会变化：模型更新、检索源增加、护栏调整，静态文档无法反映这些变化。一年前测试的AI辅助响应流程已经不能代表当前系统，需要定期重测。
在AI辅助响应中，如何评估团队对AI的信任程度？
在事后总结中，除了问“团队是否遵循了剧本”，还要问“团队是否以恰当程度信任AI系统”——既不过少（浪费投资），也不过多（导致错误答案本身成为事件）。
