Pedirle al modelo que no haga algo no es un control. Un guardrail es una barrera fuera del modelo: permisos, validaciones, listas, revisión humana y límites de acción.
Entrada
Antes de que el texto llegue al modelo, puedes comprobar varias cosas. Si el mensaje contiene datos personales que no deberían procesarse, si intenta manipular las instrucciones del sistema, si incluye contenido prohibido o si viene de un canal que no está permitido. Esa comprobación no la hace el modelo: la hace tu sistema.
La inyección de prompts es el caso más conocido. Alguien escribe «ignora las instrucciones anteriores» o mete esa frase dentro de un documento que el sistema va a leer. Si el contenido externo se trata como una instrucción, el ataque puede funcionar. La defensa es separar instrucciones de datos y no dar por buena ninguna orden que venga de una fuente no fiable.
Salida
La salida también se comprueba. Que el formato sea el esperado, que no incluya datos que el usuario no puede ver, que no prometa algo que la empresa no ofrece, que las citas existan. Si el sistema genera una respuesta para un cliente, la validación tiene que ocurrir antes de enviarla.
Los guardrails de salida no tienen que ser perfectos. Tienen que cubrir los fallos que más daño hacen. Una respuesta con un formato roto se puede reintentar. Una respuesta con un dato confidencial no se puede deshacer.
Acciones
El guardrail más importante está en las acciones. Qué puede leer el sistema, qué puede escribir y qué necesita confirmación. Una lista de herramientas permitidas, un límite de importe, una comprobación de identidad o una aprobación humana antes de cancelar un pedido. Eso no se controla con un prompt.
También importa la reversibilidad. Una acción reversible se puede probar con más margen. Una acción irreversible, como enviar un pago o borrar una cuenta, necesita más control. Cuanto más difícil es deshacer, más alta tiene que ser la barrera.
Defensa en profundidad
Un solo guardrail no basta. Combina instrucciones claras, permisos mínimos, validaciones de entrada y salida, límites de acción y revisión humana. Si una capa falla, otra puede parar el daño. La seguridad se compone de permisos, validación y límites de acción.
Tampoco confíes solo en el modelo para detectar sus propios errores. Un modelo puede decir que ha comprobado algo cuando no lo ha hecho. Las comprobaciones importantes tienen que estar en código, no en la conversación.
Falsos positivos
Un guardrail demasiado agresivo bloquea casos legítimos y enfada a la gente. Si el sistema rechaza una pregunta normal porque contiene una palabra sensible, el usuario pierde confianza. Hay que medir cuántos casos bloquea, cuántos son realmente peligrosos y cuántos son falsos positivos.
La calibración es continua. Los ataques cambian y los casos legítimos también. Revisa los bloqueos, ajusta las reglas y deja una vía para que una persona revise lo que el sistema no deja pasar.
Revisión humana
La revisión humana no es un guardrail de última hora. Es una parte del diseño. Decide qué casos necesitan una persona, cuánto tiempo puede esperar y qué información tiene que ver. Una cola de revisión sin contexto es tan mala como una respuesta automática equivocada.
El objetivo es mantener el riesgo dentro de un límite que el negocio pueda asumir, no eliminarlo. Un sistema que dice «esto no lo puedo hacer» y deriva bien vale más que uno que lo intenta todo y un día cruza una línea.
Un caso concreto: devoluciones
Un agente de devoluciones necesita tres barreras. Primero, comprobar la identidad y el pedido. Después, aplicar la política: qué se puede devolver, en qué plazo y por qué importe. Por último, confirmar antes de ejecutar la devolución. Si el importe supera un límite, si el pedido no aparece o si la política no cubre el caso, deriva a una persona.
La barrera no puede ser una frase en el prompt. Tiene que ser una comprobación en el código y un permiso en la herramienta. El modelo puede preparar la devolución, pero no debería tener la capacidad de ejecutarla sin pasar por esas comprobaciones. Así, un fallo del modelo no se convierte en un fallo del negocio.
Sigue leyendo