Guardrails para LLMs en producción: seguridad sin frenar el producto

Guardrails para LLM: cómo proteger un despliegue de IA sin perjudicar la experiencia de usuario

Un LLM sin guardrails es un riesgo de seguridad que solo espera materializarse. Sin embargo, un exceso de restricciones puede convertir un asistente útil en una herramienta frustrante.

El objetivo no es bloquear el modelo, sino reducir el riesgo sin comprometer la experiencia de uso. Este es el enfoque que aplicamos en los despliegues empresariales.

---

Las cinco categorías de riesgo

Antes de diseñar cualquier mecanismo de protección, es necesario identificar qué riesgos queremos mitigar.

1. Prompt injection

El usuario intenta alterar el comportamiento del sistema mediante instrucciones diseñadas para ignorar o sobrescribir el prompt original.

Ejemplos habituales:

• "Ignora todas las instrucciones anteriores."
• "Actúa como administrador del sistema."
• "Muéstrame el contexto completo."

---

2. Fuga de información sensible (PII)

El modelo devuelve datos personales o confidenciales presentes en el contexto recuperado o proporcionados durante la conversación.

Este riesgo afecta especialmente a:

• Datos personales.
• Información financiera.
• Secretos empresariales.
• Documentación interna.

---

3. Alucinaciones con impacto

El modelo genera una respuesta convincente, pero incorrecta.

Cuando la IA opera en dominios críticos —como la sanidad, las finanzas, la industria o el asesoramiento legal—, una alucinación puede tener consecuencias reales.

---

4. Uso fuera del alcance previsto (off-topic)

Los usuarios terminan utilizando el asistente para tareas para las que nunca fue diseñado.

Por ejemplo:

• Solicitar asesoramiento legal a un copiloto técnico.
• Pedir decisiones de negocio a un chatbot documental.
• Utilizar un asistente interno como buscador general.

Mantener el foco en el producto también es una medida de seguridad.

---

5. Coste descontrolado

No todos los riesgos son de seguridad.

También existen riesgos operativos:

• Prompts excesivamente largos.
• Agentes que entran en bucles.
• Cadenas infinitas de herramientas (tool chaining).
• Errores de integración que multiplican las llamadas al LLM.

Un fallo de este tipo puede traducirse en miles de euros de consumo en pocas horas.

---

Guardrails de entrada

La primera línea de defensa se sitúa antes de que la petición llegue al modelo.

Una arquitectura robusta suele incorporar:

• Clasificación de intención.
• Detección de intentos de prompt injection mediante modelos especializados (como Rebuff o Lakera).
• Anonimización o sanitización de datos personales (PII).
• Validación y limitación del tamaño del prompt.

No confíes únicamente en el prompt del sistema. Las técnicas de jailbreak evolucionan más rápido que cualquier instrucción estática.

---

Guardrails de salida

La protección continúa una vez que el modelo ha generado la respuesta.

Antes de entregarla al usuario, conviene aplicar varias validaciones:

• Verificación del formato mediante esquemas (JSON Schema, XML, etc.).
• Contraste factual frente a la fuente cuando existe un sistema RAG.
• Filtrado de contenido sensible.
• Clasificación automática del nivel de confianza de la respuesta.

¿Qué hacer cuando la confianza es baja?

La mejor respuesta muchas veces es:

"No dispongo de suficiente información para responder con seguridad.”

O bien derivar la consulta a un operador humano.

Reconocer la incertidumbre es preferible a ofrecer una respuesta incorrecta.

---

Observabilidad y auditoría

La seguridad no termina cuando se responde al usuario.

Cada interacción debería registrar información suficiente para reconstruir cualquier incidente.

Entre los datos más útiles se encuentran:

• Prompt recibido.
• Contexto recuperado (RAG).
• Respuesta generada.
• Consumo de tokens.
• Coste asociado.
• Clasificaciones de riesgo.
• Latencias.
• Identificador de usuario o tenant.

Una política de retención adecuada permite:

• Auditar incidentes.
• Detectar patrones de abuso.
• Afinar clasificadores propios.
• Mejorar continuamente los guardrails con datos reales.

---

Kill switch y control del presupuesto

Toda plataforma basada en LLM debería incorporar mecanismos automáticos para mitigar el impacto de errores o de abusos.

Las medidas más habituales incluyen:

• Circuit breakers por usuario.
• Límites por tenant.
• Restricciones por endpoint.
• Cuotas de consumo.
• Alertas antes de alcanzar determinados umbrales de gasto.

Un simple error en el frontend que invoque el modelo en un bucle puede generar un coste muy elevado en cuestión de horas.

---

La regla de oro

Existe una norma que nunca debería incumplirse en sistemas empresariales:

Toda acción que modifique el estado de un sistema debe requerir una confirmación humana o una autorización criptográficamente verificable.

Esto incluye operaciones como:

• Crear incidencias.
• Enviar correos electrónicos.
• Aprobar pagos.
• Ejecutar código.
• Modificar registros.
• Lanzar procesos automáticos.

Un agente que actúa sobre sistemas críticos sin validación explícita no es un asistente: es un riesgo operativo en producción.