21 · Guardrails y seguridad
Una llamada al modelo está entre una entrada no confiable y un usuario que confiará en la salida. Los guards de entrada redactan PII y rechazan temas prohibidos; los de salida validan el esquema y rechazan respuestas sin fundamento.
Los guardrails son chequeos deterministas que envuelven la llamada al modelo. Los guards de entrada redactan PII/secretos y rechazan temas prohibidos antes de enviar el prompt; los de salida validan la respuesta contra un esquema y rechazan respuestas que el contexto no respalda. Corren como código simple — rápido, auditable e independiente del modelo.
Sin esto:
Sin guardrails filtras emails de clientes en prompts y logs, respondes preguntas que legalmente no puedes y le entregas al usuario texto libre donde tu código espera JSON estricto.
El modelo es el componente menos confiable de tu stack: su entrada viene de un desconocido y su salida va a alguien que la creerá. Los guardrails son el código determinista que envuelves alrededor del modelo para hacer eso seguro. Se dividen en dos familias:
Guards de entrada (corren antes de la llamada):
- Redacción de PII / secretos — quita emails, teléfonos, claves API y números de tarjeta del texto del usuario antes de que entre al prompt y a tus logs. Reemplaza cada uno con un marcador como
[EMAIL]para que el modelo siga viendo la estructura. - Rechazo de temas prohibidos — si la petición coincide con una lista negra (violencia, consejo médico/legal sin licencia, intentos de inyección de prompt), rechaza sin llamar al modelo en absoluto.
Guards de salida (corren después de la llamada):
- Validación de esquema — si pediste JSON con claves específicas, parséalo y verifica la forma. Rechaza o reintenta ante salida malformada en vez de romper lo que viene después.
- Compuerta de fundamentación — niégate a mostrar una respuesta cuya groundedness (lección 20) esté por debajo de un umbral; mejor decir "no lo sé" que emitir una alucinación confiada.
La propiedad clave: los guardrails son código determinista simple (regex, parseo de JSON, pertenencia a conjuntos). Son rápidos, testeables y no dependen de que el modelo se comporte — justo lo que quieres en una frontera de seguridad.
Aquí hay un pipeline de guardrails compacto. El guard de entrada redacta emails, teléfonos y strings tipo clave-API con regex, luego revisa una lista negra de palabras prohibidas (rechazando de inmediato si coincide). El guard de salida valida que la respuesta del modelo sea JSON de la forma permitida. Lo corremos sobre tres entradas — una limpia, una con PII y una de tema prohibido — e imprimimos exactamente qué decidió cada guard.
Python (in browser)
La entrada 1 pasa limpia, la 2 se permite pero redactada (la PII nunca llega al modelo), la 3 se rechaza antes de llamar al modelo; el guard de salida rechaza el JSON malformado.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Librerías como Guardrails-AI y NeMo Guardrails te dejan declarar validadores (PII, toxicidad, esquema JSON) y conectarlos alrededor de la llamada — los mismos chequeos que corre nuestro pipeline hecho a mano.
Un mensaje de usuario contiene una palabra prohibida Y una dirección de email. ¿Qué debería hacer el pipeline de guardrails?
- Los guardrails son código determinista alrededor del modelo: guards de entrada (redactar PII, rechazar temas prohibidos) y guards de salida (validación de esquema, compuerta de fundamentación).
- Redacta PII/secretos antes de que entren al prompt o a los logs, y rechaza temas prohibidos antes de gastar una llamada al modelo.
- Valida la salida contra un esquema estricto y rechaza respuestas sin fundamento — nunca le entregues a tu código texto libre en el que no pueda confiar.
Todo endpoint de LLM en producción tiene guards de entrada/salida: limpiadores de PII, clasificadores de moderación, validadores de esquema JSON y umbrales de fundamentación, a menudo vía Guardrails-AI o NeMo Guardrails.
Si lo quitas: Sin guardrails filtras PII, respondes peticiones prohibidas o inyectadas y rompes ante salida malformada del modelo — los fallos que convierten un demo en un incidente.