La gobernanza de agentes no es observabilidad

Estás desplegando agentes autónomos de IA en producción. Instalas LangSmith o AgentOps para ver qué están haciendo. Tienes logs. Costes. Latencia. Trazas. Y por un momento sientes que todo está bajo control.

Hasta que el agente toma una decisión cara que nadie autorizó. Ejecuta una acción que querías revisar antes. O se coordina con otro agente de una forma que no esperabas.

Y ahí te das cuenta de algo incómodo: la herramienta de observabilidad solo te mostró el choque después de que ocurrió. No lo evitó.

Bienvenido al vacío entre observabilidad y gobernanza.

El problema de mezclar conceptos

La industria está tratando gobernanza y observabilidad como si fueran sinónimos. No lo son.

Y entender esa diferencia es justamente lo que separa estas dos frases:

• sé lo que hicieron mis agentes
• controlo lo que mis agentes pueden hacer

La observabilidad responde una pregunta:

¿Qué pasó?

• ver logs y trazas
• seguir consumo de tokens y costes
• monitorear latencia y errores
• reconstruir rutas de ejecución

La gobernanza responde otra:

¿Qué puede pasar?

• aprobar acciones antes de ejecutarlas
• aplicar políticas como “no hacer llamadas externas por encima de cierto coste”
• intervenir una ejecución en tiempo real
• auditar quién autorizó qué, cuándo y por qué

La observabilidad es forense. La gobernanza es preventiva.

El punto ciego del mercado

Todas las plataformas de observabilidad para agentes —LangSmith, AgentOps, Vellum— hacen muy bien una cosa: mostrarte datos después de que el agente corre.

Instrumentan sistemas existentes, trazan ejecución, ayudan a depurar y a entender costes. Y eso es útil.

Pero ninguna ha convertido el workflow de aprobación en una capacidad verdaderamente central.

• AgentOps: observabilidad post-hoc + alertas de coste. Útil, pero llega tarde.
• LangSmith: trazas y debugging. Excelente para desarrollo, insuficiente para gobernanza en producción.
• Vellum: constructor visual con observabilidad integrada. Aporta si vives dentro de su stack, pero no resuelve el problema de control como categoría propia.

Todas han construido espejos retrovisores muy buenos. Lo que muchas empresas necesitan es un volante.

Por qué esto importa ahora

Los agentes autónomos son cada vez más caros y más autónomos. Y esas dos curvas juntas cambian completamente el problema.

Coste

Un solo agente haciendo llamadas externas de forma autónoma puede quemar dinero a gran velocidad.

En sistemas multiagente el problema escala peor: un agente dispara a otro, el otro toma decisiones en cadena, y de pronto ya no estás optimizando productividad sino conteniendo gasto.

Por eso muchas empresas ya están presupuestando control de costes de agentes como una categoría separada de infraestructura.

Autonomía

El valor de un agente está en que no espera siempre a un humano. Toma decisiones. Ejecuta. Avanza.

Pero precisamente por eso no puedes permitirle tomar todas las decisiones sin revisión.

Hay acciones que necesitan ojos humanos antes de ejecutarse:

• borrados
• cambios de permisos
• notificaciones externas
• acciones con impacto económico
• coordinación sensible entre agentes

Compliance

Y luego está la realidad institucional.

Los auditores preguntan cosas muy concretas:

• ¿quién aprobó esta acción?
• ¿cuándo se aprobó?
• ¿qué contexto tenía esa decisión?

SOC 2 ya empuja hacia trazabilidad seria. ISO 42001 está entrando en conversaciones reales de procurement enterprise. Y los reguladores no quieren solo visibilidad. Quieren responsabilidad.

La observabilidad no responde bien a esas preguntas. La gobernanza sí.

Cómo se ve la gobernanza en la práctica

La gobernanza real no son dashboards bonitos. Es capacidad de intervención accionable.

1. Aprobación antes de ejecutar

El agente decide borrar 500 registros de usuarios.

El sistema se detiene. La acción se manda a revisión humana. Una persona revisa la consulta y aprueba o rechaza.

Luego queda un log de auditoría con:

• quién aprobó
• cuándo
• cuál era la acción exacta
• qué contexto la justificó

2. Aplicación de políticas

El agente intenta ejecutar una acción externa que viola una política.

Por ejemplo:

• supera presupuesto
• intenta usar una integración no permitida
• llama a un canal restringido

El sistema bloquea la ejecución y la escala. No porque “algo salió mal”, sino porque el sistema ya sabía que esa acción no debía pasar sin revisión.

3. Intervención en tiempo real

El agente está corriendo. Un operador detecta que va en la dirección equivocada. Pulsa stop.

Eso también es gobernanza. No análisis posterior. No postmortem. Control vivo.

Nada de esto requiere observabilidad como idea principal. Requiere puntos de control.

Observabilidad sola no basta

Si estás usando LangSmith o AgentOps y sientes que ya estás cubierto, no lo estás. Estás instrumentado. No gobernado.

Y no es lo mismo.

El flujo de solo observabilidad se ve así:

• el agente corre
• el agente se equivoca
• tú lo ves en el dashboard unos segundos después
• el daño ya ocurrió
• tienes una traza preciosa explicando por qué pasó

Eso sirve para depurar. No sirve para prevenir.

Y los compradores enterprise ya lo entendieron. Por eso una de las preguntas más repetidas hoy es:

“¿Dónde está el workflow de aprobación?”

El enfoque governance-first

La gobernanza real empieza en un concepto muy simple:

el punto de pausa

Antes de ejecutar una acción de alto impacto, el sistema:

• pausa
• presenta la acción a un humano o a un policy engine
• espera aprobación
• continúa o termina según la decisión
• registra todo

Ese punto de pausa cambia la arquitectura completa del producto.

Cómo esto cambia el diseño del producto

Observability-first

La lógica dominante del mercado hoy es:

• entender qué ocurrió
• instrumentar trazas, logs y dashboards
• analizar después de la ejecución

Eso está bien para desarrollo. Y es razonable para debugging.

Governance-first

Pero en producción, especialmente en contextos sensibles, lo que importa es otra cosa:

• controlar qué puede ocurrir
• introducir aprobación antes de ejecutar
• permitir intervención en tiempo real
• mantener audit trails útiles para compliance

Ese diseño no es una capa encima de observabilidad. Es otra arquitectura.

No puedes “añadirle un poco de gobernanza” a un sistema pensado solo para mirar después.

La realidad práctica

Hoy veo dos tipos de equipos desplegando agentes.

Startups

Dicen: “La gobernanza la resolvemos después.”

Y a veces ese “después” llega en forma de factura absurda, ejecución no autorizada o incidente operativo.

Enterprises

Dicen: “Sin approval workflows no podemos desplegar esto.”

Y cuando salen a buscar herramientas, descubren que la mayoría del mercado les ofrece visibilidad, no control.

Ese segundo grupo está creciendo rápido. Porque la pregunta ya no es solo si los agentes funcionan. La pregunta es si pueden operar dentro de límites aceptables.

Lo que sí hace bien la observabilidad

La observabilidad sigue siendo valiosa. Mucho.

Sirve para:

• depurar errores
• entender patrones de comportamiento
• optimizar costes
• monitorear rendimiento

Pero no sirve, por sí sola, para:

• frenar una mala decisión antes de que ocurra
• aplicar políticas en tiempo de ejecución
• enrutar acciones a aprobación humana
• sostener gobernanza en tiempo real para compliance serio

Desplegar agentes en producción requiere ambas cosas:

ver qué está pasando y controlar qué puede pasar.

El vacío de mercado

Cada vez es más evidente que “gobernanza de agentes” se está separando como categoría propia.

Porque las empresas que de verdad están intentando operar agentes en producción no solo quieren métricas. Quieren límites. Quieren aprobación. Quieren responsabilidad.

Si estás construyendo para enterprise, la gobernanza no es opcional. Es parte del mínimo producto aceptable.

Qué haría yo ahora

Si hoy usas LangSmith o AgentOps:

• trátalo como observabilidad, no como gobernanza
• construye workflows de aprobación por encima
• asume que depuración y control son problemas distintos

Si estás evaluando productos, haz preguntas directas:

• ¿tienen approval workflows?
• ¿puedo pausar la ejecución antes de una acción?
• ¿puedo definir políticas que autoaprueben unas acciones y escalen otras?
• ¿queda registro claro de quién aprobó qué?

Y si ya estás desplegando agentes en producción:

• asume que la gobernanza es innegociable en acciones de alto impacto
• diseña alrededor de puntos de pausa
• habilita intervención en tiempo real
• construye audit trails antes de que te los exijan

La idea final

La observabilidad te dice qué pasó. La gobernanza hace más probable que pase lo correcto desde el principio.

Las dos importan. Pero no son intercambiables.

Y a medida que los agentes entran de verdad en entornos enterprise, los equipos que entiendan esa diferencia van a desplegar más rápido, con menos riesgo y con mucha más credibilidad.