Decirle a un agente “no envíes datos sensibles” no es un guardrail. Es una instrucción que puede competir con otras instrucciones, con un documento malicioso o con una petición ambigua. El control aparece cuando el sistema puede impedir la acción.
En producción, los guardrails forman una defensa por capas. Algunas reglas son deterministas, otras clasifican contenido y otras detienen el flujo para que decida una persona. Ninguna capa cubre por sí sola todos los fallos.
El límite del prompt
Las instrucciones del sistema definen comportamiento, pero se interpretan probabilísticamente. Son apropiadas para tono, prioridades y criterios abiertos. No para imponer un tope de transferencia, ocultar secretos o garantizar que una herramienta solo lea una carpeta.
Una regla exacta debe existir fuera del modelo. El esquema rechaza formatos inválidos. La API limita importes. El sistema de identidad impide acceder a otros clientes. La red bloquea destinos no autorizados. Aunque el agente intente la acción, no puede completarla.
Esta separación reduce la superficie que exigimos al modelo y facilita probar los controles sin generar lenguaje.
Cinco puntos de control
Los guardrails pueden ubicarse en varias fronteras:
| Punto | Qué comprueba | Ejemplo |
|---|---|---|
| Entrada | Intención, datos sensibles, abuso | Bloquear una solicitud fuera de alcance |
| Contexto | Fuente, permiso, vigencia, contenido hostil | Excluir un documento no autorizado |
| Herramienta: entrada | Acción y parámetros propuestos | Rechazar un reembolso sobre el límite |
| Herramienta: salida | Datos devueltos y efectos | Redactar identificadores innecesarios |
| Respuesta | Formato, evidencia, política | Exigir citas o bloquear una recomendación |
La documentación del SDK de OpenAI distingue guardrails de entrada y salida en los límites del flujo, y guardrails de herramientas alrededor de cada llamada. En cadenas con delegaciones, confiar solo en el primer y último control deja huecos intermedios (OpenAI Agents SDK).
Determinista cuando la regla lo permita
Los controles más fiables son aburridos: listas de destinos permitidos, validación de esquema, límites numéricos, permisos, estados válidos y consultas parametrizadas. Son rápidos, reproducibles y explicables.
Un agente comercial puede preparar descuentos, pero la herramienta calcula el máximo según margen y rol. Un agente de soporte puede proponer cerrar una cuenta, pero la API exige una aprobación asociada a esa cuenta. No pedimos al modelo que recuerde cada condición.
Las reglas deben aplicarse en el último punto de confianza, justo antes de la acción. Validar al principio no protege frente a parámetros que el agente genera después.
Clasificadores para lo ambiguo
Hay políticas difíciles de expresar con una expresión regular: acoso, intento de inyección, contenido clínico o una petición que se aleja del propósito. Un clasificador especializado o un segundo modelo puede detectar estas categorías.
Necesita umbrales calibrados y una zona gris. Bloquear todo lo dudoso deteriora el producto; permitirlo todo desplaza el riesgo. Las salidas pueden ser permitir, transformar, pedir aclaración, escalar o bloquear.
OpenAI Guardrails aplica detección de inyección alrededor de herramientas y otros controles en los límites de entrada y salida; además permite detener o rechazar llamadas según la infracción (OpenAI Guardrails). Es una implementación posible, no una garantía automática. La configuración debe probarse con el dominio real.
Aprobaciones humanas en el punto correcto
Una aprobación útil se coloca antes de una consecuencia sensible y muestra acción, objeto, parámetros y evidencia. El SDK de OpenAI permite pausar llamadas, serializar su estado y reanudarlas después de la decisión (OpenAI Agents SDK).
No conviene aprobar cada herramienta. La fatiga convierte el control en un clic rutinario. Aplicamos aprobación por política: importe, sensibilidad, irreversibilidad, destinatario, baja confianza o comportamiento fuera de lo habitual.
El rechazo también debe tener una ruta. El agente puede corregir parámetros, entregar un borrador o escalar. Repetir la misma llamada hasta que alguien acepte es un fallo del bucle.
Permisos e aislamiento: el guardrail que no habla
La menor autoridad posible limita el daño incluso cuando fallan otras capas. Credenciales por agente o usuario, permisos con ámbito, secretos fuera del contexto y entornos aislados son controles fundamentales.
El contenido externo se trata como no confiable. Un PDF puede incluir instrucciones dirigidas al agente. El sistema separa datos de instrucciones y restringe las acciones disponibles durante la lectura. El proyecto OWASP para aplicaciones agentic sitúa la agencia excesiva y el privilegio mínimo entre sus preocupaciones centrales (OWASP GenAI Security Project).
También controlamos la salida de red y de archivos. Si una tarea solo necesita consultar dos dominios, no hay razón para permitir Internet abierto.
Qué registrar sin crear otro riesgo
Para investigar necesitamos entrada, decisión de cada guardrail, herramienta, parámetros, aprobación, resultado y versión de política. También quién modificó una excepción. Las trazas deben evitar secretos y aplicar acceso y retención.
Las métricas incluyen bloqueos por tipo, falsos positivos confirmados, incidentes que atravesaron el control, tiempo añadido y frecuencia de escalado. Un guardrail que bloquea el 40 % puede estar detectando ataques o una mala definición del producto. Hay que mirar muestras.
Las excepciones temporales son especialmente peligrosas. Deben tener propietario, motivo y caducidad; de otro modo se convierten en la política real.
Probar las capas juntas
Las pruebas normales verifican que el sistema permite el trabajo legítimo. Las adversariales intentan confundirlo: instrucciones dentro de documentos, codificaciones, fragmentación de datos sensibles, llamadas repetidas, cambios de rol y combinaciones de herramientas que producen un efecto prohibido.
También probamos disponibilidad. Si el clasificador no responde, ¿el sistema bloquea, degrada o continúa? La decisión depende del riesgo y debe ser explícita. Un control que desaparece silenciosamente durante una caída no es un control.
Cada cambio de modelo, prompt, herramienta o política ejecuta la batería. Los guardrails tienen versiones y se despliegan gradualmente, igual que el resto de la aplicación.
Diseñar desde la consecuencia
El proceso más útil empieza enumerando acciones y datos, no categorías abstractas de seguridad. Para cada acción preguntamos qué daño puede causar, qué regla exacta cabe imponer, qué ambigüedad queda y quién puede aprobarla. Después elegimos las capas.
Un guardrail eficaz suele ser invisible para quien trabaja dentro del recorrido permitido. Aparece con una explicación concreta cuando se cruza un límite y ofrece una alternativa segura. La meta no es que el agente parezca obediente. Es que el sistema siga siendo gobernable cuando el agente, el usuario o una fuente externa se equivocan.
Preguntas frecuentes
¿Un modelo más seguro reduce la necesidad de guardrails?
Puede reducir ciertos fallos, pero no sustituye permisos, límites de negocio, aislamiento ni aprobaciones ligadas a consecuencias.
¿Guardrails y evaluación son lo mismo?
No. El guardrail actúa durante la ejecución. La evaluación mide su comportamiento y descubre qué controles faltan o bloquean en exceso.
¿Qué hacemos ante un falso positivo?
Registrarlo, ofrecer una ruta de revisión y ajustar con ejemplos representativos. No conviene crear excepciones permanentes sin alcance ni caducidad.
¿Debemos detener todo si falla un guardrail?
Depende del riesgo. Para una acción sensible, cierre seguro. Para una ayuda de bajo impacto, puede degradar a respuesta sin herramientas o pedir revisión.
¿Dónde se aplican las reglas de herramientas?
Inmediatamente antes de ejecutar y, cuando corresponda, sobre la salida. En flujos largos deben repetirse aunque la llamada hubiera sido aprobada antes.