El 95% de los pilotos de IA generativa no llega a producción. Cinco movimientos concretos para que el tuyo esté en el otro 5%.

Segunda parte de la serie sobre agentes de IA en un landscape SAP

https://preview.redd.it/0giv5w5afejh1.png?width=969&format=png&auto=webp&s=a8f915a5ef3a663660f904596aa6cd5c3bd4614c

En la primera parte dejamos una receta de seis pasos para arrancar el journey de agentes de IA sobre un landscape SAP: elegir un proceso real, elegir la capa de agentes según tu curva de aprendizaje, diseñar con los cuatro patrones de Ng, gobernar los permisos al estilo Mollick, resolver interoperabilidad al estilo Gates, y escalar a pro-code solo cuando el caso lo exija.

Supongamos que hiciste bien la tarea: el piloto de conciliación de disputas o de aprobación de compras funciona, el dueño de proceso está contento, y ahora la pregunta cambia. Ya no es "¿cómo arranco?" sino "¿cómo hago que esto deje de ser un experimento aislado?". Ahí es exactamente donde la mayoría de los proyectos de IA se rompen.

El dato que nadie puede seguir ignorando

El informe "The GenAI Divide: State of AI in Business 2025" del MIT NANDA es contundente: el 95% de los pilotos de IA generativa en empresas no logran pasar a producción ni generar retorno medible. Lo interesante no es el número, es el motivo.

https://preview.redd.it/jruj3ipbfejh1.jpg?width=930&format=pjpg&auto=webp&s=c41b475878f6316036cf977bffa3ddf968c9542f

95% de los pilotos no llega a producción; el 5% que escala rediseña el proceso, aprende de las correcciones y suele apoyarse en un partner de dominio (MIT NANDA, 2025).

El reporte encuentra que los pilotos que fracasan comparten un patrón: usan herramientas genéricas que lucen bien en una demo pero son frágiles frente a un flujo de trabajo real, no retienen contexto ni aprenden de las correcciones del usuario, y las empresas miden adopción (logins, sesiones de chat) en vez de medir si el proceso de negocio realmente cambió. El 5% que sí escala hace lo contrario: rediseña el flujo de trabajo en vez de superponer el agente sobre el proceso existente, construye una capa de memoria que aprende de cada corrección, y —dato relevante para el mundo SAP— tiene el doble de probabilidad de éxito cuando se apoya en un partner especializado del dominio en vez de construir todo in-house.

Traducido a un landscape ECC o S/4HANA: si tu agente de aprobación de compras "funciona" pero nadie cambió el flujo de aprobación en sí, ni el agente aprende de las excepciones que el comprador corrige a mano cada semana, no tienes un piloto exitoso — tienes una demo cara esperando a ser abandonada.

Los cinco movimientos para pasar de piloto a escala

https://preview.redd.it/eikfvipbfejh1.jpg?width=929&format=pjpg&auto=webp&s=a7122868e41fee54aee4f43b03a2a96e44f163c7

Los cinco movimientos: métrica, arquitectura, confianza, interoperabilidad y partners.

MOVIMIENTO 1 · MÉTRICA

Cambia la métrica antes de pedir más presupuesto

Si tu tablero mide cuántos usuarios abrieron el agente o cuántas conversaciones tuvo, estás midiendo lo mismo que mide el 95% que fracasa. Mide en cambio el porcentaje de aprobaciones de compra, conciliaciones o tickets que el agente resuelve de punta a punta sin intervención humana, cuánto bajó el tiempo de ciclo del proceso en tu SAP, y qué tan seguido el agente aprende de una corrección para no repetir el mismo error. Esa es la diferencia entre "adopción" y "transformación" que marca el informe del MIT.

MOVIMIENTO 2 · ARQUITECTURA

Decide cuándo pasas de un agente a una red de agentes

Gates lo planteaba como pregunta abierta en su ensayo original: ¿un asistente único o una red de agentes especializados? Con el primer proceso ya en marcha, la respuesta empieza a aparecer sola. Cuando la tarea cruza módulos —una disputa de cobranza que toca FI, SD y gestión de crédito a la vez— un solo prompt gigante se vuelve inmanejable. Ahí aplica el patrón de multi-agent collaboration que Ng describe: un agente orquestador que descompone el caso y delega en agentes especializados por dominio, cada uno con su propio acceso acotado a las tablas y BAPIs que le corresponden. No fragmentes por moda; fragmenta cuando la complejidad del proceso lo exige, y solo entonces.

MOVIMIENTO 3 · CONFIANZA

Sube la autonomía como una escalera, no como un interruptor

Mollick, en su escrito más reciente sobre convivencia con sistemas cada vez más autónomos, es honesto sobre algo incómodo: la relación de confianza con un agente no se resuelve una vez, se "negocia y renegocia" todo el tiempo a medida que la capacidad del sistema cambia. En la práctica, eso significa construir niveles explícitos de autonomía sobre tu proceso SAP en vez de un botón de encendido/apagado: el agente que solo sugiere y un humano ejecuta, el agente que ejecuta acciones reversibles (crear un borrador de pedido) y notifica, y recién en un tercer nivel el agente que contabiliza documentos financieros de forma autónoma dentro de límites estrictos, con auditoría por muestreo. Cada salto de nivel se gana con evidencia del nivel anterior, no con la fecha del roadmap.

https://preview.redd.it/mv6dshpbfejh1.jpg?width=930&format=pjpg&auto=webp&s=17a4ab8adb5cb67b1a17e5acf126ef0589a5a2d0

Autonomía como escalera: la confianza se negocia nivel por nivel, no con un botón de encendido/apagado.

MOVIMIENTO 4 · INTEROPERABILIDAD

No le prometas a tu directorio una interoperabilidad que la plataforma todavía no tiene

La arquitectura de referencia de SAP para A2A y MCP es honesta al respecto: hoy el Agent Gateway que expone los agentes Joule vía protocolo A2A todavía no está disponible en general (GA), y la comunicación soportada es unidireccional —Joule puede invocar agentes externos ("bring your own agent"), pero la exposición completa hacia afuera todavía está en construcción—. Esto no invalida el consejo de la primera parte de priorizar estándares abiertos; lo que cambia es la secuencia: usa el MCP Gateway del Integration Suite para exponer hoy tus capacidades de SAP como herramientas gobernadas, y planea la malla de agentes bidireccional como una fase siguiente, no como un supuesto de la arquitectura inicial.

MOVIMIENTO 5 · PARTNERS

Compra experiencia de dominio antes que reinventarla

El propio informe del MIT lo cuantifica: las implementaciones con un partner especializado tienen el doble de tasa de éxito que las construidas enteramente puertas adentro. Tiene sentido en un landscape SAP — el riesgo no está en el modelo de lenguaje, está en modelar correctamente cómo una disputa de cobranza, una orden de venta bloqueada o una excepción de crédito se comportan realmente en tus datos maestros de ECC o S/4HANA. Ya sea un partner del ecosistema SAP, el equipo del hyperscaler o un integrador especializado, prioriza a quien ya se equivocó con esos procesos antes que a quien recién está aprendiendo con tu implementación como primer caso.

EJEMPLO EN EL ECOSISTEMA SAP Onibex, LLC · Workforce 2.0 Onibex es un partner especializado en SAP con recorrido en migraciones ECC a S/4HANA, servicios de AMS y, más recientemente, en agentes de IA en tiempo real sobre eventos (junto a Confluent). Su solución Workforce 2.0 aparece en el directorio de partners de IA de SAP como una propuesta de agentic AI gobernada para S/4HANA — es decir, exactamente el tipo de apuesta que describe este quinto movimiento: partir del conocimiento de dominio que un integrador ya tiene sobre cómo se comportan tus procesos reales, en lugar de construir esa curva de aprendizaje desde cero puertas adentro. Ver la ficha de Onibex, LLC · Workforce 2.0 en SAP.com →

El cierre de esta segunda parte

La primera parte era sobre el coraje de empezar. Esta es sobre la disciplina de no quedarse en el 95%. Ng te da el patrón para crecer de un agente a una red sin perder coherencia. Gates te obliga a decidir esa arquitectura antes de que la complejidad te obligue a decidirla mal. Mollick te recuerda que la confianza en un agente no es un checkbox que se marca una sola vez. Y el MIT, con datos duros, confirma lo que probablemente ya sospechabas: la diferencia entre un piloto que impresiona en una demo y un agente que de verdad mueve la aguja de tu negocio no está en qué plataforma elegiste, está en si rediseñaste el proceso, si mediste lo correcto, y si tuviste la humildad de traer ayuda especializada antes de que el proyecto se convirtiera en una anécdota más de la estadística.

Preguntas frecuentes

P: ¿Cómo sé si mi piloto de agentes está listo para escalar o es en realidad una demo cara?

Revisa tres señales, no una: ¿el flujo de trabajo se rediseñó de verdad o el agente solo se superpuso al proceso viejo? ¿Existe una capa de memoria que aprende de las correcciones que el usuario hace cada semana? ¿Mides el porcentaje de casos resueltos de punta a punta, o solo cuántas veces se abrió el chat? Si la respuesta a cualquiera de esas es "no", según el MIT NANDA estás en el 95%, no en el 5%.

P: ¿Qué debo medir en vez de logins o sesiones de chat?

Tres números por proceso: el porcentaje de casos (aprobaciones, conciliaciones, tickets) que el agente resuelve de punta a punta sin intervención humana; la reducción del tiempo de ciclo del proceso dentro de tu ECC o S/4HANA; y la frecuencia con la que el agente incorpora una corrección para no repetir el mismo error. Esos tres indicadores describen transformación de proceso, no adopción de herramienta.

P: ¿Cuándo conviene pasar de un solo agente a una red de agentes especializados?

Cuando la tarea empieza a cruzar módulos —por ejemplo, una disputa de cobranza que toca FI, SD y gestión de crédito a la vez— y un solo prompt se vuelve inmanejable. Ahí conviene un agente orquestador que descompone el caso y delega en agentes especializados, cada uno con acceso acotado a las tablas y BAPIs de su propio dominio. Fragmentar antes de tener esa complejidad solo añade coordinación innecesaria.

P: ¿Cómo subo el nivel de autonomía sin poner en riesgo mis datos financieros?

Construyendo niveles explícitos en vez de un interruptor único: primero un agente que solo sugiere y un humano ejecuta; luego un agente que ejecuta acciones reversibles (como crear un borrador de pedido) y notifica; y solo en un tercer nivel, con evidencia acumulada de los anteriores, un agente que contabiliza documentos financieros de forma autónoma dentro de límites estrictos y con auditoría por muestreo. Cada salto se gana con datos del nivel anterior, no con el calendario del proyecto.

P: ¿Ya puedo conectar Joule con agentes externos vía A2A hoy mismo?

Parcialmente. Según la arquitectura de referencia de SAP, Joule ya puede invocar agentes externos ("bring your own agent"), pero el Agent Gateway que expondría los agentes Joule hacia afuera vía A2A todavía no está disponible en general (GA) — hoy la comunicación soportada es unidireccional. La ruta recomendada mientras tanto es usar el MCP Gateway del Integration Suite para exponer capacidades de SAP como herramientas gobernadas, y tratar la malla de agentes bidireccional como una fase posterior.

P: ¿Por qué el informe del MIT recomienda un partner especializado en vez de construir todo puertas adentro?

Porque el informe encuentra que las implementaciones con un partner especializado en el dominio tienen el doble de tasa de éxito que las construidas enteramente in-house. En un landscape SAP el riesgo mayor no está en el modelo de lenguaje, está en modelar bien cómo se comportan realmente tus datos maestros y tus procesos (una disputa de cobranza, una orden bloqueada, una excepción de crédito). Quien ya se equivocó con esos procesos en otros clientes llega más rápido a una versión que funciona.

P: ¿Qué es Workforce 2.0 de Onibex y cómo encaja en estos cinco movimientos?

Workforce 2.0 es la solución de agentic AI gobernada para S/4HANA de Onibex, un partner del ecosistema SAP con recorrido previo en migraciones ECC a S/4HANA y en agentes de IA en tiempo real. Encaja directamente en el quinto movimiento de este artículo: apoyarse en experiencia de dominio ya probada en vez de reinventarla desde cero. Puedes ver el detalle en su ficha de partner en SAP.com.