Qué registros exige el reglamento europeo de IA
El reglamento dice qué tiene que ser posible. No dice cómo construirlo, y en ese hueco es donde se traba casi todo el mundo. Acá está la obligación de registro traducida a lo que significa para un sistema que hay que diseñar, con las fechas que aplican y las partes que se leen mal seguido.
Qué dice el reglamento
- Artículo 12(1): los sistemas de IA de alto riesgo tienen que permitir técnicamente el registro automático de eventos durante toda su vida útil. La capacidad tiene que estar construida adentro, no agregada encima.
- Artículo 12(2): esos registros tienen que ser adecuados para identificar situaciones en las que el sistema pueda presentar un riesgo o sufrir una modificación sustancial, y para sostener la vigilancia posterior a la comercialización.
- El artículo 12(3) fija una lista mínima concreta —período de uso, base de datos de referencia, datos de entrada que dieron coincidencia, personas que verificaron los resultados— pero esa lista está escrita para sistemas de identificación biométrica remota, no para todo sistema de alto riesgo. Se cita por todos lados como si fuera universal. No lo es.
- Artículo 19: los proveedores tienen que conservar los registros que generan automáticamente sus sistemas de alto riesgo, cuando estén bajo su control, al menos seis meses, salvo que otra norma de la Unión o nacional exija más.
- Artículo 26(6): el mismo piso de seis meses rige para quien despliega el sistema, sobre los registros bajo su control.
- Artículo 11 y Anexo IV: la documentación técnica tiene que existir antes de que el sistema llegue al mercado, y describe decisiones de diseño que se están tomando ahora.
Qué significa para un sistema que hay que construir
«Durante toda su vida útil» descarta agregarlo después
Un registro que empieza el día que pregunta el auditor no prueba nada sobre los once meses anteriores. Esta es la lectura equivocada más cara: los equipos tratan el registro como una función de reportes para sumar cerca de la fecha, cuando la obligación es que el sistema haya estado registrando todo el tiempo.
«Adecuados para identificar riesgo» es una decisión de diseño, no una configuración
Para la mayoría de los sistemas el reglamento no enumera campos. Enuncia un propósito: alguien tiene que poder reconstruir qué pasó. En la práctica eso significa las entradas, el contexto recuperado, la salida, las versiones de cada componente que intervino, y una marca de tiempo —porque sin versiones, una reconstrucción de hace tres meses describe un sistema que ya no existe—.
Seis meses es un piso, y choca con la protección de datos
Los registros de un sistema de IA suelen contener datos personales, así que caen bajo el reglamento de protección de datos al mismo tiempo. Guardar todo para siempre no es la opción segura: hace falta un plazo de retención defendible en las dos direcciones, y una forma de atender un pedido de borrado sin destruir el rastro de auditoría.
Proveedor y responsable del despliegue son roles, no tipos de empresa
La misma organización suele ser las dos cosas: proveedora del sistema que construyó y responsable del despliegue del que opera. Cada rol trae su propio deber de conservación. Definir cuál sos es la primera pregunta, y es una pregunta legal, no de ingeniería.
La documentación describe decisiones que estás tomando hoy
La documentación del Anexo IV cubre arquitectura, datos y las decisiones detrás de ellos. Reconstruir eso en 2027 sobre un sistema ya en producción cuesta varias veces más que registrarlo sobre la marcha, porque para entonces nadie se acuerda del porqué.
Dónde suelen quedar cortos los sistemas
Se registra la salida y no la entrada
Queda guardada una respuesta sin el contexto recuperado que la produjo. Cuando alguien pregunta por qué el sistema dijo eso, la respuesta es irreconstruible: la misma pregunta contra un índice cambiado da otro resultado.
No se versiona nada
Modelo, prompt, índice de recuperación y configuración cambian por separado, y ninguno queda registrado junto a la salida. Seis semanas después los registros describen un sistema que ya no existe.
La recuperación ignora los permisos
Un índice para todo, con el acceso comprobado después de generar o directamente nunca. Eso no es sólo un hueco de cumplimiento: es una fuga de datos, y el registro va a dejar constancia fiel de que ocurrió.
Nunca se decidió la retención
O los registros rotan a los treinta días, por debajo del piso, o se acumulan para siempre con datos personales adentro. Las dos cosas son un problema, y la segunda es peor.
Hay un documento de política y no hay mecanismo
El hallazgo más común. Un compromiso escrito de registrar cosas que el sistema no registra. Ese hueco lo ve la primera persona que pide una muestra.
Seis preguntas para hacerle a tu propio sistema
- ¿Podés producir, para cualquier respuesta que dio tu sistema, qué recuperó para producirla?
- ¿Podés decir qué versión de modelo, prompt e índice estaba en uso en ese momento?
- ¿Podés mostrar que quien preguntó tenía permiso de ver todas las fuentes que alimentaron la respuesta?
- ¿Tus registros sobreviven al menos seis meses, y tenés un motivo defendible para el plazo que elegiste?
- Si alguien ejerce un derecho de borrado, ¿tu rastro de auditoría sobrevive?
- ¿Tu documentación técnica describe el sistema que corre hoy, o el que diseñaste originalmente?
Preguntas que esto abre
¿Esto es asesoramiento legal?
No. Es una lectura de ingeniería de un texto legal, escrita por los ingenieros de Devsitia que construyen estos sistemas. Qué obligaciones le aplican a tu organización, y qué rol ocupás, son preguntas para tu equipo legal. Lo que sí podemos decirte es qué tiene que hacer un sistema para producir la evidencia que esas obligaciones describen.
¿Desde cuándo aplican de verdad estas obligaciones?
El 2 de agosto de 2026 es la fecha vinculante para las obligaciones de alto riesgo, de proveedores y de responsables del despliegue. Los requisitos más pesados para los sistemas del Anexo III se difirieron al 2 de diciembre de 2027 mediante el Digital Omnibus. Ese diferimiento mueve la fecha, no el trabajo: los registros tienen que describir decisiones que se están tomando ahora.
¿La lista de cuatro puntos del artículo 12 le aplica a mi sistema?
Probablemente no, y es la lectura equivocada que Devsitia ve más seguido. Esa lista está escrita para sistemas de identificación biométrica remota. Para los demás sistemas de alto riesgo, el artículo 12 enuncia un propósito —registros adecuados para identificar riesgo y sostener la vigilancia posterior— y te deja el diseño a vos. Copiar la lista biométrica no es cumplir, y encima puede dejar afuera lo que tu sistema realmente necesita registrar.
Estamos fuera de la Unión Europea. ¿Nos alcanza algo de esto?
Puede alcanzarte. El reglamento sigue al uso, no al domicilio: colocar un sistema en el mercado europeo o atender usuarios ahí puede meterte en alcance. Aparte de eso, las compras corporativas piden cada vez más la misma evidencia —ISO 42001, SOC 2— sin importar la jurisdicción.
Nuestra IA no es de alto riesgo. ¿Necesitamos algo de esto?
Puede que la obligación no te aplique, pero la capacidad conviene tenerla igual, y por un motivo comercial simple: el primer cliente corporativo que te pregunte qué hizo tu sistema con sus datos va a querer una respuesta, y «eso no lo registramos» termina la conversación. Construirlo después, sobre un sistema andando, es una migración en lugar de una decisión de diseño.
¿Cuál es el momento más barato para hacer esto?
Antes de que el sistema exista. Registros, versionado y recuperación con permisos diseñados desde el principio son unas cuantas decisiones. Agregados a algo que ya está en producción, son un proyecto —y uno que hay que hacer sin la historia que no se tiene—.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.