El retorno de la IA empresarial es un problema de arquitectura, no de inteligencia
Hay una cifra que los CIOs están memorizando con incomodidad: el 72% de las organizaciones admite que sus inversiones en IA están, en el mejor de los casos, en el punto de equilibrio. En el peor, perdiendo dinero. Gartner publicó ese número y no generó pánico, pero sí algo más persistente: una silenciosa incertidumbre sobre cuánto tiempo más se puede sostener una apuesta sin demostrar que funciona.
La respuesta habitual apunta a los modelos. Hay que elegir mejor el proveedor, afinar los prompts, esperar que los precios de inferencia bajen. Esa respuesta es cómoda y casi siempre equivocada. Lo que está fallando no es la inteligencia de la máquina. Lo que está fallando es la arquitectura del negocio que la rodea.
El problema tiene una mecánica muy concreta: cada vez que una empresa lanza un nuevo agente de IA, ese agente empieza desde cero. Reconecta datos, reconstruye el contexto del negocio, renegocia permisos, rediseña controles, establece sus propios criterios de validación. Si hay seis agentes en producción, hay seis versiones paralelas e independientes de esa infraestructura. Cada una con su propio costo, su propia deuda técnica, su propia opacidad. El resultado no es inteligencia artificial a escala. Es burocracia digital a escala.
Por qué el costo real de la IA no aparece en la línea de inferencia
La trampa contable es sofisticada. Cuando un equipo evalúa si un proyecto de IA tiene sentido económico, normalmente mira el costo del modelo: cuánto cuesta llamar a la API, cuántos tokens consume cada consulta, qué proveedor ofrece mejor precio por capacidad. Ese análisis no es incorrecto, pero captura apenas una fracción del costo total.
Lo que no aparece en esa línea es el costo de integración repetida. Cada agente que se despliega sin una capa compartida de contexto empresarial necesita que alguien construya, desde cero, sus conexiones con los sistemas de registro de la empresa, sus mecanismos de autorización, sus reglas de negocio, su lógica de escalamiento. Eso no es un costo de modelo. Es costo de ingeniería, de gobernanza, de operaciones. Y se repite íntegramente con cada nuevo caso de uso.
Un equipo de servicios financieros estudiado por investigadores de la Universidad de Hong Kong y Stellaris AI encontró que más del 70% de sus consultas eran lo suficientemente rutinarias como para resolverse con modelos más pequeños y baratos. Sin embargo, todo corría sobre la misma infraestructura de alto costo porque nadie había diseñado un mecanismo para discriminar por complejidad. El gasto de inferencia superaba los 200.000 dólares mensuales no porque el negocio fuera sofisticado, sino porque la arquitectura no tenía memoria de cuándo serlo.
El problema de distribución de costos tiene otro ángulo menos visible: cuando los costos están dispersos entre integraciones, equipos y herramientas, atribuir el valor generado se vuelve matemáticamente imposible. No es que el ROI sea bajo. Es que no hay forma de medirlo porque no hay un registro unificado de qué datos usó cada agente, qué decisiones tomó, cuánto costó cada paso y qué resultado produjo. La fragmentación no solo encarece el despliegue. Destruye la trazabilidad que haría posible justificar la inversión.
Lo que una capa compartida cambia en la economía del despliegue
La solución que empieza a articularse entre arquitectos de sistemas empresariales no es contratar menos IA ni mejores modelos. Es construir una capa de contexto compartida que funcione como la columna vertebral de todos los agentes y flujos de trabajo de la organización.
La idea tiene una lógica económica precisa. Si el conocimiento empresarial, los permisos, las reglas de negocio y la lógica de gobernanza se construyen una sola vez y se exponen como infraestructura reutilizable, el costo marginal de desplegar el segundo, el quinto y el décimo caso de uso cae de forma significativa. No porque los modelos sean más baratos, sino porque la empresa ya no paga el costo de reconectar su propio negocio cada vez que agrega una nueva aplicación.
Una empresa multinacional del sector de cosméticos pasó por esto. Sus primeros agentes funcionaban bien en demos, pero colapsaban en producción porque cada una de las seis soluciones que habían integrado mantenía su propio repositorio de conocimiento y sus propias reglas de gobernanza en silos independientes. Cada agente empezaba frío. Cada proyecto nuevo exigía reconectar desde cero. El costo no era el modelo. Era la repetición.
La centralización del contexto también cambia la lógica del enrutamiento. Cuando la infraestructura sabe qué tipo de tarea está procesando, puede dirigirla al modelo adecuado: uno más potente y costoso para razonamiento complejo, uno más pequeño y rápido para consultas rutinarias. El gasto de inferencia deja de ser un costo fijo y se convierte en una variable que responde a la complejidad del trabajo. Eso no es optimización marginal. Es una reconfiguración del modelo de costos.
Complementariamente, la arquitectura de enjambres de agentes especializados produce resultados similares desde el lado de la eficiencia computacional. En lugar de un superagente que necesita procesar el contexto completo de un problema en cada paso, múltiples agentes con dominios acotados operan en paralelo. Cada uno trabaja con una ventana de contexto más pequeña, más precisa, más barata. La coordinación entre agentes exige gobernanza compartida para funcionar sin crear nuevos riesgos operacionales, pero cuando esa gobernanza existe, el ahorro en tokens por tarea puede ser considerable.
La gobernanza no es el freno. Es la condición de escala.
McKinsey documentó algo que muchos equipos de tecnología han aprendido por las malas: incorporar gobernanza después de que la IA ya está en producción genera costos de reingeniería que pueden superar el valor que el sistema estaba generando. Gartner estima que tecnologías de gobernanza bien integradas pueden reducir los gastos regulatorios hasta en un 20%. Esos no son números de cumplimiento. Son números de arquitectura.
El problema con la gobernanza como capa agregada al final es el mismo que con el contexto como trabajo repetido: se reconstruye íntegramente para cada aplicación. Un flujo de trabajo de reclamaciones en seguros necesita acceso controlado a datos de asegurados, trazabilidad de decisiones, límites en la autonomía del agente y reglas de escalamiento hacia revisión humana. Si eso se diseña solo para ese flujo, hay que diseñarlo de nuevo para el siguiente. Diez agentes independientes significan diez versiones de la misma arquitectura de control, diez veces el costo de aprobación, diez veces el riesgo de inconsistencia.
Cuando la gobernanza se construye como plataforma, los controles se definen una vez como código y se aplican transversalmente. El costo no escala linealmente con el número de agentes porque los controles existen antes de que los agentes lleguen. Esa diferencia es la que separa a las organizaciones que pueden escalar la IA de las que acumulan deuda técnica y operacional mientras creen que están escalando.
La trazabilidad que produce una plataforma de gobernanza tiene un beneficio adicional que pocas conversaciones de ROI mencionan explícitamente: convierte la IA de caja negra en sistema auditable. Cada flujo de trabajo deja un registro de qué datos usó, qué acciones tomó, qué intervención humana requirió, cuánto costó y qué resultado produjo. Eso no es solo control de riesgo. Es la infraestructura que hace posible medir el valor económico con la granularidad que los consejos directivos y los inversores van a exigir cada vez con más urgencia.
La arquitectura como decisión de distribución del valor
Hay una dimensión que el análisis técnico tiende a dejar fuera, pero que tiene consecuencias económicas directas: la arquitectura de IA no solo determina qué tan eficientemente opera la empresa. Determina quién captura el valor que la IA genera.
Una organización que construye una capa de contexto compartida, un mecanismo de enrutamiento inteligente y una plataforma de gobernanza unificada está construyendo activos internos que reducen su dependencia de proveedores externos. Puede cambiar el modelo de lenguaje subyacente sin reconstruir la lógica de negocio. Puede agregar nuevas aplicaciones sin volver a pagar el costo completo de integración. Puede auditar el valor de cada flujo de trabajo porque tiene la infraestructura para hacerlo.
Una organización que no construye eso está, en cambio, externalizando permanentemente las economías de escala de la IA. Cada nuevo proveedor, cada nuevo modelo, cada nueva herramienta captura una porción del valor porque la empresa no tiene la arquitectura que le permitiría internalizar esa captura. El costo de cambio sube. La capacidad de negociación baja. El valor generado por la IA se filtra hacia afuera en lugar de acumularse adentro.
Eso tiene implicaciones para cómo evaluar el gasto en IA. La pregunta que los CIOs deberían estar respondiendo no es cuánto cuesta el modelo, sino qué parte de ese gasto está construyendo capacidad reutilizable y qué parte está pagando, otra vez, por capacidad que ya se debería tener. La respuesta a esa pregunta es la diferencia entre una inversión en arquitectura y un gasto que se repite sin acumular.
El 72% de organizaciones que están en punto de equilibrio o perdiendo no tiene necesariamente malos modelos. Tiene una arquitectura que garantiza que el costo de cada nuevo caso de uso es casi tan alto como el del primero. Eso no es un problema de inteligencia. Es un problema de diseño. Y los problemas de diseño tienen soluciones más específicas, más duraderas y más medibles que esperar que los precios de inferencia bajen lo suficiente para que las cuentas cuadren solas.
