Generar y publicar son privilegios distintos
Una arquitectura útil asume que el modelo se equivocará a veces. Permite que proponga archivos, metadatos y cambios, pero no que el mismo paso los publique en silencio. Un límite separado de build y review hace visibles y reversibles los fallos.
Limita las entradas
Entrega fuentes identificadas en lugar de contexto ilimitado. Separa hechos autoritativos del producto, ejemplos, discusión histórica y contenido de usuarios. Registra qué archivos o respuestas API alimentaron una revisión.
Eso mejora reproducibilidad y review.
Valida estructura de forma determinista
Usa schemas para frontmatter, vocabularios controlados para tags y terminología, y parsers para bloques de código. Comprueba links, imágenes, localizaciones y metadatos antes de cualquier revisión con modelo.
Las comprobaciones deterministas deben fallar rápido.
Trata texto externo como input no confiable
Issues, foros, páginas web y mensajes de clientes pueden contener instrucciones irrelevantes o hostiles. Extrae información, pero no permitas que redefinan las reglas del agente ni la política editorial.
Exige evidencia para afirmaciones de riesgo
Seguridad, límites, compatibilidad, billing, datos y operaciones destructivas requieren revisión reforzada. Enruta esos cambios a un owner aunque el texto sea impecable.
Mantén rollback
Todo cambio automático debe ser una revisión normal en control de versiones con un diff claro. Evita procesos que mutan contenido publicado sin commit o artefacto rastreable.
Los guardrails permiten aumentar throughput sin reducir responsabilidad.
Ejemplo aplicado
Prueba «Guardrails para un pipeline LLM que publica documentación técnica» con una muestra controlada antes de convertirlo en flujo de producción. Selecciona diez fragmentos cuyo estado correcto ya conozcas: algunos actuales, otros obsoletos, ambiguos y deliberadamente incorrectos. Mantén las instrucciones fijas y registra tanto los aciertos como los errores expresados con confianza.
Revísalo como editor:
- ¿separa la evidencia de la inferencia?
- ¿conserva terminología y restricciones del producto?
- ¿inventa hechos o disimula la incertidumbre?
- ¿puede un humano ver qué cambió y por qué?
La pregunta útil no es si el modelo escribe con fluidez, sino si el flujo hace visibles los errores antes de publicar. La automatización gana confianza cuando sus límites, entradas y puntos de revisión son explícitos.
Lista rápida de revisión editorial
- Generar y publicar son privilegios distintos. Una arquitectura útil asume que el modelo se equivocará a veces.
- Limita las entradas. Entrega fuentes identificadas en lugar de contexto ilimitado.
- Valida estructura de forma determinista. Usa schemas para frontmatter, vocabularios controlados para tags y terminología, y parsers para bloques de código.
- Trata texto externo como input no confiable. Issues, foros, páginas web y mensajes de clientes pueden contener instrucciones irrelevantes o hostiles.
