Un agente de IA que opera sin restricciones es como un piloto de carreras en pruebas sin frenos. La mayoría de las veces llega bien. Pero cuando algo falla — y algún día falla — lo hace rápido y caro. En la práctica hemos visto agentes que, al entrar en bucle durante la noche, generaron miles de llamadas a API y una factura de varios miles de euros; agentes que sobreescribieron datos de producción en lugar de los de prueba; y agentes que enviaron documentos internos a un endpoint externo intentando "ayudar". A todos esos casos les debería haber impedido ocurrir una sola cosa: los guardrails.
Los guardrails no son una excusa ni un bloqueador. Son las reglas de operación — como los interruptores automáticos en un cuadro eléctrico. Bien configurados, no ralentizan la producción. Si faltan, un solo fallo lo detiene todo. Este artículo descompone los guardrails en capas concretas y muestra qué implementar antes de llevar un agente a producción.
Por qué los guardrails no son opcionales
Un agente no es un chatbot. Un chatbot responde — como mucho envía texto mal redactado. Un agente actúa: llama a APIs, escribe en bases de datos, envía correos, ejecuta scripts, reserva recursos. Cada acción tiene un efecto secundario en el mundo real, fuera del LLM.
La mayoría de los incidentes de producción con agentes no surgieron porque el modelo "alucinara". Surgieron porque el modelo entendió correctamente la tarea, pero nadie restringió qué podía hacer al ejecutarla. Un atacante que conozca el prompt injection (lleva tiempo ocupando el primer puesto del OWASP LLM Top 10) puede ocultar instrucciones en contenido externo que el agente lee y ejecuta como comandos legítimos. Sin guardrails, el agente obedece.
Los guardrails son un sistema multicapa — no un filtro de salida puntual al final del pipeline. Cada capa captura un tipo de fallo diferente.
Capa 1: Validación de entradas
La primera línea de defensa está antes del propio LLM. Antes de que el agente reciba la consulta, hay que verificar:
- Longitud de la entrada — defina una longitud máxima de prompt. Entradas extremadamente largas pueden saturar el contexto, ocultar inyecciones o ralentizar el procesamiento.
- Saneamiento — elimine o escape HTML, caracteres especiales de SQL y metacaracteres de shell. Esto aplica también a textos que el agente lee de fuentes externas (páginas web, correos, documentos).
- Clasificación de intención — un clasificador ligero (puede ser un modelo pequeño o un conjunto de reglas regex) detecta si la entrada parece un intento manipulador (patrón de prompt injection, intento de jailbreak). Herramientas como
Lakera GuardoGuardrails AIresuelven esto out-of-the-box, pero incluso un conjunto de reglas propio con 20 patrones captura el 80 % de los intentos habituales. - Detección de PII — si el agente procesa entradas de usuarios, compruebe que la entrada no contiene datos sensibles (números de identificación fiscal, IBANs) que no deberían salir de su sistema.
En la práctica: la validación de entradas es barata (milisegundos, sin tokens de LLM) y captura ataques triviales antes de que lleguen al modelo.
Capa 2: Allowlist de acciones
Esta es la capa más importante para agentes con herramientas. Defina explícitamente qué acciones puede ejecutar el agente — y prohíba todo lo demás por defecto.
En concreto: cada herramienta (tool) que el agente puede llamar debe estar en la allowlist. No basta con que la herramienta exista en el código — tiene que estar registrada para ese contexto y rol de usuario. Ejemplo de estructura:
read_document(id)— permitido para todossearch_web(query)— permitido, pero solo para dominios aprobadossend_email(to, body)— permitido, pero solo para direcciones internas con@suempresa.eswrite_database(table, data)— permitido solo para tablas que no sean de produccióndelete_record(id)— prohibido; requiere aprobación humana
La allowlist no es solo un mecanismo de seguridad — también es documentación de lo que el agente hace realmente. Cuando un agente se comporta de forma inesperada, la allowlist es el primer lugar donde auditar.
Scope por sesión: no otorgue permisos globales. Cada sesión del agente recibe el alcance mínimo necesario (principio de mínimo privilegio). Un agente que analiza albaranes de entrega no necesita acceso a datos de RRHH.
Capa 3: Límites de ejecución (max_steps, presupuesto, tiempo límite)
Un agente en bucle sin techo es una receta para el incidente. Defina límites estrictos:
- `max_steps` — número máximo de pasos (iteraciones) en una sola ejecución. Rango recomendado para agentes en producción: 15–50 pasos según la complejidad. Al alcanzar el límite → parada limpia, no un crash.
- Tiempo límite — cada ejecución del agente debe tener un timeout. Si un agente ha estado corriendo 10 minutos en una tarea que debería durar 30 segundos, algo ha fallado. El timeout lo detecta antes de que lo detecte la factura.
- Límite de tokens / presupuesto — asigne a cada sesión un número máximo de tokens o un coste máximo de API. Para agentes con duración de ejecución variable, este es un techo más eficaz que
max_stepsa secas. Del orden de 0,50 €–5 € por sesión para la mayoría de los casos de uso es un máximo razonable. - Cap de reintentos — las llamadas a herramientas fallan. La lógica de reintento es necesaria, pero sin límite (p. ej., máximo 3 intentos por llamada a herramienta) el agente puede generar cientos de llamadas al mismo endpoint defectuoso.
LangGraph (estándar de facto para agentes con estado en producción) implementa estos límites de forma nativa mediante la configuración del grafo — max_recursion_limit, checkpointing, cuerpos de interrupción. La configuración es cuestión de minutos, no de días.
Capa 4: Sandbox y aislamiento
Si el agente ejecuta código, lanza comandos de shell o trabaja con el sistema de archivos, el aislamiento es obligatorio — no una funcionalidad opcional.
- Contenerización — el código que el agente genera y ejecuta debe correr en un contenedor aislado (Docker, gVisor) con permisos restringidos. No en el sistema anfitrión.
- Sistema de archivos de solo lectura — monte los datos de producción como read-only. El agente puede leer, no sobreescribir.
- Aislamiento de red — si el agente no necesita internet, bloquéelo. Si lo necesita, defina una allowlist de dominios (no internet abierto).
- Entorno efímero — cree un sandbox limpio para cada ejecución y destrúyalo al terminar. Sin estados compartidos entre sesiones.
Para agentes que ejecutan código en entornos industriales (scripting de PLC, configuración de dispositivos de red), esta capa es crítica — un error puede tener impacto físico.
Capa 5: Human-in-the-loop (HITL) y puertas de aprobación
No toda acción del agente requiere supervisión humana — eso negaría el sentido de la automatización. Pero algunas sí, y hay que identificarlas explícitamente.
Acciones típicas de alto riesgo que requieren aprobación: - Transacciones financieras por encima de un umbral definido - Envío de comunicaciones externas (correos a clientes, mensajes a socios) - Cambios en bases de datos o configuraciones de producción - Acciones con consecuencias irreversibles (borrado, despliegue)
LangGraph implementa HITL mediante interrupt() — el agente se detiene, espera la entrada humana (aprobación / rechazo / corrección) y continúa o finaliza según la respuesta. Esto no es "ralentizar" — es el kill-switch para acciones críticas.
Para los pasos habituales utilice el enfoque Human-on-the-loop: el agente corre de forma autónoma, pero cada paso queda registrado y accesible para revisión en tiempo real a través de la plataforma de observabilidad. El humano interviene solo cuando recibe una alerta o cuando quiere auditar.
El EU AI Act (art. 14) exige obligatoriamente supervisión humana para sistemas de IA de alto riesgo a partir del 2 de agosto de 2026 — la implementación de HITL no es solo una buena práctica, es una obligación legal para la categoría de sistemas relevante.
Capa 6: Validación de salidas
El filtro de salida es la última red de seguridad antes de que el resultado del agente abandone el sistema o desencadene la siguiente acción.
- Validación de esquema — si el agente produce una salida estructurada (JSON, XML, parámetros para otro sistema), valídela contra el esquema antes de usarla. Un JSON malformado puede derribar el sistema downstream.
- Filtro de contenido — detecte contenido potencialmente dañino (PII en la respuesta, información corporativa sensible, patrones no deseados).
- Comprobación de fidelidad — si el agente trabaja con documentos (RAG), verifique que la respuesta no proceda de "la nada". Heurísticas sencillas (presencia de citas, puntuación de confianza) o LLM-as-judge capturan las peores alucinaciones antes de entregar el resultado.
- Formato y longitud — si la salida va a otro sistema, verifique que no supera sus límites (máximo de tokens, tamaño máximo de archivo).
Herramientas como NeMo Guardrails (NVIDIA) o Guardrails AI permiten definir estas validaciones de forma declarativa — se añade una definición yaml de reglas, no más código en el pipeline.
Kill-switch y parada de emergencia
Aunque todas las capas estén bien configuradas, necesita un mecanismo para detener el agente de forma inmediata. El kill-switch no es paranoia — es el fusible que (si todo va bien) nunca usará.
Implementación mínima de un kill-switch:
- Kill por sesión — cada ejecución del agente tiene un ID único; el operador puede detener la sesión mediante API o dashboard
- Pausa global — un interruptor que detiene todos los agentes a la vez (actualización forzada, incidente de seguridad)
- Circuit breaker — kill automático si la tasa de errores supera un umbral (p. ej., 20 % de llamadas a herramientas fallidas en 5 minutos → el agente se detiene y espera un reinicio manual)
- Monitor de recursos — si el agente consume más de X tokens o más de Y euros durante la ejecución, parada automática + alerta
El kill-switch debe funcionar incluso cuando el agente está en bucle — por lo tanto no puede implementarse únicamente como un paso dentro del bucle del agente. Debe ser un mecanismo externo (proceso watchdog, terminación de job en Kubernetes, parada de unidad systemd).
Cómo apilar la defensa en la práctica
Los guardrails no son un módulo único — son una combinación de capas que se complementan entre sí. Ninguna capa es infalible al cien por cien; su combinación reduce el riesgo de forma drástica:
- 1.Validación de entradas → captura inyecciones y sinsentidos antes del LLM
- 2.Allowlist de acciones → limita lo que el agente puede hacer
- 3.Límites de ejecución → evita el escalado descontrolado de costes y los bucles infinitos
- 4.Sandbox → aísla los efectos secundarios
- 5.Aprobación HITL → detiene las acciones de alto riesgo antes de ejecutarlas
- 6.Validación de salidas → captura los últimos problemas antes del impacto
- 7.Kill-switch → permite detenerlo todo en una emergencia
En un despliegue real no se implementa todo a la vez. Priorice según el riesgo del caso de uso: un agente de búsqueda interna en documentos necesita principalmente validación de entradas y filtro de salida. Un agente que tramita pedidos o envía contratos necesita el stack completo.
Antes de cada despliegue en producción recomendamos red-teaming: un intento sistemático de romper el agente con el propio equipo. Los guardrails que nadie ha probado son guardrails sobre el papel.
Guardrails y observabilidad — dos caras de la misma moneda
Los guardrails le protegen del incidente. La observabilidad le dice por qué estuvo a punto de ocurrir — y qué corregir. Sin tracing y logging a nivel de cada paso del agente, no dispone de los datos necesarios para mejorar los guardrails con el tiempo.
Plataformas como LangSmith, Langfuse (auto-hosteable sobre Postgres + ClickHouse) o Arize Phoenix capturan el diff de estado nodo a nodo de cada ejecución del agente. Cuando los guardrails intervienen, ve exactamente qué entrada los activó — y puede decidir si la intervención fue correcta o un falso positivo.
Este es el ciclo iterativo: los guardrails recopilan incidentes → la observabilidad analiza las causas → los guardrails se afinan. Sin este ciclo, los guardrails se estancan y, a medida que crece el alcance del agente, dejan de cubrir nuevos vectores.
Más en profundidad sobre la arquitectura human-in-the-loop — y sobre cómo implementar puertas de aprobación sin que el agente se convierta en un chatbot más lento.
Preguntas frecuentes
¿No basta con un filtro de salida al final del pipeline?
No. El filtro de salida solo captura malas salidas — pero el agente pudo haber ejecutado mientras tanto decenas de acciones con efectos secundarios reales (llamadas a API, escrituras en base de datos, correos enviados). Los guardrails deben bloquear las acciones antes de ejecutarlas, no solo filtrar el texto después.
¿El prompt injection es una amenaza real o solo un problema académico?
Una amenaza real en sistemas de producción. El OWASP LLM Top 10 la sitúa sistemáticamente en el primer puesto. El primer ataque zero-click documentado a través de contenido externo infectado (EchoLeak, Aim Security, 2025) demostró que el atacante ni siquiera necesita comunicarse directamente con el agente — basta con infectar un documento que el agente lea. Cualquier agente que procese contenido externo (webs, correos, archivos de terceros) es un vector potencial.
interrupt() de LangGraph — ¿cómo funciona técnicamente?
interrupt() es un mecanismo que pausa la ejecución del grafo en un punto definido, guarda el estado completo (checkpointing) y espera una entrada externa. La entrada puede llegar mediante una llamada a API, un webhook o una interfaz de usuario. Tras recibirla, el grafo retoma la ejecución desde el punto de interrupción — no desde el principio. Así el agente "recuerda" el contexto anterior a la aprobación y continúa fluidamente después.
¿Cómo definir qué acciones necesitan aprobación humana?
Un marco sencillo: una acción necesita aprobación si (1) es irreversible (borrado, despliegue, envío), (2) tiene impacto financiero por encima de un umbral definido, (3) afecta a una parte externa (cliente, socio, regulador), o (4) modifica sistemas de producción. Las lecturas internas, las búsquedas y la generación de borradores generalmente no requieren aprobación.
¿Cómo afectan los guardrails a la latencia del agente?
La validación de entradas y la allowlist son prácticamente gratuitas — milisegundos sin LLM. La puerta de aprobación HITL añade latencia según la velocidad del revisor humano — segundos a minutos, pero solo para acciones de alto riesgo. La validación de salidas (comprobación de esquema, heurísticas) también es rápida. La única capa potencialmente más lenta es LLM-as-judge para la comprobación de fidelidad — pero incluso aquí basta con un modelo económico (nivel Haiku) para la verificación, no hace falta un modelo frontier.
Conclusión
*Los guardrails no son un freno para los agentes de IA — son las condiciones bajo las cuales se puede confiar en ellos en un entorno de producción. Sin ellos, cada agente es un experimento, no un producto. Si está considerando desplegar agentes de IA en su empresa o quiere verificar si los guardrails existentes son suficientes, estaremos encantados de evaluar su caso de uso concreto y proponer un esquema de defensa por capas ajustado al riesgo real.*