Registro de incidentes de IA: la pieza aburrida que te salva
Un registro de incidentes de IA es la pieza más aburrida de la gobernanza y, probablemente, la que más te va a salvar. Porque el día que un sistema se equivoque delante de un cliente, la diferencia entre un susto y un problema serio es poder demostrar que lo detectaste, lo anotaste y lo corregiste.
Qué es un registro de incidentes de IA
En primer lugar, es una lista donde se anota cada vez que un sistema de IA falla, con cuatro datos: qué pasó, cuándo, qué consecuencia tuvo y qué se hizo después. Nada más complicado que eso.
Sin embargo, casi ninguna empresa lo tiene. Lo habitual es que los fallos se comenten en una conversación de pasillo y se queden ahí, así que a los seis meses nadie recuerda si aquello fue una vez o veinte.
Además, esa diferencia importa mucho. Un fallo aislado es ruido; el mismo fallo veinte veces es un problema de diseño, y sin registro no se distinguen.
Qué cuenta como incidente y qué no
Aquí conviene ser práctico, ya que si se anota todo al final no se anota nada.
Nosotros usamos, en concreto, un criterio sencillo. Se registra cuando el fallo ha llegado a alguien de fuera del equipo que usa la herramienta, o cuando ha afectado a una decisión.
- Un dato inventado que acabó en un documento enviado al cliente: se registra.
- Una respuesta mala que la persona detectó y descartó: no, salvo que se repita.
- Un sistema que estuvo caído y, además, paró un proceso: se registra.
- Una decisión tomada con información incorrecta del sistema: se registra siempre.
- Un sesgo detectado en resultados sobre personas: se registra y además se escala.
Por tanto, el volumen razonable en una pyme es de unas pocas entradas al trimestre. Si salen cincuenta, el problema no es el registro.
Qué dice la norma sobre notificar incidentes graves
Esta parte conviene conocerla, aunque hoy no te aplique. El Reglamento Europeo de IA establece una obligación de notificar incidentes graves, y define bastante bien qué es grave.
En concreto, lo es cuando el fallo provoca la muerte o un daño serio a la salud de una persona, una interrupción grave e irreversible de infraestructuras críticas, una vulneración de obligaciones de derechos fundamentales o un daño serio a bienes o al medio ambiente.
Los plazos máximos de notificación son escalonados: dos días para los casos más graves de infraestructuras críticas o vulneraciones generalizadas, diez días en caso de fallecimiento y quince días para el resto. Además, la obligación recae principalmente en quien desarrolla el sistema, no en quien lo usa.
Ahora bien, quien lo usa sí tiene un deber concreto: informar al proveedor sin demora y, cuando corresponda, a la autoridad. Y hay un matiz de calendario importante, porque estas obligaciones se aplazaron al 2 de diciembre de 2027 junto con el resto del alto riesgo.
Por qué montar el registro de incidentes de IA ya
Vamos ahora a lo pragmático, que es donde esto se justifica solo.
En primer lugar, porque cuando llegue la obligación no se puede reconstruir el pasado. Un registro que empieza el día de la inspección no demuestra nada.
En segundo lugar, porque los cuestionarios de proveedor ya lo preguntan. Las grandes cuentas quieren saber cómo gestionas los fallos, y «no se nos ha dado el caso» es una respuesta que resta.
Y en tercer lugar, porque es información de negocio. De hecho, el registro te dice qué herramienta falla más, qué proceso es frágil y dónde hace falta supervisión, que son decisiones de dinero y no de cumplimiento.
Cómo montar el registro de incidentes de IA en una tarde
No hace falta software, por suerte. Una hoja de cálculo compartida con estas columnas es suficiente para empezar.
- Primero, la fecha y quién lo detecta.
- Sistema implicado, enlazado a tu inventario de sistemas de IA.
- Después, qué ocurrió, en una frase y en lenguaje normal.
- Consecuencia: interna, llegó al cliente o afectó a una decisión.
- Qué se hizo para corregirlo.
- Y, por último, si hay que cambiar algo en el proceso y quién se encarga.
Después, lo único que lo mantiene vivo es que registrar cueste menos de dos minutos. Si hay que rellenar un formulario de quince campos, nadie lo rellena.
El detalle que lo hace funcionar
Hay una cosa que decide si esto sirve o se abandona, aunque no es técnica. Es que registrar un fallo no puede tener consecuencias para quien lo registra.
Si la persona que avisa de que la IA se equivocó acaba cargando con la culpa, dejará de avisar. En cambio, si avisar se entiende como parte del trabajo bien hecho, el registro se llena solo.
Por eso en las empresas donde esto funciona siempre hay una frase explícita de dirección diciéndolo. Es gratis y es lo más eficaz del proyecto entero.
Preguntas frecuentes sobre el registro de incidentes de IA
¿Vale una hoja de cálculo?
Sí, perfectamente. Sobre todo porque en una empresa de menos de doscientas personas es mejor una hoja que se rellena que una plataforma que no.
¿Hay que notificar todos los incidentes a alguien?
No. La obligación de notificación se refiere a incidentes graves y, además, hoy todavía no está vigente. El registro interno es otra cosa y es voluntario.
¿Quién debe ser el responsable?
Alguien de negocio con acceso a dirección y, en cambio, no el departamento técnico. Porque la mayoría de las correcciones son de proceso, no de código.
¿Esto es asesoramiento jurídico?
No, ya que es orientación de implantación. Por eso conviene contrastar con tu asesoría cualquier obligación concreta. Puedes ver el detalle del artículo 73 en esta referencia.
Si quieres montarlo bien a la primera
En ArtiLabs dejamos este registro montado y con dueño asignado como parte del trabajo de gobernanza, junto con la evaluación de impacto de IA. Si quieres tenerlo antes de necesitarlo, cuéntanos tu caso.
