En algún punto de su stack, un agente ya ha producido el número que algún día estará frente a un auditor. Lo calculó — o lo generó; quizás usted no lo sabe — alguien lo pegó en una presentación, y la presentación se distribuyó. Meses después llega la pregunta que todo sistema de IA en producción acaba recibiendo: ¿de dónde vino este número, y lo obtendríamos de nuevo hoy?
La mayoría de los equipos responde con una transcripción. En una encuesta del primer trimestre de 2026 realizada a 420 organizaciones que ejecutan agentes de IA en producción, solo el 17 % pudo reconstruir la secuencia completa de llamadas a herramientas, entradas y salidas de una tarea específica del agente a posteriori (AgentNode, 2026). El 83 % restante tenía logs parciales, ningún log, o logs que capturaban el razonamiento del modelo pero no lo que realmente invocó. Una transcripción y una intuición.
El registro se está convirtiendo en ley
Durante un tiempo esto fue un problema de ingeniería embarazoso. Está a punto de convertirse en uno legal.
La Ley de IA de la UE exige que los sistemas de IA de alto riesgo permitan técnicamente — diseñado desde el origen, no añadido a posteriori — «el registro automático de eventos (logs) durante toda la vida útil del sistema» (European Commission, 2024). El registro manual no satisface el artículo 12. Los logs deben ser suficientes para identificar situaciones que puedan presentar riesgos o modificaciones sustanciales, para respaldar la vigilancia poscomercialización y para monitorizar cómo opera realmente el sistema. Para la identificación biométrica remota, el artículo nombra el mínimo explícitamente: cada período de uso, la base de datos de referencia consultada, los datos de entrada que condujeron a una coincidencia, las personas físicas que verificaron el resultado. Eso no es «conservar algunos logs». Es reconstruir la decisión.
Las fechas son próximas. La Ley entró en vigor el 1 de agosto de 2024; las prohibiciones se aplicaron desde febrero de 2025, las obligaciones sobre modelos de uso general desde agosto de 2025 — y las obligaciones de alto riesgo, el artículo 12 entre ellas, se aplican desde el 2 de agosto de 2026 (Future of Life Institute, 2026). Ocho días desde la fecha de esta publicación. Los sistemas de alto riesgo integrados en productos regulados (Anexo I) siguen en agosto de 2027.
La retención también tiene un mínimo. Los proveedores deben conservar los logs generados automáticamente durante al menos seis meses, y el artículo 26(6) impone la obligación simétrica a los responsables del despliegue — más tiempo cuando otra normativa como el RGPD lo exija, y en todo caso adecuado a la finalidad prevista del sistema, no solo al mínimo (artificialintelligenceact.eu, 2024).
Nada de esto llega en el vacío. El artículo 30 del RGPD ha exigido registros escritos de tratamiento — finalidades, categorías de datos, destinatarios, plazos de supresión, medidas de seguridad — desde 2018, presentables a la autoridad de control a petición (gdpr-info.eu, 2016). El CC7.2 de SOC 2 exige monitorizar los componentes del sistema en busca de anomalías y analizar los hallazgos; el CC7.3 exige evaluar si un evento comprometió los objetivos (AICPA, 2022). En una auditoría de Tipo II, esos criterios se contrastan con evidencia de logs que abarca todo el período de revisión — típicamente doce meses (AgentNode, 2026) — no una captura de pantalla del día en que visitó el auditor.
Por qué «registrar más» no funciona
El reflejo habitual es la verbosidad: activar el rastreo, almacenarlo todo, comprar un dashboard. Tres problemas persisten.
Las transcripciones registran lo que se dijo, no lo que se ejecutó. Un log de chat es el modelo narrando su propio comportamiento. Entre el 83 % mencionado, un grupo es exactamente este: razonamiento capturado, invocaciones a herramientas no. Cuando la narración y la ejecución discrepan, la transcripción mantiene el tipo — calculado y generado son indistinguibles en la página. No son lo mismo.
Un log que no se puede re-ejecutar es testimonio, no evidencia. Incluso los equipos que capturan cada llamada a herramienta generalmente no pueden ejecutarla de nuevo y comparar, porque nada fijó el entorno en que se ejecutó. El SQL se generó ese día, contra una base de datos que desde entonces ha cambiado; la aritmética se muestreó de un modelo que nunca fue estable. Conservar eso durante seis meses — o doce — significa almacenar afirmaciones más tiempo, no hacerlas verificables. La redacción del artículo 12 es precisa: el sistema debe permitir técnicamente el registro. La reproducibilidad que no se diseñó desde el origen no puede añadirse a posteriori con una biblioteca de logging.
Los metadatos no son corrección. El registro de auditoría mínimo viable — seis campos básicos, entre ellos el ID de traza, la marca de tiempo y la identidad del agente (AgentNode, 2026) — establece quién y cuándo. No dice nada sobre si el número era correcto, ni si daría el mismo resultado hoy. La investigación sobre observabilidad de agentes LLM llega a la misma conclusión: la trazabilidad debe cubrir los artefactos de todo el ciclo de vida del agente, no solo los mensajes (CSIRO Data61, 2024).
El fallo es estructural. La ejecución de forma libre — un modelo emitiendo cadenas que otra cosa ejecuta — no produce nada suficientemente estable para registrar, por mucho que se escriba.
La procedencia como parte del resultado
La respuesta de SQAI es hacer del registro una propiedad de la ejecución, no una característica del logging. Cada resultado ejecutado lleva cuatro hashes, cada uno respondiendo a una pregunta de auditoría distinta:
contract_hash— qué podía ejecutarse: el contrato de capacidad exacto en vigor (sha256:79f1c5a6c716…).plan_hash— a qué se resolvió la solicitud: el plan validado, con su resolución registrada (decision_path: "exact_spec").invocation_hash— qué se ejecutó, sobre qué: la capacidad más las entradas canonicalizadas, incluyendo uninput_hashde los datos tal como estaban.computation_hash— qué produjo: vinculado a la invocación y al valor conjuntamente.
Las construcciones están separadas por dominio, de modo que ningún artefacto puede suplantar a otro:
invocation_hash = sha256("sqai:invocation:v1\0" + canonicalJson(identity))
computation_hash = sha256("sqai:computation:v1\0" + invocation_hash + canonicalJson(value))
Junto a los hashes viaja el sobre de determinismo — el entorno de ejecución registrado: runtime_bundle_version 0.1.0 y su sha256, plataforma y arquitectura, precision_mode: float64, thread_count: 1, y la semilla cuando se requiere. Las diez capacidades de simulación que la necesitan se niegan a ejecutarse sin ella — seed_required, no una respuesta silenciosamente diferente. Todo lo que podría cambiar el número está fijado o escrito.
Esto es lo que aporta, concretamente. En marzo, un agente calcula un valor actual neto:
finance.npv(0.1, [-1000, 300, 420, 560, 680])
→ 505.020148896933
computation_hash b74f67d0d7a594aa…
En julio, el auditor pregunta. Usted reproduce la invocación — misma especificación tipada, mismo runtime fijado — y compara los hashes: b74f67d0d7a594aa… de nuevo, idéntico byte a byte. No importa si la reproducción se ejecuta en TypeScript o Python. canonicalJson y canonical_json son un contrato de serialización entre lenguajes — claves ordenadas, -0 normalizado a 0, escape unicode fijo — de modo que el mismo valor produce los mismos bytes y el mismo hash en ambos. La página de determinismo muestra dos de estos sobres, con meses de diferencia, uno junto al otro.
Y cuando la reproducción no coincide, eso es una señal. Una fuente modificada falla de forma explícita con schema_revision_mismatch — el motor se niega a calcular silenciosamente un número diferente contra datos distintos y atribuirlo al pasado. La discrepancia nombra lo que cambió.
Traslade eso a las obligaciones. Registro automático durante la vida útil del sistema: cada resultado ejecutado se registra a sí mismo, por construcción — no existe ninguna ruta sin registro, porque la superficie de ejecución son 4.574 capacidades de solo lectura con entradas tipadas, no cadenas de texto libre. Seis o doce meses de retención: almacene los sobres de resultado; la retención se convierte en una decisión de almacenamiento en lugar de arqueología. Evidencia que abarca un período de revisión SOC 2: los artefactos son la evidencia — la respuesta al auditor es una reproducción, no una investigación. El mismo pipeline produce el registro para cada capacidad, y el registro de auditoría persistente se incluye en el nivel Pro de SQAI.
Ocho días, y luego cada auditoría que siga
La fecha de agosto vincula formalmente a los sistemas de alto riesgo en la UE. Pero plazos como este establecen el modelo para cada revisión posterior — el auditor de SOC 2, el cuestionario de contratación, su propio CFO en marzo preguntando por un número de enero. A los agentes se les va a pedir que justifiquen sus respuestas como se les pide a los empleados: con registros. La mayoría de los stacks no puede producirlos, porque el SQL generado y la aritmética muestreada no dejan nada suficientemente estable para registrar — un problema que comienza mucho antes de la auditoría.
Una respuesta que se puede reproducir es una respuesta que se puede defender. Todo lo demás es una captura de pantalla.