Agent-native article available: Por qué el 95% de los proyectos de IA empresarial no sobreviven al pilotoAgent-native article JSON available: Por qué el 95% de los proyectos de IA empresarial no sobreviven al piloto
Por qué el 95% de los proyectos de IA empresarial no sobreviven al piloto

Por qué el 95% de los proyectos de IA empresarial no sobreviven al piloto

Hay una diferencia entre una demostración que asombra en una sala de juntas y un sistema que funciona de lunes a viernes sin que alguien tenga que rescatarlo. La industria de la inteligencia artificial lleva dos años construyendo lo primero con una destreza que no ha logrado trasladar a lo segundo. Y la razón no está en los modelos, que son cada vez más potentes.

Tomás RiveraTomás Rivera12 de junio de 20269 min
Compartir

Por qué el 95% de los proyectos de IA empresarial no sobreviven al piloto

Hay una diferencia entre una demostración que asombra en una sala de juntas y un sistema que funciona de lunes a viernes sin que alguien tenga que rescatarlo. La industria de la inteligencia artificial lleva dos años construyendo lo primero con una destreza que no ha logrado trasladar a lo segundo. Y la razón no está en los modelos, que son cada vez más potentes. Está en cómo se decidió hablar de ellos, y por extensión, en cómo se decidió construirlos.

La cifra que circula entre los equipos técnicos más honestos del sector es difícil de ignorar: hasta el 95% de los proyectos de IA generativa en empresas no logran retorno de inversión medible, según el MIT NANDA Initiative, citado por Iris.ai. Un rango de 70 a 95 por ciento de fracaso no es una señal de que el mercado "todavía no madura". Es una señal de que algo estructural está roto en la forma en que se está construyendo.

Enrique Dans, en una pieza publicada el 10 de junio de 2026 en Fast Company, señala dónde está la fractura. No en la capacidad técnica de los modelos de lenguaje. No en la resistencia de los empleados. Sino en algo más difícil de admitir para una industria que vive de convencer inversionistas: la IA empresarial se construyó sobre metáforas en vez de modelos formales. Y las metáforas, por útiles que sean para vender, no se industrializan.

Del lenguaje poético a la arquitectura que no escala

El inventario de metáforas que pobló el discurso de IA en los últimos dos años es extenso y revelador. Los sistemas "recuerdan", "reflexionan", "planifican" y, en el caso de la técnica de "sueño" que Anthropic describió para sus agentes, literalmente "duermen". La documentación de la API de Asistentes de Azure OpenAI describe "hilos" que almacenan el historial de mensajes y los truncan cuando se agota la ventana de contexto, presentando eso como "memoria". El equipo de ingeniería de Anthropic habla de agentes de "larga duración" que deben "preservar la continuidad entre sesiones".

Ninguna de estas descripciones es técnicamente incorrecta. El problema es que son descriptivas cuando necesitan ser formales. Una metáfora describe. Un modelo formaliza. Esa diferencia tiene consecuencias económicas directas.

Cuando la "memoria" no es un modelo de datos sino una analogía operativa, no hay identidad definida, no hay estado persistente, no hay relaciones con permisología explícita, no hay restricciones que el sistema garantice independientemente de quién lo use o cuántas veces. No hay, en términos técnicos, invariantes: las reglas que una arquitectura mantiene sin importar las condiciones externas. Sin invariantes, cada implementación es una negociación nueva. Cada despliegue requiere que alguien traduzca la realidad operativa de la empresa al lenguaje que el sistema puede procesar. Y esa traducción no se puede delegar a una plantilla.

El resultado observable es que los principales proveedores de IA de frontera, incluyendo a OpenAI y Anthropic según describe la nota de Dans, están enviando ingenieros y equipos de campo a sus clientes empresariales para mapear flujos de trabajo, definir restricciones y conectar sistemas. Lo que parece un servicio premium es en realidad una señal estructural: la plataforma no puede sola. Cuando la traducción personalizada se convierte en el modo dominante de entrega, el producto deja de ser una plataforma y se convierte en consultoría con interfaz tecnológica.

El costo de ese modelo para los compradores es doble. Primero, el gasto directo en integración bespoke que debe repetirse cada vez que cambia un sistema, una normativa o un proceso interno. Segundo, el costo de oportunidad de no poder escalar: si cada nueva aplicación requiere la misma intervención manual, el retorno marginal de cada implementación adicional no mejora con el tiempo. La curva de costos no baja. La promesa de la plataforma no se materializa.

El patrón histórico que la industria de IA todavía no atravesó

Dans conecta el momento actual de la IA empresarial con tres transiciones tecnológicas que sí lograron industrializarse, y la comparación es incómoda para quien prefiere pensar que los agentes de IA son un fenómeno sin precedente.

Edgar F. Codd desarrolló el modelo relacional de datos en los años setenta. Antes de ese trabajo, las bases de datos eran implementaciones propietarias, cada una con su propio lenguaje, su propia lógica de almacenamiento y su propia forma de acceso. Después de Codd, hubo una abstracción formal: relaciones, atributos, claves, dependencias funcionales. Sobre esa formalización surgió SQL, y sobre SQL surgió un mercado de miles de millones de dólares en software, integraciones y servicios. Lo que hizo posible ese mercado no fue que las bases de datos se volvieran más potentes. Fue que se volvieron describibles con precisión suficiente para que dos sistemas independientes se entendieran sin negociación previa.

La web siguió el mismo patrón. El W3C definió recursos identificados por URIs, un protocolo sin estado formalizado en RFC 9110, y una gramática compartida de métodos HTTP, códigos de estado y HTML. Ninguna empresa inventó el navegador y luego pidió a sus clientes que contrataran consultores para interpretar qué significaban sus páginas. La gramática era pública, formal y suficientemente precisa para que cualquier desarrollador construyera sobre ella sin llamar a nadie.

SAP hizo lo mismo con los procesos empresariales. Su dominio en ERP no vino de tener mejores interfaces que los consultores de la época. Vino de haber formalizado la empresa como objeto técnico: datos maestros, transacciones, lógica contable, inventario, procuración, relaciones operativas. Esa formalización hizo que las implementaciones fueran suficientemente repetibles para que existieran plantillas, socios certificados, extensiones y un mercado secundario robusto. La varianza entre un cliente y otro se redujo lo suficiente para que el conocimiento acumulado en una implementación transfiriera valor a la siguiente.

Lo que tienen en común estos tres casos es que el salto de la capacidad a la plataforma no ocurrió porque la tecnología mejoró. Ocurrió porque alguien definió con precisión qué representaba la tecnología y bajo qué reglas operaba. En los tres casos, hubo un momento de formalización que precedió al momento de escala.

La IA empresarial todavía no atravesó ese momento. Tiene la capacidad. Le falta la gramática.

Lo que McKinsey confirma y la mayoría de los equipos ignora

Las cifras del MIT sobre fracaso no son la única evidencia disponible. La investigación de McKinsey sobre el estado de la IA, referenciada en el artículo de Dans, llega a una conclusión que debería incomodar a los equipos que miden su progreso en número de pilotos lanzados: las empresas que obtienen beneficios materiales de la IA no son las que usan más IA. Son las que rediseñaron sus flujos de trabajo.

Esa distinción no es semántica. Usar IA sobre un proceso existente produce ganancias marginales en el mejor de los casos. Rediseñar el proceso alrededor de una representación formal del trabajo produce algo diferente: un sistema donde la inteligencia artificial no es un accesorio sino una condición de funcionamiento del proceso mismo.

Michael Hammer escribió en Harvard Business Review que las empresas cometen un error predecible cuando adoptan tecnología nueva: aceleran los procesos existentes en vez de reemplazarlos. Dans recupera ese argumento para el momento actual. La versión contemporánea del error de Hammer es tomar un flujo de aprobaciones diseñado para humanos que leen documentos en papel, añadirle un modelo de lenguaje que resume los documentos, y llamar a eso transformación. El proceso tiene la misma estructura causal. Solo tiene un componente más rápido en un paso intermedio.

El rediseño que McKinsey detecta en las empresas con retorno medible tiene una característica estructural: hay una capa que define qué es una entidad en el negocio, qué estados puede tener, qué transiciones son válidas, qué permisos se requieren para cada acción y qué reglas no pueden violarse independientemente de la instrucción que reciba el sistema. Eso no es un prompt elaborado. Es lo que Dans llama la capa formal que la industria todavía no construyó de manera estandarizada.

La diferencia entre tener esa capa y no tenerla es auditable. Sin ella, el sistema puede dar una respuesta distinta a la misma consulta dependiendo del historial de la sesión, del usuario que pregunta o de cómo se formuló la instrucción anterior. Con ella, hay invariantes: el contrato con el cliente no puede modificarse sin autorización del gerente regional, independientemente de lo que el agente haya "entendido" del correo que leyó. Esa garantía no viene del modelo de lenguaje. Viene de la arquitectura que lo contiene.

Para los sectores regulados, esta distinción no es una preferencia técnica. En servicios financieros, salud o sector público, la ausencia de invariantes verificables no es una incomodidad operativa. Es un bloqueador para el despliegue a escala, porque ningún equipo legal va a firmar la responsabilidad sobre un sistema que no puede garantizar consistencia en sus decisiones.

La próxima batalla no es entre modelos, es entre abstracciones

El análisis de Dans termina con una proyección que vale la pena tomar en serio como señal estratégica: la ventaja competitiva en la próxima fase de IA empresarial no la van a ganar los proveedores con los modelos más potentes. La van a ganar los que definan la abstracción formal sobre la que el resto construye.

Eso abre una pregunta con consecuencias de mercado concretas, aunque la respuesta todavía no sea clara. Los candidatos naturales para definir esa abstracción son varios y con incentivos distintos. Los grandes proveedores de nube, Microsoft, Google y Amazon, tienen la distribución y las relaciones empresariales, pero también tienen el incentivo de mantener el modelo de consultoría intensiva que genera ingresos por servicios profesionales. Los laboratorios de modelos como OpenAI y Anthropic tienen la profundidad técnica, pero construyeron sus negocios alrededor de la capacidad de los modelos, no alrededor de la formalización de los procesos que los rodean. Las empresas de software empresarial establecidas, SAP, Salesforce, Oracle, ya operan sobre capas formales de datos y procesos, pero su velocidad de adaptación a nuevas arquitecturas ha sido históricamente lenta.

El espacio más interesante podría pertenecer a un tipo de actor que todavía no tiene nombre claro en el mercado: un especialista en infraestructura de conocimiento y flujo de trabajo cuya propuesta de valor no sea el modelo de lenguaje sino la capa que lo hace operable dentro de una empresa sin requerir traducción manual en cada implementación. Algo análogo a lo que fue el middleware en los años noventa, pero con la capacidad de razonar sobre las reglas que contiene.

La señal de que ese actor está ganando no será un anuncio de producto. Será el momento en que dos empresas de sectores distintos puedan compartir una implementación sin que ninguna de las dos tenga que llamar a un consultor para explicar qué significa "aprobado" en su organización. Cuando la gramática sea suficientemente precisa para que eso ocurra, la fase artesanal de la IA empresarial habrá terminado. Hasta entonces, el 95 por ciento de fracaso no es un accidente estadístico. Es el precio de construir sobre analogías en vez de definiciones.

Compartir

También te puede interesar