Las empresas llevan meses depositando grandes expectativas en los agentes de IA: software capaz de ejecutar tareas de negocio de extremo a extremo, coordinando personas, sistemas y datos sin intervención humana constante. La promesa es real. Pero quienes están intentando llevarla a producción descubren rápidamente que el rendimiento del modelo de lenguaje es solo una pieza —y no necesariamente la más crítica— de un problema bastante más complejo.
La infraestructura que rodea al modelo importa tanto como el modelo mismo. Y ahí es donde muchas organizaciones se están quedando cortas.
Más allá del chatbot: qué significa realmente un agente de IA empresarial
Un agente de IA no es un chatbot más sofisticado. Es un proceso automatizado orientado a objetivos: planifica tareas en varios pasos, llama a herramientas externas, lee los resultados y reintenta cuando algo falla. Esa capacidad de recuperación ante errores es precisamente lo que lo hace útil en entornos de negocio reales.
El error conceptual más frecuente es tratar el despliegue de agentes como un problema de inferencia —elegir el mejor modelo y conectarlo a una interfaz—. El valor empresarial, sin embargo, depende del sistema completo: orquestación de tareas, acceso a datos, ejecución de herramientas, gestión de latencia, gobernanza y una infraestructura capaz de escalar. El modelo de lenguaje es solo una pieza. El sistema que lo rodea es el verdadero problema de ingeniería.
El problema de la medición: por qué las métricas actuales se quedan cortas
La mayoría de los marcos de evaluación existentes miden el rendimiento del LLM. Necesario, pero insuficiente. Los equipos que operan flotas de agentes necesitan saber cuánto tarda cada tarea, cuántos agentes puede sostener el sistema y cómo evolucionan los costes cuando más agentes trabajan en paralelo.
Intel identificó seis métricas clave para operadores empresariales: tasa de éxito por tarea, coste por tarea, tiempo por tarea, rendimiento total, densidad de agentes y latencia. Juntas responden las preguntas que realmente importan: ¿funciona el sistema como se espera? ¿Cuántos agentes puede sostener? ¿Cómo debe escalar?
Para capturar esas señales, Intel extendió Terminal-Bench, un entorno de evaluación de código abierto, añadiendo telemetría y capacidades de reproducción determinista. Las respuestas del LLM se grababan una vez y se reproducían de forma idéntica en cada ejecución. Eso permitió separar el rendimiento del agente de la variabilidad del modelo y obtener comparaciones más fiables.
Densidad de agentes: la métrica que cambia cómo se planifica la capacidad
Cuando un equipo pregunta cuántos agentes puede ejecutar su infraestructura, la respuesta correcta no es un número absoluto. Es una ratio: agentes por vCPU. Esa es la señal principal de saturación del sistema.
El ejemplo es ilustrativo. Diez agentes sobre ocho vCPU y veinte agentes sobre dieciséis vCPU se comportan de forma prácticamente idéntica si la densidad es la misma. Esto permite a los arquitectos comparar capacidad entre distintos tamaños de instancia y generaciones de procesador de forma portable y coherente.
La densidad óptima no es universal; depende del objetivo de negocio. Los asistentes interactivos orientados al usuario deben operar a densidades bajas porque el tiempo de respuesta es crítico, mientras que las tareas por lotes —flujos de trabajo de IT, procesamiento nocturno— pueden tolerar densidades más altas. Esa distinción permite ajustar las flotas en torno a objetivos de nivel de servicio y coste total.
Latencia P95 y escalado horizontal: los dos principios operativos clave
La utilización media de CPU es una señal débil para cargas de trabajo de agentes. Los agentes alternan entre periodos de espera —mientras el modelo responde— y ráfagas cortas de trabajo intensivo, de modo que la media puede parecer aceptable mientras los picos generan colas y degradan la experiencia real del usuario.
La latencia P95 resulta más útil. Detecta cuándo los flujos de trabajo empiezan a esperar, antes de que la duración media de las tareas se degrade de forma visible. Un modelo operativo práctico: alertar primero sobre P95 y confirmar el problema revisando la duración sostenida de tareas.
En cuanto al escalado, los datos de Intel apuntan al escalado horizontal como opción por defecto. Los agentes son semindependientes y tienen ráfagas modestas por unidad; añadir más sistemas mejora el rendimiento global, facilita la alta disponibilidad y mantiene la ratio de densidad objetivo a medida que la plataforma crece. El escalado vertical tiene sentido en casos concretos: mayor cómputo paralelo por agente, estado compartido que limita la partición o restricciones de licencia.
Dónde crear valor primero: los casos de uso que ya funcionan en producción
Las organizaciones que obtienen resultados reales en producción comparten un patrón claro: aplican agentes sobre flujos de trabajo que ya tienen reglas codificadas y niveles de servicio medibles. Creación de código, pruebas de regresión, triaje de incidencias, análisis de mercado y revisión de seguridad son los casos con mayor retorno inicial.
El perfil que mejor aprovecha esta tecnología no es el usuario experimental. Es el responsable que debe mejorar los ciclos de trabajo y la productividad, proteger la calidad del servicio y escalar la adopción con el coste bajo control.
Ese matiz importa. El éxito no depende solo de elegir el modelo adecuado, sino de construir una infraestructura que garantice resultados consistentes, permita controlar el gasto y cumpla los requisitos normativos desde el primer despliegue. A medida que más organizaciones pasen de pilotos a producción, la pregunta central dejará de ser «¿qué modelo usamos?» para convertirse en «¿tenemos la infraestructura para que esto funcione a escala?». Las empresas que ya están respondiendo esa segunda pregunta llevan ventaja.