Als projectes d'IA empresarial els passa una cosa estranya en el viatge del pilot a producció: la factura no creix linealment. Creix 30 vegades, 60 vegades, en alguns casos 200 vegades, segons la mateixa FinOps Foundation. I no és perquè el sistema faci 30 vegades més feina. És perquè el sistema comença a fer coses que en el pilot no es mesuraven — i quan algú les mira, ja són al contracte anual.
Hi ha un patró que portem veient en client rere client: el pilot passa tots els KPIs tècnics, algú signa producció, arriba la primera factura del trimestre i la conversa canvia de to. El CFO no pregunta per accuracy. Pregunta per què un procés que costava 200 € al mes ara costa 12.000.
Aquest post és la versió que un CTO ensenya al seu equip el dilluns següent. No és un manifest sobre FinOps. És un inventari dels 7 anti-patrons concrets que multipliquen la teva factura, una mètrica que importa més que cost/token, i un conjunt de circuit breakers que qualsevol equip pot instrumentar abans de signar el següent roadmap.
El cost d'IA empresarial en xifres
Dades públiques FinOps Foundation, Gartner i State of FinOps 2026
1. Per què el cost d'IA no s'assembla al cost de cloud tradicional
El cloud tradicional té una propietat que els seus operadors van trigar deu anys a interioritzar però que avui tothom coneix: el cost és proporcional a l'ús, i l'ús és proporcional a la feina útil. Si una API rep 10x més peticions, factura 10x més. Si un clúster serveix 10x més usuaris, paga 10x més en còmput. Hi ha esquerdes (egress de dades, costos ocults de bases de dades managed) però el principi de proporcionalitat continua sent raonable.
La IA empresarial no es comporta així. L'ús útil i l'ús facturat es desacoblen tan bon punt el sistema surt del pilot, per tres raons estructurals:
- L'input no és la unitat facturable. Quan un usuari fa una pregunta de 12 paraules a un assistent RAG, el que es factura no són 12 paraules: són els 8.000 tokens de context recuperat més el system prompt de 1.200 tokens més l'output de 600 tokens. Una petició petita pot facturar 20.000 tokens. L'invisible a l'usuari és l'única cosa que el proveïdor cobra.
- Els reintents no són de l'usuari, són del sistema. Una crida a un agent amb tool use pot generar 5-10 crides internes al model abans de retornar una resposta. Si una d'aquestes crides falla, hi ha reintents. Si l'agent està mal calibrat, hi ha bucles. La factura creix exponencialment, no proporcionalment.
- El "context bloat" és el deute tècnic més car que existeix avui. Cada vegada que un equip afegeix una nova font al RAG, una nova tool a l'agent o una nova instrucció al system prompt, el cost per petició puja de manera permanent. No hi ha res a l'observabilitat estàndard que n'avisi.
Resultat: la corba de cost té una discontinuïtat en el pas a producció que les eines de FinOps tradicionals no detecten perquè estan pensades per a VMs, no per a tokens.
2. Els 7 anti-patrons que multipliquen la teva factura
Inventari, en ordre aproximat d'impacte observat en mid/large enterprise. Cap anti-patró és exòtic. Cadascun és defensable la primera vegada que s'introdueix. El problema no és cap individualment; és l'acumulació silenciosa.
El system prompt comença sent 200 tokens. Cada vegada que alguna cosa surt malament en producció, algú afegeix una instrucció defensiva ("mai retornis X", "sempre pregunta abans de Y"). En sis mesos són 4.500 tokens. Cada petició paga aquest impost. Un assistent amb 1M de peticions/mes paga 45 milions de tokens addicionals al mes només en el system prompt — sense canviar una línia del producte.
La hipòtesi que "més context sempre és millor" porta els equips a recuperar 10-20 chunks per petició quan amb 3-5 n'hi hauria prou. L'accuracy millora marginalment; la factura creix linealment amb els chunks recuperats. Els chunks que no es fan servir són pagament pur sense valor.
Patró clàssic: un agent "supervisor" crida un agent "researcher" que crida un agent "writer" que retorna al supervisor per validar. Tres crides al model on una de ben dissenyada bastaria. En workloads agentic mal escrits, el 60-80% del cost són crides internes que l'usuari no veu mai.
Una crida falla, el codi reintenta fins a tres vegades. La validació post-crida falla, es torna a cridar el model. L'usuari no nota la latència perquè hi ha caché de resposta intermèdia, però la factura compta cada intent. Sense retry caps explícits, una petició pot facturar 5-15x el que hauria.
Activar "thinking" o "reasoning extended" en models que ho suporten dispara els tokens d'output. En models amb raonament estès (Claude Opus, GPT amb o1-style reasoning, Gemini Deep Think), una petició amb CoT pot facturar 8-15x els tokens d'una resposta directa. De vegades val la pena; moltes vegades no, i ningú ho audita.
L'equip desplega una nova versió del servei RAG. El pipeline reconstrueix els embeddings dels 200.000 documents del corpus. La factura d'embeddings d'aquell mes es multiplica pel nombre de desplegaments. Equips que despleguen 4-5 vegades al mes paguen 4-5 factures d'embeddings quan haurien de pagar-ne una.
Anthropic, OpenAI i Google porten més d'un any oferint descomptes del 50-90% sobre tokens cacheats. Equips que envien el mateix system prompt a cada petició sense marcar el cache_control estan pagant la tarifa completa per informació estàtica. El descompte no s'aplica sol: cal activar-lo.
La bona notícia: els set són evitables amb instrumentació bàsica. La dolenta: cap es detecta amb dashboards de proveïdor estàndard — cal mesurar-los a nivell d'aplicació, no de billing. És la mateixa diferència que hi ha entre arquitecturar RAG bé o malament: els errors no són tècnicament impossibles d'evitar, són els que ningú està mirant.
3. La mètrica que importa: cost per tasca útil completada
Cost/token és una mètrica de proveïdor, no de negoci. Mirar-la és com mirar el cost per mil·ligram de combustible en parlar del cost d'un viatge.
La mètrica que importa per a un CTO o CFO és cost per tasca útil completada. Una "tasca útil completada" es defineix a nivell de producte: una resposta correcta de l'assistent, un document extret sense errors, una decisió de scoring lliurada amb confiança per sobre del llindar, un codi generat que va passar els tests.
Aquesta mètrica té dues propietats que cost/token no té:
- Captura el problema dels reintents i bucles. Si el teu agent necessita 8 crides al model per lliurar una tasca útil, el cost per tasca és 8x el cost per crida. El KPI ho reflecteix; el KPI de tokens no.
- Fa explícita la qualitat com a variable econòmica. Si baixes accuracy del 95% al 70%, el cost per tasca útil puja — perquè les tasques no útils són pagament pur sense valor de negoci. Un sistema barat per petició però amb un 30% de tasques no útils és un sistema car a nivell d'unitat de negoci.
Dos casos il·lustratius: la matemàtica de l'abans i el després
Per fer el cost per tasca útil concret en lloc d'abstracte, dos escenaris compostos basats en patrons que veiem repetidament en mid-large enterprise. Els números són il·lustratius però l'aritmètica quadra amb els multiplicadors citats a dalt — estan construïts perquè qualsevol CTO pugui reproduir el càlcul en el seu propi cas.
Abans (sense instrumentació)
- 200.000 peticions/mes sobre Claude Sonnet
- System prompt acumulat: 4.500 tokens (context bloat)
- RAG amb
top_k=15(~9.000 tokens recuperats) - Reasoning extended actiu en el 30% de peticions
- Sense
cache_controlconfigurat - Input mitjà: ~14.000 tokens · output mitjà: ~1.330 tokens
- Cost/petició: ≈ $0,062
≈ 12.000 €/mes
Després (5 fixes en 2-3 sprints)
- Auditoria system prompt → 1.500 tokens (CB1)
- Cap de tokens explícit (CB2)
- Gating de CoT al 5% de peticions (CB5)
- Caché de prompts activada (anti-patró 7)
top_k=5amb reranker (anti-patró 2)- Input mitjà: ~5.000 tokens (4.500 cacheats al 25%) · output: ~555 tokens
- Cost/petició: ≈ $0,013
≈ 2.800 €/mes
Reducció: −77% sobre la factura mensual sense tocar accuracy. ROI el primer mes.
Abans (sense instrumentació)
- 50.000 tasques/mes amb tool use sense cap d'iteracions
- Mitjana: 8 crides al model per tasca (bucles entre sub-agents)
- Retry agressiu sense distingir error transitori vs. semàntic
- Sense caché
- Taxa de tasques amb output útil: ~60%
- Cost/crida al model: ≈ $0,030
- Cost/tasca bruta: ≈ $0,24
≈ 0,38 €/tasca útil
Després (1-2 sprints + alineació)
- Instrumentació
task_outcomea l'observabilitat - Cap d'iteracions a 5 (CB3)
- Retry policy diferenciada per error class (CB4)
- Caché sobre system + tool definitions
- Taxa de tasques útils puja a ~85% per reducció de bucles fallits
- Cost/crida: ≈ $0,020
- Cost/tasca bruta: ≈ $0,10
≈ 0,11 €/tasca útil
Reducció: −71% sobre el cost per unitat econòmica útil. L'accuracy puja — no baixa — perquè els bucles infinits eren el símptoma, no la cura.
Aquests dos casos no són els més extrems que hem vist. Són els més il·lustratius del patró.
4. Circuit breakers de cost: 5 controls que bloquegen el dany
Els circuit breakers són al cost d'IA el que els rate limits són a les APIs: protecció operativa pre-incident, no anàlisi post-mortem.
Budget per feature
Cada feature de producte que fa servir IA té un budget mensual assignat en euros. La instrumentació el trackeja en temps real. Quan el consum creua el 80%, alerta l'equip propietari. Quan creua el 100%, el feature degrada a un fallback determinista fins al següent període. No hi ha sorpreses a final de mes perquè és estructuralment impossible que n'hi hagi.
Cap de tokens per petició
Cada crida al model té un max_tokens explícit tant en input com en output. Si una petició està a punt de superar-lo, es rebutja abans d'arribar al proveïdor. Això bloqueja l'escenari més car: una petició patològica amb 200K tokens de context i una resposta sense límit. Cap input + cap output, no negociable.
Cap de crides per sessió agèntica
Qualsevol agent amb tool use té un màxim de N iteracions per sessió (típicament 8-15 segons el cas). En arribar al cap, l'agent retorna la millor resposta parcial disponible i registra la sessió com partial. Això bloqueja bucles infinits abans que es converteixin en factures infinites.
Sampling de retry agressiu
Si una crida falla, màxim 1 retry — i només si l'error és transitori (timeout, 429, 5xx). Errors semàntics (la validació post-crida falla) no es reintenten automàticament: es registren i es tracen per a observabilitat. Reintentar errors semàntics és la forma més cara de no resoldre un bug.
Mode "auditoria de cost" en CI
Abans de fer merge de qualsevol canvi que toqui prompts, RAG, agents o tool use, un test executa un set de peticions representatiu i compara cost i latència amb la baseline. Si el cost puja >15% sense que el PR ho justifiqui, el merge es bloqueja. El cost com a variable de qualitat — igual que tests de regressió, igual que tests de seguretat.
Els cinc són barats d'implementar (1-3 setmanes per a un equip que ja té observabilitat bàsica). El car és no tenir-los quan arriba la primera factura inesperada del trimestre.
5. Quan triar model petit, gran o on-prem: taula de llindars
La decisió model gran vs. model petit vs. inferència local no és ideològica. És econòmica, i depèn de tres variables: volum de peticions/mes, criticitat de l'accuracy i sensibilitat de les dades.
| Escenari | Volum | Accuracy crítica | Dades sensibles | Recomanació pràctica |
|---|---|---|---|---|
| Assistent conversacional client final | >5M/mes | mitjana | baixa | Model petit + fine-tuning (Haiku, GPT-4o-mini, Gemini Flash). Cost/petició 10-30x menor que el flagship a la mateixa accuracy en domini acotat. |
| Anàlisi legal / compliance | <100K/mes | molt alta | alta | Model gran managed amb BAA + zero retention (Claude Sonnet/Opus a Bedrock o Vertex). El cost/petició no domina; el risc d'error sí. |
| Agent autònom d'operacions | 50K-1M/mes | alta + multi-step | mitjana | Router pattern: model gran per a raonament + model petit per a tool calling. Redueix cost 40-60% vs. fer servir gran per a tot. |
| Processament batch documental | >10M docs/mes | mitjana | variable | Model petit + caché agressiu d'embeddings + alternatiu open-source (Llama, Mistral) on-prem si la sensibilitat ho justifica. |
| Copilot intern de desenvolupament | 200-500 devs | mitjana | alta (codi) | Barreja managed + open-source local segons sensibilitat del repo. Raonable: 30-80 €/dev/mes. Per sobre de 150 €/dev/mes cal auditar l'ús. |
Cap fila és definitiva. El punt de la taula és que la decisió del model és una decisió de cost tant com una de capacitat — i gairebé ningú la tracta així. El framework complet de selecció, amb TCO i eix d'exit cost, el desenvolupem en com triar LLM el 2026.
6. El deute invisible
El State of FinOps 2026 col·loca el cost d'IA com a prioritat #1 del CFO. Gartner prediu que >40% dels projectes d'IA agentic seran cancel·lats abans de finals de 2027 — i la raó principal no és que la tecnologia no funcioni, sinó que l'economia no quadra.
No quadra perquè hi ha un deute invisible que s'acumula des del dia 1 del pilot: cada token no auditat, cada chunk RAG sobreinclòs, cada agent que crida un altre agent sense pressupost, cada desplegament que regenera embeddings sense necessitat. Cap d'aquestes decisions és individualment sospitosa. Totes juntes són la diferència entre 200 € i 12.000 € al mes per a la mateixa feina.
El CTO que instrumenti token economics, defineixi cost per tasca útil com a KPI i desplegui circuit breakers des de la fase pilot construeix sobre fonaments auditables. El que no ho faci estarà explicant al seu CFO d'aquí a sis mesos per què el ROI estimat del projecte no apareix al P&L — i per què no es pot arreglar sense redissenyar parts del sistema.
El test dels dilluns: obre la darrera factura del proveïdor d'LLM. Saps quina feature va consumir cada partida? Saps quin percentatge són crides internes no visibles a l'usuari? Saps quin és el teu cost per tasca útil? Si la resposta a alguna és "no", ja tens el punt d'entrada.
A onext acompanyem els equips d'enginyeria a construir aquesta instrumentació des del dia u, no des de la primera factura inesperada. Si vols comparar el teu setup actual contra els 7 anti-patrons d'aquest post, parlem-ne.
Fonts citades
- FinOps Foundation — FinOps for AI Overview
- FinOps Foundation — State of FinOps 2026
- Aretove — The 2026 FinOps Frontier: governing LLM costs
- Finout — FinOps in the Age of AI: CPO's guide
- arXiv — Beyond Accuracy: CLEAR framework enterprise agentic AI
- Gartner via Joget — >40% de projectes agentic AI seran cancel·lats abans de 2027
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →