Agentes de IA en empresas: qué pueden hacer de verdad, qué no y cómo evitar un piloto inútil

Una empresa recibe cada semana decenas de solicitudes de proveedores por email. Algunas piden una copia de un certificado. Otras preguntan por el estado de un alta, una incidencia contractual, una factura o un requisito que depende del tipo de proveedor. Resolverlas implica buscar documentación, consultar un ERP o una base de datos, comprobar reglas internas, pedir información cuando falta y, en algunos casos, actualizar un sistema.

Podríamos construir un workflow tradicional con docenas de bifurcaciones. También podríamos colocar un modelo de lenguaje en uno de los pasos para clasificar el email. O podríamos dar a un agente un objetivo, contexto y un conjunto limitado de herramientas para que decida qué consultar y cómo avanzar.

Las tres opciones utilizan automatización. Solo una necesita un agente. Y esa diferencia importa porque más autonomía también significa más decisiones no deterministas, más llamadas a herramientas, más coste, más latencia y una superficie de riesgo mayor.

Un agente no es mejor porque pueda hacer más cosas. Es mejor cuando puede resolver una parte del proceso que un flujo fijo no resuelve bien.

Qué es realmente un agente de IA

El término se utiliza de forma tan amplia que ha perdido precisión. OpenAI describe un agente como un sistema que utiliza un modelo para gestionar la ejecución de un workflow, tomar decisiones durante el proceso y utilizar herramientas externas para obtener información o ejecutar acciones. Anthropic establece una distinción similar: en un agente, el modelo decide dinámicamente cómo avanzar y qué herramientas usar, mientras que en un workflow el camino está predefinido por código.

Eso significa que un chatbot que responde preguntas sobre una base de conocimiento no se convierte automáticamente en agente. Tampoco lo hace una clasificación de emails que devuelve «facturación», «soporte» o «comercial». En ambos casos puede haber IA, pero el modelo no está dirigiendo una secuencia de acciones para alcanzar un objetivo.

En términos sencillos, un agente empresarial suele tener cuatro capacidades:

• Entender un objetivo. No solo generar una respuesta, sino saber qué resultado debe conseguir.
• Elegir el siguiente paso. Decidir qué información falta o qué acción conviene ejecutar.
• Usar herramientas. Consultar un ERP, buscar un documento, escribir en un CRM o enviar un mensaje, siempre dentro de permisos definidos.
• Comprobar si ha terminado. Continuar, corregir o detenerse cuando se alcanza el resultado o una condición de parada.

Workflow determinista, workflow con IA y agente: tres arquitecturas distintas

Estas tres opciones no forman una escala de madurez. Un workflow no es una versión «menos avanzada» de un agente. Puede ser exactamente la arquitectura correcta.

Volvamos a las solicitudes de proveedores. Si todas siguen las mismas cinco comprobaciones, lo más razonable puede ser un workflow. Si el correo llega en lenguaje libre pero después siempre sigue el mismo circuito, puede bastar con IA para clasificarlo. El agente empieza a tener sentido cuando un caso puede requerir consultar fuentes distintas, decidir qué información falta y seleccionar dinámicamente la siguiente acción.

Cuándo no necesitas un agente

La tentación de utilizar la arquitectura más nueva puede introducir complejidad donde no hacía falta. OpenAI recomienda priorizar agentes cuando las reglas tradicionales se quedan cortas ante decisiones complejas, reglas difíciles de mantener o mucho contenido no estructurado. Anthropic insiste en empezar por la solución más simple y añadir complejidad solo cuando mejora resultados.

Un buen diseño de automatización no busca maximizar el uso de IA. Busca minimizar el coste y la complejidad necesarios para alcanzar un resultado fiable. Esa idea conecta directamente con preparar un proceso antes de automatizarlo.

Cuándo sí puede aportar valor un agente

Los agentes son interesantes cuando el problema contiene ambigüedad real y, al mismo tiempo, existe una forma de comprobar si el trabajo avanza correctamente. No basta con que la tarea sea «compleja»; el sistema necesita herramientas, límites y feedback.

Anatomía de un agente empresarial: modelo, herramientas y mucho más

Decir «usaremos un modelo avanzado» explica muy poco sobre cómo funcionará el sistema. En producción, un agente fiable se parece más a una pequeña aplicación con varias capas que a una ventana de chat.

Herramientas: donde el agente deja de ser un chatbot

Las herramientas son la interfaz entre el agente y el mundo real. Pueden leer un CRM, consultar un ERP, buscar archivos en Drive, recuperar datos de una base de datos, crear una tarea, enviar un email o actualizar un registro.

Anthropic señala que los agentes no utilizan herramientas como lo haría un programa determinista. El nombre, la descripción, los parámetros y la información que devuelve cada herramienta influyen en la decisión del modelo. Dos funciones técnicamente correctas pueden producir resultados muy distintos si una está mejor diseñada para que el agente entienda cuándo usarla.

Por eso no conviene exponer cada endpoint de una API como una herramienta independiente. Si para entender el estado de un proveedor hacen falta tres llamadas y después unir los resultados, puede ser más robusto ofrecer una herramienta que devuelva directamente el contexto necesario.

¿Dónde encaja MCP?

MCP, Model Context Protocol, es un estándar abierto para conectar aplicaciones de IA con fuentes de datos, herramientas y workflows externos. Puede simplificar la forma de exponer capacidades a distintos clientes o agentes. Pero MCP no convierte una automatización en agente ni resuelve por sí mismo permisos, seguridad o calidad de las herramientas.

Una empresa puede construir un agente con APIs propias, herramientas internas o MCP. La elección depende de su arquitectura. Lo importante es que las herramientas tengan propósito claro, contratos estables y permisos adecuados.

Permisos y blast radius: cuánto daño podría hacer un error

Blast radius puede traducirse como «radio de impacto». Es una forma sencilla de preguntar: si el agente se equivoca, ¿hasta dónde puede llegar el daño?

Un agente con acceso de solo lectura a una base documental puede devolver una respuesta incorrecta. Un agente con permisos para borrar archivos, modificar cuentas bancarias o lanzar pagos puede producir consecuencias mucho mayores. La capacidad del modelo es la misma; cambia el alcance de sus permisos.

Anthropic ha documentado precisamente esta evolución en sus sistemas: a medida que los agentes ganan capacidad, la seguridad no puede depender únicamente de preguntar al usuario «¿permitir esta acción?». La contención limita físicamente lo que el agente puede hacer mediante sandboxes, controles de red, máquinas aisladas y credenciales protegidas. NVIDIA propone patrones similares para entornos empresariales.

Human-in-the-loop: aprobación humana útil frente a fatiga de aprobación

Human-in-the-loop significa introducir una persona dentro del circuito en determinados puntos. Puede revisar una propuesta, aprobar una acción o tomar el control cuando el agente encuentra una excepción. La guía específica sobre intervención humana en sistemas de IA desarrolla cuándo revisar, aprobar, escalar o tomar el control.

Es una salvaguarda valiosa, pero tiene un problema si se utiliza para todo. Anthropic explica que, cuando los usuarios reciben demasiadas solicitudes de permiso, terminan aprobándolas casi por rutina. La revisión deja de ser significativa.

Por eso conviene reservar la aprobación humana para acciones donde realmente aporta control: pagos, borrados, cambios contractuales, comunicaciones sensibles o casos donde el agente no tiene suficiente información. Para microacciones de bajo riesgo es preferible restringir técnicamente el alcance y permitir ejecución automática.

Evals: cómo saber si el agente funciona antes de ponerlo en producción

Evals es la abreviatura habitual de evaluaciones. Son conjuntos de pruebas diseñados para medir si el sistema hace lo que esperamos. En software tradicional existen tests. En agentes necesitamos además medir decisiones no deterministas, uso de herramientas y trayectorias completas. Para ampliar autonomía con evidencia, conviene definir una evaluación de agentes de IA que incluya casos normales, límites, regresiones y uso de herramientas.

Anthropic destaca que evaluar agentes es más difícil porque operan durante varios turnos, modifican estado y se adaptan a resultados intermedios. Un agente puede llegar a una respuesta correcta después de ejecutar diez llamadas innecesarias, utilizar una herramienta equivocada o tocar información que no necesitaba. Mirar solo el resultado final puede ocultar problemas.

Para el caso de proveedores, una evaluación podría incluir solicitudes normales, documentos ausentes, proveedores desconocidos, conflictos entre fuentes, errores de API y casos que deberían escalar a una persona. El objetivo es comprobar no solo «si responde bien», sino también si:

• Selecciona las herramientas correctas.
• No consulta datos innecesarios.
• Se detiene cuando ha cumplido el objetivo.
• Escala cuando debe hacerlo.
• Mantiene el coste y la latencia dentro de límites aceptables.
• No empeora cuando cambia el modelo, las instrucciones o una herramienta.

Sin una batería de evals, cada cambio se convierte en una prueba manual y los fallos se descubren demasiado tarde. La evaluación debe formar parte del diseño del piloto, no añadirse después.

Coste y latencia: un agente puede salir más caro que un workflow aunque use el mismo modelo

Latencia es el tiempo que tarda el sistema en completar la tarea. Un workflow puede hacer una llamada a un modelo y terminar. Un agente puede necesitar cinco turnos de razonamiento, tres consultas, dos verificaciones y una escritura final.

Cada uno de esos pasos consume tiempo y recursos. Por eso el coste real de un agente no debería medirse únicamente en tokens. También intervienen:

• Número de llamadas al modelo.
• Consultas a APIs y sistemas externos.
• Búsquedas o retrieval de información.
• Reintentos y verificaciones.
• Infraestructura de ejecución.
• Observabilidad y almacenamiento de trazas.
• Evaluación continua.
• Tiempo de revisión humana.

OpenAI recomienda establecer primero un baseline con modelos capaces y después optimizar coste y latencia sustituyendo modelos por opciones más pequeñas donde mantengan el nivel de calidad. Es un criterio útil: optimizar después de saber qué significa «funciona».

La entrada sobre cuánto cuesta automatizar un proceso desarrolla precisamente por qué integraciones, excepciones, seguridad y mantenimiento pesan tanto como el componente de IA.

Single-agent antes que multiagente

Un sistema multiagente reparte el trabajo entre varios agentes especializados. Puede haber un coordinador que delegue en agentes de búsqueda, análisis o ejecución, o agentes que se transfieran tareas entre sí.

Eso puede ser útil cuando las responsabilidades son realmente distintas o cuando un solo agente tiene instrucciones y herramientas tan complejas que su rendimiento empeora. Pero introducir varios agentes también significa más coordinación, más mensajes, más contexto, más coste y más puntos donde algo puede fallar.

OpenAI recomienda maximizar primero la capacidad de un único agente con herramientas bien diseñadas antes de dividir el sistema. Anthropic plantea una filosofía similar: añadir complejidad solo cuando existe una mejora demostrable.

Arquitectura técnica de referencia de un agente empresarial

Una arquitectura empresarial no debería conectar directamente «modelo ↔ todos los sistemas». Conviene introducir capas que controlen identidad, herramientas, permisos, políticas, observabilidad y revisión.

Cómo diseñar un piloto útil de agente de IA

Un piloto no debería empezar preguntando qué framework de agentes utilizar. Debería empezar por una tarea estrecha y un baseline: cuánto tarda hoy, cómo se resuelve, qué porcentaje termina correctamente, qué excepciones aparecen y cuánto cuesta.

Señales de que tu piloto debería seguir siendo un workflow

Después de probar un agente puede descubrirse que el problema no necesitaba autonomía. Eso no es un fracaso; es una conclusión útil.

• El agente siempre termina ejecutando los mismos pasos. Probablemente pueden codificarse.
• Los errores aparecen en decisiones que podrían convertirse en reglas. La parte no determinista es innecesaria.
• La latencia aumenta sin mejorar el resultado. Se está pagando flexibilidad que el caso no utiliza.
• El coste por caso empeora sin compensación operativa. Un workflow puede ser más eficiente.
• Hace falta añadir cada vez más agentes para mantener el proceso. Puede que el problema esté en la definición del proceso o de las herramientas.
• No existe un criterio claro para evaluar éxito. Antes de aumentar autonomía hay que resolver la medición.

Volvamos a las solicitudes de proveedores

El email entra y un primer paso clasifica la solicitud. Si pide un documento conocido y el proceso es estable, sigue el workflow determinista: localizar, comprobar, enviar y registrar. No necesitamos un agente para ejecutar cuatro pasos predecibles.

En cambio, una solicitud ambigua puede pasar al tramo agéntico. El agente consulta el contexto del proveedor, decide qué fuente necesita, busca documentación autorizada y comprueba si falta información. Si puede preparar la respuesta sin ejecutar cambios sensibles, avanza. Si necesita modificar un dato importante o encuentra una excepción, genera una propuesta y escala.

Todo queda trazado: qué herramienta utilizó, qué dato consultó, qué resultado obtuvo, cuánto tardó y cuánto costó. Esa información alimenta los evals y permite decidir si ampliar autonomía o volver a un flujo más rígido.

Ese enfoque es mucho menos espectacular que «un agente autónomo gestiona proveedores». También es mucho más útil para una empresa que quiere llevar un sistema a producción.

El mejor agente no es el que tiene más autonomía. Es el que tiene exactamente la autonomía necesaria para resolver el problema con un nivel de riesgo aceptable.

Preguntas frecuentes sobre agentes de IA para empresas