Agentes de IA en producción: cuándo aportan valor real y cuándo son una mala idea

Los agentes de IA han pasado rápidamente de ser un experimento vistoso a convertirse en una de las arquitecturas que más conversación generan dentro del desarrollo de software empresarial. La propuesta es tentadora: en lugar de programar cada paso que debe dar una aplicación, le entregamos a un modelo de lenguaje un objetivo, un conjunto de herramientas y una serie de reglas para que decida de forma autónoma qué acciones ejecutar.

Sin embargo, hay una realidad que se pasa por alto con frecuencia. Que un proceso pueda resolverse mediante un agente no significa que deba resolverse así. La autonomía en un entorno de producción tiene un coste alto en términos de incertidumbre, nuevos puntos de fallo, complejidad en el control y unos requerimientos de seguridad mucho mayores. Antes de desplegar este tipo de sistemas conviene analizar si esa autonomía aporta una ventaja clara frente a un flujo de trabajo tradicional.

Workflow tradicional frente a una arquitectura basada en agentes

En un proceso convencional de gestión de incidencias, la secuencia de pasos suele estar definida de antemano. Se recibe el ticket, se clasifica mediante reglas prefijadas, se consulta la base de datos, se asigna una prioridad y se notifica al responsable. Cada etapa es predecible, determinista y, por tanto, sencilla de auditar y probar antes de salir a producción.

Un agente plantea un paradigma distinto. El modelo recibe el objetivo y determina qué herramientas necesita utilizar, en qué orden y en qué momento dar por concluida la tarea. La diferencia de fondo es bastante clara: un flujo de trabajo ejecuta un proceso estructurado, mientras que un agente decide cómo ejecutarlo. Es precisamente esa capacidad de decisión la que puede resolver problemas complejos o, si no se acota bien, convertirse en una fuente constante de errores.

El papel del tool calling y la separación de responsabilidades

Un agente empresarial no debe entenderse como un chatbot con acceso libre a los sistemas. La pieza central para que esta arquitectura funcione de forma segura es el llamado tool calling.

El modelo de lenguaje no interactúa directamente con las bases de datos ni ejecuta comandos en el servidor. La aplicación expone únicamente interfaces controladas que el modelo puede solicitar. El flujo debe estructurarse en capas muy definidas: el modelo decide qué herramienta propone usar, pero la aplicación backend es la que valida si los argumentos son correctos, comprueba los permisos del usuario y autoriza la ejecución real en el sistema.

Delegar la lógica de autorización al propio modelo es uno de los mayores errores de diseño. El modelo sugiere la acción; el backend decide si está permitida.

Planificación iterativa y gestión del contexto

En tareas donde el camino no está trazado desde el principio, la autonomía del agente ofrece un rendimiento excelente. Si le pedimos al sistema que investigue por qué se han disparado las incidencias de un cliente concreto durante el último mes, no existe una secuencia única de pasos. El agente puede revisar los tickets, detectar un patrón en las fechas, consultar los cambios recientes en la infraestructura del cliente y cruzar los datos con la documentación interna antes de redactar un informe.

En cada iteración, el sistema evalúa el resultado de la herramienta anterior y decide la siguiente acción. Ahora bien, si la tarea consiste simplemente en recibir un formulario, validar cuatro campos y guardar el registro en la base de datos, forzar la intervención de un agente solo añade latencia y riesgo innearios.

Por otro lado, conviene diferenciar entre el estado de la ejecución y la memoria del sistema. El estado abarca los datos temporales necesarios para completar la tarea actual. La memoria implica almacenar información de forma permanente para futuras interacciones. En entornos corporativos es preferible ser especialmente restrictivo con la memoria: guardar historiales de conversación sin una política clara de retención, acceso y borrado vulnera los principios básicos de gobernanza de datos y alguna que otra norma en materia de privacidad.

Matriz de riesgo y supervisión humana

A medida que un agente gana autonomía, el diseño de permisos se vuelve crítico. Se pueden definir distintos niveles de riesgo según el impacto de las herramientas disponibles.

Las operaciones de lectura como consultar fichas de clientes o buscar documentos internos presentan un riesgo bajo. Por su parte, las acciones reversibles como redactar un borrador de correo o preparar una tarea pendiente permiten cierta automatización al mantener una fase de revisión. Sin embargo, las acciones directas como modificar datos en el ERP, enviar notificaciones externas o alterar estados requieren mecanismos de aprobación. Finalmente, las operaciones críticas como ejecutar transferencias, eliminar información o alterar permisos no deberían delegarse a un agente autónomo de forma desatendida.

La arquitectura human-in-the-loop encaja muy bien en estos escenarios. El agente analiza la información, detecta discrepancias y propone una solución concreta, pero la ejecución final de las acciones con mayor impacto queda supeditada a la confirmación de un operador humano.

El impacto económico y la falta de determinismo

El coste de la autonomía no se limita al precio por token. Mientras que un workflow tradicional resuelve una petición con una llamada puntual o mediante código directo, un agente puede necesitar múltiples iteraciones cruzando llamadas al modelo, consultas a bases de datos y procesamiento intermedio. La suma de latencia, consumo de infraestructura y herramientas convierte a la autonomía en un recurso costoso.

A esto se suma el carácter no determinista de los modelos de lenguaje. Un cambio sutil en el texto de entrada o pequeñas variaciones en el contexto pueden alterar las decisiones del agente. Para despliegues en producción es indispensable fijar límites estrictos de iteraciones, implementar timeouts, definir esquemas de entrada y salida muy rígidos, y establecer mecanismos de corte automático para evitar bucles infinitos.

Igualmente, la auditoría debe permitir reconstruir el historial completo de cada ejecución: qué modelo se utilizó, qué herramientas se invocaron, qué datos devolvió cada consulta y cuál fue el razonamiento seguido. Sin esta trazabilidad, depurar un fallo en producción resulta prácticamente imposible.

Sistemas híbridos: lo mejor de ambos mundos

La elección entre workflows rígidos y agentes autónomos no tiene por qué ser excluyente. Las arquitecturas más estables en producción suelen combinar ambas estrategias.

El código convencional se encarga de las fases deterministas como la autenticación, la validación inicial de los datos o el volcado de registros en la base de datos. El agente se activa únicamente en los puntos del flujo donde se requiere interpretar texto no estructurado, razonar sobre datos heterogéneos o elegir dinámicamente el siguiente paso. Una vez obtenida la respuesta, el control vuelve al workflow tradicional para aplicar los controles de seguridad y auditoría pertinentes.

Antes de incorporar un agente a la pila tecnológica, hay que preguntarse si la incertidumbre y la complejidad operacional que introduce la autonomía del agente quedan compensadas por el valor real que aporta al negocio.

Si la respuesta no es un SÍ rotundo, mejor olvidarnos.