En el post anterior blindamos el system prompt. Ahora añadimos la última barrera: un filtro de salida que decide si la respuesta es utilizable, si requiere corrección o si debe reemplazarse por una versión segura.

¿Qué es un guardrail de salida?

Es un pipeline determinista que recibe la salida del LLM y ejecuta validaciones y transformaciones antes de entregar o actuar. Su objetivo es bloquear o corregir respuestas que violen formato, políticas o seguridad.

• Formato: JSON válido, HTML sanitizado, longitudes máximas.
• Seguridad: PII/secretos, contenido prohibido, instrucciones peligrosas.
• Cumplimiento: tono/idioma requeridos, citas si aplica, contratos de salida.

Checklist de validación de salida

• Contrato de salida: JSON Schema o function calling (prohíbe texto extra).
• Tipos y rangos: fechas ISO, enums, máximos de longitud, listas no vacías si son requeridas.
• PII/Secretos: emails, teléfonos, tarjetas, claves/tokens/ARNs/URLs internas → redactar o bloquear.
• Contenido: categorías de riesgo (violencia, hate, sexual, autolesión, etc.).
• HTML (si aplica): sanitize/escape, allowlist de tags/atributos, bloquea JS.
• Política de citas (RAG): si no hay evidencia suficiente → exigir abstención.

Estrategia en tres pasos

1. Validar: contrato (schema/gramática), longitud, categorías de riesgo, PII/secretos.
2. Corregir: autocorrecciones acotadas (comillas/comas), redacción de PII, sanitización HTML.
3. Decidir:
   • approved → entregar/ejecutar.
   • retry → reintentar con errores concretos (1 intento).
   • safe_response → plantilla segura y pedir más contexto.
   • block → registrar y notificar para revisión humana.

// Ejemplo de veredicto de salida
{
  "status": "approved|retry|safe_response|block",
  "errors": ["schema.missing_field: citations", "policy.pii: email detectado"],
  "output": { ... } // solo si approved o safe_response
}

Micro-workflow en n8n: “Filtro de salida”

1. Webhook → recibe {request_id, candidate_output} desde tu backend.
2. Function → valida JSON Schema / gramática y límites (longitud, enums).
3. Function → detector de PII/secretos y clasificador de riesgo (rápido).
4. IF → si schema ok y sin riesgo → approved.
5. IF → si hay errores reparables → retry (manda diff exacto al LLM).
6. IF → si hay PII/HTML → safe_response (redacta/sanitize y añade aviso).
7. Else → block + notificación y registro para auditoría.
8. Database → guarda status, errores, costo, latencia y versión de schema.

Plantillas útiles

1) Reintento guiado por errores

Rol: Reparador de formato.
Tarea: Corrige SOLO los errores listados sin cambiar el contenido.
Errores:
- Falta campo "citations"
- "date_iso" no cumple YYYY-MM-DD
Salida: SOLO JSON válido según el esquema.
Entrada (JSON actual):
{CANDIDATE}

2) Respuesta segura (fallback)

{
  "answer": "No puedo mostrar ciertos datos. Aquí tienes una versión segura de la información solicitada.",
  "notes": ["Se ocultó PII", "Se acortó la longitud para cumplir política"]
}

Tips para Laravel/PHP

• Validación JSON: usa json_validate() (PHP ≥8.3) y luego json_decode(..., associative:true, flags: JSON_THROW_ON_ERROR).
• Schema: valida con rules de Validator (tipos, date_format:Y-m-d, in:, array|min:1).
• PII/secretos: regex/heurísticas → enmascara y agrega reason_codes a logs.
• HTML: pasa por un sanitizador (allowlist de tags/attrs) o devuelve solo texto plano.
• Telemetría: tabla llm_guardrails con {request_id,status,errors[],schema_version,lat_ms,cost_usd}.

Errores comunes (y cómo evitarlos)

• Aceptar texto libre cuando exiges JSON → define y aplica Schema/gramática.
• Intentar “arreglarlo todo” en post → solo autocorrecciones mínimas; si no, reintento o safe.
• Ignorar PII/secretos en plantillas y ejemplos → demuestra el formato correcto.
• No registrar decisiones → sin auditoría no puedes mejorar umbrales ni explicar incidentes.

Conclusión

Un buen sistema no solo “pide bien”, también entrega bien. Con guardrails de salida controlas formato, seguridad y cumplimiento, y aseguras que nada llegue a usuarios o APIs sin pasar la última inspección.

← Anterior: Sistema de instrucciones de hierro: diseña prompts imposibles de romper

Siguiente: Cómo detectar y manejar alucinaciones en modelos de lenguaje →