El pipeline de IA empresarial no pierde dinero por los tokens: lo pierde antes
Hay un momento en el que la acumulación de pilotos de inteligencia artificial deja de parecer ambición y empieza a parecer desorden. Ese momento llegó a muchas grandes empresas en 2026, y la señal más clara no fue un colapso tecnológico ni un fracaso de modelo. Fue algo más mundano y más difícil de defender en una reunión de directorio: el consumo de tokens corrió por delante del presupuesto sin generar valor proporcional.
Uber fue uno de los casos que salió a la luz. La empresa ajustó su gasto interno en IA después de que el consumo superara lo planeado. No fue una excepción extraña; fue el síntoma visible de un patrón que se repite en organizaciones que adoptaron IA con lógica maximista durante los dos años anteriores: más casos de uso, más agentes desplegados, más empleados incorporados al sistema, más tokens consumidos. La lógica era defensible al principio. Cuando una tecnología es nueva y su potencial de transformación no está claro, la exploración amplia tiene sentido. El problema es que esa exploración no se detuvo cuando debía haber cedido el paso a una arquitectura deliberada.
Sumeet Agrawal, Vicepresidente de Gestión de Producto para Datos, Gobernanza de IA e Ingeniería de Contexto en Salesforce, publicó en Fortune un diagnóstico que merece más atención de la que suele recibir una columna de opinión corporativa. Su argumento central es preciso: bajar el precio de los tokens no resuelve el problema porque el problema no está en el precio. Está en cómo las empresas están arquitectadas para usarlos.
Una tubería que filtra en cada etapa
La metáfora que usa Agrawal es útil porque es exacta: el pipeline moderno de IA en una empresa grande se comporta como una coladera. Filtra tokens, y con ellos dinero, en cada fase de ejecución. Y no lo hace por accidente; lo hace por diseño. O más precisamente, por ausencia de diseño.
Cuando un agente recibe una consulta de ventas o de servicio al cliente, lo primero que hace, si no tiene una infraestructura de datos bien construida debajo, es inundar el prompt con contexto crudo. Datos sin curar, registros duplicados, historial sin priorizar. El modelo entonces procesa esa masa de información, la mayoría de la cual es ruido. Según Agrawal, ese exceso puede significar entre cinco y diez veces más tokens de los necesarios por interacción. A precios de entre diez y quince dólares por millón de tokens, y con miles de interacciones diarias en una empresa de escala media-grande, la aritmética se vuelve difícil de ignorar rápidamente.
El segundo punto de fuga es el acceso no gobernado a los datos. Sin un catálogo claro, sin linaje, sin señales de calidad, los agentes navegan almacenes de datos buscando información confiable. El proceso es lento, caro y produce resultados inconsistentes. La gobernanza, cuando existe, suele funcionar como un control posterior, no como una señal de enrutamiento que dirija al agente hacia los datos certificados desde el primer intento.
El tercer punto de fuga es quizás el más costoso en términos de presupuesto directo: enviar cada tarea al modelo más grande disponible, independientemente de la complejidad de la tarea. Una clasificación rutinaria o una búsqueda simple no requieren el mismo modelo que un razonamiento complejo o una decisión sensible. Tratar todos los casos con el mismo modelo de frontera es el equivalente organizacional de usar un equipo de directivos senior para tareas que podría resolver un analista junior: técnicamente posible, funcionalmente absurdo.
Los dos últimos puntos de fuga son menos visibles pero igualmente costosos. Los agentes sin memoria persistente comienzan cada interacción desde cero: recargan contexto, reprocesán historial, redescubren excepciones que ya estaban resueltas. Y los agentes sin semántica reutilizable vuelven a generar respuestas que podrían haber sido almacenadas en caché o precomputadas. Cada interacción recurrente se paga como si fuera la primera.
Lo que los proveedores no pueden resolver por ti
Anthropic, OpenAI y Google han bajado precios de tokens de entrada y lanzado mecanismos de caché de prompts. Cursor, en su versión Composer 2.5, incorpora el costo como variable en la selección de modelos, no solo el rendimiento. Estas son respuestas racionales a la presión de los clientes, pero atacan la variable equivocada si la empresa no tiene resueltos sus problemas de arquitectura interna.
Reducir el precio por token en un sistema que consume diez veces más tokens de los necesarios produce un ahorro proporcional, pero no cierra la brecha estructural. Es una mejora lineal sobre un problema que tiene solución de orden de magnitud. La empresa que resuelve primero la arquitectura obtiene una ventaja que la reducción de precios no puede replicar, porque esa ventaja no está en el mercado de tokens: está en la calidad de los datos propios, en la gobernanza de los flujos y en la capacidad de enrutar trabajo al modelo correcto según la naturaleza de cada tarea.
Agrawal lo formula con claridad: cualquier empresa puede comprar más tokens. Muy pocas saben cómo extraer más valor de menos tokens. La diferencia entre ambas no es tecnológica en el sentido estrecho del término. Es arquitectónica y organizacional.
El ejemplo que ofrece es concreto: la integración entre la gestión de datos maestros de Informatica y Data 360, la plataforma de datos de clientes de Salesforce, garantiza que cada agente opere sobre contexto de cliente verificado y enriquecido semánticamente. El resultado no es solo eficiencia de tokens: es la conversión del consumo no gobernado de IA en valor de negocio medible y auditable.
El verdadero costo del diseño ausente
Desde una perspectiva de diseño organizacional, lo que describe Agrawal no es un problema tecnológico ni un problema de precios. Es el costo diferido de haber saltado la fase de exploración disciplinada para instalarse en una fase de explotación prematura de una tecnología que todavía no tenía los cimientos para ser explotada de forma eficiente.
Las empresas que adoptaron IA con lógica maximista entre 2024 y 2025 lo hicieron bajo presión legítima: la incertidumbre sobre qué modelos, qué flujos de trabajo y qué equipos generarían valor justificaba una estrategia de despliegue amplio. Lo que no justificaba, y que muchas organizaciones no hicieron, era construir en paralelo la infraestructura de datos y gobernanza que iba a determinar si ese despliegue escalaría de forma sostenible o simplemente acumularía deuda técnica.
El problema no es haber explorado. Es haber explorado sin diseño de fondo. Y ahora ese diseño ausente se presenta en forma de facturas de tokens que superan los planes y resultados que no pueden atribuirse a inversiones específicas.
Hay un patrón en los casos de adopción tecnológica empresarial que vale la pena nombrar: las organizaciones tienden a medir demasiado pronto con los criterios equivocados, condenando iniciativas que aún no deberían estar siendo juzgadas con las mismas métricas que el negocio central. Pero también tienden a dejar demasiado tiempo sin métrica alguna iniciativas que ya deberían estar produciendo valor. Con la IA empresarial, muchas compañías hicieron lo segundo: desplegaron sin medir ni arquitectar, y ahora enfrentan el ajuste desde una posición de mayor desorden y mayor costo acumulado.
La corrección no es costosa en términos absolutos. Un catálogo de datos bien construido, señales de calidad que funcionen como enrutadores, memoria persistente para los agentes, reglas claras de asignación de modelos según complejidad de tarea: ninguna de estas decisiones requiere un presupuesto excepcional. Requieren algo más difícil de conseguir en organizaciones que ya están en modo de escala: prioridad deliberada y disciplina arquitectónica sostenida en el tiempo.
La ventaja que no se puede comprar en el mercado de modelos
Agrawal enmarca la eficiencia de tokens como la siguiente ventaja competitiva en la IA empresarial. La lectura es correcta pero puede refinarse. La ventaja real no está en la eficiencia de tokens como métrica aislada. Está en la capacidad organizacional de convertir datos propios en contexto confiable para agentes que operan a escala, con gobernanza suficiente para que los resultados sean auditables y atribuibles.
Eso no es una capacidad que se compra a un proveedor de modelos ni se obtiene reduciendo el precio por millón de tokens. Es una capacidad que se construye internamente, con decisiones de arquitectura de datos que preceden al despliegue de agentes y no al revés. Las empresas que ya tienen esa infraestructura obtienen una ventaja que se amplía con el tiempo: cada interacción es más barata, más rápida y más confiable que la anterior. Las que no la tienen se enfrentan a costos que no caen porque los precios de los tokens bajen.
El mercado de modelos de lenguaje seguirá siendo más barato con el tiempo. Eso es casi seguro. Pero la brecha entre empresas que saben usar IA con eficiencia y las que no seguirá siendo un problema de diseño organizacional, de calidad de datos y de gobernanza. Y esa brecha no tiene solución en el catálogo de ningún proveedor externo.
Las organizaciones que en 2026 todavía operan con agentes estateless, sin catálogos de datos funcionales y enviando toda carga de trabajo al modelo más costoso disponible, no están pagando por tokens. Están pagando el precio diferido de no haber diseñado su infraestructura de IA cuando todavía era barato hacerlo.
