Los registros de auditoría de agentes de IA necesitan 12 campos: qué registran LangChain, CrewAI y otros cuatro.

Una huella parece evidencia, pero no lo es

Imagínese a un agente utilizando una herramienta: una transferencia de fondos, la eliminación de una fila en una base de datos o el envío de un mensaje. Después, alguien debe responder a una pregunta: ¿se pueden demostrar las acciones del agente? Se examina la huella, y esta muestra un intervalo con un nombre, una hora de inicio, una entrada y una salida. Eso parece evidencia, pero en realidad es una ayuda para la depuración disfrazada de evidencia.

Para medir la brecha, se clonaron seis marcos de trabajo de agentes de código abierto y especificaciones de instrumentación con sus últimos commits del 4 de septiembre de 2026: OpenAI Agents SDK, LangChain, CrewAI, LlamaIndex, smolagents y OpenInference. Se extrajeron los campos de los registros de llamadas a herramientas de cada proyecto y se compararon con los doce campos obligatorios del formato más reciente de registro de auditoría de agentes. El resultado principal es que el marco de trabajo típico captura cinco de los doce campos que necesita un registro de auditoría, y ninguno de los seis cuenta con un campo único de evidencia de manipulación.

Los marcos de trabajo que capturan dichos campos son útiles para la depuración. Los registros de auditoría tienen otro propósito, y se puede medir la distancia entre ambos.

Cinco hallazgos de este análisis

• En los cinco marcos de trabajo, la cobertura media es de 5 de los 12 campos obligatorios: smolagents tiene 1, LlamaIndex 3, OpenAI Agents SDK 5, CrewAI 5 y LangChain 6.
• La cadena trust_level aparece en cero archivos en los seis repositorios de código. Una búsqueda en todos los archivos de Python y TypeScript de cada repositorio no encuentra nada.
• prev_hash, previous_hash y hash_chain también devuelven cero archivos. Ningún framework relaciona un registro con el siguiente, por lo que un almacén de trazas puede ser modificado posteriormente sin dejar rastro.
• OpenInference, la especificación de instrumentación más completa del ecosistema con 119 atributos de ámbito, solo logra registrar 8 de los 12 posibles y no incluye ningún campo de evidencia de manipulación.
• Solo un campo, timestamp, es registrado por los cinco frameworks. agent_id, session_id y record_phase aparecen en uno de cada cinco, mientras que agent_version, outcome y trust_level no se registran en ninguno.

Los frameworks cuentan con una buena instrumentación para la depuración y una instrumentación deficiente para obtener pruebas. Ambas son lo suficientemente similares como para que el reemplazo pase desapercibido hasta que alguien solicita evidencia. Los campos ausentes no son algo excepcional; sirven para determinar quién actuó, bajo qué autoridad y si el registro fue modificado posteriormente, preguntas a las que una traza de depuración nunca tuvo que responder.

Cómo se realizó el conteo

Se corrigieron los commits según cada proyecto: OpenAI Agents SDK (openai-agents-python) en 89c02c8, LangChain en 0d50cbd, CrewAI en 92eb5f9, LlamaIndex en d2ac544, smolagents en 30bb116 y OpenInference en 479d168. La lista de campos de cada uno provino de la clase que registra una sola llamada a la herramienta, es decir, el envoltorio del intervalo junto con su carga útil específica para esa herramienta, y se obtuvo de las definiciones de las clases y no de la documentación. Posteriormente, los campos se compararon con los doce obligatorios del borrador actual del registro de auditoría.

Cuando un campo cumple con un requisito solo parcialmente, se le asignó una calificación de parcial con la razón correspondiente. Por ejemplo, el campo error de LangChain indica que algo falló, pero no distingue entre fallo, tiempo de espera, denegación o escalada.

La captura muestra el proceso en sí: seis repositorios en la parte superior, cada campo de llamada de herramienta extraído y evaluado en relación con los doce campos. trust_level y prev_hash arrojan cero en todas partes.

Los doce campos

La referencia es el documento de auditoría de agentes Internet-Draft, revisión 02, publicado por Raza Sharif de CyberSecAI el 3 de septiembre de 2026. Se trata de una propuesta individual y no de un estándar IETF aprobado, por lo que cuenta como una propuesta cuidadosamente fundamentada y no como una ley establecida. Aun así, es la respuesta más concreta publicada hasta la fecha, y sus doce campos obligatorios son difíciles de cuestionar:

• record_id es un identificador único para el registro.
• timestamp indica la hora del evento en formato RFC 3339.
• agent_id indica la instancia del agente que realizó la acción, y agent_version indica la versión de su software.
• session_id relaciona la acción con una sesión específica.
• action_type utiliza un vocabulario controlado en lugar de texto libre, mientras que action_detail contiene la información específica del tipo de acción.
• outcome puede ser éxito, fallo, tiempo de espera, denegado o escalado.
• trust_level indica el nivel de autoridad bajo el cual operó el agente, desde L0 hasta L4.
• parent_record_id hace referencia al registro anterior en la cadena, y prev_hash almacena su hash SHA-256.
• record_phase indica si el registro fue escrito antes, durante o después de la ejecución.

Coloque esa lista junto a un objeto span y aparecerá el esquema del problema. Los primeros ocho campos son los que un depurador probablemente desearía, mientras que los cuatro últimos solo son importantes para un auditor, y esos cuatro son exactamente los que faltan.

Cuentas por framework

Cuentas de campos en el registro de llamadas a la herramienta, con cobertura respecto a los doce:

• CrewAI (ToolUsageFinishedEvent más BaseEvent): 25 campos, de los cuales 5 están completos, 3 parciales y 4 faltan.
• LangChain y LangSmith (RunTree 0.12.1): 20 campos, de los cuales 6 están completos, 1 parcial y 5 faltan.
• OpenAI Agents SDK 0.22.0 (SpanImpl más FunctionSpanData): 13 campos, de los cuales 5 están completos, 2 parciales y 5 faltan.
• LlamaIndex (SimpleSpan más BaseEvent): 10 campos, de los cuales 3 están completos, 1 parcial y 8 faltan.
• smolagents 1.26.0 (Timing más TokenUsage): 6 campos, de los cuales 1 está completo, ninguno parcial y 11 faltan.
• OpenInference semantic conventions definen 119 atributos de tipo span con espacios de nombres (constantes de nombres de atributos con puntos distintos en el commit 479d168, sin incluir otros 43 que son valores de tipo enum), y clasifican 8 como completos, 1 como parcial y 3 como faltantes.

El conteo bruto de campos no permite predecir la capacidad de auditoría. CrewAI registra la mayor cantidad de campos, pero cubre menos requisitos que LangChain, ya que gran parte de sus veinticinco se refieren al contexto del equipo, como agent_role, from_task, plan_step_number y delegations. Aunque son útiles, no responden a ninguna pregunta de auditoría. La riqueza de la instrumentación y la idoneidad como evidencia apenas se correlacionan.

El gráfico lo muestra claramente: CrewAI tiene más campos que cualquier otro framework, pero satisface menos requisitos que LangChain, porque la mayoría de sus elementos adicionales corresponden al contexto del equipo y no a pruebas.

Algo que distingue a CrewAI es que emite ToolUsageStartedEvent y ToolUsageFinishedEvent como clases separadas, por lo que cuenta con un verdadero record_phase, un registro que existe antes de que se ejecute la herramienta. Esto es más importante de lo que parece, ya que un registro escrito únicamente después de los hechos puede indicar que ocurrió algo, pero no demostrar que fue aprobado previamente.

Lo que no registra ningún framework

Cuatro de los doce campos faltan en los cinco frameworks, y dos de ellos siguen sin estar presentes incluso al considerar la especificación de instrumentación.

• trust_level no aparece en ningún archivo de ninguno de los seis repositorios. Sin él, nada registra la autoridad bajo la cual actuó un agente, por lo que un rastro no puede distinguir entre una acción permitida y una prohibida.
• prev_hash aparece en cero archivos, al igual que previous_hash y hash_chain. Nada conecta los registros, y un almacén de trazas es una base de datos ordinaria cuyas filas pueden modificarse.
• agent_version falta en los cinco frameworks. Solo existe en OpenInference como una copia de gen_ai.agent.version de OpenTelemetry, algo que se puede establecer pero que, según este análisis, los propios frameworks básicamente nunca configuran.
• outcome como categoría de clasificación no obtiene una puntuación completa en ningún framework. Todos cuentan con un campo de error, pero ninguno distingue entre casos denegados y casos fallidos, la distinción que más valoran los auditores.

Las búsquedas de non_repudiation y pre_execution también devuelven cero archivos.

Por qué faltan estos campos

Estas herramientas fueron diseñadas para otra pregunta. Un rastro ayuda a un ingeniero a descubrir por qué algo funcionó lentamente o incorrectamente, y input, output, duration junto con un puntero padre son casi suficientes para ello. La evidencia debe resistir la revisión de un adversario, incluyendo a quien controle el registro, y ninguno de estos sistemas se creó teniendo esa amenaza en mente. Las lagunas no son un descuido. Nadie esperaba que los rastros sirvieran también como evidencia hasta este año.

El argumento en contra más fuerte

¿Podría OpenTelemetry llenar esa laguna? Parcialmente. OpenInference abarca 8 de los 12 casos, el mejor resultado del conjunto, y las convenciones GenAI de OpenTelemetry definen gen_ai.agent.id y gen_ai.agent.version, lo que en teoría soluciona el problema de la identidad. Si se aplica de manera consistente, la adopción por sí sola resolvería cuatro de los doce casos sin necesidad de trabajo adicional.

Pero los dos requisitos más difíciles siguen sin resolverse. La evidencia de manipulación no puede añadirse a un span como atributo, ya que pertenece a la tienda y no al registro. Una cadena de hash solo tiene sentido si se escribe en un lugar del que el autor no pueda reescribirla. Además, record_phase necesita que se emita un registro antes de que se ejecute la acción, lo cual es una decisión arquitectónica relacionada con el momento oportuno y no un campo que se añada posteriormente. Ninguno de estos casos se ajusta a las convenciones semánticas.

Límites de la medición

Un número solo es útil si sus valores son fiables, por lo que las limitaciones son importantes:

• Se trata de un análisis estático y no de una captura en tiempo de ejecución. Se contaron los campos definidos por las clases. Seis agentes no se ejecutaron con sus cargas útiles emitidas para comparación, y un framework podría llenar un campo a través de un mecanismo de extensión que no se rastreó.
• metadata, tags y extra son mecanismos de escape y fueron considerados como ausentes. La mayoría de estos frameworks aceptan claves arbitrarias, por lo que un equipo decidido podría almacenar una cadena de hash en extra. El conteo se refiere a los valores predeterminados y no a límites máximos.
• Lo más cercano a una firma no es realmente una firma. OpenInference define message_content.signature, pero su documentación describe un valor emitido por el proveedor que se almacena tal como se recibe, similar a thoughtSignature de Gemini. Este valor sirve para verificar el contenido del razonamiento del modelo y no la integridad del registro, y solo el proveedor puede comprobarlo. Se decidió considerarlo ausente como evidencia contra manipulaciones de forma intencionada.
• La referencia de doce campos es un borrador de un único autor en la revisión 02, por lo que no está ratificada, y es razonable que haya disputas respecto a trust_level. Si la lista de requisitos cambia, los números de cobertura también lo hacen.
• Seis proyectos no representan todo el ecosistema. No se contaron Pydantic AI, Semantic Kernel, AutoGen ni las plataformas comerciales.
• La mera presencia de algo dice poco sobre su calidad. timestamp se consideró satisfecho en los cinco casos, pero un simple datetime.now() que carezca de zona horaria o no esté anclado a un punto de referencia es mucho menos fiable que un timestamp según RFC 3161.

Lo que esto no puede determinar es si alguno de estos elementos es relevante para un sistema determinado. Un agente que lee documentos y redacta texto se beneficia mucho de un rastro de depuración, mientras que los registros de nivel de auditoría serían excesivos. La brecha solo supone un problema cuando las acciones del agente tienen consecuencias que alguien podría cuestionar posteriormente.

Tres cambios según el orden de beneficio

1. Escriba un registro antes de la ejecución. Es decir, antes de la llamada y no después, anotando el ID del registro, la marca de tiempo, el ID del agente y la versión, la acción que se va a ejecutar y la autoridad que la respalda. La división entre iniciado/terminado de CrewAI sirve como plantilla, mientras que otros sistemas deben crearla manualmente.
2. Conecte los registros en un almacenamiento de solo apilamiento. Hashear el registro anterior con SHA-256 cuesta casi nada. Lo importante es el lugar donde se escribe, no el hash en sí.
3. Proporcione un vocabulario para outcome. Con cinco valores (éxito, fallo, tiempo de espera, denegado, escalado), la diferencia entre un error del herramienta y un rechazo se vuelve consultable y no queda oculta en una cadena de texto.

No se necesita un marco nuevo, solo unas doscientas líneas adicionales al existente. Refleja el patrón de fallos silenciosos de los agentes que pasan desapercibidos para los paneles de control, donde la ausencia de registros se interpreta como estado normal debido a que no se ha registrado nada.

Respuestas rápidas

¿En qué difiere un rastro de un agente de un registro de auditoría? Los rastros se crean para ingenieros que desean explicar el comportamiento posteriormente, y se supone que quien los escribe actúa con honestidad. Los registros de auditoría, en cambio, se elaboran para las partes involucradas en una disputa y deben acreditar la identidad, la autoridad y la integridad, es decir, quién actuó, con qué permisos y si la entrada ha sido modificada desde entonces. En comparación, los marcos contienen entre 6 y 25 campos de rastro cada uno, pero solo satisfacen un promedio de 5 requisitos de auditoría.

¿Se pueden preparar los registros de LangChain para auditorías? Solo en parte, y mediante el desarrollo basado en el framework en lugar de su configuración. RunTree de LangSmith proporciona 6 de los 12 directamente, incluyendo session_id y parent_run_id. Todavía faltan agregar información sobre quién es el agente y qué versión se ejecutó, un conjunto fijo de valores de resultado, un nivel de confianza, un registro escrito antes de la ejecución y una cadena de hash almacenada en un sistema de escritura exclusiva. Los datos personalizados pueden incluirse en el campo extra, aunque nada lo llena automáticamente.

¿Lo resuelve OpenTelemetry? Cubre la parte relacionada con la identidad. La evidencia de manipulaciones y el registro previo a la ejecución siguen sin solución, ya que dependen de cuándo y dónde se escriben los registros y no de qué atributos contiene un span.

¿Qué framework es el más adecuado para auditorías hoy en día? LangChain a través de LangSmith abarca la mayor cantidad de aspectos, con 6 de 12, mientras que CrewAI ofrece de forma única un registro real de pre-ejecución además de un agent_id de primera calidad. Ninguno de los dos está listo para auditorías. Si la capacidad de auditoría es algo indispensable, construya la capa de pruebas por separado y trate el rastro del framework como entrada en bruto.

¿Es excesivo utilizar una cadena de hashes para una herramienta interna? Por lo general, sí. La prueba decisiva es determinar si alguien ajeno al equipo podría llegar a depender de ese registro, como un cliente, una contraparte, una compañía de seguros o en una revisión de incidentes con consecuencias reales. Si no es así, un buen rastro es suficiente. Si es posible que lo sea, añadir la cadena ahora cuesta mucho menos que reconstruirla más tarde.

Los debates sobre la supervisión de los agentes llevan meses sin llegar a una conclusión clara. Contar los elementos resuelve en parte el problema, ya que un nombre de campo está incluido en la clase o no lo está.

Leer más

• Cuando el panel es verde y el agente se equivoca: Rastreo del estado: Cómo los fallos de los agentes se ocultan en el estado transmitido entre pasos válidos, y qué tipo de rastreo, restricciones en tiempo de ejecución, registros de enrutamiento y evaluaciones son necesarios para detectarlos.
• Notas prácticas: Programar un agente: Resolviendo bucles en agentes: Guía paso a paso de las Notas prácticas: Programar un agente: Resolviendo bucles en agentes: contratos, verificaciones y espacios de código listos para usar por los equipos que implementan este patrón.

Una plataforma mínima viable para la experimentación de agentes de IA: pruebas A/B y ejecuciones en sombra: Cómo decidir si la versión B del agente debe reemplazar a la A, utilizando definiciones de pipelines, asignación local, eventos de exposición, trazas, evaluación en entorno aislado, ejecuciones en sombra y medidas de control.

Notas prácticas: El agente nunca utilizó la herramienta de reembolso. Dos de sus tres: Guía paso a paso de las Notas prácticas: El agente nunca utilizó la herramienta de reembolso. Dos de sus tres: contratos, verificaciones y espacios para código adicional para los equipos que implementan este patrón.

Notas prácticas: Formas inteligentes de mejorar las respuestas de los agentes de IA en producción: Guía paso a paso de las Notas prácticas: Formas inteligentes de mejorar las respuestas de los agentes de IA en producción: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.

Cuando falla un agente de IA, ¿a quién culpar? Rastreando la cadena de fallos: Por qué decir ‘el modelo generó fantasías’ no es suficiente: un recorrido por la cadena de fallos del agente, desde la intención y la recuperación de información hasta las herramientas, los intentos de reintentar y el rastreo, y qué observar.