Guardrails para agentes de IA: input, output y tools

Un system prompt que dice “sé seguro” no es un guardrail. Un guardrail es código que puede abortar el run antes de llamar al modelo, antes de ejecutar una tool o antes de mandar el texto al usuario. Si no puede decir que no, es copy.

Esta guía separa tres capas (input, tools, output), el contrato del OpenAI Agents SDK (tripwires), la API de Moderación y lo que Gemini llama safety settings. No sustituye prompt injection: eso es un atacante; esto es política de contenido y de acciones. Fuentes del 3 de septiembre de 2026.

Tres capas, no un if gigante

Capa	Se corre	Bloquea	Ejemplo
Input	Antes del modelo	El mensaje del usuario	Pornografía, doxxing, “olvida tus reglas”
Tool	Antes de ejecutar la tool	La acción	Refund > umbral, rm -rf, mail a lista entera
Output	Antes de responder	El texto al usuario	PII inventada, secreto, odio, JSON fuera de política

El SDK de OpenAI nombra exactamente eso: input guardrails, tool guardrails, output guardrails, con tripwires (si saltan, el run se corta). También documenta execution modes: no todos los rails tienen que ser síncronos y caros. Un regex de “no mandes la API key” es barato y va en output; un clasificador de odio puede ir en paralelo.

Si no usas ese SDK, copia el contrato: cada rail es una función (contexto) -> {ok} | {trip, motivo}. El runner respeta el trip. Un console.warn no es un rail.

Moderación de OpenAI: clasificar no es generar

OpenAI documenta un endpoint de moderación aparte, gratis. El modelo omni-moderation-latest acepta texto e imágenes (no audio); las imágenes hasta 20 MB. Dos workflows oficiales:

1. Clasificar inputs sueltos — sin generar respuesta. Útil en la capa input.
2. Moderar contenido generado — pides scores junto a la respuesta de Responses / Chat Completions.

El resultado son flags, categorías y scores. Tú decides la política: filtrar, mandar a revisión humana o intervenir la cuenta. El modelo no aplica tu política; tú lees el JSON y actúas.

No uses el modelo de chat como único filtro de odio: es más caro, más lento y más fácil de jailbreakear. Moderación primero, chat después.

Gemini expone safety settings por categoría a nivel de request. Ajústalos por producto (un bot de soporte ≠ un playground). No asumas el default del proyecto.

Hallucinations no se “moderan”

Claude documenta guardrails de verdad, no de odio: deja decir “no sé”, pide citas textuales en docs largos (>20k tokens) y verifica claims. Eso no lo resuelve omni-moderation. Si tu agente inventa un número de pedido, el rail correcto es grounding (tool de consulta + “si la tool no encontró, di que no”) o un output rail que exige order_id presente en el resultado de la tool.

Mezclar las dos cosas en un solo prompt es cómo terminas con un agente que se niega a hablar de facturas y aun así inventa saldos.

Tool guardrails: el único que evita el desastre

Input/output filtran texto. El desastre suele ser una tool. Un rail de tool mira nombre + argumentos + quién pide:

• refund(amount) si amount > 500 → trip o HITL.
• run_sql(query) si no empieza con SELECT → trip.
• send_email(to) si to no está en el dominio de la empresa → trip.

Eso es más barato y más fiable que pedirle al modelo “por favor no”. Combínalo con sandboxing (el sandbox limita cómo corre; el rail decide si corre).

Política mínima (una página, no un PDF)

Escribe cinco líneas y cúmplelas en código:

1. Qué categorías de moderación bloquean (odio, sexual, self-harm, etc.).
2. Qué tools nunca corren sin humano.
3. Qué PII nunca sale (y cómo la detectas: regex + modelo, no solo el modelo).
4. Qué pasa en un trip: mensaje fijo al usuario, log, métrica. Nada de “el modelo se disculpa”.
5. Quién puede bajar un rail en prod (spoiler: no el on-call a las 3 AM sin ticket).

Sin esa página, cada dev pone un if distinto y el agente es un colador.

Checklist

• Input rail antes del primer token (moderación o clasificador).
• Tool rails en todas las tools con efecto. El resto puede pasar.
• Output rail de secretos/PII (regex de claves + patrones de tarjeta).
• Trip = abort + log + métrica. No “retry con otro prompt” en silencio.
• Safety settings de Gemini revisados por ambiente (dev más laxo, prod no).
• Un eval de 20 ataques: injection, odio, “ignora el rail”, tool fuera de política. Ver evals.
• El mensaje al usuario en un trip es plantilla, no generado.
• Observabilidad: cuenta de trips por rail, no un log de 4 MB.

FAQ

¿El modelo ya tiene safety. ¿Para qué otro filtro? El safety del proveedor es genérico y se evade. El tuyo conoce tu negocio (refunds, PII de clientes, el canal).

¿Puedo usar otro LLM como rail? Sí, como segundo input/output. No como único tool rail: latencia + costo + el segundo modelo también se jailbreakea. Regex + allowlist de argumentos primero.

¿Guardrail = HITL? No. HITL espera a un humano. Un trip corta ya. Usa HITL cuando la acción podría ser válida; trip cuando nunca lo es.

¿Moderation en imágenes? omni-moderation-latest sí clasifica imagen. Audio no. Si tu agente pega screenshots, móderalos igual que el texto.

Empieza por un tool rail (la acción más cara) y un output rail (API keys en el texto). Cuando esos dos disparen en staging, recién añades moderación de input.