¿Qué es un plan de respuesta a incidentes de IA?
Gobernanza, riesgo y aseguramiento
Un plan de respuesta a incidentes de IA es un manual documentado que establece cómo actúa una organización cuando un sistema de IA causa, o se sospecha de forma fundada que puede causar, daño, fallo, uso indebido o una infracción legal. Define los desencadenantes, los roles, los niveles de gravedad, las reglas sobre evidencias, los pasos de contención, las obligaciones de notificación, la remediación y la revisión. En la gobernanza de la IA, es el puente entre los controles de riesgo sobre el papel y un proceso repetible que protege a las personas, preserva las pruebas y demuestra a los reguladores cómo respondió la organización.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La palabra "incidente" es importante. En la gobernanza de la IA va más allá de un error de software. Puede abarcar comportamientos inseguros, trato discriminatorio, pérdida de privacidad, desinformación grave, compromiso de seguridad, contenido sintético dañino, fallos de proveedores o usos indebidos que puedan atribuirse al desarrollo, la implantación o el mal funcionamiento de un sistema de IA.
El plan de respuesta es la parte que se activa cuando una señal de alerta es lo suficientemente grave como para actuar. No es lo mismo que la gestión de riesgos de IA, el red-teaming ni la gestión del cambio ordinaria. Estos son mecanismos complementarios. El plan de incidentes utiliza las señales que generan, determina qué debe ocurrir de inmediato y registra el porqué.
Un buen plan es práctico. Indica al personal qué clasificar, a quién avisar, cuándo pausar o desactivar un sistema, cómo conservar registros y versiones intactos, cuándo notificar a clientes o autoridades, y cómo revisar el evento a posteriori.
Por qué es importante
Los problemas de IA rara vez se quedan dentro de un solo equipo. Un único fallo puede afectar a clientes, empleados, menores, ciudadanos, pacientes, usuarios de la vía pública o socios comerciales. Si la respuesta es improvisada, el daño puede continuar mientras los equipos discuten sobre responsabilidades, los ingenieros sobreescriben evidencias y los plazos de notificación establecidos por las normativas de privacidad, producto, transporte o IA empiezan a correr.
Los reguladores y los organismos de normalización esperan cada vez más una gestión disciplinada tras la implantación, no solo buenas intenciones antes del lanzamiento. Los planes se están convirtiendo en parte de la prueba de que una organización contaba con gobernanza: responsabilidad clara, registros, acciones correctivas, comunicaciones y revisión posterior. Esto importa a supervisores, compradores, auditores y responsables de decisiones internos.
Cómo funciona
Qué se considera un incidente de IA
A nivel de gobernanza, un incidente de IA no es solo un defecto de código. El perfil de IA generativa de NIST trata los incidentes como eventos o circunstancias en los que el desarrollo, el uso o el mal funcionamiento de uno o más sistemas de IA contribuye a causar daño, incluido el daño a la salud, las infraestructuras críticas, los derechos, la propiedad, las comunidades o el medio ambiente. Esto es suficientemente amplio para abarcar fallos técnicos, recomendaciones inseguras, contenido generado dañino, uso indebido grave, pérdida de privacidad, dependencia de un modelo externo que falla o un sistema que se comporta de formas ya no coherentes con su uso previsto.
El contexto importa. El mismo fallo técnico puede ser menor en una herramienta de redacción de bajo riesgo y grave en sanidad, transporte, educación, empleo o servicios públicos. Por eso, un plan serio define las categorías de incidentes según el contexto de uso, no solo por los síntomas técnicos. Muchos equipos también incorporan los cuasi-incidentes y los eventos precursores al mismo flujo de trabajo, pero deben indicarlo explícitamente, ya que las obligaciones legales de notificación suelen vincularse a incidentes definidos y no a cualquier señal de alerta.
Titularidad y vías de escalada
El NIST AI RMF y el perfil de IA generativa señalan la necesidad de roles, responsabilidades y canales de comunicación por escrito. En la práctica, esto implica un responsable del sistema designado, un líder de respuesta y la participación acordada de antemano de ingeniería, producto, seguridad, privacidad, legal, cumplimiento normativo, operaciones y cualquier especialista de dominio cuyo ámbito pueda verse afectado. El equipo no debe formarse desde cero después del evento.
La titularidad también implica autoridad. El plan debe indicar quién puede clasificar la gravedad, quién puede aprobar las comunicaciones con clientes o reguladores, y quién puede desconectar o desactivar un sistema si se alcanzan los umbrales establecidos. El perfil de IA generativa de NIST es explícito en que los casos graves deben tener una vía hacia la autoridad de gestión de riesgos de la organización, especialmente cuando pueda ser necesaria la desactivación, la divulgación pública o la notificación a terceros. También exige que los puntos de contacto, los formatos de notificación y la competencia del personal estén definidos de antemano.
Triaje y primeras decisiones
Los planes funcionan mejor cuando definen las vías de entrada antes de que ocurra cualquier problema. Las señales pueden provenir de la monitorización automatizada, reclamaciones de usuarios, soporte de primera línea, pruebas internas, hallazgos de red-team tras el lanzamiento, avisos de proveedores, divulgación de vulnerabilidades, denuncias internas o informes públicos. Un buen triaje plantea un conjunto breve de preguntas operativas: qué sistema, modelo, versión, prompt o flujo de trabajo está implicado; quién puede verse afectado; si el daño sigue produciéndose; qué evidencias existen; si hay un tercero implicado; y qué plazos legales o contractuales pueden estar ya en marcha.
El objetivo del triaje no es concluir la investigación de inmediato, sino clasificar la gravedad, asignar responsables, estabilizar la toma de decisiones y determinar si el sistema puede continuar sin cambios, debe degradarse o debe desconectarse. En un plan maduro, esas primeras decisiones se vinculan a umbrales predefinidos en lugar de al juicio personal bajo presión.
Contención y preservación de pruebas
El RMF de NIST, el perfil de IA generativa y el código de ciberseguridad de IA del Reino Unido orientan a las organizaciones hacia una contención y recuperación preparadas de antemano, no hacia una reacción improvisada. La contención puede implicar bloquear un patrón de prompt peligroso, activar una revisión humana más estricta, deshabilitar un plugin, revertir un modelo o una configuración, restaurar un estado conocido como correcto, detener el entrenamiento con datos sospechosos o desconectar el sistema. El plan debe definir qué medidas están disponibles para cada caso de uso y quién puede autorizarlas.
Sin embargo, la contención sin pruebas es una gobernanza débil. En cuanto un incidente parezca verosímil, el equipo debe preservar registros, versiones, prompts, linaje de datos, detalles del inventario del sistema, avisos de proveedores, informes de usuarios y decisiones internas antes de que los cambios borren el rastro. Las pruebas específicas de IA suelen distribuirse en varias capas: registros de versiones del modelo, cambios en prompts y políticas, registros de entrenamiento o ajuste fino, registros de uso, telemetría, notas de revisión manual y condiciones contractuales de los servicios externos. El código del Reino Unido va más allá al exigir trazas de auditoría sobre modelos, conjuntos de datos y prompts, además de planes de gestión de incidentes y recuperación probados.
Notificación y canales legales
La notificación externa es donde la respuesta a incidentes de IA deja de ser meramente operativa para convertirse en regulatoria. El EU AI Act exige a los proveedores de sistemas de IA de alto riesgo que incorporen procedimientos para incidentes graves en su sistema de gestión de calidad, conserven la documentación técnica y determinados registros, realicen una monitorización poscomercialización y notifiquen los incidentes graves a las autoridades de vigilancia del mercado dentro de los plazos establecidos. También exige la investigación de las causas y la adopción de medidas correctivas tras la notificación. Esto es una señal clara de que la gestión de incidentes de IA está pasando de ser una buena práctica opcional a una función de cumplimiento normativo regulada.
El canal legal rara vez es único. Un incidente grave de IA puede requerir tramitación a través de normas específicas de IA, pero también de privacidad, ciberseguridad, transporte, seguridad de productos, consumo o canales sectoriales específicos. Los problemas con proveedores y cadenas de valor requieren un tratamiento especial. El perfil de IA generativa de NIST indica que los planes deben contemplar los contactos con terceros afectados, los planes de contingencia, los incidentes de terceros, las cláusulas de notificación contractual y la alineación con la notificación de brechas o la legislación de protección de datos. A nivel intergubernamental, el trabajo de la OECD sobre un marco común de notificación marca la dirección: registros de incidentes más estructurados y comparables entre sectores y fronteras, incluso cuando la divulgación sigue siendo en parte voluntaria.
Recuperación, revisión y garantías
El cierre solo debe producirse cuando la organización pueda explicar qué ocurrió, qué cambió y por qué considera que el riesgo se ha reducido. NIST señala la necesidad de una revisión posterior a la acción, una revisión periódica de los procesos de incidentes, la conservación de documentos y la actualización del propio proceso de respuesta. La recuperación, por tanto, va más allá de volver a activar una funcionalidad. Implica un análisis de causa raíz, medidas correctivas, nuevas pruebas en el contexto real, actualizaciones de la monitorización y límites operativos más claros.
Por eso, un plan de respuesta a incidentes de IA es también un mecanismo de prueba. Debe dejar un registro de entrada en el registro de incidentes, la decisión sobre la gravedad, el conjunto de evidencias, el registro de comunicaciones, los avisos a reguladores cuando corresponda, el análisis de causa raíz, el registro de remediación, el registro de nuevas pruebas y la aprobación final. Esos registros respaldan el trabajo de garantía, la auditoría interna, la diligencia debida de compradores y las investigaciones de cumplimiento posteriores. Cualquier corrección en producción debe tramitarse a través de la gestión del cambio ordinaria, en lugar de dejarse como un parche de emergencia sin trazabilidad de gobernanza.
Ejemplos
El accidente de conducción automatizada de Uber en Tempe en 2018 sigue siendo una lección importante sobre hasta dónde debe llegar la respuesta a incidentes, más allá del lugar inmediato del accidente. La NTSB concluyó que el operador de seguridad no supervisó el entorno de conducción, y que la evaluación inadecuada del riesgo de seguridad de Uber ATG, la supervisión ineficaz del operador y la falta de mecanismos para abordar la complacencia ante la automatización contribuyeron al accidente. El informe también recoge los cambios posteriores al accidente, como la restauración de la redundancia de seguridad, la incorporación de un segundo operador de vehículo, la introducción de monitorización de atención en tiempo real y la transición hacia un sistema de gestión de la seguridad. En términos prácticos, eso es la respuesta a incidentes haciendo cuatro cosas a la vez: detener la exposición, preservar pruebas, investigar el fallo de gobernanza y definir las condiciones para el reinicio.
El caso de ChatGPT en Italia en 2023 demuestra que un incidente de IA puede tratarse como un problema de privacidad y derechos, no solo de calidad del modelo. Tras una brecha de datos notificada que afectó a conversaciones y datos de pago de suscriptores, el Garante impuso una limitación temporal del tratamiento y señaló preocupaciones sobre el aviso, la base legal, la exactitud y la protección de menores. El servicio se restableció posteriormente tras ampliar la transparencia, ampliar los derechos de exclusión voluntaria, revisar los avisos e introducir controles de acceso relacionados con la edad. La lección es que un plan de respuesta a incidentes de IA necesita vías legales, de privacidad y de comunicación junto al trabajo de ingeniería.
La gestión por parte de Cruise del accidente con un peatón en 2023 muestra por qué la exhaustividad factual importa tanto como la rapidez. En 2024, la NHTSA anunció una orden de consentimiento tras constatar que los informes de Cruise presentados en virtud de la orden de notificación de accidentes de conducción automatizada de EE. UU. omitían detalles materiales posteriores al accidente. La orden exigió un plan de acción correctiva, añadió requisitos de supervisión e impuso una sanción económica. La lección de gobernanza es sencilla: los informes tempranos pueden ser incompletos, pero no pueden ser engañosos, y el plan de respuesta debe controlar quién verifica los hechos antes de su presentación.
Malentendidos frecuentes
"Un plan de respuesta a incidentes de IA es simplemente la respuesta a incidentes cibernéticos aplicada a la IA." No exactamente. Los eventos cibernéticos importan, pero también lo hacen los fallos de seguridad, las vulneraciones de derechos, el contenido dañino, la discriminación, la pérdida de privacidad, los fallos de proveedores y el uso indebido grave.
"Si compramos un modelo de terceros, el incidente es responsabilidad del proveedor." No. El implantador sigue siendo responsable de su contexto de uso, los usuarios afectados, el plan de contingencia local, muchos registros locales y, a menudo, parte de la exposición legal.
"Podemos investigar primero y pensar en la contención después." No. Ante un daño activo, la contención inmediata y la preservación de pruebas son anteriores a un análisis completo de causa raíz.
"Solo los incidentes con daños físicos interesan a los reguladores." No. Los derechos, la privacidad, la exactitud, la transparencia, las salvaguardas relacionadas con la edad y otros daños legalmente relevantes pueden desencadenar actuaciones.
"Una vez publicado el parche, el incidente está cerrado." No. El cierre requiere evidencias conservadas, revisión de las comunicaciones, nuevas pruebas, aprendizaje del proceso y una publicación controlada de la corrección definitiva.
Riesgos y límites
Un plan de respuesta a incidentes de IA no sustituye al buen diseño, las pruebas, el red-teaming, la supervisión humana ni la monitorización tras la implantación. Es un mecanismo de respuesta, no el sistema de gobernanza completo. Si una organización lo utiliza como sustituto de los controles preventivos, se convertirá simplemente en un proceso repetitivo de limpieza.
Tampoco existe aún una plantilla legal global única. Lo que sí está confirmado es que algunas obligaciones ya son vinculantes, especialmente en ámbitos regulados como la IA de alto riesgo en la UE y la notificación de accidentes de conducción automatizada en EE. UU. Lo que aún varía entre jurisdicciones es el umbral, la forma y el destinatario para muchos otros incidentes, ya que la normativa de privacidad, seguridad, ciberseguridad, consumo y sectorial sigue haciendo gran parte del trabajo. Los marcos internacionales se están volviendo más estructurados, pero la notificación voluntaria no equivale al cumplimiento legal.
El otro límite es práctico. Si los umbrales de incidente son demasiado laxos, los daños graves se degradan a "simple error". Si son demasiado amplios, los equipos se ahogan en ruido y dejan de tratar la respuesta a incidentes como una disciplina especial. Un plan útil distingue entre defectos de atención al cliente, cuasi-incidentes, incidentes materiales y eventos de notificación legal obligatoria, e indica qué vía debe seguir cada uno.
Próximos pasos
Comience por el caso de uso activo de mayor riesgo, no por una política corporativa genérica. Designe al responsable. Defina la vía de escalada a nivel directivo. Establezca los criterios de desactivación, los requisitos de evidencia, los contactos con terceros afectados y las vías de notificación externa.
A continuación, pruebe el plan. Realice ejercicios de simulación sobre al menos tres escenarios: comportamiento dañino del modelo, fallo de un proveedor externo y un evento de privacidad o seguridad. Compruebe si sus registros, inventarios, contratos, procesos de contingencia y borradores de comunicaciones permiten realmente al equipo actuar en cuestión de horas.
Por último, haga que el cierre sea disciplinado. Exija una revisión posterior a la acción, una remediación con seguimiento, nuevas pruebas en el entorno real y un registro de decisión escrito antes de que el sistema vuelva al servicio normal.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es lo mismo un plan de respuesta a incidentes de IA que una política de riesgos de IA?
No. Una política establece principios y controles. El plan de respuesta a incidentes define qué ocurre cuando algo ha salido mal, o tiene suficientes probabilidades de salir mal como para actuar de inmediato.
¿Los equipos pequeños necesitan uno?
Sí, pero debe ser proporcional. Un plan más ligero puede igualmente establecer un responsable claro, niveles de gravedad sencillos, reglas de desactivación y reversión, conservación básica de evidencias y una vía de escalada legal.
¿Qué suele activar el plan?
Una señal fundada de daño material, uso indebido grave, infracción legal, problema de seguridad, fuga de datos, vulneración de derechos, fallo de proveedor o comportamiento persistente fuera del uso previsto.
¿Quién debe poder apagar el sistema?
El plan debe designar esa autoridad de antemano. Habitualmente la comparten el responsable del sistema y un directivo de riesgos, seguridad o producto de alto nivel, con vías más rápidas cuando el daño puede ser inminente.
¿Qué pruebas debemos conservar?
Conserve los identificadores del sistema y del modelo, las versiones, los prompts o la configuración de políticas, los registros, el linaje de datos cuando esté disponible, los informes de usuarios, los avisos de proveedores, las decisiones, las comunicaciones, las correcciones y los registros de nuevas pruebas.
¿Todos los incidentes requieren notificación al regulador?
No. Pero algunos sí. El canal depende del sector y la jurisdicción, como las obligaciones de IA de alto riesgo en la UE, la legislación de privacidad, la notificación en transporte, la seguridad de productos o las normas de ciberseguridad.
¿Con qué frecuencia debe probarse el plan?
Con regularidad, tras cambios importantes en el modelo o el flujo de trabajo, y después de cualquier evento grave. Los ejercicios de simulación suelen ser suficientes para revelar contactos que faltan, registros deficientes o planes de contingencia inadecuados.