Fa molt poc ha transcendit que UBER a aquestes alçades de l’any ja hauria esgotat el seu pressupost anual per a IA a causa de l’ús massiu de Claude Code per part dels seus enginyers de programari. És un titular molt cridaner que a la seva vegada ens condueix al que és un problema molt concret: la gran majoria d’empreses encara no entén com funciona realment l’economia dels models generatius i dels agents. Per tant, tampoc saben com controlar-ne el cost.
En un panorama tan dinàmic i on els casos d’ús es multipliquen cada poc temps, els responsables de tecnologia de les empreses cada cop tenen més feina optimitzant el funcionament de les seves eines, iterant processos i procurant les despeses no es disparin. A dia d’avui, el disseny i el manteniment d’un stack tecnològic de IA funcional és una tasca important però cada cop va prenent molt més protagonisme fer possible que aquest conjunt d’eines pugui actuar dins dels límits d’uns costos tolerables.
Què ha passat exactament a UBER?
Empresa tecnològica fundada a San Francisco al 2009, UBER opera una plataforma global de mobilitat sota demanda. La seva app connecta passatgers amb conductors professionals o particulars per fer trajectes urbans. També ofereix serveis de repartiment de menjar i paqueteria a domicili així com solucions específiques per a empreses. Podem estimar que actualment la seva plantilla ronda els 30.000 treballadors a nivell mundial sense comptar conductors o repartidors.
L’empresa va incorporar Claude Code a finals de 2025 i en pocs mesos es va estendre el seu ús a prop de 5.000 enginyers de software. Ni més ni menys que el CTO de la companyia, Praveen Neppali Naga, admet que UBER ha volatilitzat el pressupost total previst en IA pel 2026 abans d’arribar al mes de maig. Aquesta circumstància que ajuda tant a generar titulars atractius, no és un accident o un fet incontrolat, parteix la voluntat de UBER d’impulsar l’adopció agressiva i accelerada d’aquest tipus d’eines. A principis de 2026, prop del 84% dels desenvolupadors de l’empresa ja eren considerats usuaris de “agentic coding”, el 95% dels enginyers feien servir IA cada mes i aproximadament el 70% del codi generat ja provenia d’aquest tipus d’ena. Encara més, al voltant del 11% de les actualitzacions de backend en viu ja eren generades per aquests agents de IA.
El desalineament en termes pressupostaris provindria de pensar en termes de seats o llicències per usuari i no en una previsió de tokens a consumir. Conforme l’adopció d’eines avança a l’interior de les organitzacions, allò que va prenent major protagonisme és precisament la intensitat i el tipus d’ús que es dona a aquestes eines. És en aquest punt que el cost s’enfila exponencialment i és aquí on s’està començant a definir un camp de batalla que és de present per a moltes empreses i és de futur per a tota la resta.
La intel·ligència artificial no pot ser pressupostada com un SaaS clàssic
- Models més grans i amb més context: Com més gran sigui la finestra de context, més tokens es processen per consulta. Això és especialment rellevant quan es funciona contra grans bases de dades que han de ser analitzades abans d’actuar.
- Agents que treballen “de veritat”: Ha quedat enrere pensar en la IA només com un xat que respon preguntes o executa tasques a demanda en temps real. Aquesta funció forma part del present però va quedant enrere ràpidament i cada cop té més a veure amb sistemes que orquestren múltiples crides, realitzen procediments programats, consulten eines de forma autònoma i generen outputs complexes. Els agents que més impulsen la productivitat de les organitzacions consumeixen cada cop més recursos de computació i per tant, tendeixen a elevar el seu propi cost.
- Variabilitats extremes d’ús: Dues persones treballant amb la mateixa eina poden generar costos totalment dispars: un ús lleuger o que no requereix de la generació de outputs complexes, pot encara tenir un cost molt discret. Un ús intensiu d’agents pot suposar fàcilment un cost mensual de milers d’euros per usuari.
Des del punt de vista financer, ens trobem davant necessitats de càlcul pressupostari més properes a les d’un servei de infraestructura al núvol que no pas als d’un SaaS d’oficina. S’ha de gestionar capacitat, pics d’utilització, optimització dels fluxos de treball i límits de consum.
El cost real de fer-nos dependents de la IA
Som milions de persones que hem modificat la manera com treballem i és gràcies a això que en aquests moments estem vivint un impressionant supercicle al sector dels semiconductors. Empreses i professionals depenen cada cop més de la IA i les narratives que parlen d’addicció apunten en una direcció correcta. Els LLMs cada cop estan més integrats en les nostres rutines diàries i això que encara no és general ni ha arribat a tots els usuaris de la xarxa, va generant casos d’ús que tenen més a veure amb tot tipus de públics. Un exemple molt clar és la manera com els LLMs estan redefinint la nostra manera de cercar informació a internet.
Partirem de la base de que el cas de UBER, sense deixar de ser molt interesant, descriu una situació internament controlada i un escenari previst. Ningú crema aquesta muntanya de diners sense ser conscient del que està fent i sense valorar-ho dins un ventall de resultats previsibles i qui sap si desitjats. Darrere d’això poden venir acomiadaments d’enginyers i un estalvi persistent a llarg termini.
Dit això, el que sí s’ha de tenir en consideració en altres tipus d’organitzacions és que existeix un repte molt clar a nivell de disseny econòmic i operatiu. Per a qualsevol empresa que vulgui desplegar la IA a escala, existeixen com a mínim tres decisions tècniques que són crítiques.
Pressupostar pensant en tokens i workload més que en llicències
- Definir pressupostos per projecte, equip i cas d’ús, mesurats en volum de tokens i cost d’inferència esperat. No direm que sigui senzill de fer però tampoc és rocket science i amb ganes d’experimentar es poden arribar a fer previsions raonablement acurades que sempre seran preferibles al fer un salt al buit.
- Modelar diferents escenaris (ús lleuger, ús intensiu, amb agents, sense agents, outputs que generen un alt consum de recursos...) abans d’obrir l’eina a tota l’organització. En aquest moment encara estem fent determinats processos de manera molt poc eficient i això si es vol és un cost de I+D però conforme es consoliden casos d’ús i es verifica la seva utilitat, estem obligats a millorar tots els processos per acomodar-los a una lògica d’eficiència operativa.
- Revisar periòdicament el mix de models utilitzats. Aquesta tasca no existia abans de l’arribada dels LLMs i a día d’avui comença a ser imprescindible dedicar temps a la optimització en l’ús de models. Més enllà de l’eclosió d’eines que a diari ens impacta, cal no perdre de vista també que existeixen una gran varietat de models que més enllà de la nostra esfera geopolítica més propera estan demostrant ser molt competitius tant a nivell de rendiment com de costs.
Dissenyar patrons d’ús intel·ligents
A moltes organitzacions la major part del cost té a veure amb errors de disseny que s’arrosseguen des de la fase de disseny dels productes o casos d’ús. Quan estem dissenyant un procés donem prioritat a que aquest funcioni aviat i un cop el procés ja està en marxa, no dediquem suficient temps a optimitzar-lo o a buscar maneres de fer que el seu funcionament segueixi una lògica operacional. Sovint fem servir els models més potents pensant en la comoditat i des d’una òptica tècnica resulta força evident que podem moure’ns fent servir patrons més eficients:
- És una bona idea establir l’ús “per defecte” de models més econòmics per a la realització de tasques rutinàries, deixant els models més potents i cars només per a fluxos de complexitat alta.
- És important limitar la profunditat i el volum de context dels agents quan no és necessari que rastregin grans volums de dades per oferir resultats adients. Tenim una tendència natural molt comprensible a raonar que contra més gran sigui el context, millors seran els resultats i això en sí mateix no és fals però sí pot pecar de sobreactuació en molts moments. Una sobreactuació que pot esdevenir un caprici car en alguns casos.
- Podem reutilitzar resultats intermedis per reduir crides redundants. En aquest cas concret, treballar amb projectes ben definits i programats que funcionin primàriament en contra de documentació contextual pot ser un bon camí. Cada model té els seus recursos al respecte. Un exemple d’això podría ser fer un bon us dels spaces de Perplexity.
Dissenyant patrons d’ús intel·ligents no només estarem optimitzant costos, que no és poca cosa, també estaríem aportant claredat al respecte de què esperem de cada sistema, cosa que redueix soroll intern i tendeix a eliminar dependències innecessàries.
Monitorització en temps real i establiment de límits durs
La variabilitat d’ús és tan alta que la monitorització tendeix a arribar tard. Això encara s’aguditza més en eines sobre les que treballa tot l’equip i que poden tendir al descontrol si ens referim al consum de tokens. Avui estàs consumint X recursos de computació però demà algú de l’equip implementa un nou cas d’ús o arrenca un projecte i el consum es multiplica per dos en menys de 24 hores. Aquest tipus de situacions ja formen part del nostre dia a dia i hem d’estar preparats per fer-hi front. La primera conclusió a la que s’arriba és que resulta del tot necessari estar atents al consum de recursos de computació i algunes bones idees poden ser les que segueixen:
- Generar quadres de comandament que reflecteixin costos per usuari, per equip, per agent i per projecte. Això per anar bé hauría de configurar-se comptant amb alertes que s’emetin quan es superen llindars prèviament definits. En projectes interns d’una empresa de serveis professionals pot tenir una rellevància relativament alta, però que passa quan estem parlant d’un projecte facturable que hem dimensionat en X consum de dades però en execució veiem que es produeix una desviació a l’alça que amenaça amb menjar-se tot el marge? Millor tenir-ho controlat d’entrada i disposar de capacitat per redreçar la situació.
- Establir límits de despesa per agent i per projecte. Novament, aquest tipus de límit cobra especial rellevància quan estem aplicant els recursos propis de computació a projectes que en realitat es porten a terme per a terceres parts.
- Implementar auditories periòdiques de prompts, fluxos d’agents i integracions per detectar patrons que no tenen un retorn clar o que tenen un cost desalineat amb les necessitats dels projectes amb els que es relacionen.
Implementar intel·ligència artificial en escala a una empresa requereix d’un tipus de gestió que és en realitat nova i a la que la gran majoria no estem encara acostumats. Hem de saber que o aquests processos d’implementació es controlen bé o el potencial que tenen en consum de recursos és rellevant en conseqüència preocupant.
És això vàlid per qualsevol dimensió d’empresa?
Quan una empresa com UBER consumeix el seu pressupost anual d’IA en quatre mesos, pot ser un problema greu però de bon gestionar en un entorn de milers de milions de dòlars de R+D. En empreses d’un volum inferior, un error d’aquesta magnitud es encara molt més greu i podria obligar a renunciar a avantatges competitius en un moment en el que el mercat es mou molt ràpid.
Els riscos entesos des d’una escala empresarial inferior són molt similars:
- És fàcil infraestimar l’impacte quan es passa d’un pla pilot al desplegament. No és el mateix dissenyar una operativa comercial fonamentada en el scrapping i en el email marketing que posar-la a funcionar diàriament. Per molt bé que ens surti el pilot, el que acaba sent més rellevant és que el seu funcionament sigui econòmicament assumible i que el seu retorn sigui mesurable.
- Malgrat les resistències inicials, els equips s’acaben enamorant de la IA. Milloren la seva velocitat, incrementen la qualitat i permeten ampliar el seu volum de tasques. El que ahir era un malson, avui pot ser un procés automatitzat i recurrent amb una fricció operacional excepcionalment baixa. Conforme l’adopció interna de la IA creix, tendeix a multiplicar-se de manera orgànica la demanda de crèdits de computació.
- Els models i agents evolucionen a tota velocitat incorporant funcionalitats que alteren els perfils de cost i patrons d’ús. Això afecta als pressupostos i obliga a romandre molt atents als quadres de comandament.
És per això que totes les empreses, encara que es trobin en una fase exploratòria, han de disposar d’un full de ruta clar i controlat que incorpori objectius de negoci i mètriques de productivitat a la vegada que determini responsables de la seva gestió i una visió realista dels costos variables que s’hauran d’assumir conforme el procés d’adopció avanci. Implementar la intel·ligència artificial a una empresa significa iniciar un camí cap al consum creixent de tokens i no entendre-ho significa no entendre res.
Comentaris
Publica un comentari a l'entrada