Los guardrails son dos puntos de control, no uno
Alguien escribe una solicitud en tu función de IA y el modelo simplemente responde: sin fricción, sin verificación, sin nada que se interponga entre "el usuario preguntó" y "el modelo lo hizo". Así se ve funcionar con cero guardrails. La solución no es un filtro atornillado en algún lado. Son dos.
El problema: un solo filtro cubre la mitad del riesgo
La mayoría de los equipos que agregan "un guardrail" agregan exactamente una verificación, normalmente justo antes de que el modelo responda, y dan por hecho el trabajo. Pero un único punto de control solo atrapa fallas en un lado del intercambio. Se pierde por completo las fallas que ocurren del otro lado.
Los guardrails se dividen naturalmente en dos categorías, según cuándo se ejecutan respecto a la llamada al modelo:
- Guardrails de entrada se ejecutan antes de que la solicitud llegue al modelo. Su trabajo es impedir que las solicitudes malas lleguen a procesarse.
- Guardrails de salida se ejecutan después de que el modelo genera una respuesta. Su trabajo es impedir que las respuestas malas lleguen al usuario.
No son redundantes. Una verificación de entrada no puede ver lo que el modelo está a punto de decir: solo sabe lo que preguntó el usuario. Una verificación de salida no puede deshacer el hecho de que el modelo ya procesó un prompt malicioso: solo puede atrapar lo que se filtra por el otro extremo.
Por qué funciona: cada lado tiene una tarea distinta
Los guardrails de entrada son tu primera línea de defensa. Los patrones comunes incluyen:
- Detección de prompt injection / jailbreak: atrapar intentos de anular el system prompt ("ignora las instrucciones anteriores...").
- Guardrails de tema: rechazar solicitudes fuera del alcance previsto de la función antes de que consuman una llamada al modelo.
- Detección de PII: bloquear solicitudes que contienen datos sensibles que el usuario no debería estar pegando (un número de teléfono, un número de seguro social, un ID interno).
- Filtros de toxicidad: rechazar de entrada solicitudes claramente abusivas o dañinas.
Los guardrails de salida atrapan lo que se coló, o lo que el modelo produjo por su cuenta incluso a partir de una entrada limpia:
- Verificaciones de seguridad de contenido: escanear la respuesta generada en busca de contenido inseguro o que viole las políticas antes de mostrarla.
- Detección de fugas: atrapar secretos, credenciales o datos internos que el modelo no debería haber revelado.
- Verificaciones de formato / fundamentación: comprobar que la respuesta no alucina fuera de los límites permitidos.
La razón por la que ambos importan: un guardrail de entrada puede estar limpio y el modelo aun así puede producir una respuesta insegura. Y un guardrail de salida por sí solo significa que ya gastaste una llamada al modelo, y potencialmente expusiste al modelo a un prompt malicioso, antes de atrapar nada.
Cómo construirlo
No necesitas un framework pesado para empezar. Cada guardrail es apenas una pequeña función, una lista de patrones o una rúbrica evaluada por un clasificador ligero (o una llamada a un LLM más barato). La forma es simple:
request → [input check] → model → [output check] → response
- Escribe primero la verificación de entrada. Empieza por las detecciones de mayor valor: un filtro fuera de tema, un detector de PII, una verificación de patrones de jailbreak.
- Escribe la verificación de salida después. Como mínimo, ejecuta un clasificador de seguridad de contenido sobre la respuesta generada antes de devolverla. Agrega una pasada de detección de fugas específica para tu esquema si tu función puede exponer datos estructurados.
- Conecta ambas al camino de la solicitud, no como algo añadido después: la verificación de salida debe bloquear que la respuesta llegue al usuario, no solo registrar una advertencia.
- Registra cada bloqueo, en ambos lados. Cada entrada bloqueada adelanta el próximo patrón de ataque; cada salida bloqueada muestra dónde están realmente los modos de falla de tu modelo.
Un patrón de demostración concreto: una solicitud que el guardrail de tema debe rechazar devuelve algo como "Blocked. Topic not allowed"; una solicitud que dispara el filtro de toxicidad devuelve "Unsafe content detected"; una solicitud que carga datos sensibles devuelve "Sensitive information detected". Los tres viven en el lado de entrada y nunca tocan el modelo. El lado de salida ejecuta su propia verificación de contenido, separada, sobre lo que el modelo realmente produjo.
Errores comunes
- Tratar la verificación de salida como opcional porque la de entrada "debería" atrapar todo. No lo hará: los filtros de entrada se basan en patrones y los adversarios iteran sobre los patrones.
- Usar el mismo clasificador o prompt para ambas verificaciones. "¿Es aceptable procesar esta solicitud?" y "¿es aceptable mostrar esta respuesta?" son preguntas distintas.
- No registrar los bloqueos. Sin registros, no puedes ver a los atacantes convergiendo hacia un bypass, ni a los usuarios legítimos recibiendo falsos positivos.
- Configurar las verificaciones una vez y olvidarlas. Nuevos tipos de guard aparecen a medida que tu función se usa en el mundo real: trata los guardrails como una lista viva.
Trucos de poder
- Registra cada bloqueo, ambos lados, desde el día uno. Los patrones que los atacantes prueban contra tu verificación de entrada son, literalmente, la especificación de tu próxima regla de guardrail.
- Prueba con una solicitud corta y correcta frente a una larga y adversarial para asegurarte de que tu filtro de entrada no esté accidentalmente sesgado por longitud ni sea demasiado amplio.
- Trata los dos puntos de control como propiedad independiente: distintos modos de falla, distintas suites de pruebas, distintos umbrales de alerta.
Recursos
¿Estás lanzando una función de IA? Yeda AI diseña, audita y lanza sistemas LLM en producción.