Rastros de auditoría criptográficos: evidencia que un regulador puede inspeccionar

Pregúntale a un equipo cómo va a explicar después la decisión de un agente y la respuesta habitual es "lo registramos todo". Los registros parecen rendición de cuentas. Hay un apunte con fecha y hora, va a un almacén central, y cuando alguien pregunta qué pasó puedes ir a leerlo. Para muchos sistemas, con eso basta de verdad.

Solo que un registro corriente no sobrevive al único momento para el que existe: un regulador, un auditor o un tribunal diciendo "demuestra que este registro no se alteró después de la decisión, y demuestra que no falta nada". Un registro estándar no puede responder. Es escribible, así que las entradas se pueden cambiar. A menudo se escribe después de la acción, así que puede retrasarse o perderse. Y no tiene estructura interna que revele manipulación, así que una entrada borrada o editada no deja rastro. Cuando lo que está en juego es una sanción, "confíen en nuestros registros" no es evidencia. Es una afirmación, y todo el sentido del ejercicio es que tu afirmación es exactamente lo que está en cuestión.

El replanteamiento es dejar de pensar en registrar y empezar a pensar en evidencia: un registro construido para que su propia integridad sea demostrable, producido de forma que "lo cambiamos después" o "se perdió una entrada" sea detectable en lugar de negable. Ese es un objetivo de ingeniería distinto, y tiene una forma bien conocida.

Append-only y encadenado por hash: la manipulación se vuelve visible

Dos propiedades convierten un registro en evidencia, y funcionan juntas.

La primera es ser append-only. Los registros se pueden añadir pero nunca editar ni borrar en su sitio. No hay operación de actualización ni de borrado, solo de añadido. Solo eso elimina la forma más común en que un registro pierde credibilidad, la edición silenciosa a posteriori, porque la operación que lo haría no existe.

La segunda es el encadenado por hash, y es lo que hace el append-only demostrable en lugar de solo prometido. Cada registro incluye un hash criptográfico del registro anterior, así que las entradas forman una cadena en la que cada eslabón se compromete con el anterior. Organiza esos hashes en una estructura de Merkle, un árbol en el que cada nodo es el hash de sus hijos, y obtienes un único hash raíz que resume toda la historia. Cambia un campo en un registro y su hash cambia, lo que cambia todos los hashes por encima, lo que cambia la raíz. La alteración no se puede esconder. Quien tenga la raíz antigua puede demostrar, matemáticamente, que la historia se modificó, y puede demostrarlo sin confiar en ti en absoluto.

Ese es el giro de "creed en nuestro registro" a "verificad nuestra evidencia". La integridad del registro deja de descansar en tu palabra o en tus controles de acceso. Descansa en criptografía que una parte externa puede comprobar de forma independiente.

Almacenamiento WORM: el medio impone lo que el software promete

El append-only en software es una disciplina fuerte, pero un operador con privilegios suficientes, o un atacante suficientemente decidido, puede a veces llegar por debajo. Para evidencia que tiene que aguantar escrutinio adversario, el propio medio de almacenamiento debería imponer la propiedad.

El almacenamiento WORM, write-once-read-many, hace exactamente eso. Una vez que un registro se confirma, la capa de almacenamiento impide físicamente que se sobrescriba o se borre durante un periodo de retención definido, sin importar los privilegios de quien llama. La garantía deja de depender solo de que la aplicación se comporte correctamente. Se impone por debajo de la aplicación, donde ni un administrador puede reescribir la historia en silencio. Combina WORM con encadenado por hash y tienes cinturón y tirantes: el medio se niega a dejar que el registro cambie, y la criptografía lo revelaría si el medio fallara de algún modo.

Escrito antes de que la decisión se confirme: sin evidencia, no hay decisión

Esta es la decisión de diseño que separa la evidencia real de una reconstrucción, y es la que la mayoría de los equipos hace al revés.

La evidencia tiene que escribirse antes de que la decisión surta efecto, no después. Esto invierte el orden habitual, en el que un sistema actúa y luego, como efecto secundario, registra lo que hizo. En ese orden habitual, el registro es una ocurrencia tardía, y las ocurrencias tardías pueden fallar: la acción tiene éxito, la llamada de registro lanza una excepción, y ya tienes una decisión sin evidencia detrás. En un proceso regulado eso es lo peor de los dos mundos: una consecuencia en el mundo y ningún registro del porqué.

Así que la secuencia se impone al revés. El sistema monta el registro de la decisión y lo confirma primero en el almacén de evidencias. Solo una vez que esa escritura tiene éxito se permite que la decisión surta efecto. Si el almacén de evidencias no está disponible, o la escritura falla, la decisión no sigue adelante. Sin almacén de evidencias, no hay decisión. El sistema falla cerrado: cuando no puede demostrar lo que está a punto de hacer, se niega a hacerlo. Esa única regla garantiza una propiedad que a los reguladores les importa profundamente. En esta arquitectura no existe tal cosa como una acción con consecuencia sin un registro correspondiente y resistente a manipulación, porque el registro es una precondición de la acción, no un subproducto de ella.

Qué tiene que contener un registro de decisión

La integridad no vale nada si el registro está vacío de significado. Un registro a prueba de manipulación que dice "decisión tomada: aprobada" solo demuestra que no puedes alterar un registro que no dice nada útil. Así que el contenido importa tanto como la criptografía. Un registro de decisión apto para inspección debería capturar, como mínimo:

• La decisión y su veredicto. Qué se decidió, y bajo qué resultado explícito (permitir, permitir con condiciones, denegar o exigir persona).
• Las entradas. Los documentos, datos y contexto concretos sobre los que se tomó la decisión, referenciados para poder reconstruir la base de evidencia exacta.
• La autoridad. Qué identidad de agente actuó, a qué nivel de autonomía y bajo qué versión de política.
• La evaluación de la política. Qué reglas se aplicaron y qué devolvió cada una, para que el "por qué" sea explícito y no inferido.
• El razonamiento y la fundamentación. La justificación del agente y las fuentes citadas tras cada afirmación material.
• La persona, cuando la hubo. Si la decisión exigió una persona, quién fue y qué aprobó, cerrando el círculo de rendición de cuentas.
• Tiempo y posición en la cadena. Cuándo ocurrió y dónde se sitúa en la cadena de hashes, para poder localizarlo y verificarlo.

Un registro con esos campos responde a la pregunta que una inspección hace de verdad: no solo "¿qué decidió el sistema?", sino "¿con qué fundamento, bajo qué autoridad, contra qué política, y puedes demostrar que este relato está intacto?".

El artículo 12 del EU AI Act, y por qué esto no es opcional

Esta arquitectura no es lujo. Para sistemas de IA de alto riesgo, va camino de ser la base que la ley espera.

El artículo 12 del EU AI Act exige que los sistemas de IA de alto riesgo conserven registros, con registro automático de eventos a lo largo de la vida del sistema, en un grado adecuado a su finalidad prevista, para que el funcionamiento del sistema sea trazable y sus riesgos puedan supervisarse después. Lee ese requisito frente a un registro corriente, editable y de mejor esfuerzo, y la brecha es obvia. "Trazable" y "conservación adecuada de registros" no se satisfacen con un almacén cuya integridad no puedes demostrar y cuya completitud no puedes garantizar. Evidencia append-only, encadenada por hash, respaldada por WORM y escrita antes de que la decisión se confirme no es una interpretación más estricta de lo necesario de ese artículo. Es una lectura directa de lo que "registros en los que un supervisor puede confiar" tiene que significar cuando el sistema es probabilístico y las decisiones pesan.

Así que la pregunta que llevar a tu próxima revisión no es "¿estamos registrando nuestros agentes?". Todo el mundo registra algo. Es ¿podemos entregarle a un regulador el registro de cualquier decisión de un agente y demostrar, sin pedirle que confíe en nosotros, que está completo y no se alteró después? Si la respuesta honesta es no, tienes registros. Todavía no tienes evidencia, y para la evidencia es para lo que sirve una inspección.

Si quieres ver cómo es un registro de decisión inspeccionable en uno de tus procesos reales, reserva una reunión.