Qué pide realmente el reglamento
El Reglamento de IA de la UE suele presentarse como una carga de cumplimiento abstracta, pero para los equipos que operan flujos de trabajo con IA las exigencias son muy concretas. Los sistemas de alto riesgo deben conservar registros que permitan a una persona reconstruir qué hizo el sistema y por qué. No es una aspiración vaga: el artículo 12 exige el registro automático de eventos durante toda la vida del sistema, y el artículo 14 exige que una persona pueda supervisar e intervenir de forma efectiva. Si tu flujo no puede producir ese registro cuando se lo pidan, no tienes una laguna que puedas tapar más tarde, tienes una laguna de diseño.
Artículo 12: registrar no es opcional
El registro automático de eventos significa que el sistema anota las entradas que recibió, las decisiones que tomó, las versiones de modelo implicadas y el resultado, de forma continua y sin que un ingeniero tenga que acordarse de activarlo. Los registros deben ser trazables y a prueba de manipulación para que un auditor confíe en ellos. En la práctica esto empuja a los equipos hacia el almacenamiento append-only: escribes cada evento una sola vez, nunca lo editas, y cada entrada se encadena mediante hash con la anterior, de modo que cualquier manipulación posterior sea detectable. Un log de aplicación que se rota a los siete días no cumple ese listón.
Artículo 14: supervisión humana que puedas demostrar
La supervisión humana solo es real si una persona pudo entender la situación y actuar. Eso significa que el flujo debe mostrar, en el momento de una decisión relevante, contexto suficiente para que quien revisa apruebe, rechace o escale, y debe dejar constancia de lo que decidió. Una barrera de políticas que pausa una automatización para su aprobación, y que registra la identidad y el razonamiento de quien aprueba, es la diferencia entre afirmar que hay supervisión y poder evidenciarla.
Qué implica para tu arquitectura
El hilo conductor es la evidencia. Cada requisito, registro, trazabilidad, supervisión, análisis posterior a un incidente, da por hecho que podrás responder "qué pasó exactamente" meses después. Los sistemas que tratan su historial de ejecución como algo desechable lo pasarán mal. Los que se apoyan en un registro de eventos append-only y encadenado por hash responden a estas preguntas casi gratis, porque el registro ya existe y no se puede reescribir en silencio.
Empezar sin abarcarlo todo
No hace falta resolver todo el Reglamento el primer día. Empieza por identificar qué flujos tocan decisiones de alto riesgo, haz que sus registros de eventos sean append-only y encadenados por hash, y pon una barrera de aprobación humana en los pasos irreversibles. Eso te da la columna vertebral de una pista de auditoría. Todo lo demás, documentación, evaluaciones de riesgo, tareas de conformidad, se engancha a esa columna mucho más fácilmente que a un sistema que nunca registró lo que hizo.