IA agentiva en producción: guardrails, bucles de eval y la arquitectura de la confianza
Todos tienen una demo. Casi nadie tiene un despliegue. La brecha entre una IA agentiva que impresiona en una grabación de pantalla y una que sobrevive el tráfico de producción no es cuestión de prompt engineering -- es cuestión de arquitectura. Esta es una guía para construir sistemas agentivos que generan confianza a través de la estructura, no de la esperanza.
Tabla de Contenidos
Todos tienen una demo. Casi nadie tiene un despliegue.
La brecha entre una IA agentiva que impresiona en una grabación de pantalla y una que sobrevive el tráfico de producción no es cuestión de prompt engineering. Es cuestión de arquitectura. Las demos toleran alucinaciones porque un humano está observando. Producción no tiene ese lujo. Producción tiene reintentos, casos límite, inputs adversarios y un teléfono de guardia a las tres de la mañana.
Llevamos construyendo sistemas impulsados por IA desde que el aprendizaje automático significaba más que marketing. Hemos desplegado flujos de trabajo agentivos -- sistemas que usan herramientas, ejecutan múltiples pasos y toman decisiones -- en entornos de producción donde los fallos tienen consecuencias. No consecuencias de tipo «la salida fue rara». Consecuencias financieras. Consecuencias regulatorias.
Este artículo trata sobre lo que aprendimos. No es un tutorial para construir un chatbot. Es una guía de arquitectura para construir sistemas agentivos que generan confianza a través de la estructura, no de la esperanza.
I. Qué significa realmente «agentivo» en producción
La palabra «agentivo» se ha estirado para cubrir desde un wrapper de ChatGPT hasta un pipeline de despliegue de código completamente autónomo. Eso no es útil. Esta es una definición útil:
Un sistema agentivo es aquel en el que un modelo de lenguaje toma decisiones que afectan el estado más allá de la conversación. Lee datos, razona sobre opciones, selecciona acciones, ejecuta herramientas, observa resultados y decide qué hacer después -- en un bucle.
La frase clave es «afecta el estado más allá de la conversación». Un chatbot que sugiere consultas SQL es asistencial. Un sistema que escribe y ejecuta esas consultas contra una base de datos de producción es agentivo. La diferencia no es sofisticación. Es radio de impacto.
IA asistencial IA agentiva
+------------------+ +------------------+
| Usuario pregunta | | Usuario pregunta |
| Modelo sugiere | | Modelo planifica |
| Humano ejecuta | | Modelo ejecuta |
| Humano verifica | | Modelo verifica |
+------------------+ | Modelo itera |
| Humano aprueba |
+------------------+Una vez que se acepta esa distinción, los requisitos de arquitectura cambian por completo. Se necesitan guardrails. Se necesitan bucles de eval. Se necesita un protocolo para el acceso a herramientas. Se necesitan patrones de human-in-the-loop que no sean improvisaciones de último momento.
II. El bucle de eval: la única fuente de verdad
En el software tradicional se escriben tests. En los sistemas agentivos se escriben evals.
La diferencia es sutil pero estructural. Un test afirma que una función devuelve un valor específico para una entrada específica. Un eval afirma que un sistema probabilístico produce salidas aceptables a través de una distribución de entradas. Los tests son binarios. Los evals son estadísticos.
Qué evaluar
Cada ruta del modelo en el sistema necesita cobertura de eval. No «el modelo» -- cada ruta. Si el modelo puede tomar tres secuencias de acciones diferentes para completar una tarea, cada secuencia necesita cobertura.
- Tasa de completitud de tareas: ¿El agente realmente cumple lo que se le pidió?
- Precisión en la selección de herramientas: ¿Elige las herramientas correctas para el trabajo?
- Adherencia a restricciones: ¿Se mantiene dentro de los límites definidos?
- Degradación controlada: Cuando falla, ¿falla de manera segura?
- Costo por tarea completada: ¿Cuánto cuesta realmente una completitud correcta?
El framework de eval
Construirlo como CI. Ejecutarlo en cada cambio de modelo, cada cambio de prompt, cada cambio de esquema de herramientas. El framework debe:
- Mantener un dataset curado de tareas representativas (no solo las fáciles).
- Ejecutar cada tarea contra el agente en un entorno sandboxed.
- Puntuar las salidas contra rúbricas -- tanto automatizadas (validación de esquema, verificación de restricciones) como LLM-as-judge para calidad.
- Rastrear métricas a lo largo del tiempo. Las regresiones son el enemigo.
- Bloquear el despliegue cuando la calidad cae por debajo de los umbrales.
# Estructura simplificada del bucle de eval
for task in eval_dataset:
result = agent.execute(task.input, sandbox=True)
scores = {
"completed": judge_completion(result, task.expected),
"safe": judge_safety(result, task.constraints),
"cost": result.total_tokens * cost_per_token,
"latency": result.wall_time_ms,
}
eval_log.append({"task": task.id, **scores})
report = aggregate(eval_log)
assert report["completion_rate"] >= 0.95
assert report["safety_rate"] >= 0.99
assert report["p95_cost"] <= budget_per_task
Esto no es opcional. Si no se evalúa al agente, no se sabe qué hace el agente. Se tiene una demo, no un sistema.
LLM-as-judge: usarlo, pero calibrarlo
Usar un modelo para evaluar a otro es poderoso, pero circular si se hace sin cuidado. Calibrar el juez contra calificaciones humanas. Medir la concordancia. Rastrear la deriva del juez. Y nunca usar la misma instancia de modelo como actor y juez en la misma eval -- eso es corregir el propio examen.
III. Guardrails: estructurales, no aspiracionales
Un guardrail no es un prompt del sistema que dice «por favor no hagas nada peligroso». Un guardrail es una restricción estructural que hace que las acciones peligrosas sean imposibles o reversibles.
Guardrails de entrada
Antes de que el modelo vea una solicitud:
- Validación de esquema: Cada entrada se ajusta a un esquema definido. Rechazar solicitudes malformadas antes de que lleguen al modelo.
- Clasificación de intención: Un clasificador ligero (o incluso regex) marca las solicitudes que están fuera de alcance. El agente debe rechazar con gracia, no intentar heroicidades.
- Detección de PII: Si el dominio de la tarea no requiere datos personales, eliminarlos antes de que el modelo los vea.
Guardrails de salida
Después de que el modelo produce un plan de acción, antes de la ejecución:
- Allowlisting de acciones: El agente solo puede llamar a herramientas que están explícitamente registradas. Sin descubrimiento dinámico de herramientas en producción.
- Validación de parámetros: Cada llamada a herramienta se valida contra el esquema de la herramienta. Un modelo que alucina un nombre de parámetro recibe un error estructurado, no un crash en tiempo de ejecución.
- Rate limiting: Limitar el número de llamadas a herramientas por tarea. Un agente en un bucle de reintentos es un agente quemando dinero.
- Compuertas de human-in-the-loop: Para acciones de alto riesgo (eliminar datos, enviar dinero, publicar contenido), requerir aprobación humana explícita antes de la ejecución.
El kill switch
Cada agente en producción necesita uno. Un mecanismo para detener la ejecución a mitad de tarea, preservar el estado y transferir el control a un humano. Esto no es un modo de fallo. Es un requisito de diseño. El kill switch debe ser accesible vía API, dashboard y herramientas de guardia.
IV. MCP: la capa de protocolo para la integración de herramientas
El Model Context Protocol (MCP) es la forma en que conectamos los sistemas agentivos a las herramientas que necesitan. No es el único enfoque, pero es el que usamos en producción, y con buena razón.
Por qué MCP en lugar de function calling ad-hoc
Antes de MCP, la integración de herramientas significaba cablear manualmente esquemas JSON para cada herramienta, gestionar la autenticación por integración y esperar que el formato de function calling del modelo coincidiera con las expectativas del backend. Cada nueva herramienta era una integración a medida.
MCP estandariza esto. Define un protocolo para:
- Descubrimiento de herramientas: El agente consulta a un servidor sobre las herramientas disponibles y sus esquemas.
- Invocación: Solicitudes estructuradas con parámetros tipados y respuestas estructuradas.
- Acceso a recursos: Acceso de lectura a fuentes de datos (archivos, bases de datos, APIs) a través de una interfaz uniforme.
- Límites de seguridad: El servidor controla a qué puede acceder el agente. El agente no obtiene credenciales en bruto.
Agente Servidor MCP Herramientas
+-------+ +-----------+ +--------+
| Plani-|--tools/-->| Validar |--invoke-->| BD |
| ficar | list | Autorizar | | API |
| llam. |<--result--| Auditar |<--result--| Arch. |
+-------+ +-----------+ +--------+MCP como límite de seguridad
Este es el beneficio subestimado. El servidor MCP es un punto de control. Cada invocación de herramienta pasa a través de él. Eso significa que se puede:
- Auditar cada acción que toma el agente, con logging completo de request/response.
- Limitar las llamadas a herramientas por agente, por usuario, por tarea.
- Acotar el acceso a herramientas por tipo de tarea. Un agente de resumen no necesita acceso de escritura a la base de datos.
- Rotar credenciales sin tocar al agente. El servidor MCP guarda los secretos; el agente no guarda nada.
En nuestros sistemas de producción, el servidor MCP es el componente de seguridad más importante. No el modelo. No el prompt. El servidor que se interpone entre las intenciones del modelo y el estado del mundo.
El patrón de configuración MCP
Una configuración típica de MCP en producción:
{
"mcpServers": {
"database": {
"command": "mcp-server-postgres",
"args": ["--read-only", "--connection", "$DB_URL"],
"env": { "DB_URL": "postgres://..." }
},
"filesystem": {
"command": "mcp-server-filesystem",
"args": ["--allowed-dirs", "/data/reports"]
},
"api": {
"command": "mcp-server-http",
"args": ["--base-url", "https://api.internal"],
"env": { "API_KEY": "..." }
}
}
}Cada servidor está acotado. Cada servidor es auditable. El agente ve herramientas, no infraestructura.
V. Human-in-the-loop: no una ocurrencia tardía
La expresión «human-in-the-loop» se invoca a menudo como un talismán -- como si mencionarlo hiciera seguro un sistema. No lo hace. La supervisión humana es un problema de ingeniería, no una casilla de verificación.
Tres patrones que funcionan
Aprobación por compuerta. Las acciones de alto riesgo requieren aprobación humana explícita antes de la ejecución. El agente propone una acción, se pausa y espera. Un humano revisa la propuesta en contexto (qué vio el agente, qué planea hacer, por qué) y aprueba o rechaza. Esto funciona para acciones de baja frecuencia y alta consecuencia: transferencias financieras, eliminación de datos, publicación de contenido.
Revisión por muestreo. Para acciones de alta frecuencia y consecuencia moderada, revisar una muestra estadística. El agente ejecuta de forma autónoma, pero un porcentaje de las acciones se marcan para revisión humana posterior. Si la tasa de error supera un umbral, el sistema escala al modo de aprobación por compuerta. Así se escala la supervisión sin crear cuellos de botella en el rendimiento.
Cascada de escalación. El agente intenta una tarea. Si la confianza está por debajo de un umbral, escala a un agente más capaz o a un humano. Si el segundo agente también es incierto, escala más. Esto crea un triaje natural: las tareas rutinarias se manejan de forma autónoma, los casos límite reciben atención humana.
Tarea llega
|
+----v-----+
| Agente L1 |--confianza >= 0.95--> Ejecutar
+----+------+
| confianza < 0.95
+----v-----+
| Agente L2 |--confianza >= 0.90--> Ejecutar
+----+------+
| confianza < 0.90
+----v-----+
| Humano |--> Revisar y decidir
+-----------+La interfaz importa
Un revisor humano que ve «El agente quiere ejecutar la herramienta X» sin contexto aprobará o rechazará aleatoriamente. La supervisión humana efectiva requiere:
- La tarea que desencadenó la acción.
- La cadena de razonamiento del agente (abreviada, no el flujo completo de tokens).
- La acción propuesta con sus parámetros.
- El impacto esperado («esto actualizará 3 registros en la tabla de cuentas»).
- Aprobar/rechazar con un clic con retroalimentación opcional que se incorpora al dataset de eval.
VI. Modos de fallo y cómo sobrevivirlos
Los sistemas agentivos fallan de maneras en que el software tradicional no lo hace. Comprender la taxonomía de fallos es la mitad de la batalla.
La espiral de reintentos
El agente llama a una herramienta. La herramienta devuelve un error. El agente reintenta. La herramienta devuelve el mismo error. El agente reintenta con parámetros ligeramente diferentes. Sigue fallando. El agente intenta un enfoque diferente que también falla. Veinte llamadas a herramientas después, el presupuesto de la tarea se agotó y nada útil sucedió.
Solución: Establecer un presupuesto máximo de llamadas a herramientas por tarea. Cuando el presupuesto se agota, el agente debe resumir lo que intentó, lo que falló y escalar. No dejar que los agentes iteren indefinidamente.
La herramienta alucinada
El modelo inventa una herramienta que no existe, o llama a una herramienta real con parámetros alucinados. Esto es especialmente común cuando los modelos se entrenan con patrones de llamadas a herramientas de otros entornos.
Solución: Validación estricta de esquema en cada llamada a herramienta. Si el nombre de la herramienta no está en el registro, devolver un error estructurado. Si los parámetros no coinciden con el esquema, devolver un error estructurado con el esquema correcto. El agente puede autocorregirse, pero solo con retroalimentación honesta.
La respuesta incorrecta con alta confianza
El fallo más peligroso. El agente completa una tarea, reporta éxito y la salida es incorrecta. No se generó ningún error. No se activó ningún guardrail. El agente simplemente cometió un error que parecía correcto.
Solución: Para esto existen los bucles de eval. No se puede capturar cada caso en tiempo real, pero se puede medir la tasa estadísticamente y establecer umbrales. Para dominios de alto riesgo, requerir validación de salida -- un segundo modelo, un verificador basado en reglas o un revisor humano -- antes de que el resultado se confirme.
El colapso de la ventana de contexto
Los agentes de larga ejecución acumulan contexto. Eventualmente la ventana de contexto se llena y el modelo comienza a perder instrucciones, restricciones o estado anteriores. El agente se vuelve poco confiable sin ninguna señal de error obvia.
Solución: Diseñar para contexto acotado. Dividir tareas largas en subtareas. Resumir el estado intermedio explícitamente. Usar memoria externa (bases de datos, archivos) en lugar de confiar en que la ventana de contexto lo retenga todo. La ventana de contexto es memoria de trabajo, no almacenamiento a largo plazo.
VII. La lista de verificación para producción
Antes de que un sistema agentivo entre en producción, verificar:
Cobertura de eval. Cada ruta del modelo tiene cobertura de eval. La tasa de completitud, la tasa de seguridad y el costo por tarea están medidos y con línea base establecida.
Los guardrails son estructurales. Validación de entrada, validación de salida, allowlisting de acciones, rate limiting. No solo instrucciones en el prompt.
El acceso a herramientas está acotado. Cada agente tiene acceso exactamente a las herramientas que necesita, con los permisos mínimos requeridos. Los servidores MCP imponen los límites.
La supervisión humana está diseñada. Aprobación por compuerta para acciones de alto riesgo. Revisión por muestreo para acciones rutinarias. Rutas de escalación para casos inciertos.
El kill switch existe y está probado. La capacidad de detener cualquier agente a mitad de ejecución, preservar el estado y transferirlo a un humano.
El monitoreo es consciente del agente. Los dashboards muestran tasas de llamadas a herramientas, tasas de error, tasas de escalación, costo por tarea y distribuciones de latencia. Las alertas se activan ante anomalías.
El audit trail está completo. Cada llamada a herramienta, cada decisión del modelo, cada aprobación humana está registrada con marcas de tiempo, IDs de tarea y contexto de usuario. Se puede reconstruir exactamente lo que sucedió para cualquier tarea.
El presupuesto de fallos está definido. El sistema sabe cuántas llamadas a herramientas, cuánta latencia y cuánto costo puede consumir una tarea individual. Exceder el presupuesto activa la degradación controlada, no reintentos infinitos.
VIII. La realidad regulatoria
La EU AI Act no es hipotética. Las reglas de uso prohibido entraron en vigor el 2 de febrero de 2025. Las obligaciones para IA de propósito general se hicieron aplicables el 2 de agosto de 2025. Las reglas para sistemas de alto riesgo se implementan progresivamente durante 2026-2027.
Si el sistema agentivo toma decisiones que afectan a personas -- contratación, préstamos, seguros, salud, educación -- probablemente se opera en territorio de alto riesgo. La ley requiere:
- Evaluación y mitigación de riesgos.
- Gobernanza de datos y documentación.
- Documentación técnica incluyendo arquitectura del sistema.
- Logging y trazabilidad.
- Mecanismos de supervisión humana.
- Medidas de precisión, robustez y ciberseguridad.
La arquitectura descrita en este artículo -- bucles de eval, guardrails, audit trails, human-in-the-loop, acceso acotado a herramientas -- no es solo buena ingeniería. Es la base técnica para el cumplimiento regulatorio. Si se construyen estas estructuras ahora, la documentación de cumplimiento se escribe sola. Si no, habrá que adaptarse bajo presión de plazos.
IX. De la demo al despliegue
El camino de «demo impresionante» a «sistema en producción» está pavimentado con el trabajo aburrido: frameworks de eval, validación de esquema, logging de auditoría, kill switches y flujos de revisión humana. Nada de ello es glamoroso. Todo es estructural.
Construimos sistemas agentivos cada día. Usamos Claude, Gemini y modelos abiertos como componentes de runtime. Los conectamos a bases de datos de producción, sistemas de archivos y APIs a través de MCP. Evaluamos cada ruta del modelo. Controlamos cada acción de alto riesgo. Registramos todo.
El resultado no es un sistema que nunca falla. Es un sistema donde el fallo es acotado, observable y recuperable. Esa es la arquitectura de la confianza. No un modelo que siempre acierta -- ningún modelo lo hace -- sino un sistema que sabe cuándo se equivoca y tiene la disciplina estructural para detenerse, reportar y escalar.
La IA agentiva es real. Las capacidades son genuinamente nuevas. Pero la disciplina de ingeniería necesaria para desplegarlas de forma segura es genuinamente antigua. Es la misma disciplina que mantiene el dinero seguro en los libros contables, que mantiene los aviones en el aire con sistemas redundantes, que mantiene los puentes en pie con márgenes de seguridad.
La confianza no es una funcionalidad que se agrega. Es el residuo de una arquitectura que asume el fallo y construye para la recuperación. Los modelos seguirán mejorando. La arquitectura de la confianza no se volverá opcional.
Referencias
- Anthropic. Building Effective Agents. docs.anthropic.com
- Model Context Protocol. MCP Specification. spec.modelcontextprotocol.io
- European Parliament. EU AI Act. artificialintelligenceact.eu
- Anthropic. Claude Model Card. docs.anthropic.com
- OpenAI. Function Calling Guide. platform.openai.com
- Google DeepMind. Gemini Technical Report. deepmind.google
- Brundage, M. et al. (2020). Toward Trustworthy AI Development: Mechanisms for Supporting Verifiable Claims. arXiv:2004.07213.
- Shinn, N. et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS.
- Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR.
- Park, J.S. et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST.
- NIST. AI Risk Management Framework. nist.gov
- ISO/IEC 42001:2023. AI Management System Standard.
