Plantilla de plan de respuesta a incidentes de IA (Ley de IA)
Plantilla de plan de respuesta a incidentes de IA: detección, triaje, contención, informe de incidente grave del art. 73 y aviso al proveedor del art. 26.
Un informe de incidente grave es un único documento que se presenta a posteriori. Un plan de respuesta a incidentes es todo el proceso que te lleva hasta ese documento, y que devuelve el sistema al control. Esta plantilla cubre el ciclo de vida completo: cómo detectas un incidente de IA, triasas su gravedad, contienes el daño, presentas el informe de incidente grave del artículo 73 cuando es una obligación del proveedor, ejecutas el análisis de la causa raíz y cierras el círculo con la medida correctora. Es el manual de actuación permanente; el informe es uno de sus resultados.
Esa distinción importa para saber cómo usar esta página. Si solo necesitas los campos del propio informe regulatorio, usa la plantilla de informe de incidente grave. Usa este plan cuando quieras el procedimiento de respuesta de principio a fin que tu equipo sigue en cuanto un sistema de IA se comporta mal: la parte que tiene que existir antes de un incidente, no después.
Detección: cómo sabes que algo ha ido mal
No puedes responder a lo que no ves. La detección descansa en dos cosas que la Ley de IA ya te exige tener. La primera, los registros del artículo 12: los sistemas de alto riesgo deben registrar automáticamente los eventos durante toda su vida útil, y esos registros son tu principal rastro forense. La segunda, las obligaciones de vigilancia: los proveedores ejecutan la vigilancia poscomercialización en virtud del artículo 72, y los responsables del despliegue vigilan el funcionamiento en virtud del artículo 26(5). Tu plan debe nombrar las señales que activan el proceso: distribuciones de salida anómalas, deriva de la precisión por debajo de los umbrales del artículo 15, una reclamación de un usuario o una alerta externa.
Registra, para cada detección: qué hizo aflorar la señal, la marca de tiempo y quién la recibió.
Triaje: ¿esto es un "incidente grave"?
No todo fallo es un incidente grave notificable, y sobrenotificar desperdicia el mismo tiempo que cuesta infranotificar. Triasa frente a la definición del artículo 3(49): un incidente grave es un incidente o defecto de funcionamiento que, directa o indirectamente, provoque el fallecimiento o un perjuicio grave para la salud, una perturbación grave e irreversible de infraestructuras críticas, un incumplimiento de obligaciones en materia de derechos fundamentales o un perjuicio grave para los bienes o el medio ambiente. Si se cumple alguno de esos supuestos, arranca el reloj de notificación del artículo 73. Si no se cumple ninguno, igualmente registras y subsanas, pero los plazos legales no aprietan.
| Desencadenante | Plazo para notificar (artículo 73) | Quién presenta |
|---|---|---|
| Incidente grave general | A más tardar 15 días desde que se tuvo conocimiento (73(2)) | Proveedor |
| Incumplimiento generalizado o perturbación grave e irreversible de infraestructuras críticas | A más tardar 2 días (73(3)) | Proveedor |
| Incidente que implica el fallecimiento de una persona | A más tardar 10 días (73(4)) | Proveedor |
Se permite un informe inicial incompleto para cumplir el plazo, seguido de uno completo (artículo 73(5)). No esperes a tener certeza antes de presentar el aviso inicial.
Contención: detén la propagación del daño
La contención es la respuesta operativa inmediata del responsable del despliegue y del proveedor, separada del papeleo. El plan debe preautorizar a las personas que pueden actuar para que nadie espere una aprobación en plena emergencia: pausar o restringir el sistema, replegarse a un proceso manual o invocar el mecanismo de anulación humana del artículo 14. La obligación del responsable del despliegue del artículo 26(5) es explícita aquí: cuando detecta un riesgo para la salud, la seguridad o los derechos fundamentales, debe suspender el uso e informar al proveedor.
El informe y el aviso: quién hace qué
Aquí está el reparto que la gente confunde. El artículo 73 es una obligación del proveedor: el proveedor notifica el incidente grave a la autoridad de vigilancia del mercado del Estado miembro donde se produjo. La tarea del responsable del despliegue en virtud del artículo 26(5) es avisar al proveedor: identificar el incidente grave, suspender el uso e informar al proveedor (y, cuando proceda, a la autoridad). Así, en una cadena típica, el responsable del despliegue detecta y notifica; el proveedor presenta el informe del artículo 73. Tu plan debe nombrar ambos roles y el traspaso entre ellos.
Causa raíz y medida correctora
Cerrar un incidente significa algo más que restablecer el servicio. Ejecuta un análisis estructurado de la causa raíz usando los registros del artículo 12 como prueba, y luego traslada la conclusión a dos sitios: el sistema de vigilancia poscomercialización (artículo 72) del proveedor, que existe precisamente para captar la experiencia de campo y actuar en consecuencia, y el sistema de gestión de riesgos del artículo 9, que debe actualizarse cuando se materializa un nuevo riesgo. Las medidas correctoras —un reentrenamiento del modelo, un cambio de umbral, una instrucción de uso actualizada— cierran el círculo y se convierten en prueba en la siguiente evaluación de la conformidad.
La plantilla: secciones que rellenar
1. Roles y contactos: responsable del incidente; contacto del proveedor; contacto del responsable del despliegue; autoridad de vigilancia del mercado de cada Estado miembro de operación; si actúas como proveedor, responsable del despliegue o ambos.
2. Registro de detección: fuente de la señal (registros del artículo 12 / vigilancia del artículo 72 o del 26(5) / reclamación / alerta externa); marca de tiempo; destinatario.
3. Triaje y clasificación: qué supuesto del artículo 3(49) se cumple (si alguno); plazo del artículo 73 resultante (15 / 10 / 2 días) o "no es un incidente grave"; fecha en que se tuvo conocimiento.
4. Acciones de contención: pausa / restricción / repliegue / anulación del artículo 14 invocada; quién autorizó; tiempo hasta contener.
5. Notificación y aviso: para responsables del despliegue: notificación al proveedor del artículo 26(5) (fecha). Para proveedores: fecha del informe inicial del artículo 73, fecha límite del informe completo, autoridad destinataria.
6. Análisis de la causa raíz: componente o comportamiento implicado; si el sistema operó dentro de su finalidad prevista; referencias de apoyo de los registros del artículo 12.
7. Acción correctora y preventiva: corrección aplicada; actualización del registro de gestión de riesgos del artículo 9 y del expediente de vigilancia poscomercialización del artículo 72; si el cambio es una modificación sustancial (artículo 3(23)) que reactiva la evaluación de la conformidad.
8. Cierre: aprobación; lecciones registradas; actualización de las instrucciones de uso enviada a los responsables del despliegue si procede.
Ejemplo práctico: la deriva del modelo de un proveedor SaaS
Beselin Analytics OÜ, un proveedor estonio con unos 60 empleados y unos 11 M€ de facturación, comercializa un sistema de scoring de solvencia de alto riesgo (anexo III, punto 5(b)). Sus registros del artículo 12 hacen aflorar un cambio brusco en la distribución de puntuaciones; la vigilancia poscomercialización del artículo 72 lo señala. Triaje: la deriva produce denegaciones sistemáticamente injustas para una clase de solicitantes, un incumplimiento de obligaciones en materia de derechos fundamentales con arreglo al artículo 3(49), así que se aplica la regla de los 15 días, no las variantes de 2 o 10 días. Beselin contiene en cuestión de horas pausando la función de scoring y replegándose a la revisión manual, presenta un informe inicial del artículo 73 en pocos días y traza la causa raíz hasta una actualización corrupta de los datos de entrenamiento. La corrección y el análisis se escriben en el registro de riesgos del artículo 9 y en el expediente de vigilancia del artículo 72; un modelo corregido y una instrucción de uso actualizada salen hacia los responsables del despliegue. Como el reentrenamiento cambia las características de rendimiento, Beselin evalúa si es una modificación sustancial conforme al artículo 3(23) antes de volver a desplegar.
Cómo te ayuda Confir
Confir reúne en un único lugar el rol de cada sistema de IA, la clasificación del anexo III, las referencias de los registros del artículo 12 y el registro de riesgos del artículo 9, de modo que cuando se produce un incidente, tu plan de respuesta se apoya en los datos del sistema que ya tienes y el plazo del artículo 73 se calcula a partir de la fecha en que se tuvo conocimiento en lugar de adivinarse. Mantiene visiblemente separadas la obligación de notificación del proveedor del artículo 73 y la obligación de aviso al proveedor del responsable del despliegue del artículo 26(5), para que cada parte vea solo lo que le corresponde. El motor es determinista y basado en reglas.
Guías relacionadas
- Serious incident report template
- Incident reporting under the EU AI Act
- Article 73 serious-incident reporting
- Article 72 post-market monitoring
- Post-market monitoring obligations
- Risk management plan template
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.
Empieza la prueba gratuita →