El sobrecoste del presupuesto de IA de Uber expone la brecha entre adopción y retorno
Según informes, Uber agotó su presupuesto de IA para 2026 en abril, lo que expone un conflicto entre alentar a los empleados a utilizar IA y controlar el coste de esa adopción. El caso del presupuesto de IA de Uber se ha convertido ahora en el eje de un debate empresarial más amplio: ¿cuándo el mayor uso se convierte en evidencia de productividad, en lugar de simplemente un mayor gasto?
Business Standard retomó esta tensión el 8 de noviembre y describió cómo las empresas se orientan hacia controles de gasto, modelos más pequeños y una asignación más selectiva de tareas. Bloomberg ya había informado sobre los límites de uso de Uber en junio. Por tanto, el problema inmediato es una corrección de gasto en desarrollo, no una nueva política corporativa recién anunciada.
Para los compradores empresariales, la disputa central está entre los objetivos de adopción y los retornos empresariales medibles. Claude Code de Anthropic se encuentra directamente dentro de esa tensión. Un asistente de programación puede popularizarse antes de que su comprador determine si el gasto adicional produce lanzamientos más rápidos, mejor software o menos trabajo en otros ámbitos.
El caso del presupuesto de IA de Uber ha pasado de la adopción a la rendición de cuentas
Bloomberg informó el 2 de junio que Uber había introducido límites de uso de IA tras superar su presupuesto a principios de año. Su informe identificó específicamente herramientas como Claude Code.
Esto establece un registro público anterior para el problema de gasto. También separa el desarrollo original de la empresa de la discusión más amplia de noviembre. Los lectores no deberían interpretar la cobertura más reciente como evidencia de que Uber introdujo otra ronda de restricciones esta semana.
La cobertura de noviembre de Business Standard sitúa a Uber junto a otras empresas que están reevaluando los costes empresariales de IA. Su relato describe un interés creciente en modelos más pequeños y sistemas que distribuyen el trabajo entre modelos.
El cambio documentado es un giro hacia el control del consumo después de que la adopción superara las previsiones de gasto originales.
La información pública no ofrece un relato completo de la economía interna de Uber. No determina si el presupuesto original era adecuado, todos los gastos cubiertos ni el valor de todo el trabajo realizado.
Estas omisiones importan. Un presupuesto agotado puede reflejar desperdicio, software inesperadamente útil, una previsión poco realista o alguna combinación de estos factores. El sobrecoste por sí solo no puede distinguir entre esas explicaciones.
Un presupuesto también representa una decisión organizativa tomada antes de que la demanda real sea clara. Los empleados que descubren aplicaciones valiosas pueden superar una previsión conservadora sin tomar decisiones económicamente irracionales.
A la inversa, un entusiasmo generalizado no puede demostrar que el gasto adicional compense. Los usuarios pueden preferir una herramienta mientras pasan por alto el tiempo de revisión, el trabajo de integración o los errores que sus colegas deben resolver.
Esto deja a la dirección ante una pregunta más difícil que si a los empleados les gusta el software. La cuestión relevante es si sus beneficios superan su carga operativa total.
Esa carga va más allá de generar una respuesta. Un cambio de código propuesto aún necesita revisión, pruebas, integración y mantenimiento. Una redacción más rápida solo mejora la entrega cuando esas etapas posteriores preservan la ganancia.
Por tanto, los informes respaldan el escrutinio de la gobernanza del gasto, en lugar de un veredicto de que los asistentes de programación han fracasado. También cuestionan la suposición de que la adopción aporta evidencia suficiente de éxito.
La distinción es especialmente relevante cuando el liderazgo impulsa la experimentación antes de que los departamentos reciban una responsabilidad clara sobre el gasto. Las decisiones individuales pueden parecer razonables mientras que su coste combinado supera las expectativas.
Consideremos un equipo de ingeniería ilustrativo que investiga un defecto difícil. Varios desarrolladores podrían pedir de forma independiente a asistentes que inspeccionen el mismo repositorio y propongan soluciones. Cada solicitud tiene un propósito legítimo.
Sin embargo, la empresa todavía debe saber si esas investigaciones superpuestas producen valor distinto. Contar usuarios activos mostraría participación, pero pasaría por alto el trabajo duplicado.
Esta es la brecha de rendición de cuentas que el caso de Uber pone de relieve. La decisión de compra y la evaluación de productividad no pueden permanecer separadas indefinidamente.
Los equipos financieros heredan un problema que los paneles de uso no pueden responder
La presión de gasto se extiende más allá de una sola empresa tecnológica. La encuesta sectorial de 2026 de FinOps Foundation afirma que el 98% de los encuestados ya gestiona el gasto en IA, frente al 31% de hace dos años.
FinOps es la práctica de vincular el gasto tecnológico con la responsabilidad y el valor empresariales. Su creciente ámbito de IA sugiere que estos costes requieren cada vez más coordinación entre finanzas e ingeniería.
La encuesta cubre a 1.192 encuestados de la comunidad FinOps. Es una muestra significativa de profesionales, pero no representa a todas las empresas ni demuestra dificultades financieras universales.
Sus hallazgos también describen una fuerte inversión en IA y organizaciones que buscan ahorros de optimización para financiar una mayor adopción. Por lo tanto, el escrutinio financiero puede apoyar la expansión en lugar de indicar una retirada.
La presión inmediata recae sobre los líderes que deben explicar tanto el gasto como el resultado empresarial que este compra.
Los responsables de ingeniería afrontan instrucciones contrapuestas. Necesitan que los empleados descubran aplicaciones útiles, pero deben evitar tratar la experimentación ilimitada como un modelo operativo.
Los líderes financieros afrontan un problema de información diferente. Una factura muestra el desembolso, pero rara vez explica si un asistente eliminó trabajo, lo desplazó o creó obligaciones adicionales.
Los equipos de compras deben evaluar los compromisos comerciales frente a una demanda incierta. Un contrato puede facilitar la compra del consumo sin hacer que el trabajo resultante sea más fácil de medir.
Los responsables de producto afrontan las consecuencias cuando las restricciones presupuestarias interrumpen una actividad útil. Un límite de gasto que llega de forma inesperada puede cambiar las previsiones de entrega a mitad de un proyecto.
Estas presiones convergen en torno al coste por resultado aceptado, es decir, el gasto total asociado a una salida que cumple su estándar previsto. Ese estándar debe incluir la calidad.
Para los equipos de software, un resultado aceptado podría ser un cambio revisado que llega a producción sin crear defectos adicionales. El código generado es un artefacto intermedio.
Para una operación de soporte al cliente, un resultado aceptado podría ser una solicitud resuelta correctamente. Una respuesta fluida que provoca otro contacto no entrega el mismo valor.
Para los trabajadores del conocimiento, un resultado útil podría ser un informe preciso con evidencia rastreable. Un borrador rápido que exige una verificación extensa ofrece una propuesta económica distinta.
Estos ejemplos ilustran por qué un objetivo universal de uso genera problemas. Distintas tareas conllevan diferentes niveles de riesgo, requisitos de revisión y oportunidades para corregir errores.
Un departamento que reduce el gasto mientras aumenta la corrección manual no ha mejorado necesariamente su economía. Ha trasladado el gasto a una categoría menos visible.
También ocurre lo contrario. Un mayor gasto en modelos puede tener sentido cuando elimina un cuello de botella que antes consumía la escasa atención de los empleados.
Esto convierte la atribución en un elemento central del debate empresarial. Las empresas necesitan vincular el consumo con el equipo, el flujo de trabajo y el resultado responsables de este.
La atribución no exige tratar cada solicitud de un empleado como una excepción financiera. Una fricción excesiva de aprobación puede consumir el mismo tiempo de trabajo que el software promete ahorrar.
El cambio más amplio está en el punto en que la responsabilidad entra en el proceso. Las previsiones de gasto pertenecen cada vez más a las decisiones de producto e ingeniería antes de que el uso se convierta en una sorpresa contable.
Por eso la gobernanza empresarial de la IA no puede detenerse en un panel. La visibilidad identifica adónde fue el dinero; evaluar el trabajo determina si debía ir allí.
El enrutamiento de modelos cambia la economía, pero añade otra capa de decisión
Los informes de noviembre apuntan hacia la orquestación de modelos, es decir, un sistema de control que coordina modelos y herramientas a lo largo de un flujo de trabajo. El enrutamiento de modelos selecciona qué modelo gestiona una tarea concreta.
La distinción importa porque una organización no siempre necesita la misma capacidad para cada paso. Clasificar un documento y resolver una excepción compleja plantean exigencias distintas.
Un modelo más pequeño podría gestionar adecuadamente una tarea limitada de clasificación. Un modelo más capaz podría seguir siendo necesario cuando la tarea implica ambigüedad o razonamiento difícil.
El uso selectivo de modelos ofrece una respuesta plausible a la presión presupuestaria, pero su valor depende del flujo de trabajo completo.
Esto cambia la comparación entre proveedores como Anthropic, Microsoft y Google. Los compradores empresariales deben evaluar dónde encaja cada servicio, en lugar de seleccionar un modelo para cada actividad.
Esto no establece una clasificación universal entre esas empresas. La comparación relevante se refiere a la carga de trabajo real del comprador, sus requisitos de integración y su tolerancia a los errores.
Un modelo que funciona bien en una evaluación aislada aún puede crear problemas dentro de un proceso empresarial. Su resultado podría requerir más revisión o llegar demasiado tarde.
El enrutamiento introduce su propio criterio. El sistema debe decidir qué solicitudes son lo bastante simples para una ruta menos exigente y cuáles necesitan capacidad adicional.
Una asignación incorrecta puede eliminar el ahorro esperado. Una solicitud difícil enviada a un modelo inadecuado podría requerir repetición, escalado o reparación manual.
Una asignación innecesariamente cautelosa presenta el problema opuesto. Enviar trabajo rutinario a la opción que más recursos consume preserva capacidad, pero debilita el argumento financiero a favor del enrutamiento.
Por tanto, la cuestión económica se extiende más allá del modelo seleccionado para la solicitud inicial. Incluye lo que ocurre cuando esa selección falla.
Un flujo de trabajo documental ilustrativo hace concreto el equilibrio. Un sistema podría identificar primero un tipo de documento, después extraer información y luego señalar pasajes ambiguos para revisión.
Esa disposición solo ayuda si los primeros pasos identifican de forma fiable sus propias limitaciones. Un error de clasificación inadvertido puede contaminar todo lo que sigue.
La organización también hereda trabajo de mantenimiento. Los prompts, los ejemplos de evaluación, las reglas de escalado y el comportamiento de los modelos pueden cambiar con el tiempo.
Estas obligaciones forman parte de la comparación con un despliegue más simple. Un sistema elaborado no se vuelve económico simplemente porque las solicitudes individuales parezcan menos costosas.
Aquí es donde el contexto se vuelve relevante para el trabajo del conocimiento. El contexto es la información que recibe un modelo para interpretar y completar una solicitud.
Enviar material irrelevante puede sobrecargar un flujo de trabajo sin mejorar su resultado. Enviar demasiado poco puede obligar a los empleados a repetir explicaciones o corregir malentendidos.
La misma cuestión práctica aparece en una base de conocimiento consultable. Encontrar el material de origen adecuado y generar una respuesta son partes separadas del trabajo.
Esta conexión no demuestra ahorros para ningún producto concreto. Explica por qué los compradores deberían examinar la recuperación de información junto con la selección de modelos.
El debate sobre el presupuesto de IA de Uber va, por tanto, más allá de un límite de gasto. Plantea una cuestión de diseño: ¿qué partes del trabajo merecen computación adicional y cuáles no?
Los agentes pueden ampliar la capacidad y el consumo al mismo tiempo
Un agente de IA es un sistema que utiliza repetidamente un modelo y herramientas para realizar una tarea. Esa actividad repetida cambia la relación entre las solicitudes y el consumo.
Un intercambio de chat puede terminar tras una respuesta. Un agente puede inspeccionar archivos, ejecutar comprobaciones, reconsiderar su enfoque y seguir trabajando antes de devolver un resultado.
La descripción de Anthropic de junio de 2025 de su sistema de investigación multiagente deja explícita esta disyuntiva. La empresa informó de un mayor consumo de tokens junto con un mejor rendimiento en sus propias evaluaciones.
Los tokens son las unidades de texto que procesa o genera un modelo. Anthropic afirmó que sus agentes consumían normalmente cerca de cuatro veces más tokens que las interacciones de chat.
Sus sistemas multiagente, que coordinan a varios agentes, consumían aproximadamente 15 veces más tokens en los datos de la empresa. Estas cifras describen su sistema de investigación.
No son una medición universal de Claude Code, de todos los productos de agentes ni de los despliegues empresariales actuales. Aplicarlas directamente a Uber exageraría la evidencia.
Una automatización más capaz puede requerir más computación, por lo que un menor consumo no es automáticamente el objetivo correcto.
El relato de Anthropic respalda una conclusión más acotada: algunas arquitecturas gastan deliberadamente más recursos para completar trabajos más difíciles. Su justificación económica depende del valor resultante.
Esto ofrece un contrapeso útil a la narrativa del exceso presupuestario. Una empresa puede aumentar racionalmente el consumo cuando el sistema realiza un trabajo que un software más simple no puede manejar.
La dificultad reside en distinguir la persistencia productiva de la repetición improductiva. Ambas pueden generar un largo registro de actividad y una factura considerable.
Un agente de programación ilustrativo podría ejecutar pruebas después de una corrección propuesta, descubrir otro fallo y revisar su enfoque. Ese trabajo adicional puede evitar un cambio incompleto.
Otro agente podría modificar código repetidamente sin identificar el problema subyacente. Una actividad de aspecto similar puede producir un resultado muy distinto.
La distinción se vuelve más difícil cuando varios agentes operan simultáneamente. El trabajo en paralelo puede acortar el tiempo transcurrido mientras aumenta el consumo combinado.
Por ello, los directivos deben distinguir entre la atención de los empleados y la actividad de las máquinas. Que un sistema funcione durante más tiempo no significa necesariamente que ocupe a un desarrollador durante todo ese período.
Del mismo modo, el aparente ahorro de tiempo de un empleado no refleja el trabajo de revisión transferido a otro equipo. Ambos lados del flujo de trabajo importan.
Esto complica las comparaciones simples entre asistentes de chat, agentes de programación y sistemas coordinados de agentes. Pueden realizar cantidades de trabajo diferentes ante solicitudes de usuario superficialmente similares.
El caso de negocio debe especificar qué cambió. ¿El sistema terminó un análisis que antes era inviable, redujo un cuello de botella para un empleado o simplemente generó material adicional?
La calidad también debe formar parte de esa evaluación. Una ejecución más cara puede ser preferible si evita un error con consecuencias importantes aguas abajo.
No hay contradicción entre reconocer estos beneficios y examinar la factura. La contradicción surge cuando las organizaciones exigen una automatización ambiciosa mientras presupuestan como si los empleados solo intercambiaran mensajes breves.
Las previsiones presupuestarias deben reflejar el trabajo que el producto realmente realiza. De lo contrario, una adopción exitosa puede convertirse por sí misma en el detonante de una restricción de emergencia.
La evidencia sobre productividad se resiste a un veredicto simple
La objeción más sólida a los límites de gasto es directa: pueden suprimir trabajo útil junto con el desperdicio. Una restricción no puede distinguir entre ambos sin evidencia de apoyo.
La objeción más sólida al gasto sin restricciones es igualmente directa: las impresiones de los empleados pueden diferir de los resultados medidos. La satisfacción y la productividad responden a preguntas relacionadas, pero distintas.
METR, una organización independiente de evaluación de IA, ilustró esa distinción en un estudio que utilizó herramientas de principios de 2025. Los desarrolladores experimentados de código abierto que participaron tardaron un 19% más cuando se permitió la asistencia de IA.
El estudio incluyó a 16 desarrolladores y 246 tareas. Su contexto acotado es importante, incluida la familiaridad de los participantes con proyectos consolidados y las herramientas disponibles entonces.
No demuestra que los asistentes de programación actuales ralenticen a todos los desarrolladores. Tratar un resultado anterior como un veredicto universal sobre el presente tergiversaría la investigación.
La actualización de medición de productividad de METR del 24 de febrero de 2026 añade otra complicación. Los investigadores afirmaron que datos experimentales posteriores ofrecían una estimación poco fiable de los efectos actuales sobre la productividad.
Algunos desarrolladores evitaron participar porque no querían trabajar sin IA. Los participantes también reservaron ciertas tareas, lo que generó problemas de selección.
METR consideró probable que los desarrolladores estuvieran obteniendo mayores beneficios que antes, pero hizo hincapié en la incertidumbre sobre su magnitud. Esto evidencia un desafío de medición.
Ni el aumento del uso ni un exceso presupuestario resuelven si la IA crea valor neto.
Esta incertidumbre afecta directamente a la interpretación de la historia del presupuesto de IA de Uber. El registro público respalda la existencia de un problema de control del gasto, pero no proporciona un balance completo de productividad.
Una evaluación creíble tendría que examinar trabajo comparable, incluidos los requisitos de tiempo y calidad asociados a completarlo. Los casos de éxito seleccionados no pueden proporcionar esa comparación.
Los fracasos seleccionados tampoco pueden hacerlo. Los incidentes difíciles pueden revelar debilidades y, al mismo tiempo, decir poco sobre el efecto promedio en una empresa.
La selección de tareas presenta otro obstáculo. Los empleados suelen elegir la IA para trabajos en los que esperan que ayude, lo que dificulta las comparaciones con trabajo no tratado.
A medida que mejoran las herramientas, el propio trabajo puede cambiar. Los equipos podrían emprender proyectos más ambiciosos en lugar de completar más rápido proyectos idénticos.
Eso puede generar valor sin producir una reducción evidente de las horas por tarea. También puede ocultar si una mayor ambición ofrece un resultado útil.
La distinción entre beneficios individuales y organizativos genera más incertidumbre. Un desarrollador puede avanzar más rápido mientras la capacidad compartida de revisión se convierte en el nuevo cuello de botella.
Por ejemplo, cambios adicionales propuestos podrían aumentar la cola que afrontan los revisores sénior. La empresa debe entonces evaluar la entrega global, no solo la velocidad de redacción.
Estas son posibilidades analíticas, no hallazgos publicados sobre Uber. Explican por qué los datos de consumo no pueden sustituir una evaluación de la entrega de software.
La posición escéptica debería aplicarse a los controles financieros tanto como a las afirmaciones de los proveedores. Una factura menor no demuestra que una política haya mejorado la productividad.
Las restricciones merecen ser evaluadas frente a los resultados, igual que la expansión. De lo contrario, las empresas corren el riesgo de sustituir un objetivo de adopción por un objetivo de gasto y repetir el mismo error de medición.
Tres señales mostrarán si la disciplina de gasto mejora el resultado
La siguiente fase debería juzgarse mediante cambios observables, no mediante otra ronda de afirmaciones generales sobre la transformación mediante IA. Tres señales merecen especial atención.
La primera es si los empleadores conectan las políticas de gasto con los resultados de entrega. Las explicaciones públicas de las restricciones resultan más útiles cuando también abordan la calidad, el trabajo terminado y la capacidad de los empleados.
Una empresa que muestre una entrega estable o mejorada tras reducir el consumo innecesario reforzaría el argumento a favor de controles selectivos. Una disminución del gasto por sí sola dejaría abierta la cuestión de la productividad.
Por el contrario, la evidencia de que las restricciones retrasaron proyectos valiosos debilitaría el argumento a favor de límites indiscriminados. El efecto de la política importa más que su aparente severidad.
La segunda señal es cómo los proveedores empaquetan y gobiernan la actividad de los agentes. Los compradores deberían observar las actualizaciones de productos que permitan atribuir el consumo a tareas y flujos de trabajo concretos.
Controles más claros sobre acciones repetidas, escalamiento y finalización de tareas ayudarían a las empresas a entender qué están comprando. Su valor aún requiere pruebas en el trabajo real.
Las afirmaciones de los proveedores sobre eficiencia deberían distinguir entre un menor uso de recursos y una menor capacidad. Un sistema que hace menos trabajo no se ha vuelto necesariamente más eficiente.
La tercera señal es una evidencia más sólida sobre el trabajo terminado. Las evaluaciones que incluyan revisión, corrección y calidad posterior abordarían lagunas que los paneles de uso dejan sin resolver.
Las observaciones repetidas en tareas comparables reforzarían la confianza. Los resultados limitados a la producción generada o a las impresiones de los empleados mantendrían gran parte de la incertidumbre actual.
El próximo avance útil es una conexión más clara entre consumo y trabajo aceptado, en lugar de otro aumento de la adopción por sí solo.
En los próximos meses, estas señales ofrecen una forma más fundamentada de evaluar los controles presupuestarios de IA en las empresas. También dejan espacio para resultados distintos entre departamentos.
Un equipo de programación, un grupo de investigación y una operación de soporte no tienen por qué llegar a conclusiones idénticas. Sus tareas, costes de error y oportunidades de automatización difieren.
Por tanto, los compradores empresariales deberían resistirse a tratar la decisión de gasto de otra empresa como una respuesta ya preparada. La experiencia de Uber identifica una pregunta que cada organización aún debe investigar.
Lo mismo se aplica a los proveedores. El escrutinio presupuestario puede recompensar productos que faciliten demostrar sus beneficios, incluso cuando esos productos requieran una computación considerable.
También puede poner al descubierto despliegues cuyo éxito aparente depende de medir la actividad en lugar de los resultados. Esa distinción importará a medida que los flujos de trabajo basados en agentes asuman más responsabilidad.
La próxima conversación útil dentro de una empresa debería conectar al responsable del presupuesto con las personas responsables del trabajo terminado. Empiece por un flujo de trabajo cuya producción pueda evaluarse. Pregunte qué completaron los empleados, qué requirió corrección y qué cambió después de que la IA entrara en el proceso. Compare el esfuerzo total requerido, incluida la revisión y el seguimiento. Mantenga abierta la cuestión cuando la evidencia siga siendo incompleta. El episodio del presupuesto de IA de Uber ofrece una razón para exigir esa contabilidad, sin asumir que la respuesta deba favorecer la expansión o la restricción. Antes de tratar otro hito de adopción como un resultado de negocio, formule una pregunta más concreta: ¿qué trabajo útil alcanzó un estándar aceptable y cuánto gastó la organización para lograrlo?
