Lista de control de registro y conservación

Una lista eficaz convierte la trazabilidad en trabajo operativo normal. Primero identifique el sistema de IA completo, su finalidad prevista, el rol de la empresa, su clasificación y los registros realmente bajo su control. Después defina el conjunto mínimo que permita explicar resultados importantes, cambios, acciones humanas, controles e incidentes. Asigne responsables de captura, acceso, revisión, conservación y borrado, y compruebe que una persona autorizada puede reconstruir lo ocurrido.

Para sistemas de IA de alto riesgo, el artículo 12 del Reglamento de IA exige capacidades técnicas de registro automático durante la vida del sistema. Los artículos 19 y 26 obligan a proveedores y responsables del despliegue a conservar los registros generados automáticamente que controlen durante un periodo adecuado y, por regla general, al menos seis meses, salvo que otra norma disponga otra cosa. No es una autorización para conservar toda interacción indefinidamente.

1. Confirmar el alcance

• [ ] Documentar nombre estable, propietario, finalidad, usuarios, personas afectadas, entradas, salidas y decisiones.
• [ ] Mapear modelos, fuentes, reglas, intervención humana, integraciones y acciones posteriores.
• [ ] Registrar el rol, la clasificación de alto riesgo, supuestos, revisor y desencadenantes de reevaluación.
• [ ] Separar los registros controlados por empresa, cliente y proveedor, e identificar normas de privacidad, seguridad, empleo, sector y contrato.

Una etiqueta contractual no determina el rol. Un cambio sustancial, una nueva finalidad o la comercialización bajo otro nombre puede modificar responsabilidades.

2. Definir preguntas y eventos mínimos

• [ ] Enumerar preguntas de investigación, auditoría, clientes y propietarios de controles; asignar a cada una un evento.
• [ ] Incluir identificadores de sistema, modelo, configuración, versión y entorno, además de tiempo y correlación.
• [ ] Registrar controles, alertas, errores, excepciones y revisiones, aprobaciones, rechazos o escalados humanos.
• [ ] Vincular cambios, quejas, incidentes y correcciones con la versión afectada; versionar y probar el esquema.

Un registro útil responde una pregunta concreta. La telemetría de disponibilidad no suele probar qué versión produjo una decisión. Guardar por defecto prompts, documentos, respuestas e identidades puede aumentar el riesgo. Use referencias protegidas, hashes, resúmenes o muestras restringidas cuando basten.

3. Asignar responsabilidades

• [ ] Nombrar una persona responsable por sistema.
• [ ] Asignar instrumentación a ingeniería; finalidad y cambios a producto; modelos y evaluaciones a datos/ML; acceso e integridad a seguridad; minimización a privacidad; y requisitos, pruebas y brechas a cumplimiento.
• [ ] Documentar expresamente las responsabilidades de clientes y proveedores.

Una tabla en el registro de sistemas suele bastar. Debe conectar los procesos existentes y evitar reconstrucciones improvisadas ante un plazo.

4. Integrarlo en la entrega

• [ ] Vincular alcance y clasificación con la especificación, y versiones de modelo, prompt, datos, configuración y evaluación con la entrega.
• [ ] Hacer que el despliegue emita identificadores, aprobaciones, controles y referencia de reversión.
• [ ] Capturar automáticamente excepciones, intervenciones, quejas, incidentes y alertas cuando sea posible.
• [ ] Reevaluar cambios materiales de finalidad, modelo, datos, umbral, integración o supervisión.

La evidencia debe nacer donde se decide: especificación, revisión de código, evaluación, despliegue, ticket o incidente. Automatice la integridad rutinaria y reserve el juicio humano para cambios y excepciones relevantes.

5. Proteger acceso e integridad

• [ ] Clasificar por sensibilidad; separar visibilidad operativa y acceso de investigación.
• [ ] Aplicar privilegio mínimo, autenticación, cifrado y registro de accesos.
• [ ] Controlar exportaciones, alteraciones, preservación por incidentes y documentación del esquema.

Los registros pueden contener datos personales, secretos de clientes o información de seguridad. Un repositorio central sin límites crea un nuevo riesgo.

6. Conservar y borrar por clase

• [ ] Definir finalidad, inicio del plazo, fecha de borrado y mínimo aplicable de los artículos 19 o 26.
• [ ] Conciliarlo con minimización, limitación de conservación, reglas sectoriales, contratos, incidentes y bloqueos.
• [ ] Aplicarlo a almacenes principales, analítica, exportaciones, réplicas y copias; aprobar excepciones y probar el borrado.

«Al menos seis meses» no es una respuesta universal: se refiere a determinados registros automáticos de alto riesgo bajo control del operador. Cada clase necesita una justificación propia.

7. Revisar y escalar

• [ ] Activar revisión por cambios materiales, identificadores ausentes, controles fallidos, anulaciones inusuales, rendimiento inesperado o uso no autorizado.
• [ ] Vincular incidentes, quejas y avisos de proveedores al sistema.
• [ ] Definir destino, gravedad, plazo, decisor y prueba de cierre para cada desencadenante.
• [ ] Seguir brechas abiertas, tendencias y muestras basadas en riesgo.

Un aviso sin propietario ni regla de cierre no es un control. Mida integridad del esquema, reconstrucciones, excepciones abiertas, accesos indebidos y borrado, no volumen almacenado.

8. Probar la cadena de evidencia

• [ ] Reconstruir una entrega con alcance, aprobaciones, versiones, evaluación y despliegue.
• [ ] Trazar un resultado y una excepción hasta controles, acción humana, corrección y cierre.
• [ ] Comprobar acceso, exportación y borrado en todas las copias gobernadas.
• [ ] Registrar brechas, responsables, fechas y repetición de pruebas.

Debe probarlo alguien que no creó el expediente. Si depende de mensajes privados o de la memoria de una persona, aún no es repetible.

Puesta en marcha en una semana

Elija un flujo relevante. Documente límite, rol, clasificación, preguntas, proveedores y brechas. Acuerde esquema, responsabilidades, acceso, conservación y desencadenantes. Ejecute una reconstrucción y cree una lista breve de correcciones. Reutilice la plantilla en el siguiente flujo de mayor riesgo.

Tras la modificación de 2026, las reglas de alto riesgo para los usos del anexo III se aplican desde el 2 de diciembre de 2027 y para sistemas integrados en productos regulados del anexo I desde el 2 de agosto de 2028. Use la transición para probar el modelo operativo.

Errores comunes

Empezar por una herramienta; registrarlo todo; confundir telemetría con evidencia completa; ignorar límites de proveedores; exigir aprobación manual siempre; o no probar el borrado. Automatice lo rutinario y pruebe reconstrucción y eliminación.

Preguntas frecuentes

¿Cuál es la finalidad práctica?

Permitir que una persona autorizada reconstruya actividad, controles, acciones humanas, cambios y seguimiento relevantes, no maximizar la recogida de datos.

¿Cuándo se aplica a SaaS?

Estas obligaciones del Reglamento de IA afectan a sistemas de alto riesgo según el rol y control. Otros sistemas pueden necesitar registros proporcionados por seguridad, privacidad, contratos o incidentes.

¿Qué debe hacerse primero?

Documente límite, finalidad, rol, clasificación, registros controlados y preguntas de un sistema. Después defina eventos mínimos, responsables, acceso, conservación y desencadenantes.

¿Hay que conservar todos los prompts y respuestas?

No. Elija campos por una finalidad definida y use metadatos minimizados, referencias protegidas, hashes o muestras restringidas cuando sean suficientes.

¿Cómo se demuestra que funciona?

Con pruebas de reconstrucción, acceso, exportación y borrado, brechas documentadas y nuevas pruebas tras la corrección.

Fuentes

• Reglamento (UE) 2024/1689, texto consolidado a 27 de julio de 2026, en especial artículos 12, 19 y 26.
• Reglamento (UE) 2026/1744 sobre las fechas modificadas.
• Comisión Europea, «Reglamento de IA», calendario y resumen actuales.