Qué distingue una buena gestión de incidentes de IA

Un sistema de IA empieza a producir decisiones inusuales. El equipo técnico corrige el problema en unas horas y el servicio vuelve a la normalidad. Sin embargo, nadie puede responder con precisión cuándo comenzó el fallo, qué versión del modelo estaba activa, cuántas personas fueron afectadas, por qué no se escaló antes, si existía una obligación de notificación o si el mismo patrón podría repetirse en otro sistema.

La falla técnica terminó. El problema de gobierno no.

Una buena gestión de incidentes de IA no consiste en abrir un ticket cuando el modelo “se comporta raro”. Es un proceso integral que conecta detección, clasificación, decisión, contención, investigación, comunicación, recuperación y aprendizaje. Para auditoría interna, la pregunta clave no es solo si la organización puede solucionar un incidente, sino si puede demostrar que respondió de forma oportuna, proporcional, trazable y capaz de reducir la probabilidad de recurrencia.

Un incidente de IA no es solo una caída del sistema

Los incidentes tradicionales de tecnología suelen asociarse con indisponibilidad, ciberataques o pérdida de datos. Un sistema de IA puede fallar sin dejar de funcionar técnicamente. Puede mantener una disponibilidad del 99,9 % y, aun así, producir resultados discriminatorios, degradarse por cambios en los datos, revelar información sensible, generar contenido incorrecto con impacto material o inducir a usuarios a tomar decisiones equivocadas.

El NIST AI Risk Management Framework trata la respuesta y recuperación como parte del manejo continuo del riesgo. Su función Manage incluye monitoreo posterior al despliegue, respuesta a incidentes, recuperación, gestión de cambios y documentación. El Generative AI Profile de NIST profundiza este enfoque: recomienda registrar y seguir errores, cuasi incidentes e impactos negativos, realizar revisiones posteriores y comunicar los incidentes a los actores pertinentes.

Esto obliga a ampliar la definición operativa de incidente. Una organización madura no espera a que exista daño confirmado. También establece criterios para registrar cuasi incidentes, incumplimientos de umbrales, resultados inesperados, fallos de controles, pérdida de supervisión humana e incidentes de terceros.

El momento de definir qué constituye un incidente no es durante la crisis, sino antes de que ocurra.

Los disparadores y el escalamiento deben estar definidos antes del incidente

La primera debilidad que debería buscar un auditor es una definición demasiado vaga. Expresiones como “escalar cuando el impacto sea significativo” parecen razonables hasta que nadie sabe quién decide qué significa significativo.

Los disparadores deben vincularse al perfil de riesgo del sistema. Pueden incluir desviaciones de desempeño por encima de límites establecidos, fallos de calidad de datos, resultados potencialmente dañinos, violaciones de políticas, pérdida de controles de supervisión humana, incidentes de privacidad o seguridad, quejas relevantes, fallos de un proveedor o cambios inesperados después de una actualización.

La clasificación debe considerar más que severidad técnica. Conviene evaluar, al menos, impacto sobre personas, alcance, reversibilidad, duración, exposición regulatoria o contractual, sensibilidad de los datos, posible propagación a otros sistemas y grado de incertidumbre. Un incidente con impacto todavía incierto puede requerir una escalada más rápida, no más lenta.

El escalamiento también necesita responsables y tiempos definidos. Para cada nivel de severidad debería quedar claro quién puede detener el sistema, quién lidera la respuesta, cuándo participan Legal, Riesgos, Cumplimiento, Privacidad o Ciberseguridad, quién informa a la alta dirección y qué eventos deben llegar al consejo o al comité correspondiente.

Las herramientas de apoyo del IIA para su AI Auditing Framework ofrecen un buen punto de referencia práctico. Su cuestionario de riesgos y controles de IA para la dirección presenta, como prácticas de ejemplo y no como requisitos obligatorios, un proceso que cubre detección, registro, clasificación, investigación, análisis de causa raíz, remediación, lecciones aprendidas y escalamiento de incidentes materiales.

Una respuesta sólida separa contención, investigación y remediación

Uno de los errores más comunes es confundir “arreglar el sistema” con “gestionar el incidente”. Son actividades relacionadas, pero cumplen propósitos distintos.

Etapa	Qué debería ocurrir	Evidencia que un auditor puede esperar
Contención	Limitar el daño: suspender una función, revertir una versión, activar un proceso manual, restringir usuarios o aislar una integración.	Hora de decisión, responsable, aprobación, versión afectada, medidas temporales.
Investigación	Reconstruir qué ocurrió, a quién afectó y por qué; preservar registros antes de modificar el entorno.	Línea de tiempo, logs, modelo y versión, datos, prompts o configuraciones relevantes, análisis de causas y controles fallidos.
Remediación y recuperación	Corregir causas y condiciones contribuyentes, validar la solución y autorizar el retorno a operación.	Plan de acción, pruebas, aprobación de reactivación, seguimiento reforzado y cierre formal.

La separación importa porque una corrección rápida puede destruir evidencia. Si el equipo sobrescribe la versión del modelo, cambia datos de referencia o elimina registros antes de preservar el estado del sistema, después puede resultar imposible determinar el alcance real o la causa del incidente.

ISO/IEC 42001:2023 aporta una lógica de sistema de gestión útil. La norma exige determinar qué debe monitorearse y medirse y, cuando existe una no conformidad, reaccionar, controlar y corregir, evaluar causas, implementar acciones correctivas y revisar su eficacia. Sus controles de referencia y la guía de implementación también abordan el reporte externo y la comunicación de incidentes. Esto no equivale a un único procedimiento obligatorio para todo incidente de IA: los controles se seleccionan y diseñan en función del tratamiento de riesgos y del contexto de la organización.

El reporte debe ser una decisión de gobierno, no un correo improvisado

Un incidente puede requerir distintas comunicaciones: al propietario del proceso, al responsable del sistema, a funciones de segunda línea, a la alta dirección, al consejo, al proveedor, a clientes o personas afectadas, y eventualmente a una autoridad.

Por eso el playbook debe contener una matriz de notificación que responda cuatro preguntas: qué tipo de evento activa la comunicación, quién decide si es reportable, a quién debe informarse y en qué plazo. Legal y Cumplimiento deberían validar esta lógica para cada jurisdicción y tipo de sistema.

El Reglamento (UE) 2024/1689 ilustra por qué no conviene codificar un plazo universal. Su artículo 73 establece reglas de notificación de incidentes graves para proveedores de sistemas de IA de alto riesgo, mientras que el calendario de aplicación vigente difiere según la categoría de sistema de alto riesgo. La lección es más amplia: la decisión regulatoria debe formar parte del flujo del incidente, con evidencia de quién evaluó la obligación, sobre qué hechos y con qué conclusión.

El reporte interno tampoco debería limitarse al número de incidentes. Para los órganos de gobierno son más útiles las tendencias de severidad, detección, contención, recurrencia, causas comunes, acciones vencidas y excepciones al apetito de riesgo.

Lo que auditoría interna debería poder reconstruir

La prueba más reveladora no es preguntar si existe una política. Es seleccionar incidentes reales y reconstruirlos desde la primera señal hasta el cierre.

Un auditor debería poder seguir la cadena completa: cuándo surgió la alerta, quién la recibió, cómo se clasificó, qué criterio activó la escalada, quién decidió contener, qué evidencia se preservó, cómo se determinó el alcance, qué obligaciones de comunicación se evaluaron, cómo se validó la solución y qué cambió después del incidente.

La evidencia incluye el registro de incidentes y cuasi incidentes, criterios de severidad, alertas y umbrales, matriz de responsabilidades, bitácoras y versiones, análisis de causa raíz, decisiones de notificación, planes de acción, pruebas de recuperación y cláusulas con terceros.

También conviene probar el proceso sin esperar al próximo fallo. Los ejercicios de mesa permiten introducir un escenario inesperado —por ejemplo, un proveedor modifica un modelo subyacente y aparecen resultados materialmente distintos— y observar si los equipos saben quién decide, qué se detiene, qué evidencia se conserva y a quién se informa. El perfil de NIST para IA generativa recomienda ensayar planes de respuesta para tecnologías de terceros y mejorarlos a partir del aprendizaje retrospectivo.

El cierre técnico no es el final del incidente

La gestión madura termina cuando la organización ha aprendido, no cuando el sistema vuelve a estar disponible. Una revisión posterior debería preguntar qué condiciones permitieron el incidente, por qué los controles preventivos o detectivos no funcionaron, si existen sistemas similares expuestos y qué debe cambiar en el inventario, la evaluación de riesgos, los umbrales, el diseño de controles, los contratos, la capacitación o la supervisión humana.

El informe de 2026 de NIST sobre monitoreo de sistemas de IA desplegados refuerza una idea importante: el comportamiento real de un sistema puede diferir de lo observado antes del despliegue y las prácticas de monitoreo aún están evolucionando. Por eso la gestión de incidentes no puede diseñarse como un proceso estático.

Para auditoría interna, la conclusión es sencilla: una organización no demuestra resiliencia porque haya resuelto algunos incidentes. La demuestra cuando detecta antes, decide con criterios claros, conserva evidencia, comunica a tiempo, recupera de forma controlada y convierte cada incidente en mejores controles para el siguiente ciclo.