Guardrails: decide lo que la IA nunca debe hacer
Los guardrails convierten “el modelo no debería hacer eso” en reglas que el sistema hace cumplir. Cómo ponerlos en lo que entra, en lo que sale y en lo que la IA puede hacer, y cómo probarlos y mantenerlos como código.
La mayoría de los proyectos de IA ponen su energía en lo que el modelo debe hacer. Las decisiones que protegen al negocio tratan de lo que nunca debe hacer: responder fuera de su alcance, filtrar datos personales de alguien, inventar una política, prometer un descuento, enviar un mensaje que nadie aprobó. Escribir “por favor no lo hagas” en el prompt no basta. Un prompt es una guía que el modelo suele seguir. Un guardrail es una regla que el sistema hace cumplir, coopere el modelo o no.
Si lideras el equipo: qué preguntar
- ¿Qué no puede decir ni hacer esta función con IA, y dónde está escrita esa lista?
- Si un documento o un correo trae instrucciones escondidas, ¿puede cambiar lo que hace la IA?
- ¿Intentamos romper los guardrails a propósito, y esas pruebas corren en cada cambio?
Los guardrails van en tres lugares: en lo que entra, en lo que sale y en lo que la IA tiene permitido hacer.
Guardrails de entrada
- Alcance. Decide para qué es la función y rechaza lo demás temprano. Un asistente de soporte para tu producto no necesita escribir ensayos ni dar consejos médicos. Un clasificador simple o un conjunto de reglas delante del modelo puede desviar las peticiones fuera de alcance a una negativa amable o a una persona.
- Inyección de prompts. Cualquier texto que lea el modelo, de un usuario, un correo, un documento o una página web, puede contener instrucciones. Mantén las instrucciones del sistema separadas del contenido del usuario y del contenido recuperado, marca con claridad el contenido no confiable y nunca dejes que el texto de un documento cambie lo que el sistema tiene permitido hacer.
- Datos personales. Detecta y enmascara los datos personales antes de que lleguen al modelo cuando la tarea no los necesita, y antes de que lleguen a tus logs en todos los casos.
Guardrails de salida
- Esquema. Exige salidas estructuradas y valídalas. Una respuesta con campos faltantes o tipos equivocados se rechaza o se reintenta, nunca se muestra.
- Afirmaciones prohibidas. Haz una lista de lo que la IA nunca debe afirmar: precios o descuentos que no se le dieron, garantías, conclusiones legales o médicas, afirmaciones sobre competidores. Revisa las salidas contra esa lista con reglas, y con un segundo modelo donde la redacción varía.
- Citas obligatorias. Cuando la respuesta debe salir de tus documentos o datos, exige que la salida señale sus fuentes, y verifica que las fuentes citadas existan y digan lo que se afirma. Sin fuente, no hay respuesta.
- Reglas de negativa. Define cuándo el sistema dice “no puedo responder eso” o pasa el caso a una persona, y haz que esa respuesta sea clara y útil en vez de evasiva.
Guardrails de acción
Cuando la IA puede actuar, mediante herramientas, APIs o automatizaciones, los guardrails que más importan son los de las acciones:
- Listas de permitidos. El modelo solo puede llamar las herramientas y endpoints que tú enumeras, con parámetros validados en el código. Todo lo demás se niega por defecto.
- Aprobación para acciones con consecuencias. Enviar algo a clientes, cambiar registros oficiales, mover dinero o borrar cualquier cosa pasa primero por una persona o por una verificación estricta de reglas.
- Límites de tasa y de volumen. Pon un tope a cuántas acciones puede tomar una IA por ejecución, por usuario y por hora, para que un ciclo o un malentendido no se repita miles de veces.
Prueba los guardrails con ejemplos adversarios
Un guardrail que no has intentado romper es una suposición. Arma un conjunto de pruebas con entradas diseñadas para pasarlo: peticiones fuera de alcance dichas con amabilidad, instrucciones escondidas dentro de documentos, pedidos de datos personales, intentos de colar una afirmación prohibida con otras palabras, llamadas a herramientas con parámetros fuera de rango. Córrelo en cada cambio de prompts, modelos o reglas, y agrégale cada incidente real. Mide dos cosas: lo que pasó y lo que se bloqueó sin deber, porque bloquear de más también le cuesta a los usuarios.
Los guardrails son código
Mantén los guardrails en el repositorio, versionados, revisados y probados como cualquier otro código. Una lista de afirmaciones prohibidas editada en una hoja de cálculo, o un filtro cambiado directamente en producción, es una regla que nadie puede auditar. Cada guardrail debería tener un responsable, una razón para existir, pruebas que demuestren que funciona y una entrada en el log cada vez que se activa, para que veas qué reglas hacen trabajo real y cuáles son ruido.
Lista de guardrails
- Un alcance escrito, con las peticiones fuera de alcance desviadas antes del modelo.
- Instrucciones del sistema separadas del contenido del usuario y del recuperado.
- Datos personales enmascarados antes del modelo cuando no se necesitan, y siempre antes de los logs.
- Validación de esquema en cada salida.
- Una lista de afirmaciones prohibidas, revisada automáticamente.
- Citas obligatorias y verificadas donde las respuestas deben salir de tus datos.
- Listas de herramientas permitidas, aprobaciones para acciones con consecuencias, límites de tasa.
- Un conjunto de pruebas adversarias que corre en cada cambio.
- Guardrails versionados, revisados y registrados cuando se activan.
Para ver en qué punto están tus planes de IA frente a esto, haz el chequeo de preparación para IA.
Escrito a partir del trabajo de nuestros ingenieros en sistemas en producción. ¿Quieres una segunda opinión sobre tu proyecto? Habla con un ingeniero.
Ver el trabajo →