Definición
Los guardrails son los controles que rodean a un modelo para que, cuando se equivoque —y se va a equivocar—, el error no salga caro.
El nombre es el de las quitamiedos de la carretera, y la metáfora es exacta: no impiden que el coche se desvíe, impiden que el desvío acabe en el barranco. No hacen al modelo más listo; acotan las consecuencias de que no lo sea.
La idea de fondo: un modelo es un componente que falla de forma no determinista. Nunca vas a poder garantizar su salida. Lo que sí puedes garantizar es lo que el sistema hace con esa salida.
Dónde se ponen
Se ponen en cuatro sitios, y funcionan en capas:
A la entrada. Antes de que el texto llegue al modelo: límite de longitud, detección de contenido prohibido, comprobar que la petición viene de donde debe, cortar por número de peticiones por IP.
En las instrucciones. El system prompt con su alcance y sus reglas. Es el más blando de todos y no debe ser el único.
A la salida. Antes de enseñar la respuesta o de dársela a otro sistema: validar que el formato es el esperado, que la categoría está en la lista permitida, que no aparecen datos que no deberían, que no hay enlaces a sitios raros.
En la ejecución. El más importante. Qué herramientas puede llamar, con qué permisos y qué pide confirmación humana.
Ejemplo práctico
El asistente público del teléfono de aeworks.tech es un buen ejemplo porque es un endpoint abierto a internet que cuesta dinero en cada mensaje. Los controles, de fuera hacia dentro:
- Solo acepta POST y solo desde la propia web. Una comprobación de origen corta el uso del endpoint desde otra página.
- Cuerpo de la petición limitado a 4 KB. Nadie manda una novela.
- Campo trampa en el formulario. Es invisible para una persona; si viene relleno, es un robot. Se responde "gracias" y no se gasta ni una llamada al modelo.
- Topes por mensaje, por conversación, por IP y hora, y por IP y día. Sin eso, cualquiera usa tu web como chatbot gratis a tu costa.
- La IP nunca se guarda en claro, solo un hash con sal que cambia cada día.
- El modelo no tiene herramientas. Conversa y nada más.
- La única "acción" es escribir una marca al final del mensaje cuando ya tiene un contacto; el servidor la detecta y crea el aviso.
Ninguno de esos siete controles depende de que el modelo se porte bien. Esa es la prueba de que son guardrails de verdad y no buenas intenciones.
Guardrails que funcionan y guardrails de mentira
Funcionan:
- Validar la salida contra un esquema en código.
- Comprobar permisos en el servidor, con la sesión del usuario.
- Lista blanca de acciones permitidas.
- Confirmación humana para lo irreversible.
- Topes de gasto y de frecuencia.
- Registro de entradas y salidas.
No funcionan solos:
- Pedirle al modelo que no haga algo.
- Filtrar palabras prohibidas.
- Confiar en que el formato de salida siempre será el pedido.
- Suponer que el usuario no va a intentarlo.
La regla para distinguirlos: si la barrera depende de que el modelo colabore, no es una barrera.
Errores comunes
- Poner todo el peso en el prompt. Es la capa más fácil de escribir y la más fácil de romper, con prompt injection o simple insistencia.
- Guardrails tan estrictos que el producto no sirve. Un asistente que contesta "no puedo ayudarte con eso" a la mitad de las preguntas legítimas está roto, aunque sea muy seguro.
- No medir cuántos falsos positivos generas. Cada bloqueo tiene un coste en experiencia; hay que saber cuál es.
- Olvidar el coste. El tope de gasto es un guardrail, y de los que más disgustos evita.
- No registrar nada. Cuando pase algo raro —y pasará— sin registro no hay investigación posible.
Cuándo montarlos
Los de coste y frecuencia, desde el primer día en cualquier endpoint público: es lo que separa una demo de algo que puedes dejar encendido.
Los de ejecución, en cuanto le des al modelo la capacidad de hacer algo más que escribir texto.
Los de salida, en cuanto otra parte del sistema consuma esa salida sin que una persona la mire por el camino.
