Descubrimiento seguro de herramientas para agentes de IA empresarial: Registro, Pasarela y Políticas.
Un diseño para agentes de servicios financieros: un Registro de Herramientas, descubrimiento filtrado, una Pasarela de Herramientas determinística, autorización a nivel de intención y efectos secundarios duraderos.
Fuentes: From Chatbots to Action-Bots: Designing Safe Tool Discovery and Authorization for Agentic AI
La pregunta detrás de las herramientas para agentes
Si se le proporcionan a un agente algunas APIs y se deja que el modelo elija cuál utilizar, el acceso a las herramientas parece ser un problema resuelto. Pero una empresa cambia completamente la situación: allí el catálogo contiene cientos o miles de herramientas. Algunas son búsquedas de solo lectura inofensivas, otras pueden modificar datos de clientes o información personal sensible, y un grupo más reducido puede iniciar transacciones financieras, reconfigurar cuentas o realizar operaciones administrativas. “¿Cómo encuentra el agente la herramienta adecuada?”, es la pregunta sencilla. La más difícil es cómo garantizar que el agente solo pueda ver y utilizar las herramientas a las que tiene permiso para acceder en relación con esa solicitud específica del usuario.
Esto es lo que se analiza aquí como un estudio de diseño. Se trata de una arquitectura bien fundamentada para entornos de servicios financieros y no debe interpretarse como un informe sobre un sistema de pagos ya implementado.
Mantener al modelo fuera del perímetro de seguridad
La inteligencia artificial de producción enseña una lección importante: el proceso crítico para el negocio no reside dentro del modelo. Un modelo puede predecir, recomendar o clasificar, mientras que la seguridad, la validación, las reglas de negocio, la autorización y el procesamiento de transacciones pertenecen al software determinista que se encuentra fuera de él. Los agentes hacen que esas reglas sean más estrictas, no más flexibles, ya que pueden tomar acciones. Un LLM puede ser un razonador muy capaz y, aun así, ser una mala opción para delimitar la seguridad de un sistema empresarial.
Un escenario financiero sencillo muestra por qué. Un cliente pide al agente que revise una transacción reciente y determine si se ha procesado un reembolso. El agente debe comprender la solicitud y utilizar herramientas de búsqueda de clientes y de transacciones, lo cual es algo habitual.
Ahora modifiquemos la solicitud: si el reembolso aún no se ha procesado, procedan a emitirlo. El agente ya no se limita a obtener información, ya que eso podría tener consecuencias financieras. Ese pequeño cambio motiva el principio en el que se basa todo lo demás:
El agente puede razonar sobre una acción y proponerla. Si dicha acción se lleva a cabo realmente lo decide la plataforma determinista.
La separación entre el razonamiento y la ejecución permite a un sistema aprovechar lo que los LLM hacen bien sin depender de ellos para tareas que no pueden realizar de manera fiable.
Un registro de herramientas en lugar de una lista gigantesca
¿Cómo debería aprender el agente qué herramientas existen? Una opción es proporcionarle al modelo una lista muy larga de definiciones de herramientas y dejar que él determine su relevancia. Eso podría funcionar para un prototipo, pero falla a escala empresarial. Miles de descripciones generan costos de latencia y contexto, y un descubrimiento sin restricciones aumenta la exposición a riesgos sin ningún beneficio.
Una solución más adecuada es un Registro de Herramientas, un catálogo empresarial de capacidades. Contiene algo más que nombres de API y esquemas. Cada entrada incluye metadatos que la plataforma puede utilizar para el descubrimiento, la gobernanza y la toma de decisiones de políticas:
- dominio empresarial, propietario y versión
- si la herramienta es de solo lectura o puede escribir
- clasificación de riesgos y capacidades requeridas
- clasificación de datos
- esquemas de entrada y salida
- características de idempotencia
- requisitos de auditoría
Los metadatos son de suma importancia al diferenciar los tipos de operaciones. Una búsqueda de transacciones es una lectura de bajo riesgo, un reembolso es una escritura financiera de alto impacto, y una operación administrativa puede conllevar aún más riesgo. Esas distinciones no pueden quedar solo en la documentación; deben existir en la plataforma para que la infraestructura determinista pueda actuar en función de ellas.
El descubrimiento no es autorización
Esta podría ser la distinción más útil de todo el diseño: descubrir una herramienta y estar autorizado para usarla son cosas diferentes.
El descubrimiento responde qué herramientas deben ponerse a disposición de este agente para esta tarea. La autorización responde si esta llamada específica está permitida en este momento.
Por lo tanto, los metadatos del registro impulsan un paso de filtrado que tiene lugar antes de que el LLM evalúe sus opciones. Primero, la plataforma determina quién es el usuario, qué agente está actuando, el inquilino, el contexto circundante y qué intenta lograr la solicitud. Luego, elabora una lista corta de herramientas que coinciden con esa intención y, a continuación, reduce esa lista utilizando las capacidades del agente, los permisos del usuario, los límites del inquilino, la región y las políticas de riesgo. El modelo solo ve lo que queda.
Ese filtro aún no puede ser la última línea de defensa. El modelo podría realizar una llamada inesperada, interpretar mal la intención del usuario o ser manipulado mediante inyección de prompts. Por eso, cada llamada pasa por una Tool Gateway controlada en su camino hacia la API empresarial subyacente.
En concepto, la pasarela evalúa conjuntamente un conjunto de datos (quién es el usuario, qué agente realiza la llamada, qué se está solicitando, en qué recurso, con qué parámetros, en qué contexto) y aplica la política de correspondencia.
Autoricar la intención, no solo la herramienta
El ejemplo del reembolso pone de manifiesto otro punto: la autorización no puede depender únicamente de qué herramienta se está utilizando. Debe tener en cuenta la intención y la acción que resulta de ella.
Verificar el estado de un reembolso y iniciar uno no son la misma funcionalidad: una es una operación de lectura y la otra tiene un efecto financiero. La plataforma debe modelarlas de manera explícita. Una solicitud clasificada como consulta sobre el estado de reembolso puede llegar a las herramientas de búsqueda de clientes y transacciones, pero esa clasificación no otorga automáticamente permiso para realizar la operación de reembolso. Incluso si el modelo decide erróneamente que se debe emitir un reembolso, la capa de autorización puede comparar la acción solicitada realmente con la intención permitida y rechazarla.
El enfoque en materia de seguridad cambia aquí de preguntarse si un agente tiene acceso a la API de reembolsos a determinar si este usuario, agente, intención, recurso y acción están permitidos en este contexto.
Cuando falla la mitad de un flujo de trabajo
Una vez que se permite una acción, surge un segundo problema: ¿qué pasa si una parte del flujo de trabajo tiene éxito y otra falla? Supongamos que el reembolso se procesa, pero el correo de confirmación no. Reiniciar todo el flujo de trabajo del agente podría ejecutar el reembolso dos veces.
Un patrón más seguro convierte el efecto secundario en un paso dentro de un flujo de trabajo duradero. La autorización aprueba el reembolso, la API de reembolso se ejecuta y el resultado exitoso se almacena. Ese resultado almacenado emite un evento RefundCompleted, que activa las notificaciones. Si el correo falla, entonces se intenta nuevamente enviar solo la notificación, sin repetir la operación financiera.
Tener un LLM en el sistema no hace obsoleto el conjunto de herramientas empresariales clásico. Las reintentos y la deduplicación, los interruptores de circuito y las acciones compensatorias, las operaciones idempotentes, el estado duradero y el procesamiento basado en eventos siguen siendo relevantes. Los agentes pueden contribuir a decidir qué debe ocurrir, mientras que la infraestructura determinista se encarga de los cambios críticos en el estado.
Las aprobaciones pertenecen a la política
El LLM tampoco debería decidir cuándo un humano debe aprobar algo. Eso es una cuestión de política. Una organización podría permitir que los reembolsos por debajo de un umbral se realicen automáticamente y exigir la aprobación para aquellos por encima de ese umbral, solicitar siempre la aprobación para las operaciones administrativas y añadir controles para transacciones con destinos inusuales o riesgo elevado. El modelo puede indicar que podría ser necesaria alguna acción. El sistema de políticas decide si se requiere aprobación, y la Tool Gateway aplica esa decisión. También se beneficia la gobernanza, ya que las reglas son explícitas, revisables, versionadas y auditables, y no están ocultas dentro de un prompt.
Plano de control y plano de ejecución
Tras analizar estos escenarios, el diseño se parece mucho menos a un simple pipeline de Usuario a LLM a Herramientas y más a una plataforma de gobernanza empresarial. Se divide naturalmente en dos áreas.
El Plano de Control es donde la organización establece sus reglas. Incluye el catálogo de agentes, el Registro de Herramientas, las definiciones de capacidades, las clases de riesgo, las políticas de autorización y aprobación, y los ajustes generales de gobernanza.
El Plano de Ejecución es donde se lleva a cabo la actividad en tiempo real. Contiene las pasarelas para APIs y agentes, los propios agentes, el proceso de detección ya filtrado, la aplicación de políticas, el intercambio de credenciales, las herramientas que se ejecutan, el estado del flujo de trabajo y el flujo de eventos de auditoría. Las reglas pueden gestionarse de forma centralizada, mientras que su aplicación se realiza más cerca del lugar donde se ejecutan las cargas de trabajo.
Esa separación es importante a gran escala. Con cientos o miles de agentes y una enorme cantidad de herramientas, nadie quiere que cada verificación de autorización espere en un único servicio central. Las políticas se gestionan en un solo lugar, mientras que los puntos de aplicación están distribuidos y los datos de las políticas se almacenan en caché o se replican cuando es apropiado.
Evaluación de acciones, no solo respuestas
El diseño se integra perfectamente con el ML empresarial al tiempo que añade una nueva categoría de problemas. El ML tradicional se centra en la precisión, la calidad de los datos, la deriva, la latencia, la seguridad, la supervisión y la fiabilidad operativa. Los agentes mantienen todo eso y añaden la evaluación de las acciones.
Una respuesta final correcta no es suficiente. Los revisores también necesitan saber si el agente eligió la herramienta adecuada y pasó los parámetros correctos, se mantuvo dentro de los límites de autorización, evitó acciones para las que no tenía permiso, siguió el flujo de trabajo previsto, solicitó la aprobación de un humano cuando fue necesario, y generó los efectos secundarios esperados. La evaluación pasa de calificar las respuestas a calificar las acciones.
El principio que rige
Hay una regla que se repite constantemente: tratar al LLM como un componente de toma de decisiones en el que no se puede confiar y nunca como la barrera de seguridad. El agente puede razonar, descubrir capacidades relevantes y proponer acciones. La infraestructura empresarial determinista decide qué puede hacer el agente, qué recursos puede acceder, qué parámetros son aceptables, si se requiere aprobación humana, cómo funcionan de forma segura los efectos secundarios y cómo se audita todo el proceso.
Ese es el verdadero desafío arquitectónico de la IA agente. Hacer que un agente sea lo suficientemente inteligente como para utilizar una herramienta es la parte fácil. Una plataforma en la que miles de agentes actúen para millones de usuarios, manteniendo bajo control la identidad, la autorización, las reglas de negocio y la fiabilidad operativa, es la parte difícil.