El problema central no es que un agente de IA no pueda planificar: es que nadie sabe cómo validar que lo que planificó es seguro, ejecutable y alineado con lo que vos realmente querés. Cuando construís un sistema donde un modelo de lenguaje decide qué código correr, qué API llamar o qué datos acceder, los obstáculos reales son cuatro: la máquina no puede validar si su propio output es correcto (hallucinations), no hay forma de verificar permisos sin un sistema de autorización robusto, los sandboxes modernos todavía tienen agujeros, y el modelo tiende a sobreestimar su confianza. Eso que ves en los demostratos bonitos de startup no existe en producción.
En 30 segundos
- Los agentes de IA no pueden ejecutar acciones fiables porque los modelos generan hallucinations: inventan funciones que no existen, parámetros incorrectos, o lógica defectuosa. Sin verificación externa, el código se corre igual.
- La ejecución requiere autorización granular (qué puede acceder cada agente, a qué recursos, con qué límites). La mayoría de implementaciones lo ignora o lo improvisa.
- Los sandboxes y entornos aislados típicos (containerización, control de permisos SO) siguen siendo vulnerables a inyecciones de prompt o exfiltración de datos.
- El modelo no sabe si falló. Si una API retorna un error o datos inesperados, el agente sigue adelante asumiendo éxito, generando cascadas de errores.
- La prueba más real es: si el agente necesita ejecutar SQL, ¿puede verificar que la query es correcta antes de correrla? La mayoría dirá que no.
Qué es un agente y qué significa “ejecución”
Un agente de IA es un sistema que toma una tarea de alto nivel, la descompone, planifica pasos concretos, y ejecuta acciones (llamadas de API, queries de base de datos, comandos de sistema operativo, escritura de archivos). La diferencia con un chatbot es que el chatbot te dá una respuesta de texto; el agente realmente hace cosas.
El flujo típico: (1) recibe un objetivo, (2) piensa qué pasos necesita, (3) llama una función o API, (4) ve el resultado, (5) decide si continúa o itera, (6) reporta el resultado final. Suena lógico, pero en la práctica se rompe en cada paso.
La barrera central: validación y alucinaciones
Ponele que le pedís a un agente que ejecute una query en Postgres. El modelo genera código SQL que parece correcto a primera vista. Vos lo ejecutás, y resulta que la tabla que inventó no existe, o la sintaxis es PostgreSQL pero la query intenta un feature que solo existe en MySQL. Más contexto en en la guía de seguridad de Microsoft.
El punto es que el LLM no tiene manera de verificar su propio output sin ejecutarlo. No puede comprobar “¿esta tabla existe realmente?” antes de escribir la query. Tiene que confiar en su entrenamiento (que está lleno de baches), y vos tenés que confiar en que el agente reporte el error correctamente.
Eso que llamamos “hallucinations” es el problema #1 de ejecución confiable. (No es que el modelo esté alucinando para ser difícil; es que los LLMs predicen el próximo token según patrones estadísticos, y a veces eso produce cosas que no existen en realidad.) El modelo cree que sabe dónde está la función, cómo se llama, qué parámetros espera—pero no lo sabe. Lo adivinó, y muchas veces erró.
La barrera de autorización y control de permisos
Otro escenario: un agente que necesita acceder a tu base de datos de clientes para filtrar registros. La pregunta es: ¿cómo garantizás que el agente solo accede a esos registros, no a otros? ¿Cómo evitás que en su siguiente iteración se le ocurra deletear la tabla, o exfiltrar datos a un servidor externo?
La respuesta honesta es: no hay una solución estándar. Algunos sistemas usan context windows (limitar qué información ve el agente), otros usan control de acceso a nivel de base de datos (roles de SQL, permisos de AWS IAM), otros directamente ignoran el problema. Complementá con como ChatGPT lo enfrenta.
El punto es que necesitás un sistema de autorización granular donde cada acción que el agente quiera hacer se verifique contra políticas (eso se llama “agentic guardrails”). Si no implementás esto, te pasa lo que a muchas empresas: el agente funciona en demo, pero en producción cualquier prompt injection lo deja acceder a cosas que no debería.
Sandboxes y contención: teórica vs. real
Imaginá que containerizás tu agente en Docker, con red aislada y permisos SO limitados. Suena seguro, ¿no? El problema: un LLM que genera código malicioso (o que un adversario fuerza a generar a través de prompt injection) puede escapar del container con exploits conocidos de kernel, exfiltrar datos por canales side-channel, o simplemente escribir a un volumen compartido que luego procesa otro servicio.
Los sandboxes modernos (gVisor, Firecracker, etc.) son mucho más seguros que Docker, pero siguen siendo atacables. Y acá está lo crucial: ¿vos realmente ejecutás tu agente en un sandbox industrial, o en un servidor normal corriendo cualquier código que el modelo decide generar?
La mayoría de las implementaciones que ves (y que ves en “demostratos de IA”) no tienen sandbox real, o tienen uno débil. Porque los sandboxes imponen latencia, límites de recursos, y complejidad operacional. Para más detalles técnicos, mirá en nuestro análisis de GPT.
La barrera del loop de retroalimentación incierto
El agente ejecuta una acción, recibe un resultado, y tiene que interpretarlo. Problema: el LLM no siempre sabe si falló. Si una función retorna un error 500, el modelo puede interpretar eso como “continuá”, “reintentar”, “abortá”, o “ignoralo”. No hay consenso, y menos aún hay una estrategia robusta para cada tipo de error.
Subís el modelo, lo probás en local con datos de prueba, funciona bárbaro, lo mandás a producción, el primer agente se topa con un error inesperado de la API, interpreta mal el mensaje de error, genera un comando SQL peligroso para compensar, e inmediatamente hay un problema. El loop de retroalimentación es demasiado frágil.
Confiabilidad del razonamiento y planificación
Los LLMs son buenos generando planes de alto nivel (“para hacer X, primero hago A, luego B, luego C”). Pero cuando los pasos tienen interdependencias complejas, o cuando el orden importa mucho, el modelo tiende a sobreestimar su confianza en el plan. No se detiene a verificar si el plan es realmente ejecutable.
Ejemplo real: un agente que intenta automatizar un workflow de soporte. El plan dice: (1) buscar el ticket, (2) responder al cliente, (3) cerrar el ticket, (4) enviar notificación. Pero en producción, el paso 2 falla porque la API de respuesta rechaza el formato del mensaje. El agente nunca llegó al paso 3 ni al 4, pero tampoco supo cómo recuperarse. El loop se quedó colgado. En como sucede en Gemini profundizamos sobre esto.
Errores comunes al implementar agentes
#1: Confiar en que el modelo “sabe” qué API llamar sin validación explícita
El modelo ve docstrings de funciones, ejemplos en el prompt, y asume que las entiende. Pero fácilmente inventa parámetros que no existen. Solución: validación de esquema antes de ejecutar, logs detallados de qué intentó llamar, y rollback automático si falla.
#2: Cero manejo de errores en la retroalimentación del agente
Cuando una acción falla, muchos agentes sencillamente ignoran el error o lo interpretan de formas inconsistentes. Necesitás un parser robusto de errores que el modelo pueda entender: “si el error es de timeout, reintentar; si es de permiso, reportar; si es de lógica, escalar”.
#3: No limitar recursos ni tiempo de ejecución
Un agente en loop infinito consumiendo APIs sin límite. O generando queries que hacen full table scan. Necesitás timeouts, límites de API calls por sesión, y monitoreo en tiempo real.
Preguntas Frecuentes
¿Un agente de IA como Claude puede ejecutar código directamente?
No por sí solo. Claude puede generar código (Python, JavaScript, SQL, etc.), pero no lo ejecuta. Vos tomar ese código, validarlo, y ejecutarlo en tu propio entorno. Si implementás un sistema que ejecute automáticamente lo que Claude sugiere, entonces sí; pero en ese caso vos tenés todo el riesgo de ejecución. La mayoría de implementaciones reales agregan un paso manual de aprobación, o un sistema de validación automática.
¿Cómo verificás que un agente no hizo algo peligroso?
Auditoria después del hecho (logs de qué acción intentó, qué ejecutó, qué resultado tuvo), sandboxing durante la ejecución (entorno aislado donde no puede dañar sistemas críticos), y guardrails antes (bloquear ciertos tipos de comando antes de que los ejecute). Lo ideal es los tres combinados, pero la mayoría de producción va con auditoria + algunos guardrails.
¿Existen frameworks que resuelven qué impide la ejecución?
Parcialmente. LangChain y OpenAI’s functions API ofrecen abstracciones para que el agente sepa qué funciones puede llamar. Pero eso no resuelve validación de parámetros, sanitización de entrada, o autorización granular. Anthropic ha publicado research sobre tool use seguro, pero implementar eso en producción sigue siendo trabajo de tu equipo.
¿Puedo usar agentes para tareas críticas de producción?
Sí, pero con infraestructura robusta detrás. Aprobación humana para acciones criticas, logging exhaustivo, rollback automático en fallos, sandboxing, y testing caótico (simular fallos y ver cómo el agente responde). Si tu tarea es “clasificar emails”, el riesgo es bajo. Si es “borrar registros de base de datos”, necesitás guardrails industriales. Ojo con priorizar “automatización rápida” sobre “seguridad verificada”.
Conclusión
Cuando preguntás qué impide la ejecución fiable en sistemas de agentes, la respuesta no es “el modelo no puede pensar”. El modelo puede pensar bastante bien. El verdadero obstáculo es que no hay manera de garantizar que lo que el agente decide hacer es seguro, correcto y alineado con tus intenciones, sin una infraestructura robusta de validación, autorización, sandboxing, y manejo de errores. Eso requiere trabajo de ingeniería real: esquemas, permisos, logging, rollback, auditoria. Lo que ves en el demo de la startup que automática “X con IA” probablemente no tiene ninguno de esos componentes. Cuando evalúes un agente en producción, preguntá por guardrails, no por el tamaño del modelo.
Fuentes
- Anthropic — Tool Use and Agent Safety Research — guía de buenas prácticas para agentes que usan herramientas de forma segura
- LangChain — Framework de agentes y tools — librería estándar para construir agentes con validación de funciones
- OpenAI Function Calling API — Documentación oficial — especificación de cómo integrar funciones ejecutables en agentes
- ArXiv — “Agents can be LLMs or React: A Survey on Generative Models for Dialogue Systems” (2023) — análisis académico de arquitecturas de agentes y limitaciones de confiabilidad
- Microsoft Research — Agentes, Sistemas y Herramientas con LLMs — estudio de barreras técnicas en ejecución de agentes