IBM tiene más de 1,000 agentes de IA en producción — Lo que los CIOs pueden aprender de la guía de escalamiento empresarial
IBM ha desplegado cientos de agentes de IA de flujos de trabajo empresariales y miles de agentes de productividad personal, según Matt Lyteson, CIO de IBM. Esto no es un piloto. Es una operación de producción a escala. Y lo que IBM ha aprendido al ejecutar más de 1.000 agentes es el manual de escalado empresarial que la mayoría de las empresas que todavía ejecutan pilotos aún no tienen.
Don Schuerman, de Pega, plantea la restricción actual con honestidad: las alucinaciones impiden la adopción generalizada, y las empresas que han logrado implementar en producción saben que la arquitectura debe ser segura frente a alucinaciones desde el primer día. Este blog es el manual práctico basado en la experiencia de IBM: qué significa en la práctica el enfoque de resultados específicos, cómo IBM delimitó y gobierna sus despliegues, y qué cambios organizacionales se necesitaron para pasar de unos pocos pilotos a más de 1.000 agentes ejecutándose en producción.
Cómo lucen más de 1.000 agentes en IBM
La cifra de más de 1.000 agentes es una composición de dos categorías de despliegue muy diferentes que IBM ejecuta de forma diferenciada.
Agentes de flujos de trabajo empresariales: cientos de agentes automatizando procesos de negocio multifuncionales. Construidos con propósito para funciones empresariales específicas, cada uno vinculado a un flujo de trabajo definido con resultados medibles. Mayor escrutinio, mayores stakes, requisitos de arquitectura más rigurosos. Estos son los agentes que requieren la pila completa de arquitectura segura frente a alucinaciones, gobernanza formal y cobertura dedicada de operaciones de agentes.
Agentes de productividad personal: miles de agentes desplegados a empleados individuales para automatización de tareas. Clasificación de emails, gestión de calendario, redacción de documentos. Menor impacto individual, mayor ahorro de tiempo agregado. Ciclo de despliegue más rápido, iteración más rápida. Estos agentes pueden desplegarse a trabajadores individuales más rápidamente porque el radio de impacto de un fallo se limita al flujo de trabajo de una persona, no a un proceso de negocio multifuncional.
Lo que esta composición le dice a la mayoría de las empresas: no deberías intentar desplegar agentes de flujos de trabajo empresariales a todos a la vez. IBM comenzó con agentes de productividad personal, lo que les dio experiencia operativa con agentes en un contexto de menor riesgo, mientras construían la infraestructura de flujos de trabajo empresariales.
El Enfoque de Resultados Específicos — El Principio Central de Escalado de IBM
El principio de resultados específicos es lo primero que IBM hace bien y que la mayoría de las empresas hacen mal. Cada agente que IBM despliega está vinculado a un resultado empresarial específico y medible. No es un mandato tecnológico. No es "usar agentes de IA". Es una meta concreta como reducir el tiempo de clasificación de emails en un 60% para el equipo de ventas empresariales.
Por qué funciona esto: cuando empiezas con un resultado definido, delimitas el agente para ese resultado. El agente es más fácil de probar porque sabes exactamente qué significa el éxito. Es más fácil de monitorear porque tienes un número para seguir. Cuando el agente tiene éxito, tienes una métrica inequívoca para demostrar el retorno de inversión. Cuando falla, sabes exactamente qué salió mal.
Por qué el despliegue amplio fracasa: "Agentes de IA para la organización" no produce una definición clara de éxito, no hay forma de medir el retorno de inversión, no hay ciclo de retroalimentación y no hay iteración. Los agentes desplegados sin resultados claros se convierten en vitrinas tecnológicas. Son impresionantes en las demos. Nadie sabe si realmente están funcionando.
El enfoque de IBM en la práctica: cada agente tiene un dueño empresarial definido. Cada agente tiene una métrica de éxito medible acordada antes del despliegue. Cada agente tiene un humano designado que revisa el rendimiento. Los agentes se expanden solo después de un éxito medible, no según un calendario.
La Arquitectura de Alucinaciones — Lo Que IBM Construyó para Permitir el Escalado
Las alucinaciones impiden la adopción generalizada. Cada incidente de alucinación erosiona la confianza organizacional en los agentes y crea resistencia que hace que el siguiente despliegue sea más difícil. A la escala de IBM, las alucinaciones no son solo un problema de confiabilidad. Son una restricción de escalado.
Qué luce una arquitectura segura frente a alucinaciones a escala empresarial: Graph-RAG conecta fuentes de datos empresariales a un grafo de conocimiento. Los agentes recuperan solo hechos verificados, no fragmentos de texto crudo que podrían contener errores. La selección semántica de herramientas confirma la coincidencia de herramientas antes de llamar. Las políticas empresariales se codifican como guardrails neurosimbólicos que invalidan la salida del modelo. Los flujos de trabajo empresariales críticos obtienen validación de múltiples agentes: un segundo agente revisa las acciones del primer agente antes de la ejecución.
Esta infraestructura es el prerrequisito para el escalado, no un complemento. Los más de 1.000 agentes de IBM no tienen humanos revisando cada acción. Tienen arquitectura que delimita lo que los agentes pueden hacer y verifica que lo que hacen es correcto.
La Función de Operaciones de Agentes — Lo Que Realmente Requiere Ejecutar más de 1.000 Agentes
El software se ejecuta. Los agentes necesitan gestión. Esta distinción suena obvia una vez que la escuchas, y la mayoría de las organizaciones la aprenden de la manera difícil después de su primer incidente con un agente.
Los agentes se desvían. Su comportamiento cambia a medida que el entorno cambia, a medida que los modelos se actualizan, a medida que los datos de los que dependen se desplazan. Un agente que estaba funcionando correctamente hace seis semanas podría estar funcionando de manera diferente hoy.
Los agentes fallan silenciosamente. Completan tareas de maneras que parecen razonables pero están equivocadas. El software o se ejecuta o lanza un error. Los agentes completan tareas que parecieron tener éxito pero no lograron el resultado previsto.
La infraestructura operativa de IBM para más de 1.000 agentes: un equipo dedicado de operaciones de agentes. Una pila de observabilidad donde cada agente es observable. Playbooks claros de respuesta a incidentes para fallas de agentes. Revisiones regulares de rendimiento donde los resultados de los agentes se comparan con las métricas de éxito objetivo.
El Marco de Gobernanza — Cómo IBM Mantiene el Control a Escala
El desafío de gobernanza para agentes autónomos es diferente de la gobernanza de software de una manera que la mayoría de las empresas no anticipan. El software o ejecuta un procedimiento definido correctamente o no. Los agentes pueden ejecutar procedimientos de maneras que son técnicamente correctas pero contextualmente incorrectas.
El enfoque de gobernanza de IBM tiene cuatro componentes. Límites claros de alcance: los agentes están autorizados para hacer cosas específicas, no todo. Rastreos de auditoría: cada acción del agente se registra con suficiente contexto para reconstruir lo que sucedió. Caminos de escalamiento: los agentes saben cuándo escalar a un humano. Codificación de políticas: las reglas de negocio se codifican como guardrails que invalidan la salida del modelo, no solo pautas suaves que se le pide al modelo seguir.
El modelo de responsabilidad humana es lo que hace que el despliegue de agentes autónomos sea aceptable para reguladores y gobernanza interna. Cada agente tiene un humano propietario identificado que es responsable de su rendimiento. Siempre hay un humano responsable. Esta estructura de responsabilidad es lo que permite a los agentes operar de manera autónoma dentro de su alcance.
Lo Que Cada CIO Debería Tomar del Manual de IBM
Cinco lecciones transferibles de la experiencia de IBM.
Lección 1: Comienza con resultados específicos, no mandatos amplios. Si no puedes enunciar qué resultado específico y medible necesita lograr este agente, no tienes un despliegue de agentes. Tienes un piloto que no escalará.
Lección 2: Construye arquitectura segura frente a alucinaciones antes de necesitarla. Graph-RAG, selección semántica de herramientas, guardrails y validación de múltiples agentes no son opcionales cuando llegas a cierta cantidad de agentes. Son la infraestructura habilitadora que hace posible el escalado.
Lección 3: Designa ops de agentes antes de desplegar. Los agentes requieren gestión continua. Esta es una nueva función organizacional, no un deber colateral. Las empresas que tratan ops de agentes como infraestructura operarán agentes de manera más eficiente.
Lección 4: Los agentes de flujos de trabajo empresariales y los agentes de productividad personal son diferentes. No los trates de la misma manera. Comienza con agentes de productividad personal para construir experiencia operativa antes de intentar agentes de flujos de trabajo empresariales.
Lección 5: La mayoría de los pilotos fracasan porque omiten el trabajo organizacional. La tecnología no es la barrera. La preparación organizacional lo es.
La ventana competitiva es real. IBM está años adelante de la mayoría de las empresas en despliegue de agentes. Las empresas que construyan infraestructura de ops de agentes ahora tendrán una ventaja acumulativa.