Hace solo unos meses, un titular sobre Uber resumió mejor que muchos informes el momento que vive la inteligencia artificial dentro de las empresas: la compañía habría agotado antes de tiempo el presupuesto anual destinado a IA a causa de la adopción masiva de herramientas de programación asistida. El titular tiene fuerza porque combina dos cosas que hoy conviven en tensión: por un lado, la sensación de que la IA multiplica la productividad; por otro, la constatación de que esa productividad no es gratuita y de que, si no se gobierna bien, puede disparar el coste operativo a una velocidad inquietante.

Ese es, en realidad, el núcleo del problema al que empiezan a enfrentarse muchas organizaciones. Han aprendido a incorporar modelos generativos a sus flujos de trabajo, pero todavía no han aprendido a pensarlos económicamente. Entienden la promesa, intuyen el retorno y experimentan con entusiasmo, pero a menudo siguen presupuestando estas herramientas como si fueran software tradicional. Y no lo son. A medida que crecen los casos de uso y aumenta la dependencia funcional de la IA, lo que entra en juego ya no es solo la calidad de los resultados, sino la sostenibilidad de su coste a corto, medio y largo plazo.

Por eso el debate importante no es si la IA compensa o no compensa. La pregunta relevante es otra: cómo se diseña una arquitectura de trabajo con IA que sea útil, escalable y al mismo tiempo asumible. Ahí es donde el caso Uber resulta interesante, no tanto por la espectacularidad del titular como por la lección de fondo que deja entrever.

Uber como síntoma de un cambio de modelo

Uber es una gran empresa tecnológica de movilidad, reparto y servicios digitales con una estructura corporativa de decenas de miles de trabajadores a escala global. Cuando una organización de este tamaño decide incorporar herramientas de IA al corazón de su operativa técnica, no está haciendo una prueba de laboratorio: está alterando la forma en que produce, desarrolla y toma decisiones.

La incorporación de herramientas de programación asistida por IA creció con mucha rapidez dentro de la compañía hasta llegar a miles de ingenieros de software usándolas a diario. En paralelo, el uso de estas herramientas no se limitó a tareas anecdóticas o experimentales, sino que se integró en procesos recurrentes de desarrollo. Cuando este tipo de adopción se produce a gran escala, el coste deja de depender del número de personas con acceso a una herramienta y pasa a depender de la intensidad con la que se utiliza.

Ese matiz es esencial. El problema no es que Uber usara IA, sino que su adopción efectiva desbordó el modelo mental con el que probablemente se había pensado el presupuesto. Si una empresa calcula el gasto en términos de licencias o asientos, pero el coste real depende del volumen de tokens consumidos, de la longitud del contexto procesado y del número de llamadas ejecutadas por los agentes, tarde o temprano se produce el desalineamiento. Y cuando la herramienta funciona bien, ese desalineamiento se acelera todavía más. En realidad, lo que está haciendo UBER es vender un caso de éxito, no nos engañemos.

Por qué un LLM no se gestiona como un software convencional 

Durante años, las empresas han aprendido a convivir con un ecosistema de software relativamente predecible. Se contratan herramientas, se asignan usuarios, se negocian licencias y se trabaja con unos costes mensuales o anuales razonablemente estables. Ese esquema ha funcionado bien para CRMs, ERPs, herramientas creativas, recursos de ofimática, plataformas de colaboración y la mayoría de soluciones habituales de productividad corporativa.

La IA generativa, en cambio, rompe esa lógica. Aquí no se paga solo por tener acceso a una plataforma, sino por cada proceso de inferencia, por cada fragmento de contexto procesado y por cada output que se genera. Dicho de una manera muy simple: no pagamos solo por entrar en la herramienta, sino por cada vez que la hacemos pensar, leer, calcular o escribir.

Esta diferencia es decisiva porque introduce tres fuentes de tensión presupuestaria. La primera es el tamaño del modelo y de la ventana de contexto: cuanta más información se carga en cada consulta, más recursos se consumen. La segunda es el paso del simple asistente conversacional hacia agentes que operan de forma más autónoma, encadenando acciones, consultando fuentes y ejecutando procesos complejos. La tercera es la variabilidad extrema del uso: dos personas trabajando con la misma herramienta pueden generar costes mensuales radicalmente distintos según la naturaleza de lo que le pidan.

Desde el punto de vista financiero, esto se parece menos a comprar software de oficina y más a gestionar infraestructura de computación. Hay que pensar en picos de uso, en eficiencia operativa, en cargas de trabajo y en límites de consumo. Es otra cultura presupuestaria y conviene asumirlo cuanto antes.

Cuando la productividad también encarece la operación

La idea de que nos estamos volviendo dependientes de la IA describe una realidad bastante tangible y que ya no se discute en despachos y oficinas. Cuando una herramienta reduce fricciones, acorta plazos y eleva la capacidad de producción, los equipos la incorporan a su rutina con una rapidez sorprendente. Al principio es una ayuda puntual; poco después se convierte en una pieza central de la forma de trabajar. Genera dependencia y cualquiera sabe que volver atrás, a trabajar como hace cuatro o cinco años, resulta mentalmente imposible para quienes ya acumulan muchas horas de vuelo de la mano de los LLMs.

Esto está ocurriendo tanto en grandes corporaciones como en empresas medianas. Redactar, sintetizar, analizar, programar, documentar, investigar o preparar entregables son actividades que hoy ya se pueden acelerar de manera significativa con IA. Lo que a menudo se infravalora es que cada mejora percibida en productividad tiende a generar más uso, y más uso significa más consumo de recursos computacionales.

En este sentido, el caso Uber es útil porque pone sobre la mesa una verdad incómoda: el éxito de una herramienta también puede convertirse en un problema de costes. Cuando la tecnología es lo bastante buena como para que los equipos la usen para casi todo, la cuestión deja de ser la adopción y pasa a ser la gobernanza. Ahí es donde muchas empresas todavía no han llegado, pero se dirigen cuesta abajo y sin frenos. El problema aparecerá y tendrán que afrontarlo más pronto que tarde.

Los presupuestos ya no pueden hacerse contando solo usuarios 

Si una empresa quiere escalar el uso de la IA, tiene que aprender a presupuestar de una manera diferente. La unidad de medida relevante ya no es solo el número de usuarios, sino el volumen de tokens que se consumen y el tipo de carga de trabajo que se está ejecutando. No cuesta lo mismo una consulta breve que un proceso que analiza documentación extensa, realiza varios pasos intermedios y genera una respuesta compleja. No es lo mismo pedir un markdown que un PDF, por ilustrar el caso con un ejemplo muy concreto.

Esto obliga a trabajar sobre nuevos y diversos escenarios. Hay que distinguir entre usos ligeros y usos intensivos, entre flujos puntuales y automatizaciones recurrentes, entre asistentes simples y agentes capaces de orquestar múltiples acciones. Esta manera de pensar sigue siendo nueva para muchas organizaciones, pero es imprescindible si se quiere evitar que un piloto exitoso se convierta en una chapuza operativa cara y difícil de sostener. Quien esté libre de pecado puede lanzar la primera piedra y seguramente lo que estará indicando es que en realidad no tiene horas de vuelo peleándose de verdad con modelos de IA.

La situación también obliga a revisar el mix de modelos utilizados. No todas las tareas necesitan el mejor modelo disponible ni la máxima ventana de contexto. En muchos casos, una parte muy importante del coste nace de haber sobredimensionado la solución. Cuando se generaliza el uso del modelo más potente por defecto, el presupuesto empieza a degradarse sin que la organización obtenga siempre un retorno proporcional.

Eficiencia de uso: dónde se decide buena parte del margen 

Una parte considerable del sobrecoste asociado a la IA no proviene tanto de la tecnología en sí como de malas decisiones de diseño. En las empresas es habitual priorizar que un proceso funcione rápido y demostrar que el caso de uso es viable. El problema es que, una vez que el sistema ya está en marcha, a menudo no se dedica suficiente tiempo a optimizarlo.

Ese es un error comprensible pero caro. Hay muchas tareas rutinarias que pueden funcionar perfectamente con modelos más económicos, contextos más delimitados y flujos más simples. Sin embargo, tendemos a operar con el máximo de potencia por defecto, como si cualquier petición requiriera el máximo nivel de sofisticación. Esa inercia es cómoda y genera sensaciones muy agradables, pero suele ser ineficiente.

Diseñar patrones de uso inteligentes significa, entre otras cosas, reservar los modelos más exigentes para los casos que realmente lo requieren, limitar el contexto cuando no aporta un valor claro y reutilizar resultados intermedios siempre que sea posible. También significa ordenar mejor la documentación, delimitar bien los proyectos y construir entornos donde la herramienta no tenga que redescubrir continuamente el mismo conocimiento. Cuando eso se hace bien, no solo baja el coste: también mejora la coherencia del sistema y la calidad del trabajo.

Sin visibilidad del consumo no hay control real 

Otro error habitual es pensar que el gasto en IA podrá revisarse con la misma calma con la que se revisan otras partidas de software. No es así. La variabilidad de uso puede ser tan alta que un cambio aparentemente menor en un flujo de trabajo puede duplicar o triplicar el consumo en pocas horas.

Por eso la monitorización en tiempo real no es un lujo, sino una necesidad. Las empresas que quieran operar con IA de forma madura necesitan cuadros de mando que permitan ver coste por usuario, por equipo, por proyecto e incluso por agente. No por afán de control excesivo, sino porque sin visibilidad es muy difícil corregir desviaciones antes de que se vuelvan problemáticas.

Esa monitorización debería ir acompañada de límites concretos. Límites de gasto, alertas de consumo, auditorías periódicas de prompts, revisión de flujos y control sobre qué procesos están generando valor y cuáles simplemente consumen recursos. La IA puede ser muy rentable, pero solo cuando la organización sabe distinguir entre uso intensivo y uso inteligente.

Un reto que no es exclusivo de los grandes

Este reto puede ser todavía más relevante en empresas medianas o pequeñas. Una gran corporación puede asumir mejor una desviación presupuestaria importante porque tiene más músculo financiero, más margen de error y más capacidad para absorber económicamente el coste de aprendizajes caros. En cambio, en organizaciones más compactas, un mal dimensionamiento del coste puede afectar directamente a la rentabilidad de un servicio, al margen de un proyecto o a la viabilidad de una línea completa de trabajo.

Los riesgos, en esencia, son los mismos. Es fácil subestimar lo que ocurre cuando un piloto se convierte en despliegue real. También es habitual que los equipos, una vez descubren la utilidad práctica de la IA, incrementen su uso de forma orgánica y continua. Y a todo ello se suma otra dificultad: los modelos evolucionan muy deprisa, cambian sus capacidades, se modifican los patrones de uso y el perfil de coste puede variar en muy poco tiempo.

Por eso cualquier empresa que quiera integrar la IA con seriedad necesita algo más que entusiasmo y herramientas atractivas. Necesita criterio operativo, disciplina de seguimiento y una visión realista de lo que cuesta producir con inteligencia artificial cuando esta deja de ser una prueba y se convierte en infraestructura de trabajo.

La lección de fondo es clara. Implantar IA en una empresa no consiste solo en abrir cuentas, probar modelos y celebrar las ganancias iniciales de productividad. Consiste en entender que cada proceso automatizado, cada agente desplegado y cada capa de inteligencia añadida amplía también la necesidad de gobernar mejor el consumo. En este terreno, los tokens no son un detalle técnico: son una variable central del negocio.