Gobernanza de agentes de IA: la capa que el mercado no vio venir

Gobernanza de agentes de IA: la regulación llegó a mitad del summit

El 2 de agosto de 2026, segundo día del Agentic AI Summit en UC Berkeley, entraron en vigor dos marcos regulatorios que llevaban meses en discusión: el Artículo 50 de la Ley de IA Europea y la SB 942 de California. (Esta es una descripción general y no asesoría legal; el alcance exacto para su empresa depende de su jurisdicción y debe revisarlo con su equipo de cumplimiento.) No fue una coincidencia de calendario que alguien mencionó de pasada. Fue el telón de fondo literal de más de 25 charlas que WATR documentó de primera mano —de Amazon, OpenAI, Google DeepMind, NVIDIA, Databricks, Microsoft y MIT, ante más de 5,000 asistentes presenciales según la asistencia reportada por la organización— que discutían, en tiempo real, cómo construir sistemas que ya estaban obligados a cumplir con reglas que apenas acababan de nacer.

Esa coincidencia expone algo más interesante que la anécdota: la primera generación de análisis sobre agentes de IA se concentró en capacidades —qué tan bien razonan, qué tan bien usan herramientas, qué tan autónomos pueden ser. Lo que ese análisis no anticipó es que, en paralelo, se estaba formando una capa completamente nueva en la pila: gobernanza y procedencia. No es una característica adicional. Es la condición de entrada para que una empresa delegue trabajo real a un agente.

La tesis: falta gobernanza, y falta comunicación confiable entre agentes

El summit dejó dos conclusiones que, leídas juntas, definen el estado real de la industria. Primera: existe ya tecnología seria para gobernar y auditar lo que hace un agente de IA, y llegó justo cuando la regulación la volvió obligatoria. Segunda: la comunicación entre agentes —el tejido que permite que varios agentes trabajen juntos con supervisión y sin fallar en silencio— sigue siendo la capa menos resuelta de todo el stack. Una empresa puede tener el mejor modelo, el mejor agente individual y el mejor marco de cumplimiento, y aun así no tener manera confiable de coordinar múltiples agentes con trazabilidad de nivel regulatorio.

Evidencia: de la política escrita al control en tiempo de ejecución

Fujitsu presentó PolicyOS con una pregunta que resume el problema de fondo:

"Los agentes de IA ejecutan código. ¿Por qué no ejecutan política?" — Fujitsu, presentación de PolicyOS en el Agentic AI Summit 2026

PolicyOS funciona como un compilador de gobernanza: toma regulación escrita en lenguaje natural y la convierte en cinco controles de tiempo de ejecución por cada cláusula, con rastros de auditoría a nivel de cláusula individual. Es decir, no se trata de un documento de políticas que alguien redacta y espera que se respete; es una traducción mecánica de la norma a comportamiento verificable del agente, con evidencia de que cada cláusula se cumplió o no en cada ejecución.

UC Berkeley presentó un problema complementario con TRACE, orientado a procedencia de decisiones en trabajo colaborativo entre humanos y agentes:

"No existe un 'git blame' para las decisiones. Construimos uno." — UC Berkeley, presentación de TRACE en el Agentic AI Summit 2026

La analogía es exacta y por eso funciona: en ingeniería de software se da por sentado que cualquier línea de código tiene autor, fecha y contexto reconstruibles. En los flujos de trabajo donde humanos y agentes de IA colaboran, esa trazabilidad casi nunca existe. TRACE la construye, y lo hace para el objeto que realmente importa en gobernanza: la decisión, no solo la acción.

El examen de cinco preguntas para preparación empresarial

Otra contribución central del summit fue un criterio de evaluación —presentado como examen de "preparación empresarial"— para decidir si un agente está listo para operar en un entorno de negocio real. Las cinco preguntas son:

• Grounding: ¿las respuestas y acciones del agente están fundamentadas en evidencia verificable, o son plausibles pero no verificadas?
• Cumplimiento de políticas (Policy Compliance): ¿el agente respeta las reglas de negocio y regulatorias de forma comprobable, cláusula por cláusula?
• Calibración y abstención: ¿el agente sabe cuándo no debe actuar, en lugar de forzar una respuesta?
• Seguridad de escritura (Write-Safety): ¿puede modificar sistemas sin romperlos, y esa modificación es reversible?
• Economía de la supervisión (Oversight Economics): ¿cuánto cuesta, en tiempo y dinero, supervisar adecuadamente lo que el agente hace?

Este marco es útil precisamente porque no es aspiracional. No pregunta si el agente es inteligente; pregunta si es gobernable, auditable y económicamente sostenible de supervisar. Es el mismo criterio, en esencia, que exigen el Artículo 50 europeo y la SB 942: no basta con que el sistema funcione, hay que poder demostrar cómo y por qué.

La brecha que ningún protocolo cubre por completo

El punto más incómodo del summit no fue de gobernanza en abstracto, sino de infraestructura concreta: la comunicación entre agentes sigue fragmentada entre protocolos que resuelven partes distintas del problema. MCP cubre el uso de herramientas. A2A cubre comunicación básica entre agentes. NANDA cubre descubrimiento. Temporal cubre durabilidad en tiempo de ejecución. Ninguno de estos protocolos cubre paso de mensajes al estilo actor —con supervisión jerárquica y semántica de fallos definida a nivel de protocolo— que es exactamente lo que se necesita cuando varios agentes colaboran y algo falla a mitad de camino.

Esa brecha no es un detalle técnico menor. Es la razón por la que las conclusiones de gobernanza y las de coordinación multiagente terminan chocando: se puede auditar perfectamente la decisión de un agente individual y, aun así, no tener manera confiable de saber qué pasó cuando ese agente delegó una tarea a otro, ese otro falló, y nadie —ni humano ni sistema— fue notificado con el contexto correcto.

La postura técnica de WATR: AMP como respuesta a esa brecha específica

Frente a ese vacío, WATR ha desarrollado AMP, un protocolo de comunicación entre agentes inspirado directamente en Erlang/OTP —el modelo de actores que sostiene sistemas de telecomunicaciones de alta confiabilidad desde hace décadas—. La premisa de AMP es simple de enunciar y difícil de ejecutar bien: procesos monitoreados, un vocabulario explícito de fallos y buzones auditables (auditable mailboxes) para cada intercambio entre agentes.

La elección de Erlang/OTP como referencia no es casual. Ese modelo fue diseñado para sistemas donde el fallo parcial es la norma, no la excepción, y donde la pregunta relevante no es "¿cómo evitamos que falle?" sino "¿cómo sabemos que falló, quién lo supervisa y qué pasa después?". Esa misma pregunta es, en esencia, lo que exige la regulación de procedencia: no la ausencia de errores, sino la capacidad de reconstruir con evidencia qué ocurrió.

Es importante ser preciso sobre qué es AMP hoy: existe un RFC y un prototipo funcional en Elixir/OTP. No es un producto cerrado ni una solución de mercado lista para venderse. La posición de WATR es presentarlo en foros académicos y en conversaciones de estándares abiertos mientras la capa de protocolo de comunicación entre agentes sigue en disputa activa en la industria. La propiedad central que AMP busca garantizar —auditabilidad de cada mensaje y cada fallo entre agentes— es exactamente la misma que exigen las nuevas regulaciones de procedencia y el cálculo de insight y control que toda empresa debe hacer antes de delegar trabajo real a un sistema autónomo.

Implicaciones para el negocio: la trazabilidad como ventaja, no solo como obligación

Es tentador leer todo esto como un costo de cumplimiento adicional. Es un error de lectura. Una empresa que puede reconstruir, con evidencia verificable, por qué un agente tomó una decisión específica —qué política aplicó, qué evidencia usó, en qué momento se abstuvo de actuar y a quién delegó qué tarea— no solo cumple con el Artículo 50 o la SB 942. Tiene una capacidad operativa que sus competidores sin esa trazabilidad no tienen: puede depurar fallos en horas en lugar de semanas, puede auditar internamente antes de que un regulador lo obligue, y puede escalar la delegación de trabajo a agentes con un nivel de confianza que la organización sin gobernanza simplemente no puede sostener.

Dicho de otro modo: la gobernanza de agentes de IA deja de ser un requisito legal externo y se convierte en infraestructura de control interno. Las organizaciones que la traten como tal antes de que sea obligatoria en su jurisdicción tendrán una ventaja de tiempo que las demás tendrán que recuperar bajo presión regulatoria.

Recomendaciones y próximos pasos

• Auditar el stack actual de agentes contra las cinco preguntas del examen de preparación empresarial —grounding, cumplimiento de políticas, calibración y abstención, seguridad de escritura, y economía de la supervisión— antes de ampliar el alcance de cualquier despliegue.
• Tratar la procedencia de decisiones como requisito de diseño, no como registro posterior. Si un agente no puede explicar, con evidencia, por qué actuó de cierta forma, no está listo para tareas de negocio con consecuencias reales.
• Mapear cada punto de comunicación entre agentes en la arquitectura actual y verificar explícitamente qué protocolo cubre qué: herramientas (MCP), comunicación básica (A2A), descubrimiento (NANDA), durabilidad (Temporal) — y documentar dónde queda la brecha de supervisión y semántica de fallos sin cubrir.
• No esperar a que exista un estándar cerrado para esa brecha. El área sigue en disputa activa en foros académicos y de estándares abiertos; participar en esa conversación ahora —como hace WATR con el RFC de AMP— es más barato que adoptar tarde un estándar diseñado sin considerar los casos de uso propios.
• Presupuestar la supervisión como costo recurrente, no como gasto único de implementación. La economía de la supervisión es, literalmente, una de las cinco preguntas que determina si un agente está listo para producción.