Tradicionalmente, los ejercicios de simulación para la gestión de incidentes, conocidos como «tabletops», se diseñaban para evaluar una pregunta clave: cuando algo falla, ¿las personas responsables actuarán de forma correcta, ordenada y con la rapidez suficiente? Durante años, esta evaluación se centraba principalmente en las capacidades humanas: la formación recibida, los protocolos establecidos y la toma de decisiones bajo presión. Se partía de la premisa de que las herramientas tecnológicas eran estáticas e infalibles, por lo que solo se ponía a prueba a las personas, pues eran el factor variable.
Sin embargo, esta suposición ya no se sostiene. En empresas como Webflow, se ha invertido un año en integrar la inteligencia artificial en aspectos de la respuesta a incidentes que antes dependían exclusivamente de humanos, como la clasificación de alertas, la selección automática del protocolo adecuado, propuestas de respuesta y hasta la elaboración de análisis postincidente con sus tareas correspondientes.
Como se ha explicado anteriormente, esta inclusión de la IA multiplica la eficacia del equipo de seguridad en lugar de sustituirlo, pero implica un reto al que aún pocas organizaciones han prestado atención: si la IA participa activamente en la respuesta a incidentes, también debe formar parte de los ejercicios tabletop. Ya no basta comprobar si los técnicos conocen bien los protocolos; es imprescindible probar que el sistema de IA que les proporciona esos protocolos funciona correctamente bajo presión. 
Este no es un problema exclusivo del equipo de seguridad. Cualquier departamento que haya integrado silenciosamente un sistema de IA en sus procesos de respuesta —desde soporte técnico que deriva casos complejos, pasando por equipos de fiabilidad de sitios (SRE) que gestionan interrupciones, hasta el área de TI que automatiza accesos— tiene esa dependencia que no se somete a prueba. Si los formatos de los ejercicios tabletop no se han actualizado tras la introducción de la IA, se está ensayando un equipo obsoleto, sin detectar posibles vulnerabilidades.
De evaluar personas a evaluar sistemas
Diseñar ejercicios tabletop clásicos asumía un conjunto fijo de herramientas tecnológicas y un grupo variable de personas. Los escenarios variaban, pero las situaciones estaban planteadas para decidir quién recibe alertas, quién toma decisiones y si se siguen los protocolos bajo estrés. La tecnología era un componente inmutable, sin posibilidad de fallo o malfuncionamiento que mereciera ser analizado en el informe postincidente.
«Cuando un sistema basado en IA clasifica alertas, un fallo durante un incidente no se presenta como un servidor caído, sino como un resumen erróneo presentado con total confianza.»
Pero esa realidad cambia cuando la IA actúa de intermediaria entre el equipo y la información que utilizan. Un error de la IA no se detecta fácilmente, porque no genera fallos evidentes, sino decisiones aparentemente seguras pero incorrectas: puede ofrecer un resumen erróneo de alertas, acceder a un protocolo obsoleto o sugerir acciones inseguras. Estos fallos son silenciosos y ralentizan o desvían la respuesta sin que nadie se percate hasta que es demasiado tarde. Por tanto, un ejercicio que no contempla la posibilidad de fallo en la IA está incompleto, pues solo evalúa parcialmente la cadena real que se activa en un incidente.
Inyecciones imprescindibles en los ejercicios actuales
Existen nuevas categorías de posibles errores relacionados con la IA que la mayoría de los ejercicios tabletop no contemplan aún, pero deberían incorporarse para mejorar la preparación:
- La IA proporciona una respuesta incorrecta o parcial con total confianza. Este es el caso más relevante y el más sencillo de omitir por incomodidad. Es necesario diseñar escenarios en los que la IA cometa errores evidentes, como identificar mal la causa de un problema o extraer protocolos antigüos. La meta no es esperar que la IA sea infalible —ya que, inevitablemente, puede producir errores o “alucinaciones”—, sino comprobar si los responsables detectan esas equivocaciones y mantienen una actitud crítica en lugar de confiar ciegamente.
- Disponibilidad del sistema de IA. Especialmente crítico en seguridad, es fundamental prever y practicar qué sucede si la IA que se utiliza para investigar un incidente está comprometida o fuera de servicio. Mientras la mayoría de equipos cuenta con planes alternativos para fallos en sistemas tradicionales como los SIEM, pocos han ensayado la gestión cuando la IA, pieza central del triage, falla o desaparece, dejando a parte del equipo sin herramientas.
- Las barreras de seguridad se ponen a prueba bajo presión real, no solo en revisión. Las medidas de seguridad que en un entorno tranquilo parecen sólidas, pueden ser ignoradas o saltadas de forma discreta cuando el estrés y la fatiga se acumulan durante un incidente. Un buen ejercicio debe situar a un operador en esa tesitura para observar sus decisiones reales, más allá de lo que dicta la política.
- Olvido de los métodos tradicionales. La dependencia continua de la IA en la búsqueda rápida de protocolos y clasificación de alertas puede atrofiar las habilidades manuales del equipo. Si la IA lleva ayudando mucho tiempo, es probable que el personal haya perdido agilidad para buscar documentación o realizar triage manual bajo presión. Debemos practicar esa capacidad de forma intencionada antes de que un incidente real ponga a prueba esta competencia olvidada.
- Falta de claridad en el punto de traspaso entre IA y humano. La colaboración entre inteligencia artificial y humanos se basa en un límite claro: la IA sugiere y el humano decide y actúa. Los ejercicios tabletop son clave para comprobar si quienes participan entienden realmente esta delimitación o solo la conocen sobre el papel. Se debe incluir un escenario donde la sugerencia de la IA, aparentemente correcta, sea en realidad errónea, para ver quién detecta la anomalía.
Adaptaciones necesarias en la ejecución de los ejercicios
No es necesario desechar los programas tabletop existentes, pero sí añadir nuevas capas para contemplar los desafíos que introduce la IA. Algunas recomendaciones prácticas:
- Diseñar inyecciones específicas para la capa de IA y no solo para el factor humano. Si los escenarios solo describen eventos que afectan sistemas y equipos humanos, sin tocar la herramienta de IA, hay una importante fuente de fracaso inadvertida.
- Incluir en los ejercicios a los responsables de desarrollar y mantener las soluciones de IA, no solo a los usuarios finales. Ellos entienden mejor los posibles modos de fallo y se beneficiarán de una reflexión forzada que los talleres facilitan.
- Tras el ejercicio, evaluar no solo si se siguieron los protocolos, sino si el equipo asignó a la IA el nivel adecuado de confianza —ni demasiado escasa, desperdiciando el potencial, ni excesiva, lo que puede dar lugar a incidentes por errores no detectados en la IA.
- Repetir pruebas de manera regular, ya que los sistemas de IA cambian constantemente: actualizaciones de modelos, incorporación de nuevas fuentes de información o ajustes en las barreras de seguridad alteran la respuesta, y un ejercicio realizado hace un año puede no reflejar el estado actual.
Lo difícil pero necesario
Paradójicamente, quienes más tienden a saltarse estas actualizaciones en los ejercicios son los equipos que mejor rendimiento obtienen con la ayuda de IA, porque no perciben problemas evidentes y les incomoda buscar debilidades en una herramienta que funciona. Esto es un error. Cuanto más dependan del sistema de IA, mayor será el coste de identificar sus fallos por primera vez en un incidente real en lugar de un ejercicio simulado.
«Cuanto más soporte reciba la respuesta de la IA, más caro resulta descubrir sus fallos durante un incidente real en vez de en uno de práctica.»
Por ello, cualquier equipo que utilice inteligencia artificial para clasificación, recuperación de información o propuesta de acciones, ya sea en seguridad o en otros ámbitos, debe preguntarse: no solo si el equipo humano está preparado, sino si el sistema completo, con IA incluida, ha sido probado a fondo. El mensaje final es claro: testea el sistema antes de que sea el incidente quien lo ponga a prueba.
