Registro de incidentes de IA: plantilla para una pyme
Resumen
Un registro de incidentes de IA sirve para reconstruir qué ocurrió, quién actuó y qué falta por comprobar. No basta con anotar «el asistente se equivocó» y marcar el asunto como resuelto. Esta guía propone una ficha interna, dos ejemplos ficticios y una secuencia de cierre para equipos pequeños. Es una propuesta operativa propia, no un formulario oficial ni una declaración de cumplimiento.
1. Abre la ficha con hechos, no con una causa supuesta
Describe la conducta observada, el momento y la tarea. Separa «el asistente mostró una fecha incorrecta» de «el proveedor cambió el modelo». La primera frase puede estar respaldada por una captura. La segunda necesita una comprobación independiente. Si todavía no sabes la causa, escribe «pendiente de investigar».
No esperes a conocer todo para asignar responsable. Registra también qué información falta y quién puede conseguirla. Para interpretar una captura, conserva el contexto mínimo: versión del sistema, entrada utilizada, salida y estado del proceso. Consulta cómo dar contexto a las evidencias de IA: https://veritias.eu/blog/capturas-pantalla-evidencia-ia-contexto-version.
2. Usa una plantilla de incidentes de IA que permita decidir
La siguiente estructura es una propuesta de trabajo de Veritias. Puedes adaptarla a tu proceso sin presentar sus campos como exigencias universales.
Identificación: Código interno, sistema, versión y persona responsable.
Detección: Fecha, hora, canal del aviso y tarea que se estaba ejecutando.
Hecho observado: Resultado concreto y evidencia que permite comprobarlo.
Alcance: Usuarios o procesos afectados; distinguir confirmado de pendiente.
Contención: Acción aplicada, responsable, momento y resultado comprobado.
Investigación: Hipótesis, comprobaciones y cuestiones todavía abiertas.
Corrección: Cambio propuesto, quién lo autoriza y cómo revertirlo.
Cierre: Pruebas realizadas, resultado, decisión y revisión posterior.
No copies conversaciones completas si basta un fragmento reducido. Restringe el acceso a los originales cuando contengan información sensible. Mantén una copia de trabajo minimizada para revisar el fallo sin difundir datos innecesarios.
3. Ejemplo: una fecha de entrega inventada
Supongamos que un asistente de soporte afirma que un pedido llegará mañana sin haber consultado su estado. El registro describe esa respuesta, no una supuesta avería del almacén. Una persona revisa el pedido y determina si el mensaje llegó al cliente. Hasta comprobarlo, el alcance queda abierto.
Como contención propuesta, el equipo puede derivar las consultas de entrega a revisión humana. La corrección podría exigir una consulta válida antes de responder. El cierre debe probar tanto un pedido existente como uno inexistente: en el segundo caso, el asistente debe pedir información verificable o derivar la consulta. Guarda también el resultado fallido inicial; no lo sustituyas por la prueba correcta.
4. Ejemplo: una tarifa antigua recuperada por el asistente
Imagina ahora una propuesta comercial que usa una tarifa retirada. El equipo confirma qué documento consultó el asistente y qué propuestas contienen ese importe. Retirar el documento no demuestra que todas las copias o respuestas guardadas hayan desaparecido.
La prueba de cierre incluye una consulta nueva, otra reformulada y una revisión del acceso al documento antiguo. Si existe una caché, el responsable técnico comprueba su tratamiento. Registra por separado la corrección del origen y la revisión de los documentos ya enviados. No cierres ambos trabajos con una única casilla.
5. Cierra con pruebas, no porque el proveedor diga «solucionado»
En el registro de incidentes de IA, distingue al menos tres estados internos: contenido, corregido y verificado. Son etiquetas propuestas, no categorías legales. Una corrección puede funcionar en un caso y fallar cuando faltan datos. Recupera el fallo original y añade variantes antes de darlo por cerrado.
La guía de diez casos de prueba para un asistente: https://veritias.eu/blog/pruebas-asistente-ia-casos-antes-produccion ayuda a ampliar esa revisión. Si cambia el modelo, relaciona el incidente con el registro de cambios del proveedor: https://veritias.eu/blog/registro-cambios-proveedor-modelo-ia-plantilla. Identifica quién acepta el resultado y cuándo se revisará de nuevo.
6. Separa la gestión interna de una notificación externa
El AI RMF de NIST, función MANAGE: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ contempla respuesta, recuperación y seguimiento documentado. Es un marco voluntario, no una lista de obligaciones españolas. La OCDE propone un marco común de comunicación de incidentes: https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf para facilitar un entendimiento compartido entre contextos distintos.
La ficha de ISO/IEC CD 25870: https://www.iso.org/standard/91804.html, consultada el 26 de octubre de 2026, figura como borrador de comité en desarrollo. No debe presentarse como una norma final publicada. Estas referencias no determinan por sí solas si tu caso exige comunicar algo a una autoridad.
Si hay posible daño, exposición de datos o una comunicación externa pendiente, activa la revisión de los responsables competentes. Este artículo no fija destinatarios ni plazos legales universales. Empieza hoy por un fallo conocido: completa la ficha, asigna responsable y escribe una prueba concreta que permita decidir su cierre. Contenido elaborado con asistencia de IA.