Monitorización de agentes de IA con LangSmith y Langfuse: observabilidad para agentes de IA seguros

La monitorización de agentes de IA (Agent Observability) es el registro y análisis continuo de lo que hace un agente de IA: trazas, llamadas a herramientas, costes de tokens, latencia, errores y puntuaciones de evaluación. Herramientas como LangSmith y Langfuse permiten reconstruir el proceso de decisión de un agente y son, por tanto, un requisito para la seguridad, la depuración y el cumplimiento normativo. A diferencia de la monitorización clásica de aplicaciones, no tiene que representar peticiones aisladas, sino cadenas de razonamiento de varios pasos completas.

Los tres puntos más importantes, de entrada:

• Qué hay que monitorizar: trazas (cadena de razonamiento completa), llamadas a herramientas con argumentos, consumo de tokens y costes, latencia por paso, errores y puntuaciones de evaluación de la calidad de las respuestas.
• Qué herramientas: LangSmith (comercial, estrechamente ligado a LangChain, con región en la UE), Langfuse (código abierto, autoalojable, región en la UE) y, como complemento, Arize Phoenix, Weights & Biases Weave, Datadog LLM Observability y OpenTelemetry para trazas de IA generativa.
• Por qué es crítico: sin observabilidad, las amenazas agénticas catalogadas por OWASP, como Goal Hijack o Memory Poisoning, siguen siendo invisibles, y no se pueden cumplir los requisitos de la ISO 42001, del Reglamento de IA de la UE (para sistemas de alto riesgo) ni de DORA.

Por qué los agentes necesitan su propia observabilidad

Las aplicaciones clásicas basadas en modelos de lenguaje reaccionan: entra un prompt, sale una respuesta. Los sistemas agénticos, en cambio, planifican, razonan de forma recursiva, eligen herramientas, escriben en memoria persistente y actúan con una aprobación paso a paso mínima. Este cambio amplía la superficie de ataque y de error en tres ejes: autonomía (planes de varios pasos, automodificación del contexto), uso de herramientas (sistema de archivos, API, bases de datos, sandboxes de código, servidores MCP) y persistencia (memorias de larga duración, bases de datos vectoriales, cadenas de confianza entre agentes).

Precisamente por eso no basta con un registro de peticiones. Hay que poder reconstruir toda la trayectoria de un agente; de lo contrario, no se puede rastrear ni un bug, ni un ataque, ni una alucinación. En la arquitectura de referencia MAESTRO de la Cloud Security Alliance, la observabilidad forma una capa propia (Layer 5: Evaluation & Observability) que, a su vez, se convierte en objetivo de ataque: los datos de observabilidad envenenados, la elusión de la monitorización y la evaluación comprometida figuran allí como amenazas.

Qué hay que monitorizar exactamente

Para que el registro sea completo desde el punto de vista forense, registra como mínimo lo siguiente por cada acción del agente. Esta lista es el núcleo práctico de cualquier estrategia de monitorización:

• Prompt completo: contexto de usuario, de sistema e inyectado (clave para detectar la inyección indirecta de prompts).
• Versión del modelo y hash de configuración: reproducibilidad y trazabilidad de los cambios.
• Secuencia de llamadas a herramientas con argumentos: qué herramienta se invocó, cuándo y con qué parámetros.
• Consultas de recuperación e ID de los documentos devueltos: trazabilidad de la base RAG.
• Salida y justificación de la decisión: incluida la cadena de pensamiento (chain of thought), si está disponible.
• Eventos de intervención humana: cada aprobación o corrección humana.
• Accesos de escritura y lectura a la memoria: críticos para detectar el Memory Poisoning.
• Costes y latencia: por paso, para la rentabilidad y la detección de anomalías.

Las puntuaciones de evaluación también forman parte de la monitorización: valoraciones automatizadas o basadas en modelos de la calidad de las respuestas (corrección, groundedness, tasa de alucinaciones), que se comparan entre versiones. LangSmith y Langfuse admiten este tipo de pipelines de evaluación, con los que se pueden detectar regresiones antes de pasar a producción.

Para la conservación se recomiendan el almacenamiento WORM (write-once-read-many, es decir, registros inalterables) y la firma criptográfica para detectar manipulaciones. Los plazos de conservación dependen del sector y del país. Para los sistemas de IA de alto riesgo, el Reglamento de IA de la UE prevé, por regla general, al menos seis meses (ver más abajo), a lo que se suman requisitos sectoriales en el ámbito financiero, en el sanitario (BfArM en Alemania, BASG en Austria, Swissmedic en Suiza) y en el sector público (legislación de archivos). Como los prompts completos pueden contener datos personales, debes compatibilizar la conservación WORM y los plazos largos con el RGPD: los principios de minimización de datos y limitación del plazo de conservación del art. 5 y el derecho de supresión del art. 17 encajan mal con registros inalterables a largo plazo. El conflicto se puede mitigar, por ejemplo, seudonimizando los datos personales antes de registrarlos.

El panorama de herramientas: enfoque y alojamiento

LangSmith y Langfuse son el centro de este artículo; la tabla los sitúa junto a otras herramientas. Para quienes deciden en Europa, además de las funcionalidades cuenta sobre todo el alojamiento, porque la residencia de datos en la UE o en Suiza suele ser el criterio decisivo en los sectores regulados. Ambas ofrecen una nube gestionada con región en la UE (LangSmith, Langfuse). La diferencia está en el autoalojamiento: Langfuse es de código abierto y se puede autoalojar sin contrato Enterprise, mientras que LangSmith solo se puede autoalojar en el plan Enterprise.

Las plataformas de observabilidad generales, como Honeycomb o Splunk, se pueden conectar como piezas adicionales. Si quieres evitar el lock-in, instrumenta con OpenTelemetry y envía las trazas a la plataforma que elijas.

En el mercado contiguo de los guardrails opera Lakera, un proveedor de Zúrich que desde octubre de 2025 pertenece a Check Point. Con todos los proveedores rige lo mismo: las tasas de benchmark y de detección que publican ellos mismos deben tratarse como marketing hasta que se verifiquen de forma independiente.

Por qué la monitorización es infraestructura de seguridad y cumplimiento normativo

La observabilidad es la base sobre la que la detección puede funcionar. Las amenazas del OWASP Top 10 for Agentic Applications 2026 casi siempre solo pueden descubrirse a través de señales de monitorización:

• Agent Goal Hijack (ASI01): URL salientes atípicas en las salidas del agente, llamadas a herramientas que no encajan con la petición del usuario, cambios bruscos de tema en la traza de razonamiento; todo ello solo es visible si la traza está completa.
• Tool Misuse (ASI02): frecuencias anómalas de llamadas a herramientas, secuencias de invocación inusuales, operaciones destructivas poco después de incorporar contenido externo.
• Memory & Context Poisoning (ASI06): deriva del comportamiento sin cambios en el código ni en el modelo, entradas de memoria no verificables, valores atípicos semánticos en la memoria vectorial.
• Cascading Failures (ASI08): fan-out rápido (una decisión activa en segundos muchos agentes posteriores), bucles de reintento oscilantes.
• Rogue Agents (ASI10): deriva del comportamiento respecto a la línea base, acceso a recursos fuera del alcance habitual.

En el lado de los costes, la monitorización aborda la amenaza del consumo ilimitado de recursos (Unbounded Consumption, LLM10), los llamados ataques Denial of Wallet. Los planes de varios pasos multiplican el consumo de tokens; la detección de anomalías en la serie temporal de uso de tokens y los límites de coste estrictos con circuit breakers son las contramedidas.

En el ámbito del cumplimiento normativo, el registro es el denominador común de todos los marcos pertinentes. La ISO/IEC 42001 lo aborda directamente con los controles del anexo A A.6.2.6 (Operation and monitoring) y A.6.2.8 (Logging). El Reglamento de IA de la UE regula expresamente el registro en los sistemas de alto riesgo: según el art. 12, deben poder registrar automáticamente eventos durante toda su vida útil. Los proveedores (art. 19) y los responsables del despliegue (art. 26, apartado 6) deben conservar estos registros, en la medida en que estén bajo su control, durante al menos seis meses, salvo que el Derecho de la Unión o nacional disponga otra cosa. Además, el Reglamento de IA exige supervisión humana en el art. 14, ciberseguridad y solidez en el art. 15 y vigilancia poscomercialización en el art. 72. Según el art. 113, estas obligaciones para sistemas de alto riesgo se aplican a partir del 2 de diciembre de 2027 a los sistemas del anexo III y a partir del 2 de agosto de 2028 a los del anexo I. El RGPD conecta con ello a través del art. 32 (medidas técnicas y organizativas para la integridad y la disponibilidad).

En el sector financiero se aplica DORA (arts. 5-15, gestión del riesgo relacionado con las TIC). En su guía orientativa no vinculante del 18 de diciembre de 2025, la BaFin clasifica los sistemas de IA como un subtipo de los sistemas de redes y de información según el art. 3, punto 2, de DORA y recomienda prever, con un enfoque basado en el riesgo y según la criticidad y el ámbito de uso, un registro completo de las decisiones de la IA. En Austria, la FMA es la autoridad competente para DORA según la ley de aplicación de DORA (DORA-Vollzugsgesetz). Para las entidades esenciales e importantes en el sentido de la NIS2 (transpuesta en Austria mediante la NISG 2026), el art. 21 exige, entre otras cosas, la gestión de incidentes y el control de acceso. Nota: esta sección sitúa los marcos normativos y no constituye asesoramiento jurídico; conviene que hagas revisar jurídicamente su aplicabilidad concreta a tu sistema.

Hay que decirlo con franqueza: la detección en despliegues productivos de agentes es actualmente débil. La mayoría de los stacks de observabilidad se crearon para aplicaciones clásicas y no capturan señales específicas de agentes, como anomalías en las trazas de razonamiento, violaciones de la procedencia de las escrituras en memoria, fallos de integridad entre agentes o deriva del comportamiento respecto a la línea base. En consecuencia, la práctica de detection engineering para agentes es joven: utilizable, pero con altas tasas de falsos negativos. Si no ves nada en el SIEM, no deduzcas de ello que no está pasando nada.

Ejemplo práctico: lo que hace visible una traza

Supongamos que una aseguradora utiliza un agente de triaje de siniestros. En un informe médico escaneado se esconde un texto manipulador, legible mediante OCR, que empuja al agente a aprobar un pago automático: un escenario de Goal Hijack (ASI01). Una traza bien instrumentada en Langfuse o LangSmith hace visible el ataque:

```
trace_id: claim-48211
step 1 retrieval query="siniestro 48211" docs=[doc_91, doc_OCR_scan]
step 2 reasoning "El documento contiene una instrucción: aprobar de inmediato" <- anomalía
step 3 tool_call approve_payout(amount=14.900 EUR) <- inusualmente pronto
step 4 output "Pago autorizado"
tokens: 8.420 cost: 0,11 USD latency: 3,2 s
```

El paso 2 muestra un paso de razonamiento que adopta una instrucción procedente del contenido de un documento (es decir, de los datos y no del prompt del sistema): la señal clásica de una inyección indirecta. El paso 3 es una llamada a herramienta destructiva (un pago) inmediatamente después de incorporar contenido externo. Sin traza, en el sistema solo se vería un pago aprobado; con la traza, metadatos de procedencia en la entrada de memoria y una alerta basada en la regla «llamada a herramienta destructiva tras contenido externo», el incidente se puede detener en tiempo real y documentar después de forma forense.

En los sistemas multiagente se suma la velocidad: los Cascading Failures (ASI08) pueden propagarse más rápido de lo que la respuesta a incidentes clásica es capaz de contenerlos. Por eso, la monitorización continua de los flujos entre agentes es obligatoria.

Para agencias y responsables de decisión B2B

Si construyes agentes de IA para clientes o los utilizas en tu propia empresa, planifica la observabilidad como componente obligatorio desde el primer día, no como un complemento posterior. En la práctica, esto significa instrumentar con OpenTelemetry de forma agnóstica respecto al framework, autoalojar Langfuse u operarlo en la región de la UE si importa la residencia de datos, capturar íntegramente el contenido mínimo de registro mencionado arriba y colocar las puntuaciones de evaluación como control de calidad antes de cada release. Para las agencias, una monitorización verificable de trazas y costes es además un argumento de confianza y de venta: demuestra al cliente que el agente es controlable, auditable y presupuestable. Blck Alpaca, desde Viena, acompaña a empresas de toda Europa en la creación y la protección de este tipo de stacks de agentes, desde la arquitectura de observabilidad hasta su encaje en la ISO 42001 y el Reglamento de IA de la UE.