DEV Community: Ayoub Laroussi

Observabilidad en agentes de IA: Las 4 métricas clave que debes trazar en producción

Ayoub Laroussi — Sat, 22 Aug 2026 13:00:00 +0000

published: true

devto-post5-observabilidad

Cuando un servicio web falla, tienes logs, métricas y trazas que te dicen exactamente qué petición falló y por qué. Cuando un agente de IA falla, el problema suele ser más difícil de diagnosticar: no fue un error de código, fue una decisión — y las decisiones no siempre dejan rastro si no lo has diseñado explícitamente.

Esta es la razón por la que la observabilidad de agentes necesita pensarse distinto a la observabilidad de software tradicional.

Las 4 preguntas que tu sistema debería poder responder

Si algo sale mal con un agente en producción, alguien va a preguntar:

¿Qué acción propuso o ejecutó el agente, exactamente, con qué parámetros?
¿Cuánto costó esa acción (en tokens, en llamadas a APIs de terceros, en dinero real si movió fondos)?
¿Requería aprobación humana, y si es así, quién la dio (o por qué no se pidió)?
¿Cuándo pasó, con qué exactitud, y se puede confiar en que ese registro no se alteró después?

Si tu sistema no puede responder estas 4 preguntas para cualquier acción de cualquier agente en los últimos meses, no tienes observabilidad real — tienes logs sueltos que alguien tendría que reconstruir a mano.

Qué trazar, en concreto

No hace falta registrar absolutamente todo — eso genera ruido y coste innecesario. Lo que sí merece la pena trazar de forma sistemática:

Cada acción con efecto externo: enviar un email, escribir en una base de datos, llamar a una API de pago, modificar un registro de cliente.
El coste asociado a cada acción — para detectar agentes que se disparan en bucle o gastan más de lo esperado antes de que sea un problema real.
Las propuestas que requieren aprobación, junto con la decisión humana final — este es el dato que conecta observabilidad con cumplimiento normativo.
Los fallos y reintentos, no solo los éxitos — un agente que reintenta silenciosamente 40 veces antes de tener éxito es una señal de que algo no está bien, aunque el resultado final parezca correcto.

No hace falta rediseñar tu agente para tener esto. Basta con que, en el punto donde tu código decide ejecutar una acción, haga una llamada HTTP registrando qué está a punto de pasar — una línea de código, no una reescritura.

Alertas de coste: la señal más subestimada

De las 4 preguntas anteriores, la del coste es la que menos equipos monitorizan activamente — y suele ser la primera señal de que algo va mal. Un agente que empieza a costar 5 veces más de lo normal en un día concreto casi siempre indica un bug (un bucle, una llamada mal configurada), no una casualidad. Sin una alerta automática, ese tipo de fallo se descubre al recibir la factura del proveedor de IA a fin de mes — no cuando pasó.

Checklist abierto

Si quieres una lista completa que cubre también seguridad del código, supervisión humana y cumplimiento AI Act, tengo un checklist de uso libre en GitHub:

👉 github.com/tradeayoub98-ops/checklist-auditoria-agentes-ia

Automatizándolo

En DatotecAudit registramos cada acción, su coste y su estado de aprobación automáticamente — sin cambiar tu arquitectura.

Sobre DatotecAudit

DatotecAudit es una plataforma de observabilidad, auditoría y gobernanza de agentes de inteligencia artificial. Analizamos arquitectura RAG, seguridad LLM, trazabilidad de agentes, gobernanza de datos (AI Act) y control de costes de tokens para empresas y startups que operan agentes en producción.

¿Vuestro sistema podría responder hoy mismo a esas 4 preguntas para cualquier acción del último mes?

Supervisión humana en la AI Act: Cómo diseñar el bucle "Human-in-the-Loop" para agentes autónomos

Ayoub Laroussi — Sat, 15 Aug 2026 13:00:00 +0000

published: true

devto-post4-supervision-humana

Si tu empresa usa o construye agentes de inteligencia artificial que toman decisiones con impacto real — enviar comunicaciones, mover dinero, aprobar o rechazar solicitudes — el Reglamento (UE) 2024/1689, conocido como AI Act, probablemente ya te afecta. Y el requisito que más confusión genera, con diferencia, es el de supervisión humana.

No es un checkbox legal abstracto. Es un requisito técnico con consecuencias muy concretas si no puedes demostrarlo cuando toque.

¿Qué dice exactamente el Reglamento?

El AI Act exige que los sistemas de IA de alto riesgo estén diseñados para que una persona pueda supervisar su funcionamiento, entender sus resultados, y — esto es lo importante — intervenir o detener el sistema cuando sea necesario. No basta con que un humano "pueda en teoría" revisar lo que hace el sistema; tiene que haber un mecanismo real, documentado y auditable.

En la práctica, esto se traduce en tres capacidades que el regulador espera poder verificar:

Visibilidad: qué decisiones tomó el sistema, cuándo, y con qué datos.
Capacidad de veto: un humano puede aprobar o rechazar una acción antes de que se ejecute, cuando el riesgo lo justifique.
Trazabilidad histórica: un registro que no se pueda alterar a posteriori, que sirva como evidencia real ante una auditoría.

El error más común

Muchos equipos interpretan "supervisión humana" como "un ingeniero revisa los logs de vez en cuando". Eso no es supervisión humana en el sentido del Reglamento — es observabilidad pasiva. La diferencia está en si existe un punto de control activo donde una persona aprueba o bloquea la acción antes de que ocurra, no después.

¿Qué pasa si no puedes demostrarlo?

Las sanciones del AI Act para sistemas de alto riesgo pueden llegar hasta 15 millones de euros o el 3% de la facturación global de la empresa, lo que sea mayor. Pero en la práctica, el problema suele llegar antes de eso: un cliente enterprise, un inversor, o un auditor de cumplimiento pide ver la evidencia de supervisión humana, y la empresa se da cuenta de que no la tiene — solo tiene buenas intenciones y algún log disperso.

Cómo se ve esto en un sistema real

Un flujo de supervisión humana que de verdad cumple tiene esta forma:

El agente de IA propone una acción con impacto (enviar un email a un cliente, ejecutar un pago, modificar un registro).
Esa propuesta queda registrada con timestamp y contexto, antes de ejecutarse.
Un humano la aprueba o la rechaza desde un panel — no desde un canal de Slack que nadie audita después.
La decisión (y quién la tomó) queda en un registro con hash de integridad, que no se puede editar ni borrar retroactivamente.

Esto es exactamente el flujo Human-in-the-Loop — no como una feature añadida, sino como el núcleo del producto, porque es literalmente lo que el Reglamento pide poder demostrar.

Checklist abierto

Si quieres una lista completa que cubre también seguridad del código, trazabilidad y control de costes, tengo un checklist de uso libre en GitHub:

👉 github.com/tradeayoub98-ops/checklist-auditoria-agentes-ia

Automatizándolo

En DatotecAudit registramos cada aprobación, cada rechazo y cada traza con hash de integridad — listo para enseñárselo a un auditor sin montar nada a mano.

Sobre DatotecAudit

¿Tenéis ya un punto de control real donde un humano apruebe acciones antes de que se ejecuten, o todavía es revisión posterior?

AI Act para ingenieros: Qué exige el Reglamento Europeo a tus agentes de IA (y cómo cumplirlo)

Ayoub Laroussi — Sat, 08 Aug 2026 13:00:00 +0000

published: true

devto-post3-ai-act.md

Si tu empresa opera en la Unión Europea y usa agentes de IA que toman decisiones o ejecutan acciones con impacto real, el Reglamento (UE) 2024/1689 (AI Act) ya te afecta, tengas o no un equipo legal dedicado a vigilarlo. La pregunta que de verdad importa no es "¿nos afecta?" — casi siempre la respuesta es sí — sino "¿podemos demostrarlo si nos lo piden mañana?".

¿A quién afecta realmente el AI Act?

El Reglamento clasifica los sistemas de IA por nivel de riesgo. Los agentes que ejecutan acciones automatizadas con efecto en personas o en la operación del negocio — enviar comunicaciones, mover dinero, aprobar o denegar solicitudes — entran con frecuencia en la categoría de alto riesgo, la que trae obligaciones concretas de supervisión y documentación.

Qué exige exactamente para sistemas de alto riesgo

Supervisión humana real: un punto de control donde una persona pueda aprobar, rechazar o detener una acción antes de que se ejecute.
Trazabilidad documentada: registro verificable de qué hizo el sistema, cuándo, y con qué datos.
Evaluación de riesgo continua: no basta con evaluarlo una vez al lanzar el producto.
Capacidad de auditoría externa: un tercero (cliente, inversor, regulador) debe poder verificar el cumplimiento con evidencia real, no con una declaración de intenciones.

Las sanciones no son la parte que más duele primero

El Reglamento contempla multas de hasta 15 millones de euros o el 3% de la facturación global. Pero en la práctica, el problema suele llegar antes: un cliente enterprise pide ver la evidencia de supervisión humana en la fase de contratación, y la empresa descubre que solo tiene buenas intenciones, sin nada documentado que enseñar.

Cómo prepararte, paso a paso

Identifica qué agentes de tu operación ejecutan acciones con efecto real (no solo los que generan texto o sugerencias).
Define qué acciones de esos agentes requieren aprobación humana antes de ejecutarse.
Conecta un sistema de trazabilidad que registre cada acción, decisión y coste con timestamp e integridad verificable.
Genera periódicamente un informe de cumplimiento consolidado, no solo cuando alguien lo pida con urgencia.
Revisa y actualiza la evaluación de riesgo cuando cambien los agentes o sus permisos, no solo una vez al año.

Checklist abierto

Si quieres una lista más completa que cubre también seguridad del código, trazabilidad y control humano paso a paso, tengo un checklist de uso libre en GitHub:

👉 github.com/tradeayoub98-ops/checklist-auditoria-agentes-ia

Automatizándolo

En DatotecAudit automatizamos los puntos 2 a 4: control Human-in-the-Loop, trazabilidad forense con hash de integridad, e informe de cumplimiento AI Act generado directamente desde tus datos reales de uso.

Sobre DatotecAudit

¿Ya habéis evaluado si vuestros agentes entran en la categoría de alto riesgo del AI Act, o es algo que tenéis pendiente de mirar?

Trazabilidad de agentes de IA en producción: Qué logs registrar y cómo implementar la auditoría

Ayoub Laroussi — Sat, 01 Aug 2026 13:00:00 +0000

published: true

devto-post2-trazabilidad.md

Un agente de IA en producción falla de formas que un backend tradicional no falla: puede alucinar un dato, llamar a la herramienta equivocada, o repetir una acción varias veces sin que nadie se dé cuenta hasta que llega la factura o la queja del cliente. Sin trazabilidad real, reconstruir qué pasó es prácticamente imposible.

El problema no es solo técnico. Cuando un cliente enterprise, un auditor o un regulador te pregunta "¿qué hizo exactamente vuestro agente el día X?", la respuesta tiene que ser un registro verificable — no una reconstrucción a ojo a partir de logs sueltos de distintos servicios.

Trazabilidad real vs logging básico

Un log tradicional te dice que algo pasó. Una traza de verdad te dice qué acción se propuso, con qué datos, quién o qué la aprobó, cuánto costó, y qué resultado tuvo — todo encadenado y con timestamp, de forma que puedas reconstruir la secuencia completa de decisiones del agente, no solo el resultado final.

Qué debe registrar cada traza

La acción propuesta: qué quería hacer el agente (enviar un email, ejecutar un pago, modificar un registro).
El contexto y el payload: con qué datos exactos iba a actuar, no solo un resumen.
El coste asociado: tokens consumidos, llamadas a APIs de terceros, coste económico estimado.
La decisión humana (si la hubo): quién aprobó o rechazó, y cuándo.
El resultado final: si la acción se ejecutó, falló, o quedó pendiente.

El error más común

Muchos equipos solo guardan el resultado final ("email enviado correctamente"), no el camino que llevó hasta ahí. Cuando algo sale mal, no hay forma de saber si el fallo estuvo en el prompt, en una herramienta externa, o en una decisión del propio modelo — porque esa parte nunca quedó registrada.

Cómo generar trazabilidad a prueba de auditoría, paso a paso

Cada acción del agente con efecto real se envía como evento a un sistema de trazas, antes de ejecutarse.
El evento incluye timestamp, payload completo y coste estimado.
Si la acción requiere aprobación humana, la decisión (y quién la tomó) se registra en el mismo hilo de la traza.
Cada traza se sella con un hash de integridad, para que el historial no se pueda alterar retroactivamente — ni por error ni a propósito.
Las trazas quedan disponibles en un panel consultable, no enterradas en logs de distintos servicios sin relación entre sí.

Checklist abierto

Si quieres una lista más completa que cubre también seguridad, control humano y cumplimiento AI Act, tengo un checklist de uso libre en GitHub:

👉 github.com/tradeayoub98-ops/checklist-auditoria-agentes-ia

Automatizándolo

En DatotecAudit automatizamos exactamente esto: cada traza queda encadenada, sellada con hash, y disponible para consulta o exportación cuando alguien la pida.

Sobre DatotecAudit

¿Cómo lleváis vosotros la trazabilidad de vuestros agentes hoy? ¿Logs sueltos o algo más estructurado?

Guía práctica: Cómo auditar agentes de IA y sistemas RAG antes de ir a producción (con ejemplos)

Ayoub Laroussi — Sun, 26 Jul 2026 20:08:53 +0000

articulo-devto-auditoria-agentes

Si tu equipo tiene agentes de IA ejecutando acciones reales — enviando emails, tocando bases de datos, llamando APIs de terceros — en algún momento alguien te va a preguntar: ¿cómo sabes que ese agente hace lo que debería, y solo eso?

La mayoría de equipos confunde "tener logs" con "tener una auditoría". No son lo mismo, y la diferencia importa mucho cuando un cliente enterprise, un inversor o un regulador te pide evidencia real.

Observabilidad no es lo mismo que auditoría

La observabilidad te dice qué está pasando ahora mismo. La auditoría te da evidencia verificable e inalterable de lo que pasó, para poder demostrarlo después ante quien lo pida. Necesitas las dos, pero solo la segunda te protege legalmente.

Qué debe cubrir una auditoría real de agentes LLM / RAG

Seguridad del repositorio: secretos expuestos, dependencias vulnerables, patrones OWASP en el código que orquesta al agente.
Prompts y system messages: qué instrucciones recibe el modelo y si alguien puede alterarlas sin control.
Trazabilidad de acciones: cada llamada a herramientas, cada efecto secundario real (email enviado, pago ejecutado, registro modificado), con timestamp.
Control de costes: qué gasta el agente por acción, y si hay límites que disparen una alerta antes de un sobrecoste.
Puntos de control humano: qué acciones requieren aprobación antes de ejecutarse, y si ese control es real o solo teórico.
Cumplimiento normativo: si operas en la UE, documentación de supervisión humana para el AI Act en sistemas de alto riesgo.

El error más común

Checklist abierto

He publicado un checklist completo y de uso libre en GitHub, cubriendo seguridad, trazabilidad, control humano, costes y cumplimiento AI Act:

👉 github.com/tradeayoub98-ops/checklist-auditoria-agentes-ia

Contribuciones y sugerencias son bienvenidas vía issues o pull requests.

Automatizándolo

Si tu equipo quiere automatizar buena parte de estas comprobaciones en vez de hacerlas a mano, en DatotecAudit construimos exactamente esto: auditoría de seguridad del repo, trazabilidad forense con hash de integridad, control Human-in-the-Loop, e informes de cumplimiento AI Act generados directamente desde tus datos de uso reales.

¿Cómo audita tu equipo sus agentes hoy en día? Curioso por saber qué enfoques usáis.