El plano de control: Gobernando la IA Agéntica a Escala

Esta guía comenzó como un informe técnico para líderes de ingeniería en un importante banco canadiense. No partían de cero. Tenían agentes en LangGraph en preproducción: guardando puntos de control en Postgres, subgrafos para roles especializados, interrupt() configurados para revisión humana. Habían leído la documentación y construido cosas reales. Así que cuando entré a hablar sobre orquestación, un ingeniero principal hizo la única pregunta que valía la pena hacer: “Ya tenemos LangGraph. Tiene persistencia, tiene humano en el bucle, tiene estado. ¿Por qué íbamos a poner algo más en medio?”.

Hay una forma incorrecta de responder a esa pregunta, y la mayoría de los proveedores la adoptan. La respuesta incorrecta es tribal: mi tiempo de ejecución contra el tuyo, mi logo en el diagrama de arquitectura. Esa respuesta merece el desdén que recibe. También debo revelar mi posición antes de continuar: trabajo en Camunda, y una de las posibles respuestas en esta guía es la categoría de producto que vende mi empleador. Descuenten mi perspectiva en consecuencia. Intentaré recuperar la confianza siendo específico sobre las compensaciones, nombrando las alternativas con honestidad y diciéndoles cuándo no necesitan nada de esto.

La respuesta correcta es una separación de responsabilidades. Los frameworks de agentes son excelentes en el bucle interno: el ciclo de razonamiento, selección de herramientas y memoria que convierte un objetivo en acciones. Son estructuralmente inadecuados para ser dueños del bucle externo: el conjunto de obligaciones que una institución tiene, independientemente de si interviene un LLM o no. La respuesta que el banco necesitaba no era “arrancar y reemplazar”. Era un plano de control que orquesta agentes construidos sobre cualquier framework, y una línea clara sobre qué bucle es dueño de qué. Esta guía es ese informe técnico, generalizado.

El bucle interno y el bucle externo

El bucle interno es lo que un framework ejecuta entre recibir una tarea y producir un resultado. Ensamblar el prompt, razonar sobre el objetivo, elegir una herramienta, llamarla, leer la salida, actualizar la memoria, decidir si se repite el bucle. LangGraph, CrewAI y el SDK de OpenAI Agents son genuinamente buenos en esto, y están mejorando rápidamente. No tengo interés en reemplazarlos, y ustedes tampoco deberían tenerlo. Si su equipo es productivo en LangGraph, eso es un activo.

El bucle externo es todo lo que la institución está obligada a envolver alrededor de ese ciclo. No es inteligencia. Es rendición de cuentas. Los dos bucles tienen diferentes propietarios, diferentes ciclos de vida y diferentes audiencias.

Bucle interno (propiedad del framework de agentes)	Bucle externo (propiedad del plano de control)
Razonamiento y planificación	Registro de auditoría que existe sin logging personalizado
Selección e invocación de herramientas	Aprobación humana con identidad y autorización
Ensamblaje de prompts y gestión de contexto	SLAs, escalaciones y temporizadores duraderos
Memoria a corto plazo y episódica	Política como datos, propiedad de cumplimiento
Autocorrección y reintento ante una salida incorrecta	Versionado y migración de trabajo de larga duración
Salida estructurada y producción de artefactos	Investigación de incidentes en un solo lugar
Elección del modelo y economía de tokens	Cancelación atómica y compensación

La afirmación importante no es que los frameworks carezcan de estas características hoy en día. Es que son el lugar estructuralmente incorrecto para ellas. Un framework se ejecuta dentro del proceso de su aplicación. Su almacén de estado existe para que el grafo pueda reanudarse, no para que un auditor pueda dar fe. Su contexto de autorización es lo que su aplicación le pasó. Su ciclo de vida es el ciclo de vida de un despliegue. Los requisitos del bucle externo son institucionales: tienen que sobrevivir a procesos, despliegues, reorganizaciones de equipos y, a veces, al propio framework. Un sistema de puntos de control de LangGraph es una buena pieza de ingeniería para la reanudación. Nunca fue diseñado para ser evidencia. Las guardrails en el SDK de OpenAI Agents se ejecutan en el mismo proceso que el agente al que protegen, que es exactamente donde un control no debería residir. Para ser justos, las plataformas alojadas alrededor de estos frameworks (LangSmith, LangGraph Platform y sus equivalentes) añaden una verdadera observabilidad y herramientas de operaciones. Pero lo que añaden está orientado al desarrollador y ligado al framework. La audiencia del bucle externo incluye a personas que nunca abrirán un visor de trazas: oficiales de cumplimiento, auditoría interna, operaciones y, eventualmente, un regulador.

Las cinco obligaciones del bucle externo

Cuando escribí el informe técnico original, seguí recortando la lista hasta que solo quedaron las obligaciones que sobrevivieron al contacto con revisiones reales. Cinco lo hicieron.

1. Un registro de auditoría que existe sin logging personalizado

La prueba es simple: ¿puede reconstruir lo que sucedió sin que ningún desarrollador haya recordado registrarlo? Si la respuesta depende de llamadas logger.info() salpicadas por el código del agente, no tiene un registro de auditoría. Tiene un diario, llevado por voluntarios.

Las preguntas de un auditor son específicas. ¿Quién inició este caso? ¿Qué sabía el sistema en cada paso? ¿Qué versión de qué política se evaluó, con qué entradas? ¿Quién aprobó la acción y bajo qué autoridad? Los logs de la aplicación no responden a ninguna de estas preguntas de forma fiable. Son muestreados, rotados según programas de retención medidos en días, mutados por la configuración del pipeline y moldeados por lo que un desarrollador consideró interesante a las 4 p.m. de un jueves. Reconstruir un caso a partir de ellos es arqueología, y la arqueología es lo que se hace cuando la civilización no logró mantener registros.

Un plano de control invierte esto. Cuando cada paso de un proceso es una transición de estado en un motor, el historial es un subproducto de la ejecución. El rastro no puede desviarse de la realidad porque el rastro es cómo se ejecutó la realidad. Este es el argumento más sólido para el patrón, y no cuesta nada extra en tiempo de desarrollo. Lo obtiene al poner el trabajo dentro de lo que registra, en lugar de pedirle a lo que funciona que también recuerde escribir.

2. Humano en el bucle con identidad y autorización

Cada framework ahora incluye una primitiva de pausa. LangGraph tiene interrupt(). Otros tienen equivalentes. Una pausa no es una aprobación. Una aprobación es una pausa más un modelo de autorización, y el modelo de autorización es la parte difícil.

Una aprobación institucional real significa: un conjunto definido de personas que pueden aprobar esta acción específica, resuelto desde un directorio, no codificado de forma rígida. Cuatro ojos (maker-checker) donde la persona que inició el caso no puede ser la persona que lo aprueba. Enrutamiento basado en el monto, donde una excepción de $2,000 va a un líder de equipo y una excepción de $200,000 va a un oficial designado. Delegación cuando el aprobador está de vacaciones, y escalación cuando nadie actúa. Y un registro inmutable de quién hizo clic exactamente, cuándo y en qué versión de los datos del caso.

Nada de eso es trabajo de un framework, y los frameworks correctamente no lo intentan. Pero tiene que ser el trabajo de alguien. El peligroso estado intermedio es una primitiva de pausa conectada a cualquier canal que fuera conveniente, que es como las aprobaciones terminan siendo mensajes de Slack. Volveré a ese fallo más adelante, porque lo he visto ocurrir.

3. El tiempo como ciudadano de primera clase

Los frameworks de agentes piensan en turnos. Las instituciones piensan en días. Un caso de disputa espera once días por una respuesta del comerciante. Una excepción de préstamo permanece con un suscriptor durante un fin de semana largo. Una actualización de KYC tiene un reloj regulatorio asociado. En la vida de uno de estos casos, la ventana de contexto ya desapareció, el pod se ha reiniciado dos veces, el modelo detrás del agente recibió una actualización de versión y la aplicación se desplegó cuatro veces. El bucle externo tiene que sobrevivir a todo eso sin que nadie se dé cuenta.

Eso significa temporizadores duraderos, no setTimeout() y no un trabajo cron leyendo una tabla que escribiste un viernes. Significa SLAs modelados como datos con cadenas de escalación adjuntas: si la aprobación no se concede en 48 horas, notificar al gerente; a las 72, redirigir. Significa que un caso puede “dormir” durante tres semanas sin costo alguno y despertar exactamente donde estaba. Los motores de ejecución duradera y los motores BPMN hacen esto de forma nativa, porque ambos fueron construidos por personas a las que se les avisaba cuando la versión casera fallaba. Los frameworks están mejorando en persistencia, pero la persistencia para la reanudación es una promesa menor que el tiempo como primitiva de modelado con semántica de escalación.

4. Política como datos, propiedad de cumplimiento

Aquí está la frase que he repetido en más reuniones que ninguna otra: la verificación de presupuesto no reside dentro del modelo.

Si su límite de gasto es una frase en un prompt del sistema (“nunca apruebe reembolsos superiores a $500”), no tiene un control. Tiene una solicitud, hecha cortésmente, a un sistema estocástico, en un canal al que también escribe una entrada adversaria. La inyección de prompt es el fallo dramático, pero el fallo mundano es peor: incluso cuando el modelo cumple cada vez, no puede probarlo. “Le dijimos al modelo” no es una frase que quiera decir a la auditoría interna.

Comentario de revisión: una política que no se puede demostrar que se evalúa es indistinguible de una política que no se tiene. Los auditores descubrieron esto mucho antes de que existieran los LLMs.

El patrón es la política como datos, evaluada fuera del modelo, antes o después de que el agente actúe, pero nunca dentro de él. Tablas de decisión (DMN si está en el mundo BPMN, pero un servicio de reglas o incluso un módulo de políticas bien probado también califica) que cumplimiento puede leer, versionar y cambiar sin un despliegue de código. El agente propone: “reembolsar $650, aquí está mi razonamiento”. La política dispone: monto por encima del umbral, enrutar a aprobación humana. La división del trabajo es limpia. El modelo proporciona juicio. La tabla proporciona límites. Cuando el límite cambia, cumplimiento edita una fila, el cambio se versiona y ningún ingeniero de prompts está involucrado.

5. Operabilidad

La obligación menos glamurosa, y la que decide si el sistema sobrevive al segundo año. Cuatro capacidades, todas aburridas, todas esenciales.

Pausar y reanudar sin perder el contexto: no solo la memoria del agente, sino todo el caso, incluyendo sus temporizadores y aprobaciones pendientes. Migración de instancias en curso: desplegó la versión 3 del proceso, pero 4,000 casos todavía están en curso en la versión 1, y algunos de ellos se ejecutarán durante semanas; necesita herramientas para mapear el estado antiguo a nuevas definiciones o para permitir que las versiones se agoten en paralelo, deliberadamente. Cancelación atómica: cuando un caso debe morir, todo muere con él, las acciones de compensación se disparan para los pasos que ya se comprometieron, y ningún agente huérfano sigue llamando a herramientas al vacío. Y un solo lugar para investigar: cuando operaciones pregunta “¿dónde está el caso 8842 y por qué está atascado?”, la respuesta debería ser una pantalla, no un grep a través de cuatro servicios y un hilo de Slack.

Los frameworks casi no tienen nada que decir sobre nada de esto, y eso está bien. No es su preocupación. Tiene que ser la suya.

El plano de control es un rol, no un producto

Todo lo anterior describe un rol. Al menos tres familias de tecnología pueden desempeñarlo, y he visto funcionar a las tres. La comparación honesta importa más que la categoría en la que se encuentra mi empleador.

Opción A: un motor BPMN

Camunda, Flowable y sus parientes. Las fortalezas se mapean casi uno a uno con las cinco obligaciones, porque los motores de flujo de trabajo fueron construidos exactamente para esta clase de problema dos décadas antes de que existieran los agentes. El historial de ejecución es nativo y completo. Las tareas humanas con identidad, grupos de candidatos y cuatro ojos están incorporadas. Los temporizadores y las escalaciones son elementos del modelo a los que se puede apuntar. La externalización de políticas tiene una respuesta de primera clase en las tablas de decisión. Las herramientas de migración de instancias existen porque los procesos de larga duración lo hicieron necesario. Y el modelo de proceso es legible por no ingenieros, lo que suena blando hasta el día en que cumplimiento aprueba el artefacto ejecutable real en lugar de una página de Confluence que se desvió de él.

Dos propiedades más importan a escala institucional, y son la razón por la que esta categoría sigue ganando las evaluaciones de la industria regulada en las que participo. Primero, la escala aquí está probada en lugar de proyectada: los motores de esta familia ya ejecutan procesos centrales en algunos de los bancos, aseguradoras y minoristas más grandes del mundo, y la generación actual fue rediseñada precisamente para cargas de trabajo de alto rendimiento y escaladas horizontalmente, lo que significa que el tráfico de agentes que está planificando es menor que el tráfico de pagos que estos motores ya manejan. Segundo, la superficie de gobernanza es un producto, no un proyecto: las herramientas de operaciones para investigar una instancia atascada, reproducir un incidente o migrar diez mil casos en curso existen listas para usar, con un proveedor responsable de ello. Cuando un agente se comporta mal a las 2 a.m., la diferencia entre “abrir la consola de operaciones” y “grep el almacén de eventos” es la diferencia entre un incidente y una interrupción.

Los costos son reales. Usted ejecuta un motor, y los motores tienen un peso operativo. BPMN tiene una curva de aprendizaje, y algunos desarrolladores tienen una reacción alérgica a cualquier cosa que parezca diagramas como código. Se requiere disciplina de modelado; un modelo BPMN descuidado se pudre exactamente como un código descuidado, solo que de forma más visible.

Opción B: un tiempo de ejecución duradero

Temporal, Restate y los equivalentes nativos de la nube. Estas son excelentes piezas de ingeniería con la semántica de durabilidad más fuerte de la industria: historiales basados en eventos, reproducción determinista, temporizadores y “reposos” de varias semanas como primitivas de primera clase, y APIs de versionado para la evolución de flujos de trabajo. Si su organización prioriza el código y es alérgica a los modelos visuales, esta es una forma legítima de desempeñar el rol, y equipos que respeto lo han hecho.

Las brechas son institucionales más que técnicas. El historial de eventos existe para hacer que la reproducción sea correcta, no para facilitar la vida de un auditor; está diseñado para desarrolladores, y un oficial de cumplimiento no puede leer un flujo de trabajo en Go. La gestión de tareas humanas con identidad resuelta por directorio, cuatro ojos y delegación es algo que usted debe construir. La externalización de políticas es algo que usted debe construir (la mayoría de los equipos añaden OPA o un servicio de reglas, lo que funciona pero añade una integración que ahora también debe gobernar). Puede construir absolutamente el bucle externo sobre Temporal. Solo presupueste el hecho de que lo está construyendo, no configurándolo.

Opción C: una máquina de estados de desarrollo propio disciplinada

Postgres, una columna state, workers, una tabla de outbox. No deje que nadie le diga que esto siempre está mal. Para un proceso con un volumen modesto y un equipo estable, a menudo es el primer paso correcto, y lo he visto bien hecho. Sin nueva infraestructura, control total, cada línea comprendida.

La compensación es que la disciplina es portante y la disciplina se deteriora. Reimplementará temporizadores duraderos, escalación y versionado, cada uno aproximadamente un 80% correctamente. El registro de auditoría es tan bueno como su revisor de código más débil. Y lo que mata es la migración en curso: el modo de fallo no es el día uno, es el mes dieciocho, cuando la versión 3 del proceso se encuentra con 4,000 instancias que todavía ejecutan la versión 1 y no hay herramientas, solo un canal de incidentes muy largo.

Obligación	Motor BPMN	Ejecución duradera	Desarrollo propio
Registro de auditoría sin logging personalizado	Nativo	Parcial (historial de reproducción, orientado a desarrolladores)	Construirlo
Tareas humanas con identidad, cuatro ojos	Nativo	Construirlo	Construirlo
Temporizadores duraderos, SLAs, escalación	Nativo	Nativo (escalación: construirlo)	Construirlo
Política como datos, editable por no desarrolladores	Nativo (tablas de decisión)	Añadir (OPA, servicio de reglas)	Construirlo
Migración de instancias en curso	Existen herramientas	Existen APIs, se requiere esfuerzo	El incidente del mes 18
Legible por cumplimiento	Sí	No	No
Costo operativo y de aprendizaje	Motor + curva BPMN	Clúster + reglas de determinismo	El más bajo para empezar, se acumula

Elija basándose en quién es su organización, no solo en esta tabla. Pero elija deliberadamente, porque la opción por defecto (el bucle externo en ninguna parte, esparcido por el código de la aplicación) es la única opción que siempre falla.

El patrón de integración: orquestar, no reemplazar

El temor del banco, razonable a primera vista, era que añadir un plano de control significara reescribir sus agentes. No es así, y cualquier arquitectura que lo requiera está equivocada. El patrón que funciona mantiene a cada agente en su framework nativo y coloca el modelo de proceso por encima de ellos.

El proceso es el agente, no una llamada a uno de forma secundaria.

Esa frase es todo el diseño. Desde el punto de vista de la institución, la unidad que importa es el proceso de principio a fin: resolver la disputa, abrir la cuenta, examinar la carta de crédito. Ese proceso es lo que se audita, lo que lleva el SLA, lo que un regulador pregunta. El bucle del LLM es una actividad dentro de él, no el contenedor que lo rodea. Invierta eso (código de aplicación con un agente en el centro, llamando ocasionalmente a un flujo de trabajo) y cada obligación del bucle externo recae de nuevo en el código de la aplicación, que es donde comenzó esta guía.

Concretamente, para un caso de disputa:

1. El plano de control inicia una instancia de caso con una clave de negocio y un ID de correlación. Desde este momento hay un historial.
2. Un paso determinista recopila datos de la cuenta. Sin agente. Es una búsqueda.
3. El plano de control invoca al agente de triaje como una tarea. El agente reside en su propio tiempo de ejecución (LangGraph, CrewAI, lo que el equipo haya elegido) y se accede a él a través de A2A como un agente par, o sus capacidades se exponen como herramientas a través de MCP. El bucle interno se ejecuta completamente dentro del framework: razonamiento, llamadas a herramientas, memoria. El plano de control ve una tarea en progreso, luego un artefacto que regresa.
4. La propuesta del agente aterriza en las variables del proceso. Una tabla de decisión la evalúa: monto, nivel de cliente, puntuación de fraude. Por debajo del umbral, se procede automáticamente. Por encima, se crea una tarea humana para el grupo de aprobadores correcto, con la aplicación de cuatro ojos y un temporizador de escalación de 48 horas activado.
5. Aprobado, el paso de ejecución se ejecuta. Cada transición, incluyendo la tarea del agente y la identidad del aprobador, ya está en el historial. Nadie registró nada.

El límite del protocolo es lo que lo hace agnóstico al framework. A2A le da al plano de control una forma estándar de entregar una tarea a un agente que no aloja y recibir artefactos de vuelta, con el equipo del agente manteniendo la propiedad total de su stack; escribí la mecánica, el descubrimiento de tarjetas y los modos de fallo en la guía de campo de A2A. MCP cubre los casos con forma de herramienta. Los equipos mantienen sus frameworks, sus evaluaciones, sus pipelines de despliegue. La institución obtiene una única columna vertebral.

Este patrón es también donde los agentes se pagan a sí mismos. En una prueba de concepto de financiación comercial, mover el examen de documentos a un paso de agente redujo el examen de cartas de crédito de horas a segundos. El agente produjo ese número. El plano de control es lo que hizo que el número fuera utilizable en producción: cada documento examinado dejó un evento de auditoría, cada excepción se enrutó a una persona con autoridad, y los casos de dos semanas sobrevivieron a cada despliegue intermedio.

Cuándo no necesita un plano de control

Esta sección es la razón por la que debería confiar en el resto. Un plano de control no es gratuito. Está añadiendo un motor para operar, un modelo o artefacto de flujo de trabajo para versionar, latencia en cada límite y un segundo sistema que su equipo de guardia debe entender. No pague eso por un chatbot.

No necesita un plano de control cuando un humano revisa el 100% de la salida antes de que suceda algo (un asistente de redacción no es un sistema autónomo, diga lo que diga la presentación). No necesita uno para herramientas internas de desarrollador, prototipos o cualquier cosa cuyo peor fallo sea un párrafo malo. No necesita uno para la generación de una sola vez sin efectos secundarios. En todos estos casos, el framework solo, o ningún framework en absoluto, es la cantidad correcta de arquitectura.

Un paso antes, pregúntese si necesita un agente en primer lugar. Mi heurística, de un artículo que escribí sobre banca abierta, es contar las herramientas y la desviación en el camino: “cuando tiene ese nivel de desviación en el que puede usar tres herramientas versus 10 herramientas, ahí es donde la IA agéntica encaja mejor”. Tres herramientas y un camino predecible es un programa. Escriba código, o modele un flujo de trabajo determinista, y obtenga determinismo gratis. Diez herramientas, alta varianza en lo que cada caso necesita, juicio sobre cuál usar y en qué orden: ahí es donde el bucle interno gana sus tokens. He visto a equipos desplegar un agente, con toda su carga de evaluación, en un flujo que eran tres sentencias if disfrazadas.

El plano de control se vuelve necesario cuando las obligaciones del bucle externo dejan de ser teóricas. El dinero o los compromisos se mueven sin que un humano toque cada uno. El trabajo sobrevive a una ventana de contexto y a un despliegue. Un regulador, o su propia función de auditoría, puede preguntar “¿por qué hizo esto el sistema?” y esperar una respuesta. Los agentes de más de un equipo tienen que componerse en un solo proceso. Dos o más de esos, y la pregunta ya no es si tiene un bucle externo, sino si es deliberado o accidental.

Qué falla cuando el bucle externo reside dentro del framework

Tres fallos, generalizados a partir de sistemas reales que he revisado. Detalles alterados, estructura intacta.

El registro de auditoría que murió con el pod

Un equipo construyó un pipeline de agentes que ensamblaba su traza de razonamiento completa en memoria y escribía un registro consolidado al final de cada ejecución. Diseño limpio, fácil de leer, hasta que un pod fue eliminado por OOM a mitad de ejecución después de que la acción ya se había tomado. Resultado: una operación ejecutada sin registro de por qué. El almacén de puntos de control tenía el estado del grafo necesario para reanudar, pero el estado de reanudación no es una atestación, y la política de retención de ese almacén había sido establecida por un valor predeterminado de infraestructura que nadie había leído. La solución no fue un mejor logging. Fue mover la finalización de cada paso a un motor donde el registro no es opcional, de modo que un fallo puede perder el futuro pero nunca el pasado.

La aprobación que fue un emoji de Slack

Humano en el bucle, implementado como un mensaje a un canal; un pulgar hacia arriba de cualquiera en el canal reanudaba el grafo. Se demostró maravillosamente. Luego las preguntas: ¿quién aprobó exactamente el caso 4417? ¿Estaba esa persona autorizada para ese monto? ¿Se editó el mensaje después de la reacción? ¿Qué sucede cuando el aprobador se va y su cuenta se desactiva? Y la que puso fin a la revisión de diseño: la política de retención del espacio de trabajo eliminaba los mensajes después de 90 días, lo que significaba que la evidencia de aprobación tenía una vida útil más corta que los préstamos que aprobaba. La aprobación es un evento de autorización con una identidad adjunta. Un emoji de reacción no es ninguna de las dos cosas.

La verificación de presupuesto que residía en el prompt del sistema

Un agente de reembolso con su límite expresado como una instrucción en el prompt del sistema. Un ejercicio de equipo rojo lo superó en un día con una inyección poco notable. Pero el hallazgo que importaba era el contrafactual: incluso si el modelo hubiera mantenido la línea cada vez, la institución no podía demostrar el cumplimiento. No había artefacto que mostrar, ni log de evaluación, ni política versionada. Mover el límite a una tabla de decisión evaluada después de la propuesta del agente convirtió un comportamiento no demostrable en un control con evidencia. El prompt todavía menciona el límite, como cortesía al modelo. La tabla es lo que lo impone.

Comentario de revisión: cada uno de estos sistemas funcionó en la demo. El bucle externo es invisible en las demos, porque las demos no fallan, no se auditan y no se ejecutan durante tres semanas.

Lo que los reguladores realmente están pidiendo

Ninguno de los documentos importantes aquí dice “agente”. No necesitan hacerlo. Léalos como requisitos para el bucle externo y el mapeo es directo. Esta es una lectura mesurada, no un susto; la mayoría de estas expectativas son cosas que un sistema bien gestionado desea de todos modos.

La Guía E-23 actualizada de la OSFI sobre la gestión del riesgo de modelos (final en septiembre de 2025, efectiva el 1 de mayo de 2027, para todas las instituciones financieras reguladas federalmente en Canadá) incluye explícitamente la IA y el aprendizaje automático en su alcance y exige una gobernanza del ciclo de vida: inventario, diseño, revisión, despliegue, monitoreo y una clara rendición de cuentas, proporcional al riesgo. Un sistema agéntico que reside completamente dentro del código de la aplicación convierte casi todas esas expectativas en un proyecto de documentación manual. Un plano de control convierte la mayoría de ellas en un subproducto: el inventario es el conjunto de definiciones de procesos y decisiones desplegadas, el ciclo de vida es el historial de artefactos versionados, el monitoreo son los propios datos operativos del motor.

La Ley de IA de la UE sitúa la evaluación de la solvencia de las personas físicas en el Anexo III, lo que convierte a un agente de decisión de crédito en un sistema de alto riesgo; esas obligaciones serán exigibles a partir del 2 de agosto de 2026. El Artículo 12 exige registros de eventos generados automáticamente, que es la obligación uno de esta guía en lenguaje regulatorio (“automático” es la palabra clave; el logging voluntario no califica). El Artículo 14 exige una supervisión humana efectiva, que es la obligación dos, incluyendo la parte en la que la supervisión significa una persona con autoridad y la capacidad de intervenir, no una persona en copia en un canal.

SR 11-7, la guía de riesgo de modelos de la Reserva Federal, ha sido la base para los bancos de EE. UU. desde 2011, y su definición de modelo (un enfoque cuantitativo que procesa entradas en estimaciones, aplicado a decisiones) cubre cómodamente un agente impulsado por LLM. Su demanda central es el desafío efectivo: validación independiente, documentación e inventarios. No se puede desafiar eficazmente un sistema cuyo camino de decisión existe solo en los logs de la aplicación y los archivos de prompt. Se puede desafiar un modelo de proceso, una tabla de decisión y un historial de ejecución, porque son objetos inspeccionables con versiones.

El patrón en los tres: los reguladores están convergiendo en la gobernanza del ciclo de vida, los registros automáticos y la supervisión humana responsable. Esas son exactamente las cosas que el bucle interno no puede proporcionar y que el bucle externo existe para proporcionar. Las instituciones que separan los bucles encontrarán que el cumplimiento se deriva en gran medida de la arquitectura. Las instituciones que no lo hagan ejecutarán un proceso de papeleo paralelo que describe un sistema que en realidad no pueden ver.

La versión de un párrafo

Los frameworks de agentes (LangGraph, CrewAI, el SDK de OpenAI Agents) son excelentes en el bucle interno: razonamiento, selección de herramientas, ensamblaje de prompts, memoria. Son estructuralmente inadecuados para ser dueños del bucle externo: el registro de auditoría que existe sin logging personalizado, la aprobación humana con identidad y cuatro ojos, el tiempo como ciudadano de primera clase, la política como datos propiedad de cumplimiento y la operabilidad del trabajo de larga duración. La respuesta no es “arrancar y reemplazar”; es un plano de control que orquesta agentes en cualquier framework en el que fueron construidos, accesibles a través de A2A o MCP, con el modelo de proceso como el artefacto gobernado. El proceso es el agente, no una llamada a uno de forma secundaria. Desempeñe el rol con un motor BPMN, un tiempo de ejecución duradero o una máquina de estados de desarrollo propio disciplinada, con los ojos abiertos sobre lo que cada uno hace nativo y lo que cada uno convierte en su problema. Omita todo esto para prototipos y herramientas revisadas por humanos, y omita el agente por completo cuando tres herramientas y un camino predecible signifiquen que solo debe escribir código. Adóptelo antes de la primera vez que un auditor, un regulador o su propia revisión de incidentes haga una pregunta que sus logs no puedan responder.

Referencias

• OSFI, Guideline E-23: Model Risk Management (2027), final en septiembre de 2025, efectiva el 1 de mayo de 2027.
• Ley de IA de la UE, Anexo III: sistemas de IA de alto riesgo y Artículo 12: mantenimiento de registros; las obligaciones del Anexo III son exigibles a partir del 2 de agosto de 2026.
• Reserva Federal, SR 11-7: Guidance on Model Risk Management (2011).
• Blog de Camunda, Agentic AI Puts Open Banking to Work, fuente de la heurística de tres herramientas versus diez citada anteriormente.
• Blog de Camunda, Using A2A to Achieve Your Business Goals, part 1 y part 2, mi artículo coescrito sobre el patrón de integración agente a agente.
• Especificación del protocolo A2A y Model Context Protocol, las dos capas de interoperabilidad referenciadas en el patrón de integración.
• Documentación de LangGraph (persistencia y interrupt()), SDK de OpenAI Agents y documentación de Temporal, para las capacidades de bucle interno y ejecución duradera discutidas.
• Relacionado en este sitio: la guía de campo de A2A.