
Guardrails en IA: barreras que validan entradas, salidas y acciones
Los guardrails son controles que revisan lo que entra a un modelo, lo que sale y lo que hace un agente. Tipos, herramientas, cuándo correr y por qué no bastan.
¿Qué es un guardrail?
Un guardrail es una regla con capacidad de frenar. Puede ser una validación simple en código (el monto del reembolso no supera el límite), un clasificador que detecta contenido sensible o una comprobación de formato antes de ejecutar una acción.
La palabra viene de la seguridad vial: la baranda no conduce el coche, pero evita que caiga por el barranco. En IA, el modelo decide y el guardrail filtra qué pasa.
¿Qué tipos existen?
Hay tres puntos donde se pueden colocar:
| Tipo | Qué revisa | Caso típico |
|---|---|---|
| De entrada | Lo que llega al agente | Detectar un intento de inyección de instrucciones dentro de un correo |
| De salida | La respuesta antes de entregarla | Bloquear un dato personal en un texto generado |
| De herramienta | Cada llamada a una acción | Impedir que un agente borre muchos archivos sin aprobación |
El SDK de agentes de OpenAI hace esta separación explícita. Los guardrails de entrada corren solo sobre el primer agente de una cadena y los de salida, solo sobre el último. Los de herramienta envuelven las herramientas de tipo función y revisan cada llamada, antes y después de ejecutarla. Cuando un guardrail salta, el SDK lanza una excepción y detiene la ejecución.
Hay un matiz que importa al diseñar: según esa documentación, los handoffs (cuando un agente delega en otro) usan su propio canal y los guardrails de herramienta no los cubren. Tampoco pasan por ese canal las herramientas alojadas por OpenAI ni las de ejecución integradas. Si tu agente delega o usa esas herramientas, pregunta al equipo qué control cubre cada tramo.
NVIDIA, en NeMo Guardrails, usa una clasificación más fina con cinco tipos de “rails”: entrada, recuperación, diálogo, ejecución y salida. Los de recuperación revisan los documentos que se pasan al modelo en un sistema RAG.
¿Cuándo corren?
En el SDK de OpenAI, los guardrails de entrada tienen dos modos con un trade-off claro:
- En paralelo, junto al agente. Es el modo por defecto y el de menor latencia, pero el agente puede haber gastado tokens o ejecutado herramientas antes de que el guardrail lo detenga.
- En bloqueo, antes de que el agente empiece. Si el guardrail salta, el agente nunca corre: no hay costo de modelo ni efectos secundarios.
Los de salida siempre corren después de que el agente termina, así que no tienen modo paralelo.
Regla práctica: si el costo de un error es alto (un pago, un borrado, un mensaje a una clienta), usa bloqueo. Si el error es barato y la latencia importa más, puedes correrlo en paralelo.
¿Qué herramientas existen?
Las fuentes citadas aquí no publican una cifra de eficacia general: prueba cada herramienta con tus propios casos.
| Herramienta | Qué ofrece | Lo que dice su documentación |
|---|---|---|
| Endpoint de moderación de OpenAI | Clasifica texto e imágenes en categorías como acoso, odio, violencia o autolesión | Es gratuito, el modelo es omni-moderation-latest, no clasifica audio y los puntajes se deben tratar como señales, no como bloqueo automático |
| Filtro previo con un modelo ligero | Un modelo pequeño clasifica la entrada antes de llegar al modelo principal | Anthropic lo llama harmlessness screen y sugiere salidas estructuradas para que la respuesta sea un simple sí o no |
| NeMo Guardrails (NVIDIA) | Paquete de Python de código abierto, con licencia Apache 2.0 | Se configura con archivos YAML y Colang; NVIDIA advierte que sus guardrails incluidos pueden no ser adecuados para un caso de producción |
| Guardrails AI | Marco de Python con validadores del Guardrails Hub | Combina validadores en guards de entrada y de salida que interceptan lo que entra y sale del modelo |
Según la documentación de OpenAI, los puntajes pueden cambiar cuando se actualiza el modelo, así que una regla basada en un umbral puede necesitar recalibrarse.
Anthropic añade dos prácticas: filtrar también lo que devuelven las herramientas (un correo o una página web pueden traer instrucciones escondidas) y probar tu propio agente con documentos y correos que contengan intentos de inyección antes de lanzarlo. Ese tipo de pruebas se conoce como red teaming.
¿Por qué le importa a un diseñador?
Un guardrail que se dispara es un momento de interfaz. La persona necesita saber qué pasó, por qué y qué puede hacer. “No se puede completar esta acción” sin explicación es una mala experiencia y una mala señal de seguridad.
Diseña tres cosas:
- El mensaje: qué regla se activó, en lenguaje claro, sin exponer la lógica interna.
- La salida: ofrecer una alternativa, pedir una aprobación o escalar a una persona.
- El registro: que quede constancia de lo que el guardrail frenó, para revisarlo después.
Si el clasificador devuelve un puntaje y no un sí o un no, tienes un cuarto estado que diseñar: el caso dudoso. En vez de bloquear, puede pedir confirmación o enviar la acción a revisión humana. Esa decisión es de producto, no del clasificador.
¿Cuándo NO bastan?
Un guardrail es una capa, no la defensa completa. Anthropic describe sus salvaguardas en varias capas: política de uso, entrenamiento, pruebas previas, detección de violaciones y monitoreo. Y afirma que proteger el uso de la IA es demasiado importante para que una sola organización lo resuelva sola.
Lo mismo aplica a un producto. Un guardrail de texto no reemplaza que el agente no tenga permisos de borrado, que una persona apruebe los pagos grandes y que haya registros. La documentación de Anthropic sobre inyecciones recomienda el principio de mínimo privilegio: no darle al modelo secretos que no necesita, ejecutar las herramientas en entornos aislados y acotar los permisos al máximo, para que una inyección exitosa haga el menor daño posible.
Ejemplo
Ejemplo ilustrativo: un agente de soporte puede emitir reembolsos. Tiene tres capas. Un guardrail de herramienta, en bloqueo, verifica que el monto no supere el límite del agente y que el pedido existe. Un guardrail de salida revisa que la respuesta a la clienta no incluya datos de otra cuenta. Y cualquier reembolso mayor a cierto monto se manda a aprobación humana. Si el primer guardrail salta, la clienta ve “Necesito revisar esto con un equipo; te escribimos en un día hábil” y el caso queda registrado con la regla que lo frenó.
Para ver cómo se coordinan las aprobaciones humanas en el flujo, lee human-in-the-loop y aprobación de acciones de un agente. Para diseñar qué puede hacer un agente sin preguntar, UX de permisos de agentes. Y para cuándo parar y preguntar, modo plan.
Errores comunes
- Confiar en un solo guardrail para todo el sistema.
- Correr en paralelo un guardrail que protege una acción costosa o irreversible.
- Dejar el mensaje de bloqueo genérico. La persona no sabe qué hacer y reintenta sin cambiar nada.
- No registrar los bloqueos. Sin registro, no puedes saber si el guardrail es demasiado estricto o demasiado laxo.
- Pensar que una regla escrita en el prompt es un guardrail. Un prompt pide; un guardrail verifica.
- Tratar un puntaje de moderación como veredicto final, sin definir qué pasa en los casos dudosos.
- Suponer que el guardrail de herramienta cubre también los handoffs y las herramientas alojadas.
Fuentes
- Guardrails, OpenAI Agents SDK (documentación)
- Moderation, OpenAI API (documentación)
- Mitigate jailbreaks and prompt injections (documentación de Anthropic)
- Building safeguards for Claude (Anthropic)
- Building effective agents (Anthropic Engineering)
- NeMo Guardrails, visión general (NVIDIA)
- NeMo Guardrails, tipos de rails (NVIDIA)
- NeMo Guardrails en GitHub (licencia y limitaciones)
- Guardrails AI (documentación)