Guardrails de IA para agentes: qué son, los principales tipos y dónde debe vivir cada uno

“Guardrails” se ha convertido en la respuesta por defecto a cualquier pregunta sobre el riesgo de los agentes de IA, y la palabra significa ya casi cualquier cosa. Para un equipo, es un filtro de contenido sobre la salida del modelo. Para otro, es un párrafo en el system prompt que dice al agente qué no hacer. Para un tercero, es la pantalla de permisos de la plataforma de agentes. Los tres son guardrails. No protegen contra lo mismo, y solo algunos sobreviven a un agente que ha sido manipulado.

Esta guía ordena los principales tipos, con ejemplos de productos y casos que ya hemos analizado, y termina con la prueba que separa un control real de una instrucción bienintencionada.

Qué es un guardrail de un agente de IA

Un guardrail es cualquier control que limita lo que un agente de IA puede decir o hacer, o cuánto puede hacer, con independencia de lo que se le pida. La distinción útil es dónde se ejecuta el control:

• Dentro del razonamiento del agente: instrucciones en el prompt, reglas que se pide al modelo que siga. El agente las lee, así que se le puede convencer de saltárselas.
• Alrededor del modelo: filtros que inspeccionan entradas y salidas, como temas bloqueados, detección de datos sensibles o comprobaciones de que una respuesta se apoya en sus fuentes.
• Fuera del agente: controles que el agente no ve ni puede cambiar, aplicados por el sistema operativo, el runtime, un gateway, un sistema de identidad o una persona.

Dónde viven los guardrails de los agentes, del más fuerte al más débil frente a la manipulación

Identidad y permisos

• En nombre de quién actúa el agente
• A qué llegan sus credenciales

Lo aplican los sistemas de registro

Contención en el runtime

• Archivos, red y procesos a los que llega el agente

Lo aplica el sistema operativo o el runtime

Gateway de herramientas y modelos

• Qué herramientas y modelos, con qué frecuencia, a qué coste

Se aplica en cada llamada

Filtros de entrada y salida del modelo

• Temas bloqueados, datos sensibles, comprobación de fuentes

Instrucciones en el prompt

• Reglas que se pide al agente que siga

El agente las lee, así que puede ser convencido

Los principales tipos, con ejemplos

1. Instrucciones de prompt y de política. El system prompt dice “no compartas nunca datos de clientes” o “responde solo preguntas de recursos humanos”. Barato, útil para el comportamiento y el tono, y no es un control de seguridad: una inyección de prompt en un documento que el agente lee puede anularlo. Explicamos por qué en los guardrails de prompt no son una frontera de seguridad.

2. Filtros de entrada y salida del modelo. Productos como Amazon Bedrock Guardrails y NeMo Guardrails, de código abierto, de NVIDIA, revisan prompts y respuestas en busca de temas vetados, contenido dañino o datos sensibles, y pueden comprobar si una respuesta está respaldada por sus fuentes. Buenos para el riesgo de contenido; ciegos a lo que el agente hace con las herramientas.

3. Contención en el runtime. El sistema operativo o el runtime limita a qué archivos, redes y procesos llega el agente. Ejemplos: los Execution Containers de Microsoft en Windows y OpenShell de NVIDIA, que ServiceNow usa para gobernar su agente personal Arc. Es la capa que limita el daño cuando todo lo demás falla.

4. Gateways de herramientas y de modelos. Cada llamada a una herramienta o a un modelo pasa por un gateway que la permite, la bloquea o la registra. Agent 365 de Microsoft puede bloquear las herramientas MCP que llama un agente en el gateway; los gateways de IA fijan qué modelos puede usar un equipo y a qué coste.

5. Reglas de secuencia y contexto. Algunas acciones son seguras por separado y peligrosas juntas: leer la ficha de un cliente y luego enviar un correo fuera de la empresa. Strands Box de AWS hace que la autorización dependa de lo que el agente acaba de hacer.

6. Aprobación humana. Una persona aprueba antes de que el agente envíe, pague, borre o despliegue. Es más fuerte cuando usa el proceso de aprobación que la empresa ya audita, como la gestión de cambios, y más débil cuando quien aprueba no puede ver lo que aprueba.

7. Presupuestos y límites de uso. Los límites de gasto y de volumen frenan bucles desbocados y abusos. Databricks comprobó que una fricción que aumenta de forma gradual funciona mejor que los topes rígidos para las personas; para los agentes autónomos, los límites rígidos siguen siendo una red de seguridad sensata.

La prueba que importa

Para cada guardrail, haga una pregunta: si un documento malicioso convenciera al agente de hacer lo prohibido, ¿lo seguiría impidiendo este control? Si la respuesta es no, es una pauta de comportamiento, valiosa para la calidad e inútil para la seguridad. Los tipos 1 y 2 suelen fallar esa prueba. Los tipos 3 a 7 suelen superarla, porque se ejecutan fuera del agente.

La segunda pregunta es quién es responsable. Estos controles responden a preguntas distintas, funcionan a ritmos distintos y deberían estar en manos de equipos distintos; lo ordenamos como seis autoridades independientes sobre un agente.

Un conjunto mínimo para un agente en producción

• Una identidad propia, con permisos limitados a su tarea.
• Contención que limita lo que puede tocar, aplicada fuera del agente.
• Un gateway que registra cada llamada a herramientas y modelos.
• Aprobación humana para las acciones difíciles de revertir.
• Un presupuesto con alerta y un tope rígido.
• Instrucciones en el prompt y filtros de salida para el comportamiento y el contenido, encima de todo lo anterior, no en su lugar.

Los guardrails no son un producto ni una capa. Los agentes que fallan de forma segura son aquellos cuyos límites no dependen de que el agente esté de acuerdo con ellos.