
Gastamos $35 mil millones en IA y no obtuvimos casi nada a cambio
La llamada llegó un martes por la noche. Una empresa de salud del mercado medio —a la que habíamos estado asesorando— acababa de cancelar su proyecto estrella de IA. Nueve meses de trabajo. Un gasto de seis cifras. El CTO sonaba agotado, no enfadado. «Funcionaba a la perfección en la demo», me dijo. «Todas y cada una de las veces. Luego lo conectamos a datos reales de pacientes y empezó a alucinar códigos de seguros».
No supe qué decir, porque solo en ese trimestre había escuchado alguna versión de esta historia una docena de veces. IA que deslumbra en una sala de reuniones y se desintegra en producción. Pilotos que generan entusiasmo en el primer mes y revisiones presupuestarias en el sexto. La brecha entre lo que la IA generativa promete y lo que entrega dentro de una empresa real es la tensión que define este momento de la tecnología.
Y ahora tenemos las cifras que lo demuestran. La iniciativa NANDA del MIT publicó a mediados de 2025 un estudio que cayó como una granada: de los aproximadamente 30.000 a 40.000 millones de dólares que las empresas han volcado en IA generativa, alrededor del 95% de los pilotos no ha logrado un impacto medible en la cuenta de resultados. La propia encuesta de McKinsey de 2025 se hace eco de ello: el 88% de las organizaciones dice que usa IA en algún punto, pero solo el 39% puede señalar algún impacto en el EBIT, por mínimo que sea.
Dirijo Veriprajna, donde construimos sistemas de IA profunda para empresas. No soy un observador neutral en esto. Pero he estado lo bastante cerca de los restos del naufragio —y de los escasos éxitos— como para tener una idea clara de qué está fallando de verdad. Y no es lo que la mayoría piensa.
La demo tenía una pinta estupenda. Luego llegó la realidad.

La experiencia de aquel CTO del sector salud no era inusual. Era prácticamente el resultado mediano.
Los datos del MIT trazan un embudo brutal: el 80% de las organizaciones explora herramientas de IA generativa. Solo el 20% llega a un piloto. Y apenas el 5% alcanza la producción con resultados de negocio medibles. Los investigadores lo llaman una «brecha de aprendizaje», que es una forma educada de decir que la mayoría de las empresas no entiende lo que ha comprado.
Recuerdo estar sentado en nuestra oficina después de leer el informe completo del MIT, discutiendo con mi cofundador sobre si la cifra del 95% era demasiado dramática. No lo era. En todo caso, se quedaba corta, porque muchos de los «exitosos» del 5% habían redefinido el éxito a la baja: habían medido tasas de adopción o satisfacción de los usuarios en lugar del impacto real en los ingresos.
El patrón que veo una y otra vez es este: un equipo construye una prueba de concepto usando uno de los grandes LLM. Maneja a la perfección las diez consultas de muestra. La dirección se entusiasma. Se aprueba el presupuesto. Entonces el sistema se encuentra con el mundo real —datos desordenados, casos límite, entradas ambiguas, requisitos regulatorios donde «más o menos bien» es una demanda judicial— y se desmorona.
La distancia entre una IA lista para una demo y una IA lista para producción no es una brecha. Es un cañón, y la mayoría de las empresas no se da cuenta de que está en el lado equivocado hasta que ya ha saltado.
El 60% de los usuarios del estudio del MIT informó de que los modelos no podían aprender de la retroalimentación con el tiempo. El 55% dijo que dedicaba un esfuerzo excesivo a proporcionar contexto para cada prompt. El 40% dijo que los modelos simplemente «se rompían» al encontrarse con entradas no estándar. No son modos de fallo exóticos. Son un martes cualquiera.
¿Por qué las empresas construyen sobre arenas movedizas?
La mayor parte de lo que el mercado empresarial llama hoy «productos de IA» son wrappers: finas capas de interfaz de usuario montadas sobre una llamada a la API de GPT-4, Claude o Gemini. Escribes algo, va al modelo, el modelo responde y el wrapper le da un formato bonito.
Tengo un recuerdo visceral de una reunión de presentación en la que un cliente potencial me mostró su «motor de cumplimiento normativo impulsado por IA». Le pregunté qué pasaba cuando el comportamiento del modelo subyacente cambiaba tras una actualización del proveedor. La sala se quedó en silencio. No lo habían considerado. Todo su producto era una plantilla de prompt y un panel de control bonito. La «inteligencia» que vendían era enteramente alquilada.
Esta es la falacia del wrapper, y está en todas partes. El enfoque suele apoyarse en lo que en el sector llaman un «megaprompt»: metes reglas, datos, contexto e instrucciones en una única interacción gigantesca y esperas que el modelo lo resuelva. Escribí sobre este problema arquitectónico con más profundidad en la versión interactiva de nuestra investigación, pero la versión corta es que los megaprompts crean tres problemas fatales:
No se pueden auditar. No hay forma de verificar que el modelo siguió las instrucciones en el orden correcto. Para los sectores con fuertes exigencias de cumplimiento normativo, esto es inviable.
Son económicamente frágiles. Las ventanas de contexto largas y los reintentos consumen tokens sin parar. Y aquí va una cifra que me impactó la primera vez que la vi: la diferencia entre un tokenizador eficiente y uno ineficiente puede suponer una variación de costes del 450% para la misma carga de trabajo. Una empresa que procese 100.000 consultas diarias de clientes podría ver cómo sus costes anuales pasan de 36.500 a más de 164.000 dólares solo por elegir el modelo equivocado para un caso de uso multilingüe.
Son quebradizos. Cambia tres palabras en un prompt y obtendrás un resultado completamente distinto. Intenta construir un SLA sobre eso.
La trampa económica es aún peor que la técnica. Cuando OpenAI o Anthropic bajan los precios de su API —y seguirán bajándolos—, las empresas de wrappers ven cómo se evaporan sus márgenes. No son dueñas de los datos. No son dueñas del flujo de trabajo. Están revendiendo la inteligencia de otro con un margen, y en el momento en que el casero baja el alquiler a todo el mundo, el subarrendador se queda sin negocio.
¿Qué significa realmente «IA profunda»?

Te voy a contar el momento en que el concepto me encajó.
Estábamos trabajando en un sistema de procesamiento de documentos para un cliente de logística. El enfoque inicial era sencillo: enviar el documento de envío a un LLM, pedirle que extrajera los campos relevantes y devolver los resultados. Funcionaba con formularios estándar. Luego nos topamos con un manifiesto de contenedor de un puerto del sudeste asiático con anotaciones en varios idiomas, correcciones manuscritas y un formato que no se parecía a nada de los datos de entrenamiento. El modelo devolvió basura con total confianza.
Mi ingeniero principal, frustrado tras una semana de ingeniería de prompts que no dejaba de producir nuevos modos de fallo, dijo por fin: «Le estamos pidiendo a un solo cerebro que haga siete trabajos. ¿Y si le diéramos cada trabajo a un especialista?».
Eso es la IA profunda en una frase. En lugar de tratar el LLM como un oráculo que se ocupa de todo, lo tratas como un componente más dentro de un sistema mayor. Descompones el problema. Un agente se encarga de comprender la consulta. Otro recupera datos de una base de datos estructurada. Un tercero valida la salida frente a reglas conocidas. Un cuarto da formato a la respuesta. Cada agente tiene una responsabilidad definida, y el flujo de trabajo entre ellos es determinista, es decir, tú controlas la secuencia, la lógica y los puntos de control.
La IA profunda trata al modelo de lenguaje como a un becario brillante, no como a un CEO. Le das tareas concretas dentro de una estructura gobernada, no las llaves del edificio.
Los patrones de diseño agéntico que hacen que esto funcione no son teóricos. Se están desplegando ya:
Un patrón de reflexión en el que el agente critica su propia salida antes de enviarla al usuario. Un patrón de uso de herramientas en el que el agente recurre a herramientas externas —calculadoras, API o bases de datos— en lugar de intentar calcular las respuestas de memoria. Un patrón de planificación que descompone objetivos complejos en pasos secuenciales. Y un patrón de orquestación en el que un agente supervisor gestiona todo el flujo de trabajo y dirige las tareas al especialista adecuado.
Cuando reconstruimos aquel sistema de logística usando orquestación multiagente, la precisión de extracción en documentos no estándar pasó de aproximadamente el 60% a más del 95%. Y lo más importante: cuando sí fallaba, podíamos ver exactamente dónde y por qué, porque el sistema ya no era una caja negra. Era un pipeline con pasos observables y auditables.
¿Por qué el coste de los tokens mata el ROI de la IA empresarial?
Esta es la parte a la que no se presta suficiente atención.
Todo el mundo habla de la precisión de los modelos. Casi nadie habla de la economía unitaria de operar estos sistemas a escala. Pero he visto cómo los costes de tokens asesinaban en silencio el caso de negocio de proyectos de IA que, por lo demás, funcionaban a la perfección.
La cuenta es sencilla, pero brutal. Los distintos modelos tokenizan el texto de forma diferente, sobre todo el texto que no está en inglés y los sistemas de escritura complejos. Una consulta que cuesta 800 tokens en un modelo puede costar 4.500 en otro. Multiplica eso por cientos de miles de interacciones diarias y te encuentras con una diferencia de coste que borra cualquier ganancia de eficiencia que la IA debía aportar.
Tuve un momento de auténtica alarma cuando hicimos el análisis de tokenización para un cliente que operaba en tamil e inglés. El diferencial de coste entre su modelo actual y una alternativa más eficiente era de 4,5x. Estaban sangrando dinero en cada interacción y lo atribuían a «costes de infraestructura» en su presupuesto. A nadie se le había ocurrido mirar el tokenizador.
Los sistemas de IA profunda abordan esto siendo quirúrgicos sobre cuándo usan tokens caros de LLM. Las tareas de gran volumen y baja complejidad las gestionan modelos más pequeños o lógica determinista. La capacidad de razonamiento cara se reserva para los pasos en los que realmente importa. Es la diferencia entre contratar a un consultor sénior para que atienda cada llamada telefónica y que se centre en las decisiones que requieren criterio.
La regla 10-20-70 que nadie sigue

Cuando hablo con directivos sobre por qué se estancaron sus proyectos de IA, casi siempre señalan a la tecnología. El modelo no era lo bastante bueno. Los datos no estaban limpios. La integración era demasiado compleja.
No se equivocan en nada de eso. Pero se les escapa la proporción real. Las empresas que sí están viendo impacto en el EBIT —y McKinsey dice que solo el 6% obtiene de la IA más del 5% de su EBIT total— siguen una asignación de recursos que sorprendería a la mayoría de los tecnólogos:
El 10% del esfuerzo se destina a elegir y ajustar los algoritmos. El 20% se destina a construir la infraestructura de datos y de tecnología. El 70% se destina a gestionar personas, procesos y transformación cultural.
Setenta por ciento. No en tecnología. En conseguir que las personas cambien su forma de trabajar.
Me resistí a esta idea más tiempo del que debería. Soy ingeniero por instinto. Quería creer que, si construíamos un sistema mejor, la adopción vendría sola. Hizo falta un proyecto doloroso —uno en el que entregamos una solución técnicamente excelente que quedó sin usar durante tres meses porque nadie había rediseñado el flujo de trabajo a su alrededor— para interiorizar que la tecnología es la parte fácil.
Las empresas del mercado medio que siguen el principio 10-20-70 mejoran su EBITDA entre 160 y 280 puntos básicos en 24 meses. Las que gastan el 70% en tecnología y el 10% en gestión del cambio acaban con software caro acumulando polvo en la estantería.
Las victorias no son glamurosas. Gestión del ciclo de ingresos. Automatización de la aplicación de cobros. Optimización de costes en la nube. Nadie escribe publicaciones entusiastas en LinkedIn sobre reducir la acumulación de expedientes de pacientes ya dados de alta pero aún no facturados de forma definitiva (DNFB). Pero Inova Health System recortó esa acumulación un 50% y ahorró 1,3 millones de dólares al año. Los asistentes virtuales de IA de OSF HealthCare ahorraron 1,2 millones de dólares mientras aumentaban los ingresos en otros 1,2 millones de dólares. UPS ahorra $400 millones al año gracias al enrutamiento basado en IA.
No son resultados de un piloto. Son sistemas en producción funcionando a escala, construidos con el tipo de integración profunda que los wrappers no pueden alcanzar.
¿Qué ocurre cuando los agentes de IA empiezan a actuar por su cuenta?
El paso de una IA que responde preguntas a una IA que ejecuta acciones cambia por completo el cálculo de la seguridad.
He estado pensando mucho en esto, en parte por un incidente que estuvimos a punto de tener durante unas pruebas. Estábamos construyendo un sistema agéntico que necesitaba acceder al ERP de un cliente para extraer datos de inventario. Durante una ejecución de prueba, el agente —siguiendo una cadena de razonamiento técnicamente lógica, pero contextualmente errónea— intentó modificar una orden de compra en lugar de solo leerla. Teníamos salvaguardas activas. No llegó a ejecutarse. Pero después me quedé sentado en mi escritorio pensando en lo que habría pasado si hubiéramos sido menos cuidadosos.
Por eso importan tanto estándares como el Model Context Protocol (MCP) y el marco NANDA. MCP —desarrollado por Anthropic— actúa como una capa de integración estandarizada entre los agentes de IA y las fuentes de datos empresariales. La gente lo llama el «USB-C de la IA», y es acertado: significa que no necesitas integraciones personalizadas y frágiles para cada conexión. NANDA aporta la capa de gobernanza: atestación de capacidades verificable criptográficamente (es decir, puedes demostrar qué puede y qué no puede hacer un agente), controles de acceso de confianza cero extendidos a agentes autónomos y registros de auditoría centralizados.
Para el desglose técnico completo de estos patrones arquitectónicos y de cómo encajan entre sí, consulta nuestro artículo de investigación.
La cuestión no es que la IA agéntica sea peligrosa y debamos frenar. La cuestión es que el enfoque de wrapper —en el que tienes una visibilidad mínima de qué hace el modelo y por qué— se vuelve genuinamente temerario cuando el modelo puede ejecutar acciones en el mundo real. Los sistemas de IA profunda con flujos de trabajo observables y gobernados no son solo mejor ingeniería. Son la única forma responsable de desplegar agentes autónomos en una empresa.
«Usa GPT y ya está» y otros consejos caros
La gente me pregunta constantemente si deberían limitarse a esperar a que los modelos mejoren. «GPT-5 resolverá esto», le oí decir a un inversor en una cena. «¿Para qué construir toda esta infraestructura si la próxima versión del modelo lo hará de forma nativa?».
Entiendo el atractivo de este argumento. Es limpio. No exige trabajo duro. Y es falso.
Los modelos mejores no arreglan el problema del wrapper. Lo empeoran. Un modelo más potente dentro de una arquitectura de megaprompt es como poner un motor de Fórmula 1 en un coche sin volante. Vas más rápido en la dirección equivocada. Los problemas que matan la IA empresarial —falta de auditabilidad, prompts quebradizos, ausencia de bucles de retroalimentación, falta de contexto de negocio, costes descontrolados— son problemas arquitectónicos, no problemas de capacidad.
La economía de la IA en la sombra lo demuestra. Más del 90% de los empleados ya usa en secreto cuentas personales de ChatGPT o Claude para el trabajo, porque las herramientas de IA oficiales de su empresa son demasiado rígidas. Los modelos son lo bastante capaces. Los sistemas que los rodean, no.
Los modelos mejores no salvan una arquitectura mala. Solo alucinan más rápido y con más confianza.
La otra pregunta que me hacen es sobre los plazos. «¿Cuánto tarda esto en realidad?». La respuesta honesta es de 12 a 18 meses para pasar de experimentos dispersos a una IA que mueva la cuenta de resultados. Los tres primeros meses son de descubrimiento: identificar dónde la IA puede crear valor sin generar exposición regulatoria. Del mes tres al seis toca la preparación de los datos, que es donde el 58% de los CXO dice que se atasca. Del mes seis al doce se construyen e iteran prototipos multiagente, y hablo de más de 30 ciclos de iteración contra datos del mundo real, no de tres demos pulidas. La fase final es el despliegue en producción con soporte operativo completo: detección de deriva, monitorización de sesgos, gobernanza de costes.
No es rápido. No es fácil. Pero las empresas que lo hacen son las que aparecen en ese 6% de McKinsey con impacto real en el EBIT.
La brecha es una elección
La «brecha de la IA generativa» que identificó el MIT no es una brecha tecnológica. Es una brecha de decisiones.
En un lado: empresas que trataron la IA generativa como un producto que comprar, un wrapper que desplegar, una demo que enseñar al consejo. Son el 95%. Gastaron dinero de verdad y consiguieron notas de prensa.
En el otro lado: empresas que trataron la IA como un reto arquitectónico, uno que exige descomponer problemas, gobernar flujos de trabajo, rediseñar procesos y hacer el trabajo poco glamuroso de conectar los modelos con la realidad desordenada de los datos empresariales. Son el 5%. Gastaron un dinero parecido y consiguieron impacto en el EBIT.
A veces pienso en aquel CTO del sector salud. El que me llamó un martes, agotado, tras haber cancelado su proyecto de IA. Volvió a llamar cuatro meses después. Su equipo había reconstruido el sistema con un enfoque multiagente: agentes separados para la extracción de datos, la validación de códigos y la comprobación del cumplimiento normativo, con traspasos deterministas entre ellos. No era tan elegante como la demo original. Se tardó más en construir. Exigió pensar más por adelantado en el diseño del flujo de trabajo y en los modos de fallo.
Funcionó. No a la perfección —nada lo hace—, pero sí lo bastante fiable como para desplegarlo, auditarlo y mejorarlo. Lo bastante fiable como para aparecer en una cuenta de resultados.
La era de tratar la IA como un truco de magia ha terminado. Lo que viene es más difícil, más lento y menos fotogénico. También es lo único que funciona de verdad.


