Artificial intelligence has changed how security and operations teams handle incidents, as it is now used for alert triage, runbook retrieval, action suggestions, and even preparing post-incident analyses. However, simulation exercises known as Tabletop Exercises still mostly test people’s knowledge of procedures and their ability to make decisions under pressure, without testing the intelligent system that has become an intermediary between them and the information.
The article, published by Webflow as sponsored content, argues that this leaves a practical gap: if artificial intelligence is part of the actual response process, it should become part of the testing as well. This applies to security teams, site reliability teams that use it to triage outages, support teams that rely on it to direct escalations, and IT operations that use it to automate access requests.
From Testing People to Testing the Entire System
Traditional simulation exercises assumed that tools were fixed and that the primary variable was people: Who receives the alert? Who has decision-making authority? And can the team follow the runbook quickly enough? But the failure of an artificial intelligence tool does not necessarily appear as an obvious malfunction. It may confidently provide an incorrect summary, retrieve an outdated runbook because it matches the keywords, or suggest an action that seems logical but is unsafe.
These quiet failures may slow the response or push the team toward the wrong decision without displaying an error message to alert it. Therefore, an exercise that does not include these scenarios tests only part of the system that will operate during a real incident.
Scenarios That Should Be Included in the Exercise
- Confidently incorrect answer: A hallucination in identifying the root cause or retrieving a nearby but outdated document can be simulated. The goal is not to assume that the system will not make mistakes, but to test responders’ ability to verify information and not treat the answer as fact.
- Artificial intelligence system outage: Teams should test what happens if the system used for investigation becomes unavailable or is affected by the incident itself, and whether the team still knows how to perform triage manually.
- Safeguard bypass under pressure: Controls may seem appropriate during a calm review, but they may be disregarded when the incident continues for hours and someone wants the system to execute the action instead of proposing it for human approval.
- Atrophy of manual skills: Long-term reliance on automated retrieval may weaken the team’s ability to search documents and execute steps without assistance.
- Handoff ambiguity: Teams should test whether employees clearly understand where the system’s role ends and the human decision begins, especially when the automated recommendation is persuasive but partially wrong.
How Can Teams Update Their Exercises?
Organizations do not need to eliminate their existing programs; instead, they should add a layer targeting the artificial intelligence tool itself. The people who build and operate these tools should also be involved, because they are best positioned to identify their failure patterns. The review session should also move beyond the question, “Did the team follow the runbook?” to another question: “Did the team give the system the right amount of trust?” Low trust wastes the tool’s benefits, while excessive trust may turn an incorrect answer into a direct cause of the incident’s escalation.
The article emphasizes that one test is not enough, because models, retrieval sources, and safeguards change over time. Therefore, the exercise should be repeated whenever components of the system that affect response change.
Editorial Perspective from certi.news
The real change here is not adding artificial intelligence to the list of tools, but its move into an influential position in the decision chain. This broadens the scope of incident response: the team is not testing only the readiness of its members, but also the reliability of the intermediary that condenses information and suggests the next step. The limitations of the argument remain clear; the article does not provide independent measurement results or a standardized framework for evaluating these exercises, and it is based on Webflow’s experience. Its recommendations should therefore be treated as an adaptable practical framework, not as generally conclusive evidence.