Por qué los registros de los agentes no satisfarán el artículo 12: registros de decisiones, causalidad y procedencia
Los registros de los agentes no cumplirán con lo dispuesto en el artículo 12 de la Ley de IA de la UE. Se deben registrar las decisiones de los agentes de IA como objetos duraderos con vínculos causales, cadena de huellas hash y reglas fijas.
En agosto de 2026 entró en vigor una norma que la mayoría de los equipos de ingeniería aún no han sentido. El artículo 12 de la Ley de IA de la UE establece que los sistemas de IA de alto riesgo deben permitir técnicamente el registro automático de eventos durante toda su vida útil, con un nivel de trazabilidad proporcional al propósito del sistema. El artículo 26 impone al responsable de su implementación la obligación correspondiente: conservar esos registros durante al menos seis meses, o más si lo exigen otras leyes.
Un ingeniero que lee el texto observa un extraño desequilibrio. El objetivo se expresa con precisión, mientras que el formato requerido apenas se menciona. El objetivo es poder reconstruir, a posteriori, una decisión concreta. Un producto APM no lo permite, ya que fue diseñado para otra finalidad. Tampoco lo hace un almacén de vectores.
El momento es inoportuno, ya que los agentes acaban de dejar de responder preguntas y comenzaron a actuar. Aproban gastos, modifican el tamaño de la infraestructura, gestionan las reclamaciones de seguros, rechazan a los solicitantes y dan su aprobación para las liberaciones. Cada una de estas acciones es una decisión que alguien podría pedirle eventualmente a la empresa que justifique, y en la mayoría de las organizaciones actuales la respuesta sincera sería que no pueden hacerlo.
Un caso de reclamaciones menores que anticipó el problema
Antes de que existiera la regulación, y antes de que los agentes pudieran actuar, un tribunal en Columbia Británica puso a prueba la misma debilidad a pequeña escala. Sigue siendo el ejemplo más claro disponible.
La abuela de Jake Moffatt falleció en noviembre de 2022. Ese mismo día visitó el sitio web de Air Canada para reservar un vuelo a Toronto y, al no saber cómo funcionaban las tarifas por duelo, consultó al chatbot de la aerolínea. El bot le indicó que podía comprar un boleto al precio completo de inmediato y solicitar posteriormente la tarifa reducida por duelo, dentro de los 90 días siguientes. Antes de confiar en esto, Moffatt hizo algo sensato: tomó una captura de pantalla de la respuesta. Luego reservó el vuelo, viajó, asistió al funeral y presentó su solicitud.
Air Canada le rechazó la solicitud. No existía tal política, y el bot la había inventado.
La continuación es la parte instructiva. En el Tribunal de Resolución Civil, la aerolínea argumentó que no podía ser considerada responsable de lo que decía su chatbot, describiéndolo como una entidad separada responsable de sus propias acciones. El miembro del tribunal, Christopher Rivers, calificó ese argumento como notable y señaló que la aerolínea nunca había explicado por qué alguien debería aceptarlo. Un chatbot forma parte de un sitio web, y la empresa es responsable de su sitio web. Air Canada pagó 812,02 dólares canadienses.
Esa cantidad es insignificante. La cifra relevante es cero: el número de registros que Air Canada podría presentar para demostrar por qué su propio sistema dijo lo que dijo. La única prueba duradera de toda la audiencia fue la captura de pantalla del cliente.
Ese mismo fallo ha ido agravándose desde entonces. En abril de 2025, un bot de soporte de Cursor creó una política que limitaba las suscripciones a un único dispositivo. Los clientes comenzaron a cancelarlas, y la empresa se enteró solo porque un cofundador encontró el hilo de discusión en Reddit. El patrón es idéntico, el alcance del problema es mayor y el ritmo más rápido, y no fue necesario recurrir a ningún tribunal.
Ahora imagine esa misma debilidad en la evidencia presentada ante un regulador, asociada a un agente que maneja dinero.
El depuración y la rendición de cuentas son tareas diferentes
La mayoría de los sistemas nunca establecen una distinción que sea relevante en este caso.
La observabilidad está centrada en la ejecución. Captura lo que hizo un proceso durante una ejecución: intervalos de tiempo, llamadas a herramientas, conteos de tokens, intentos de reintentar y latencia. Se obtiene mediante muestreos, expira después de un período de retención y está limitada a una solicitud. Eso es exactamente lo necesario para localizar un error un martes.
La rendición de cuentas está centrada en el dominio. Captura qué concluyó la organización, con qué evidencia, bajo qué política, y qué sucedió después. Debe sobrevivir a migraciones de frameworks, retiro de modelos, reconstrucción de índices, reorganizaciones y la partida de dos colegas.
En otras áreas de una empresa esto es algo rutinario. Un cambio en producción nunca se reconstruye a partir de los registros de la aplicación, ya que el registro del cambio incluye al autor, un ticket y una aprobación. Una situación financiera nunca se reconstruye a partir de rastros HTTP, ya que existen entradas en el libro mayor. Los pedidos, pagos, aprobaciones y despliegues son objetos duraderos, y cada uno tiene un ciclo de vida, un responsable y una regla de retención.
Las decisiones de los agentes son el único tipo de evento significativo que aún queda como información no estructurada, sin un sistema formal para gestionarla.
La versión de las 3 a.m.
El enfoque basado en el cumplimiento hace que el fallo parezca algo exótico, cuando en realidad es algo muy común; por eso un caso concreto resulta útil.
Veinte minutos después del lanzamiento, los procesos de verificación comienzan a devolver errores 5xx. Un agente de triaje compara la tasa de errores con el período de implementación, no detecta alertas de infraestructura y clasifica el incidente como una regresión del lanzamiento. Un agente de corrección deshace el lanzamiento, y los errores vuelven a la normalidad. Un agente de lanzamientos vuelve a abrir la cola de despliegue. Alguien envía un símbolo de aprobación en el canal de incidentes y el equipo da por finalizada la tarea. En total, once minutos, y no se realiza ninguna revisión del incidente, ya que parecía haberse resuelto por sí solo.
Pero el lanzamiento nunca fue el culpable. Un proveedor de pagos intermedio había estado funcionando de forma deficiente y, por casualidad, se recuperó justo en el momento del deshacimiento del lanzamiento. La correlación fue pura coincidencia, y los agentes inventaron una historia creíble al respecto.
La verdad sale a la luz en octubre, cuando se repite el mismo patrón y alguien se pregunta si el episodio de abril compartía la misma causa raíz. Es hora de ir a comprobarlo.
Para entonces las huellas ya han caducado, habiéndose eliminado en junio. La plantilla de consulta ha sido reescrita dos veces. Cuando cambió el modelo de incrustación, se reconstruyó el índice de recuperación, por lo que los pasajes del manual que el agente leyó en aquel entonces no son los mismos que leería hoy. La versión del modelo indicada en el encabezado de la solicitud ya está obsoleta. Lo que queda es un hilo de chat que termina con un emoji de pulgar arriba.
La pregunta no puede responderse. Nadie fue descuidado. Nada en la arquitectura estaba diseñado para contener la respuesta.
Por qué una mejor memoria no lo solucionará
El instinto habitual es recurrir a la capa de memoria, que suele ser un almacén de vectores. Eso aborda un problema completamente distinto.
El sistema de búsqueda incrustada resuelve bien una pregunta: ¿qué se parece a esto? No puede indicar qué creía el sistema a las 14:02 de un día determinado, qué conclusión anterior condujo a esta, de dónde proviene un hecho concreto, ni si la política diseñada para restringir una acción realmente se activó.
También existe un defecto más sutil. La recuperación de información no permanece reproducible a lo largo del tiempo. Al incrustar nuevamente el corpus con un modelo más reciente, una consulta idéntica devuelve un entorno diferente, por lo que lo que se consideraba un registro ha cambiado silenciosamente. Una huella de auditoría que puede ser reescrita sin que se note al actualizar una dependencia ya no es una verdadera huella de auditoría.
Cada capa responde a su propia pregunta:
- Búsqueda vectorial: ¿qué elementos se parecen a este?
- Gráfico de conocimiento: ¿qué está vinculado a él?
- Procedencia: ¿de dónde proviene y sigue siendo válido?
- Registros de decisiones: ¿qué se concluyó y con qué fundamentos?
- Vínculos causales: ¿qué evento influyó en cuál?
- Reglas: ¿qué política determina el resultado?
- Estado temporal: ¿qué era cierto en el sistema el 14 de marzo?
Una investigación real del tipo “¿por qué hizo eso?” necesita la mayoría de estos elementos. Solo uno de ellos es un almacén de vectores.
Convierte una decisión en un objeto
Aquí es donde Semantica merece ser considerada. Se trata de una capa en Python con licencia MIT que se encuentra debajo de un marco de agentes y trata el contexto como un grafo en lugar de un bloque de texto de instrucción. La construcción de grafos, el razonamiento y el seguimiento de origen son deterministas, sin la participación de modelos de lenguaje grande, lo cual es importante cuando el resultado debe servir como evidencia.
La idea central es sencilla. Una decisión se convierte en algo que se escribe deliberadamente, y no en algo que se registra al azar en un registro.
from semantica.context import ContextGraph
ctx = ContextGraph(advanced_analytics=True)
decision_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated 20 minutes after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts; "
"no dependency alarms visible at time of assessment",
outcome="classified_as_release_regression",
confidence=0.83,
)
La mecánica es sencilla. Lo que cambia es lo que el autor se ve obligado a explicar detalladamente. En lugar de texto libre en una línea de registro, se deben indicar una categoría, un escenario, los motivos, un resultado y un valor de confianza. Todo eso sigue siendo consultable dieciocho meses después, algo que el texto narrativo no permite.
Considere la cadena de texto reasoning del escenario de octubre. Indica que no había alarmas de dependencia visibles en el momento de la evaluación. Esa sola frase transforma la historia de un agente que cometió un error a uno que llegó a una conclusión razonable a partir de una señal parcial, lo cual señala una brecha en la supervisión que merece ser subsanada. Estas dos interpretaciones conducen a reuniones muy diferentes.
Una advertencia sobre ese campo: no es un lugar para la cadena de razonamiento bruta del modelo, la cual es inestable, a veces inventada e imposible de defender cláusula por cláusula ante un tercero. Registre la lógica detrás de la cual la organización está dispuesta a apoyarse: las pruebas consideradas, el umbral superado, la política aplicada, la persona que la anuló. De todos modos, eso sirve mejor a los procesos de producción.
Un único registro es una línea de registro; una cadena es la infraestructura
Los flujos de trabajo de los agentes reales se expanden, y el daño rara vez se concentra en un único nodo; se encuentra en todo lo que sigue en la cadena y que absorbió silenciosamente una conclusión errónea.
El ejemplo más conocido anterior a la IA es Knight Capital. Una implementación defectuosa en 2012 dejó activo un camino de código obsoleto, y en aproximadamente 45 minutos la empresa perdió unos 440 millones de dólares. Nadie dudó de lo que hacía el software, ya que cada orden se había registrado. Lo que nadie podía hacer era seguir las consecuencias manualmente tan rápido como se propagaban.
Semantica permite declarar los vínculos entre decisiones al momento de escribirlas:
triage_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts",
outcome="classified_as_release_regression",
confidence=0.83,
)
rollback_id = ctx.record_decision(
category="remediation",
scenario="Contain checkout 5xx",
reasoning="Regression attributed to release; rollback is lowest-risk action",
outcome="rolled_back_to_2026.30",
confidence=0.91,
)
unblock_id = ctx.record_decision(
category="release_gate",
scenario="Resume deploy queue after containment",
reasoning="Error rate normal for 30 minutes post-rollback",
outcome="deploy_queue_reopened",
confidence=0.86,
)
ctx.add_causal_relationship(triage_id, rollback_id, relationship_type="CAUSED")
ctx.add_causal_relationship(rollback_id, unblock_id, relationship_type="INFLUENCED")
why = ctx.trace_decision_chain(unblock_id)
blast_radius = ctx.analyze_decision_impact(triage_id)
Existen tres tipos de relaciones: CAUSADO, INFLUIDO y PREDECESOR_DE. El vocabulario es reducido, y eso es aceptable. Casi todo el valor proviene de una sola operación.
Al descubrir en octubre que la triaje estaba incorrecto, la pregunta cambia. Al preguntar qué registros mencionan los reembolsos se obtienen cuarenta mil filas. Al preguntar qué decisiones heredaron esa conclusión se obtiene una lista corta y limitada: el deshacer cambios, la reapertura de la cola, los mensajes enviados al cliente y el informe posterior que nadie escribió. Ese es el alcance de las decisiones subjetivas, y es precisamente la operación necesaria una vez que los agentes dejan de sugerir y comienzan a actuar.
find_similar_decisions() funciona en la dirección opuesta y devuelve precedentes. ¿Ha recibido este sistema este tipo de solicitud antes y qué hizo? Así es como se descubre a un agente que se contradice silenciosamente cada tercer martes, un verdadero fallo del que nadie se da cuenta porque no existe ninguna métrica para ello.
La causalidad no es la procedencia
Se confunden constantemente los dos conceptos, aunque responden a preguntas distintas. Saber que la decisión C se basó en la decisión A es de poca utilidad si no se conoce en qué evidencias se apoyó A.
El módulo de procedencia en Semantica sigue las normas W3C PROV-O. Es anticuado, pero correcto.
from semantica.provenance import ProvenanceManager
prov = ProvenanceManager(storage_path="./provenance.db")
prov.track_entity(
entity_id="release_2026_31",
source="ci/pipeline_runs/2026-31/manifest.json",
metadata={"stage": "canary", "extractor": "ManifestParser", "confidence": 0.99},
)
lineage = prov.get_lineage("release_2026_31")
Hay dos opciones de diseño aquí que vale la pena adoptar, incluso por parte de equipos que nunca instalan la biblioteca.
Primero, las entradas de procedencia forman una cadena de hash. Cada registro contiene un número de secuencia además de una suma de verificación que lo vincula con el anterior, y verify_chain() permite determinar si el historial fue modificado o si se eliminaron entradas. Eso es lo que distingue una tabla que cualquiera puede actualizar silenciosamente de algo que funciona como evidencia.
Segundo, los datos se invalidan en lugar de eliminarse. Cuando algo deja de ser cierto, se reemplaza junto con el responsable y la razón:
prov.invalidate(
"release_2026_31",
agent_id="human_sre_lead",
reason="Error attribution corrected; degradation traced to payments provider",
)
Una columna mutable con valid=false indica el estado actual. Un registro muestra que el estado alguna vez fue diferente, quién lo modificó, cuándo y por qué. Vuelva a la audiencia de Air Canada y pregunte cuál de los dos necesitaba la aerolínea. La respuesta es obvia.
Sacar la política del prompt
Otra ventaja discreta es que Semantica incluye motores de razonamiento reales: enlace forward, Rete, Datalog y SPARQL. La lógica es sencilla. Si una organización ya conoce una regla, no hay razón para pedirle a un modelo de lenguaje que la improvise en inglés en cada solicitud.
from semantica.reasoning import ReteEngine, Rule, Fact, RuleType
engine = ReteEngine()
engine.build_network([
Rule(
rule_id="dual_control_prod",
name="Human approval required for high blast-radius prod changes",
conditions=[
{"field": "env", "operator": "==", "value": "production"},
{"field": "blast_radius", "operator": "in", "value": ["high", "critical"]},
],
conclusion="require_human_approval",
rule_type=RuleType.IMPLICATION,
)
])
engine.add_fact(Fact("chg_014", "change", [{"env": "production", "blast_radius": "high"}]))
matches = engine.match_patterns()
El modelo sigue procesando la entrada compleja y sugiriendo la acción correspondiente. El cambio se produce en la verificación que aprueba o bloquea dicha acción: ya no se trata de un párrafo optimista dentro de una instrucción del sistema, al que un caso límite redactado de forma extraña podría eludir. Dado que rule_id se puede almacenar en el registro de decisiones, preguntar qué política se aplicó se convierte en una búsqueda sencilla, en lugar de un debate entre dos equipos.
Una advertencia: el comparador de condiciones es deliberadamente básico. Pruébelo bajo estrés con el conjunto real de reglas antes de que se interponga entre un agente y cualquier acción regulada. Un motor de reglas de demostración no equivale a un control de cumplimiento, y descubrir las deficiencias durante una auditoría es una forma costosa de aprender de ellas.
Los estándares simples sobreviven a los marcos
PROV-O maneja la procedencia, la representación en RDF, las consultas SPARQL, las restricciones SHACL y las ontologías OWL. Nada de esto es emocionante, y ese es precisamente el objetivo.
Los marcos de agentes tienen un tiempo de vida de aproximadamente dieciocho meses. Los requisitos de auditoría, en cambio, no. Un revisor en 2030 no se preocupará por qué biblioteca de orquestación estaba de moda cuando se tomó una decisión, y nadie quiere un registro permanente atrapado en el formato de exportación propietario de una startup que desde entonces ha cambiado de dirección.
También existe un servidor MCP, que se inicia con python -m semantica.mcp_server. Sus herramientas abarcan la extracción de datos, el registro de decisiones, la búsqueda de precedentes, las cadenas causales y el razonamiento. Con esto en marcha, el agente registra sus propias decisiones a través de una llamada a herramienta ordinaria, sin necesidad de añadir un recubrimiento de registro al que el agente pudiera eludirlo.
El verdadero precio
Los costos merecen una exposición clara.
El primer costo es un nuevo servicio con estado, que incluye sus copias de seguridad, migraciones, esquema y control de acceso. El segundo es el esfuerzo de modelado, ya que nadie más puede decidir qué se considera una decisión digna de ser registrada. Registrar cada paso genera otro registro, solo que más costoso. Registrar demasiado poco deja lagunas en la cadena justo donde surgirá la pregunta.
También existe un costo cultural, que tiende a ser subestimado. Un grafo de decisiones permite ver con facilidad que un agente ha estado tomando una decisión específica de manera incorrecta durante cuatro meses. Ese es el propósito, pero la reunión seguirá siendo incómoda.
El proyecto también avanza rápidamente. Fije la versión que ya fue validada. Quienes necesiten un comportamiento aún no lanzado deben instalarlo desde una fuente vinculada a un commit específico. Trátelo como infraestructura, nunca como una importación por conveniencia.
Comience con un flujo de trabajo
Gráficar todo es un error. Gráfique solo aquello que necesite ser defendido.
Elija un flujo de trabajo en el que una mala decisión pueda costar dinero real o confianza. Registre una decisión únicamente en los puntos en los que se ejerce la autoridad, como al aprobar, rechazar, gastar, enviar información a producción o comprometerse con un cliente. Junto con cada decisión, almacene la evidencia en la que se basó y el ID de la regla cuando haya sido aplicada una política determinista. Guarde los datos en el gráfico de forma asíncrona para que ninguna escritura quede en un camino que el usuario esté esperando.
Después de treinta días, intente responder a una pregunta genuina del tipo “¿por qué hizo eso?” utilizando únicamente el gráfico. Aparecerán brechas de inmediato, y no serán las que se hayan predicho. Ese ejercicio enseña más que cualquier cantidad de diseño de esquemas realizado de antemano.
Qué recordar
Se pasaron dos años persiguiendo la explicabilidad, lo que en su mayor parte significó intentar mirar dentro del modelo. Ese objetivo es incorrecto y no se está acercando. El modelo sigue siendo probabilístico, y ninguna técnica de estimulación inteligente hace que sus mecanismos internos sean aceptables en ningún ámbito relevante.
La rendición de cuentas es la alternativa viable, y cada uno de sus componentes se encuentra fuera del modelo: la decisión, sus causas, las pruebas, el origen, la política aplicada, los efectos posteriores y las correcciones posteriores. Todo ello son datos estructurados comunes. Se han mantenido registros como estos desde la contabilidad de doble entrada. La costumbre simplemente desapareció cuando quien toma las decisiones pasó a ser un modelo de lenguaje, como si eso cambiara la función de un registro.
Si se elimina el lenguaje legal, la exigencia del Artículo 12 resulta modesta. No solicita más registros; solo pide un registro cuyo significado se mantenga durante tres años, incluso después de que el marco normativo haya sido retirado, el índice reconstruido en dos ocasiones y el autor de la consulta haya pasado a otra cosa.
Una prueba mejor que la regulatoria es revisar el incidente de las 3 de la mañana. Nadie allí tuvo la culpa. Los agentes sacaron conclusiones razonables a partir de la información que tenían a mano y el incidente se resolvió en once minutos; sin embargo, la explicación desapareció en un cuarto de hora. Si una jornada rutinaria de martes puede hacer que se pierda la capacidad de explicar una decisión, un auditor no será el primero en darse cuenta. El equipo, en una reunión meses después, se dará cuenta gradualmente de que nadie presente sabe qué sucedió.
Lo que realmente le costó caro a Air Canada no fue los 812 dólares canadienses. Lo que sucedió fue que aparecieron en una audiencia sin tener nada que decir sobre el comportamiento de su propio sistema y recurrieron a la idea de que el software era responsabilidad de otra persona. La defensa colapsó aunque solo estuvieran involucrados un boleto y un pasajero en duelo, un pasajero que intentó grabar la conversación.
Hoy en día, los agentes aprueban, gastan, despliegan y rechazan con mayor rapidez de lo que alguien puede verificar, y nadie toma capturas de pantalla de eso. Es necesario registrar todo primero, antes de que alguien lo solicite. La pregunta siempre llega en el peor momento posible, y para entonces la respuesta ya está almacenada en una base de datos o se ha perdido permanentemente.
Leer más
- Notas prácticas: Las 10 habilidades más prácticas para agentes en 2026 (y en la próxima generación) — Guía paso a paso de las Notas prácticas: Las 10 habilidades más prácticas para agentes en 2026 (y en la próxima generación: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Agentes que se mejoran a sí mismos mediante habilidades: reutilización, selección, reparación y verificación — Un diseño en cuatro partes para agentes que mejoran sus propias habilidades: guardar código funcional, perfeccionar las descripciones, proponer soluciones revisadas y verificar el resultado antes de la transferencia.