Los incidentes de IA se están convirtiendo en crisis operativas. Debemos tratarlos de esa manera.

Durante los últimos años, la mayoría de las organizaciones han hablado sobre el riesgo de la IA en el lenguaje de la gobernanza.

¿Es el modelo preciso? ¿Es justo? ¿Está aprobada la data? ¿Estamos cumpliendo con la regulación emergente? Esas son preguntas importantes, pero no son las únicas preguntas. La pregunta más urgente es qué sucede cuando algo sale mal!

¿Qué sucede cuando un agente de IA toma una acción que nunca debió tomar? ¿Qué sucede cuando un modelo filtra datos sensibles? ¿Qué sucede cuando una respuesta alucinada crea exposición legal, o una decisión automatizada afecta a un cliente, empleado, paciente o socio de una manera que no se puede deshacer fácilmente?

Y quizás más prácticamente: ¿dónde va la organización para coordinar la respuesta? Ese es el cambio que ahora está en marcha. El riesgo de la IA se está convirtiendo en un tema de resiliencia operativa, no solo de gobernanza.

La IA se está moviendo desde la experimentación hacia la maquinaria de trabajo de la empresa. Se está integrando en el soporte al cliente, el desarrollo de software, las operaciones financieras, los flujos de trabajo de atención médica, la contratación, el procesamiento de reclamos, las cadenas de suministro y la automatización interna. A medida que la IA se vuelve más conectada con el negocio, los fallos de la IA se convierten en incidentes comerciales.

El Monitor de Incidentes de IA de la OCDE rastreó 596 incidentes de IA en enero de 2026 solo, un crecimiento del 200% año tras año. Esfuerzos como el Monitor de Incidentes de IA de la OCDE y la Base de Datos de Incidentes de IA documentan resultados negativos o perjudiciales que involucran a sistemas de IA para que la industria pueda aprender de la experiencia de la misma manera que la aviación y la ciberseguridad han hecho durante años.

Esa comparación es importante. Las industrias maduras preguntan cómo prevenir el fallo y cómo responder cuando el fallo ocurre de todos modos.

Los incidentes de IA no se comportan como los errores de software tradicionales

Un error de software tradicional suele tener un límite relativamente claro. Algo se rompe, los ingenieros investigan y el equipo reproduce el problema, parchea el código y envía una solución.

Sin embargo, los incidentes de IA son más desordenados. Pueden ser probabilísticos, intermitentes y surgir de la interacción entre un modelo, un prompt, un sistema de recuperación, un complemento, un agente, un usuario y un proceso de negocio descendente. A veces el sistema de IA está funcionando exactamente como se diseñó, pero el diseño es incompleto para el entorno en el que se está utilizando. Eso hace que la respuesta sea más desafiante.

Una alucinación en un chatbot de consumo es un tipo de problema. Una alucinación dentro de un flujo de trabajo legal, financiero, clínico o de recursos humanos es otro. Una salida sesgada en pruebas es seria. Un proceso de decisión automatizado que se ejecuta a escala en producción es algo completamente diferente. Un asistente de IA que redacta un correo electrónico es una cosa, pero un agente que puede cambiar permisos, emitir reembolsos, actualizar registros, activar flujos de trabajo o ejecutar código es una categoría muy diferente de riesgo.

El Repositorio de Riesgos de IA del MIT captura una amplia gama de riesgos de IA, incluyendo información falsa o engañosa, fallos de privacidad y seguridad, discriminación, mal uso e inseguridad del sistema. La lista de los 10 principales de OWASP para aplicaciones de LLM destaca riesgos como la inyección de prompts, la divulgación de información confidencial, el manejo de salida inseguro y la excesiva agencia. Estos son modos de fallo prácticos, en lugar de preocupaciones técnicas abstractas.

Si un agente de IA tiene demasiada autoridad, puede tomar acciones que ningún ser humano pretendía. Si una inyección de prompt tiene éxito, el sistema puede divulgar información o seguir instrucciones hostiles. Si los datos confidenciales se filtran a través de un modelo o un sistema de recuperación, la respuesta tiene implicaciones legales, regulatorias, de cliente y de reputación. Es por eso que el lenguaje de la gobernanza de la IA puede volverse demasiado pasivo. La gobernanza nos dice qué debería ser cierto. La respuesta a incidentes nos dice qué hacer cuando la realidad se mueve más rápido que la política.

La respuesta será transfuncional

Una de las mayores lecciones de la ciberseguridad es que los incidentes rara vez se quedan dentro del equipo de seguridad. Al principio, un evento puede parecer técnico. Muy rápidamente, involucra a los equipos legales, de comunicaciones, de liderazgo empresarial, de cumplimiento, de atención al cliente, de asesoramiento externo, de aseguradoras, de especialistas forenses y, a veces, la junta directiva.

Los incidentes de IA seguirán el mismo patrón.

Imaginen un modelo que expone información confidencial de los clientes. Los equipos de seguridad y privacidad necesitan entender qué sucedió. El equipo legal necesita evaluar las obligaciones. Las comunicaciones pueden necesitar prepararse para los clientes, los reguladores o los medios. Los ingenieros pueden necesitar deshabilitar o revertir un sistema. Los líderes empresariales pueden necesitar sopesar la continuidad frente al aislamiento.

O imaginen un agente de IA que comienza a tomar acciones no intencionadas en los sistemas empresariales. El equipo técnico puede ser capaz de desactivarlo, pero la organización todavía necesita saber qué hizo, a quién afectó, qué decisiones se tomaron, si se activaron obligaciones contractuales y cómo se prevenirá el mismo fallo en el futuro. Eso no se puede resolver solo por el equipo de IA.

Las organizaciones deben construir músculo transfuncional antes de que lo necesiten. Eso significa desencadenantes de escalada claros, roles claros, derechos de decisión claros, caminos de comunicación claros, documentación clara y práctica.

En una crisis, la coordinación es infraestructura, no solo una habilidad blanda.

La IA que se investiga no debe controlar la respuesta

Hay otro tema que las organizaciones necesitan pensar con mucha más cuidado. Si el sistema de IA bajo investigación puede acceder a las mismas comunicaciones, documentos, flujos de trabajo o automatización que se utilizan para coordinar la respuesta, la organización tiene un problema.

En la ciberseguridad, este es un principio familiar. Si el ransomware ha comprometido la red corporativa, no se coordina la respuesta en sistemas que el atacante pueda leer, interrumpir o manipular. Se sale del sistema. Se separa el incidente de la respuesta.

La misma lógica se aplica a la IA.

Un sistema de IA puede no ser malicioso en el sentido humano, pero si puede ver el plan de respuesta, resumir la reunión de respuesta, influir en el flujo de trabajo, recomendar el próximo paso o operar dentro del mismo entorno que se utiliza para contenerlo, entonces la organización no ha aislado verdaderamente la respuesta.

Esto se vuelve aún más importante con la IA agente. El Marco de IA Segura de Google destaca riesgos como la inyección de prompts, la intoxicación de datos y las acciones deshonestas, y los asigna a controles en todo el ciclo de vida de la IA. Esa es la configuración correcta. A medida que los sistemas de IA se vuelven más capaces de actuar en herramientas, datos y flujos de trabajo, las organizaciones necesitan pensar en la seguridad del modelo y en la separación operativa.

Piénselo como investigar un incendio. No querrías que los controles de los sprinklers estuvieran vinculados al mismo sistema defectuoso que estás tratando de diagnosticar.

Prepararse, practicar, responder, informar

Un marco útil para la preparación para incidentes de IA es el mismo que ha madurado en la ciberseguridad: prepararse, practicar, responder, informar.

Prepararse significa definir los tipos de incidentes antes de que ocurran, como el sesgo, la alucinación, la fuga de datos, la deriva del modelo, la inyección de prompts, la fuga de agentes, el uso no autorizado de herramientas y el fallo de modelos de terceros. Cada uno requiere diferentes partes interesadas y diferentes decisiones.

Un buen libro de jugadas no debe ser un documento de 200 páginas que se sienta en una carpeta. Nadie abre la página 137 durante una crisis. Un buen libro de jugadas es basado en roles, accesible y accionable. El equipo legal sabe qué necesita hacer el equipo legal. El equipo de ingeniería sabe qué necesita hacer el equipo de ingeniería. Las comunicaciones saben cuándo involucrarse. La junta directiva sabe cuándo la administración escalonará.

Practicar significa ejecutar ejercicios de mesa. No una vez al año como una casilla, sino con suficiente frecuencia como para construir memoria muscular. La primera vez que la junta directiva discuta un incidente de IA no debe ser durante un incidente de IA real. La primera vez que los equipos legales, de ingeniería, de privacidad, de seguridad y de comunicaciones trabajen juntos en un fallo de IA no debe ser cuando los clientes ya están haciendo preguntas.

Responder significa coordinar el evento en vivo con disciplina. ¿Quién está en la habitación? ¿Qué hechos son conocidos? ¿Qué hechos todavía son inciertos? ¿Qué decisiones se tomaron? ¿Quién las aprobó? ¿Qué cambió entre la hora 12 y la hora 48?

Informar significa reconocer que la regulación de la IA se está volviendo más concreta. El Acta de IA de la UE incluye obligaciones serias de informe de incidentes para los proveedores de ciertos sistemas de IA de alto riesgo. Los detalles variarán según la jurisdicción, la industria y el caso de uso, pero la dirección es clara. Los incidentes de IA requerirán cada vez más un registro defendible de qué sucedió, qué se sabía, qué acciones se tomaron y cuándo.

La IA puede ayudar, pero no puede reemplazar el juicio

Hay una tentación de pensar que la respuesta a incidentes de IA debería ser completamente automatizada. Creo que esa es la configuración incorrecta.

La IA puede ayudar enormemente. Puede resumir hechos. Puede identificar información que falta. Puede comparar un incidente con patrones anteriores. Puede redactar informes de después de la acción. Puede ayudar a mapear obligaciones regulatorias. Puede reducir la carga administrativa cuando las personas están bajo presión.

Pero en un incidente grave, los humanos siguen siendo indispensables.

Alguien tiene que decidir si los hechos son suficientes. Alguien tiene que sopesar el impacto en el cliente. Alguien tiene que decidir si pausar un sistema. Alguien tiene que determinar si la organización ha cruzado un umbral de informe. Alguien tiene que comunicarse con responsabilidad y empatía.

El papel correcto de la IA en la respuesta a incidentes no es reemplazar al equipo de crisis. Es dar al equipo de crisis un mejor contexto, más rápido.

El Marco de Gestión de Riesgos de IA del NIST es útil porque enmarca la gestión de riesgos de IA en torno a cuatro funciones: gobernar, mapear, medir y gestionar. Para la respuesta a incidentes, agregaría una extensión práctica: ensayar.

Un plan que nunca se ha probado no es realmente un plan. Es una teoría.

Las juntas directivas necesitan un libro de jugadas, también

El riesgo de la IA se está convirtiendo en un tema de la junta directiva, pero la participación de la junta directiva no puede detenerse en diapositivas de supervisión. Las juntas directivas necesitan entender su papel antes de que ocurra una crisis.

¿Cuándo se informará a la junta directiva? ¿Qué decisiones requieren la entrada de la junta directiva? ¿Qué información proporcionará la administración? ¿Cómo se evaluarán la materialidad, el impacto en el cliente, la exposición legal, las obligaciones regulatorias y la interrupción operativa?

Muchas organizaciones tienen libros de jugadas de seguridad, libros de jugadas de privacidad, libros de jugadas de comunicaciones y libros de jugadas legales. Muchas menos tienen un libro de jugadas para la junta directiva para incidentes de IA. Esa brecha se volverá más visible a medida que los sistemas de IA se muevan hacia flujos de trabajo regulados, generadores de ingresos y orientados al cliente. El papel de la junta directiva es ayudar a la organización a tomar mejores decisiones bajo presión, no volverse más técnicos.

La IA confiable requiere resiliencia operativa

Hay mucha conversación sobre la IA confiable. Esa es la aspiración correcta, pero la confianza no se crea solo con principios. La confianza se crea cuando las organizaciones pueden mostrar cómo se preparan, cómo detectan problemas, cómo responden, cómo comunican, cómo documentan decisiones y cómo mejoran.

La ciberseguridad pasó por la misma evolución. Las organizaciones pasaron años invirtiendo en prevención, y deben seguir haciéndolo. Pero las organizaciones maduras eventualmente aprendieron que la prevención no es suficiente. También necesitas resiliencia. La IA está entrando en la misma fase.

Debemos construir modelos más seguros, controles más fuertes, evaluaciones mejores, un mejor rojo, y una mejor gobernanza, pero también debemos aceptar que los incidentes ocurrirán. Los modelos fallarán, los agentes se comportarán de manera inesperada, los datos se filtrarán, los humanos malutilizarán los sistemas, los proveedores cometerán errores y las regulaciones evolucionarán.

La pregunta es si la organización puede responder con velocidad, coordinación, juicio y responsabilidad cuando ocurre un incidente. Esa es la forma en que la IA se mueve de la experimentación a la infraestructura confiable, y esa es la forma en que la resiliencia se convierte en cultura.