Guardrails para agentes de IA

1. Introducción a la IA Agentic

El debate en torno a ChatGPT (en general, IA generativa) ha evolucionado hacia la IA Agentic. Si bien ChatGPT es principalmente un chatbot que puede generar respuestas de texto, los agentes de IA pueden ejecutar tareas complejas de forma autónoma, por ejemplo, realizar una venta, planificar un viaje, reservar un vuelo, contratar a un contratista para que haga un trabajo doméstico o pedir una pizza. La siguiente figura ilustra la evolución de los sistemas de IA Agentic.

Bill Gates imaginó recientemente un futuro en el que tendríamos un agente de IA capaz de procesar y responder al lenguaje natural, y realizar diversas tareas. Gates puso como ejemplo la planificación de un viaje. Normalmente, esto implicaría reservar hotel, vuelos, restaurantes, etc., por cuenta propia. Pero un agente de IA podría usar su conocimiento de sus preferencias para reservar y comprar esas cosas en su nombre.

1.1 Ciclo de vida de la IA con agentes

En esta sección, profundizamos en las etapas típicas de la creación y operación de estos agentes de IA, ilustradas en la Fig. 2.

Primero, necesitamos definir el caso de uso: Esto incluye definir el planteamiento del problema, comprender su contexto empresarial, los requisitos y la disponibilidad de los datos, y establecer objetivos claros para la solución de IA agéntica que cuantifique el retorno de la inversión (ROI).
Segundo, necesitamos un mercado de modelos de razonamiento/modelos de lenguaje extenso (LLM), agentes y herramientas. Definir agentes y crear integraciones de herramientas empresariales sobre la marcha no funciona realmente en la práctica.

Por ejemplo, el protocolo Agente2Agente (A2A) especifica el concepto de una Tarjeta de Agente (un documento JSON) que funciona como una tarjeta de presentación digital para los agentes. Incluye la siguiente información clave:

Identidad: nombre, descripción e información del proveedor.
Punto final del servicio: URL donde se puede acceder al servicio A2A.
Capacidades A2A: Funciones de protocolo compatibles, como streaming o notificaciones push.
Autenticación: Esquemas de autenticación necesarios (p. ej., «Bearer», «OAuth2») para interactuar con el agente.
Habilidades: Lista de tareas o funciones específicas que el agente puede realizar (objetos AgentSkill), incluyendo su ID, nombre, descripción, modos de entrada, modos de salida y ejemplos.

Los agentes cliente pueden entonces descubrir agentes remotos analizando sus respectivas Tarjetas de Agente para determinar si un agente remoto es adecuado para una tarea determinada, cómo estructurar las solicitudes para sus habilidades y cómo comunicarse con él de forma segura.

En la misma línea, el Protocolo de Contexto de Modelo (MCP) especifica un mecanismo similar para el descubrimiento dinámico de herramientas. Mediante las URI mcp://, los agentes pueden resolver y recuperar información completa de metadatos sobre las capacidades, los requisitos y los métodos de interacción de las herramientas.

Tanto A2A como MCP se basan en descripciones textuales/en lenguaje natural de agentes y herramientas. En un artículo anterior, señalé escenarios en los que esto podría no ser suficiente y necesitamos un modelo de descubrimiento más formal basado en capacidades/restricciones para permitir un descubrimiento preciso y automatizado de herramientas y agentes.

En tercer lugar, necesitamos diseñar la lógica de la agencia (plan para alcanzar el objetivo). Aquí, debemos diferenciar entre agentes deterministas y autónomos, ya que su diseño y ejecución son muy diferentes.

En el caso de los agentes deterministas, esto implica principalmente definir (estáticamente) un esquema de orquestación inicial con agentes/herramientas predeterminados.

En cambio, en el caso de los agentes autónomos, esto se limita a especificar el objetivo del caso de uso como una indicación para un LLM/modelo de razonamiento.

El planificador define entonces dinámicamente el plan de ejecución con la capacidad de adaptarlo entretanto, básicamente reaccionando al entorno según las observaciones en memoria.

En cuarto lugar, debemos considerar la optimización del despliegue de agentes para la inferencia. Con la IA generativa y el gran tamaño de los LLM, se prestó especial atención a la optimización/cuantificación de los LLM a modelos de lenguaje pequeños (SLM). Dado el enfoque actual en el flujo de trabajo empresarial de la mayoría de los agentes, esto parece haber perdido cierta prioridad. Estoy seguro de que la optimización de costes y la eficiencia energética volverán a ser prioritarias en cuanto tengamos más agentes en producción. Por lo tanto, esta etapa consiste en pensar proactivamente en optimizar las implementaciones de agentes, hasta el punto de que puedan implementarse en dispositivos edge. Para más detalles, consulte mi artículo anterior sobre el dimensionamiento de la inferencia de la IA de agentes).

Finalmente, analizamos la capa de gobernanza, y es en ella en la que nos centraremos principalmente en este artículo. Seamos realistas, sin esta capa, ningún agente entraría en producción en ninguna empresa, ni debería permitírsele hacerlo. Un buen ejemplo es la carta, ampliamente difundida, del CISO de JP Morgan sobre la necesidad de arquitecturas de agentes seguras y resilientes.

Las barreras de seguridad también parecen haberse convertido en un elemento clave en el ecosistema de la IA de agentes con la publicación del SDK de agentes de OpenAI.

En general, la observabilidad de extremo a extremo es fundamental no solo para recuperarse de situaciones en las que el agente se bloquea, sino también para las estrategias de reversión en situaciones en las que el agente empieza a desviarse del guion. En resumen, la conclusión clave es que crear agentes confiables y seguros en producción implica más que escribir unas pocas líneas de código -:)

2. Capa de evaluación integrada con barreras de seguridad para agentes de IA

La adopción empresarial de agentes de IA autónomos atraviesa actualmente una crisis de confianza y fiabilidad. Con este fin, destacamos la necesidad de una estrategia de evaluación integral con la generación de barreras de seguridad específicas para cada caso de uso, con el fin de detectar y mitigar los riesgos específicos de la IA con agentes.

2.1 Estrategia de evaluación para agentes de IA

En esta sección, damos los primeros pasos para definir una estrategia de evaluación integral para agentes de IA empresariales. Se trata de un problema multifacético (ilustrado en la Fig. 3) que requiere diseñar pruebas de validación específicas para cada caso de uso que cubran métricas funcionales y no funcionales, teniendo en cuenta:

• el modelo de razonamiento subyacente (LLM),
• la arquitectura de la solución (generación aumentada por recuperación – RAG, ajuste fino, patrón de orquestación de agentes/herramientas, etc.),
• las políticas empresariales aplicables y las regulaciones y directrices de IA responsables.

Actualmente, prevalecen principalmente tres tipos de metodologías de evaluación:

• Puntos de referencia y conjuntos de datos genéricos
• Maestría en Derecho como Juez
• Evaluación manual

Consideremos primero las tablas de clasificación de LLM disponibles públicamente, como la tabla de clasificación de LLM abierta de Hugging Face. Si bien son útiles, se centran principalmente en probar LLM preentrenados en tareas genéricas de PLN (p. ej., preguntas y respuestas, razonamiento, completar oraciones) utilizando conjuntos de datos públicos, como:

• SQuaD 2.0: Preguntas y respuestas
• Alpaca Eval: Seguimiento de instrucciones
• GLUE: Tareas de comprensión del lenguaje natural (PLN)
• MMLU: Comprensión del lenguaje multitarea
• DecodingTrust: Dimensiones de IA responsable, el marco subyacente a la tabla de clasificación de seguridad de LLM de Hugging Face

La principal limitación radica en que estas tablas de clasificación se centran en la evaluación de LLM fundamentales (preentrenados) en tareas genéricas de procesamiento del lenguaje natural (NLP). La contextualización de casos de uso empresariales implica la aplicación de procesos y datos empresariales para perfeccionar los agentes de IA.

Por lo tanto, estos resultados genéricos de evaluación comparativa no pueden aplicarse tal cual (son insuficientes) para realizar una evaluación de IA específica para cada caso de uso.

El método LLM como juez utiliza un LLM de «evaluación» (otro LLM preentrenado) para evaluar la calidad de las respuestas del LLM objetivo, calificándolas mediante métodos como CriteriaEvalChain de LangChain. Desafortunadamente, las limitaciones específicas de cada caso de uso persisten también en este caso. Ofrece la ventaja de acelerar el proceso de evaluación del LLM, aunque (en la mayoría de los casos) con un mayor coste debido al uso de un segundo LLM.

La última alternativa es la validación manual (externalizada) con la ayuda de expertos empresariales en la materia (SME). Si bien puede funcionar como una opción alternativa, tiene implicancias de (alto) costo y esfuerzo, debe planificarse teniendo en cuenta la disponibilidad de las PYMES y realizarse de manera estandarizada para tener en cuenta los sesgos humanos.

2.2 Gestión de Riesgos de la IA Agentic

Con el creciente número de sistemas de IA Agentic implementados en producción, observamos una mayor atención a sus riesgos. En lugar de crear una nueva lista, intenté consolidar los riesgos identificados en las dos referencias siguientes:

• Documento técnico de OWASP: IA Agentic: Amenazas y Mitigaciones, 2025.
• Documento técnico de IBM: La Responsabilidad y el Riesgo Importan en la IA Agentic, 2025.

R1–15 se refieren a los riesgos identificados en [1]. Los entre paréntesis () se refieren a los riesgos correspondientes identificados en [2]. R16: El sesgo impulsado por la persona, por ejemplo, es bastante interesante; se ha identificado en [2], pero no se encuentra en [1].

• R1: Comportamientos desalineados y engañosos (Engaño dinámico)
• R2: Rompimiento de intenciones y manipulación de objetivos (Desalineación de objetivos)
• R3: Uso indebido de herramientas (Uso indebido de herramientas/API)
• R4: Envenenamiento de memoria (Persistencia del agente)
• R5: Ataques de alucinaciones en cascada (Ataques sistémicos en cascada)

(Vulnerabilidades de seguridad)

• R6: Compromiso de privilegios
• R7: Suplantación de identidad
• R8: Ataques de código y RCE inesperados

(Resiliencia operativa)

• R9: Sobrecarga de recursos
• R10: Repudio e impracticabilidad

(Colusión multiagente)

• R11: Agentes no autorizados en sistemas multiagente
• R12: Envenenamiento de la comunicación de agentes
• R13: Ataques humanos a sistemas multiagente

(Supervisión humana)

• R14: Manipulación humana
• R15: Presencia excesiva de personas en el circuito
• R16: (Sesgo basado en la persona)

Lo interesante desde el punto de vista de la mitigación de riesgos es que su mitigación suele dejarse en manos de una capa central de protección. Sin embargo, esto no es realista, y las barreras deben ser específicas para el caso de uso subyacente e implementarse en sus respectivos componentes/capas de la plataforma, lo que tiene un impacto directo en la arquitectura general de la solución.

El mapeo de la arquitectura de riesgos del componente de IA agentic se muestra en la Fig. 4.

3. Automatizar la generación de barreras para agentes

En esta sección, nos centramos en la evaluación específica de cada caso de uso y la generación de barreras para agentes de IA. La cuestión es que, si el caso de uso está relacionado con finanzas, derecho, etc., debemos diseñar pruebas de validación y funciones de barrera teniendo en cuenta los datos del dominio subyacente, los (sub)temas, las consultas de los usuarios, las métricas de rendimiento y los requisitos regulatorios, etc., del caso de uso subyacente. Por ejemplo, las políticas de cancelación correspondientes a la función cancel_flight_booking() incluyen:

«Se debe obtener confirmación explícita del cliente antes de cancelar un vuelo».
«Las reservas de vuelos se pueden cancelar sin cargo dentro de las 24 horas posteriores a la reserva».
«Los vuelos en clase turista o ejecutiva solo se pueden cancelar si se contrata un seguro de viaje».

Presentamos un enfoque de tres pasos para generar barreras basadas en políticas para casos de uso de agentes (ilustrado en la Fig. 5):

1. Asignar las políticas a los agentes/herramientas relevantes sin conexión.
2. Genera barandillas para los agentes mapeados en forma de código de validación de políticas.
3. Invoca las barandillas en tiempo de ejecución antes de la invocación del agente. Esto actúa como medida preventiva para garantizar que los agentes/herramientas no infrinjan ninguna política. En caso de infracción, se le solicita al agente que reflexione y adapte su estrategia.

3.1 Asignar políticas a funciones del agente

El algoritmo de asignación consta de los siguientes pasos:

• Solicitar al modelo de lenguaje grande (LLM) que extraiga una lista de políticas aplicables a cada agente.
• Para cada política, agregar una descripción e incluir referencias del documento original de la política para fundamentarla y minimizar las posibles alucinaciones.
• Descomponer las políticas complejas en políticas atómicas más pequeñas, especialmente aquellas donde las condiciones estén conectadas mediante un operador OR lógico. Esto incluye la eliminación de políticas duplicadas mediante la fusión de las idénticas o superpuestas.
• Generar ejemplos positivos (cumplimiento) y negativos (infracción) para cada política. Estos ejemplos sirven para aclarar la ambigüedad y garantizar la coherencia durante la fase de implementación.

3.2 Algoritmo de generación de barandillas

El algoritmo consta principalmente de dos pasos:

1. Generar primero el código «esqueleto» de la política, que consta de las definiciones de clase de Python para los tipos de datos, las funciones del agente y los stubs vacíos (marcadores de posición) para las barandillas.
2. Solicitar a los grandes modelos de lenguaje (LLM) que generen el código de las barandillas (dinámicamente) para rellenar los stubs de marcador de posición con código funcional de validación de políticas. Los ejemplos positivos (cumplimiento) y negativos (infracción) se traducen en pruebas de validación individuales que guían la generación de barandillas, impulsada por la interpretación de políticas proporcionada por el asignador de políticas a agentes. (Consulte el ejemplo de solicitud de generación en el bloque de código a continuación).

Generar pruebas unitarias en Python para una barrera de seguridad que valide el cumplimiento de la función de agente de políticas con las restricciones de la política empresarial.
El objetivo de la barrera de seguridad es validar los datos de los argumentos de la función y generar una excepción si infringe las restricciones de la política.

Reglas de generación de pruebas:

• Cada política tiene múltiples ejemplos de cumplimiento e infracción.
• Para cada ejemplo de cumplimiento, generar una función de validación.
• Si se produce una excepción en la función del agente bajo prueba, registrarla y propagarla.
• Para cada ejemplo de infracción, generar una función de validación.
• Si no se generó la excepción esperada, la prueba debe registrar un mensaje de error que indique que el caso de prueba no generó una excepción.
• Para cada prueba generada, agregar un comentario que vincule la función con la política relevante que está validando.
• Cada mensaje de error en el registro debe describir el escenario de prueba que falló, los resultados esperados y reales.

Seguimos el paradigma de desarrollo impulsado por pruebas (TDD), donde las pruebas se escriben antes que el código real: este proceso iterativo rojo-verde-refactorización implica escribir una prueba, escribir el código mínimo para pasarla y luego refactorizar ambos.

3.3 Validación de la barrera de seguridad del agente (en tiempo de ejecución)

Cada función de barrera de seguridad (generada) valida la funcionalidad del agente con respecto a los tres tipos de entradas siguientes:

• Argumentos de la función: Por ejemplo, las horas transcurridas tras la reserva, por ejemplo, 48 horas, en una invocación de cancel_flight_booking() pueden validarse con la política «Las reservas de vuelos se pueden cancelar sin coste en las 24 horas posteriores a la reserva».
• Historial de conversaciones: Puede ser especialmente útil para validar el consentimiento del usuario a una acción específica (por ejemplo, la cancelación de una política de reserva de vuelo requiere la confirmación explícita del usuario), así como para conocer la secuencia de agentes/herramientas invocados previamente.
• Integración con otros agentes/herramientas: Permite que la barrera de seguridad valide el acceso a los datos, la consistencia de los datos, etc., y las comprobaciones de las acciones realizadas por otros agentes/herramientas en tiempo de ejecución. Por ejemplo, antes de ejecutar flight_booking(), la función del agente debe validar que haya suficientes asientos disponibles en la cabina solicitada.

4. Conclusión

Si bien los beneficios de los sistemas de IA agentica son evidentes, también son sistemas complejos, difíciles de ejecutar de forma fiable y autónoma. Su adopción empresarial depende de garantizar que los agentes se implementen de forma totalmente compatible con las políticas empresariales correspondientes a cada caso de uso.

Desafortunadamente, esto supone un gran reto hoy en día, dado que las políticas empresariales pertinentes están integradas en documentos complejos, redactados en lenguaje legal y definidos por expertos en la materia (SME). Para superar esto, primero identificamos los riesgos específicos de la IA agentica y, a continuación, asignamos sus correspondientes barreras de seguridad a los componentes relevantes de la plataforma. Esto permite un enfoque modular y componible para la gestión de riesgos de la IA agentica. Posteriormente, describimos una metodología que se basa en la estrategia fundamental de evaluación LLM y el desarrollo impulsado por pruebas (TDD), teniendo en cuenta los datos y procesos relacionados con los casos de uso de la IA agentica, para generar barreras de seguridad específicas para cada caso de uso de forma automatizada.