Guardrails - filtros de entrada y salida
Los guardrails validan la entrada (prompt injection, PII, jailbreak) y la salida (PII, schema, política) en cada turno. Complementan al eval: retienen lo que va al usuario, pero no miden si la respuesta es buena.
Qué es
Un guardrail es una capa de validación que queda entre el usuario y el agente, y entre el agente y la respuesta final. En cada turno, dos bordes: el borde de arriba analiza el mensaje del usuario (y el historial, y los documentos que entrarán como contexto) y decide si pasa, bloquea o reescribe. El borde de abajo hace lo mismo con la salida del agente antes de que llegue a quien la pidió.
La diferencia con el eval es la posición en el tiempo. El eval mide la calidad después de que se generó la respuesta, en batch o por muestreo. El guardrail actúa ahora, en cada request. Son complementarios. Quien reemplaza uno por el otro crea teatro de seguridad: un eval demasiado lento para bloquear y un guardrail solo sin visión de la calidad general.
Entrada: prompt injection, jailbreak, PII
La entrada es la parte más apuntada. El usuario puede intentar instruir al modelo para que ignore las instrucciones del sistema (jailbreak clásico), incrustar un comando dentro de un documento recuperado (indirect ), o pegar datos sensibles pidiéndole al agente que los procese ( que termina en el log). El guardrail de entrada necesita las tres detecciones, y cada una tiene su propio mecanismo.
La PII es lo más fácil: regex sobre correo, documento de identidad, teléfono, tarjeta. Los falsos positivos son trabajo de revisión, los falsos negativos se vuelven incidentes. El jailbreak es más sutil: clasificadores entrenados con prompts adversariales, o patrones conocidos (DAN, role-play). La indirect injection es lo más nuevo y lo más difícil: la instrucción hostil está en un documento que trajo el retrieval, no en el mensaje del usuario. La detección aquí pide un análisis semántico del contenido recuperado, no solo del texto crudo.
Salida: schema, PII, política
La salida también necesita tres capas. La validación de schema garantiza que la respuesta final tenga la forma esperada (JSON tipado, markdown válido, links con host confiable). La máscara de PII redacta correo, teléfono, dirección que el modelo haya inventado o copiado. La política rechaza contenido prohibido por el negocio (competidor citado, jurisdicción restringida, categoría sensible).
La capa de schema merece atención especial. Sin un schema válido, el frontend no renderiza y el agente parece roto. Por eso el guardrail de salida arranca casi paranoico: es mejor bloquear una respuesta válida y devolver un fallback que entregar una respuesta que rompe al consumidor.
Guardrail de salida en la práctica
El snippet muestra un guardrail de salida mínimo: valida JSON contra un schema, redacta PII básica y bloquea cuando el contenido se aparta de la rúbrica. En producción conviene cambiar el regex por un detector (Guardrails AI, Lakera), pero la mecánica es esta:
import Ajv from "ajv";
const schema = {
type: "object",
required: ["resposta", "fontes"],
properties: {
resposta: { type: "string", minLength: 1, maxLength: 2000 },
fontes: { type: "array", items: { type: "string" } }
},
additionalProperties: false
};
const ajv = new Ajv();
const validate = ajv.compile(schema);
const PII = /\b([\w._%+-]+@[\w.-]+\.[A-Za-z]{2,}|\d{3}\.\d{3}\.\d{3}-\d{2})\b/g;
const PROIBIDO = /(competidor-x|competidor-y)/i;
export type Veredito = { ok: true; saida: unknown } | { ok: false; motivo: string };
export function guardrailSaida(raw: string): Veredito {
let parsed: unknown;
try { parsed = JSON.parse(raw); } catch { return { ok: false, motivo: "json_invalido" }; }
if (!validate(parsed)) return { ok: false, motivo: "schema_invalido" };
if (PROIBIDO.test(JSON.stringify(parsed))) return { ok: false, motivo: "politica_violada" };
const redigido = JSON.stringify(parsed).replace(PII, "[REDACTADO]");
return { ok: true, saida: JSON.parse(redigido) };
}Dónde entra en la arquitectura
Como capa transversal, antes del LLM y después del LLM. En producción el guardrail de entrada se vuelve un middleware del endpoint HTTP; el de salida se vuelve un wrapper del cliente LLM o un post-processor del stream. En frameworks como LangGraph, es un nodo dedicado entre el usuario y el agente, y entre el agente y la respuesta.
El rendimiento importa. Cada guardrail agrega latencia, y la latencia en un chat se nota de inmediato. Regla: el guardrail de entrada corre en <= 50ms para la mayoría de los casos, y el de salida queda dentro del presupuesto total del request (típicamente <= 200ms). Por encima de eso, usa un detector asíncrono y muestra un placeholder mientras procesa.
El guardrail no reemplaza al eval
El guardrail se ocupa de lo que puede pasar. Un agente puede pasar todos los guardrails y aun así dar una mala respuesta (fuera de tema, factualmente errónea, con un tono inadecuado). Eso es trabajo del eval, y el eval corre en batch donde el guardrail no puede.
La confusión aparece cuando alguien trata el guardrail como prueba de calidad. La puntuación media del guardrail es alta (la mayoría de los requests pasa), y eso lleva al equipo a pensar que 'todo está bien'. No lo está. El guardrail mide seguridad y conformidad; el eval mide calidad. Son dos ejes distintos, ambos necesarios.
Puntos fuertes
- bloquea ataques conocidos antes de que lleguen al modelo, p. ej. injection simple y PII obvia
- conformidad rastreable: cada turno se vuelve un log de decisión, y la auditoría quiere una señal rápida cuando hay una violación
- componible: se pueden combinar varios guardrails en un pipeline, cada uno encargándose de una clase de riesgo
Limitaciones
- falso negativo ante ataques nuevos: la prompt injection evoluciona, y un detector entrenado en 2024 falla en 2026
- costo de latencia: cada capa síncrona adicional se ve en el SLA, y un pipeline de 5 guardrails empieza a parecer caro
- ceguera de calidad: bloquea lo peligroso, pero no mide si lo que pasó es bueno, y eso sigue siendo del eval
conexiones en el mapa
- Guardrails - filtros de entrada y salidafiltra entrada/salidaLLM - large language model
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Proteger al propio agentvibecodinglos mismos límites, aplicados al agente que escribe código
- Threat modeling: pensar como el atacante antes de programarappsecmapea lo que el agente no puede hacer
- Bot managementsecopsdistinguir automatización legítima de abuso vale también para los agentes
- IA en el triaje y la mitigaciónsecengel mismo cuidado con la entrada y la salida del modelo
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…