De pilots GenAI a producció: un framework de CTO per extreure valor de negoci real
La majoria de projectes GenAI moren en fase de pilot. No pas perquè la tecnologia no funcioni — funciona —, sinó perquè la distància entre «aquesta demo és impressionant» i «això és un sistema en producció que aporta valor de negoci mesurable» és més ampla del que la majoria d'equips es pensen, i més estreta del que la majoria de proveïdors admeten.
He tingut aquesta conversa amb prou CTOs per saber-me la història de memòria: la majoria de pilots GenAI corporatius no arriben mai a producció. I dels que hi arriben, una part gens menyspreable es retira discretament al cap d'un any, quan la relació cost-valor deixa de justificar la inversió. El problema no és la tecnologia. És el model de desplegament.
Les empreses que he vist extreure valor real de la GenAI el 2025 no fan res de màgic. Fan unes quantes coses concretes de manera sistemàtica — i s'estalvien el teatre que es menja la major part dels pressupostos d'IA.
El que ve a continuació és el framework que donaria a qualsevol CTO amb un pilot encallat: el que separa la feina de GenAI que es converteix en valor de negoci de la que acaba com una línia en un post-mortem.
Els pilots moren en cinc passos previsibles
Per entendre la bretxa, primer cal entendre on fallen la majoria de pilots. El patró es repeteix amb una constància descoratjadora:
- Es construeix una demo en 4–8 setmanes que demostra que la tecnologia pot fer alguna cosa útil amb inputs escollits a mà.
- La direcció s'engresca. El pilot rep finançament per anar a producció.
- L'equip descobreix la part dura. Les dades són pitjors del que es pensava. Els casos límit trenquen el sistema. L'avaluació costa més del previst. Integrar-ho amb els fluxos de treball existents demana canvis que ningú no assumeix.
- El projecte s'alenteix. Al cap de sis mesos, la producció queda més lluny del que semblava al mes dos.
- El projecte mor en silenci quan la direcció salta a la següent oportunitat d'IA, o quan els números no surten.
Amb el framework adequat, totes les etapes d'aquest patró tenen sortida. El framework que la majoria d'organitzacions apliquen, per accident o a consciència, és «munta un equip d'IA i ja veurem què passa». I aquest enfocament fracassa molt més sovint que no pas funciona.
Quatre proves que maten d'hora les males iniciatives
Abans de qualsevol iniciativa GenAI cal respondre quatre preguntes. Si alguna resposta és «no» o «no ho sabem», la iniciativa no està a punt.
Prova 1: hi ha un resultat concret i mesurable?
Vague: «fer servir IA per millorar l'experiència de client». Concret: «reduir el temps de resposta del suport de 8 hores a 30 minuts en el 40% de consultes entrants més freqüents, mantenint el CSAT per sobre de 4,2/5».
Si no pots enunciar el resultat en una frase amb almenys un número, la feina anirà a la deriva. Els objectius vagues conviden a l'scope creep, conviden a la lectura política, i no donen mai un senyal d'èxit inequívoc.
Prova 2: hi ha prou dades de qualitat?
Els sistemes GenAI que funcionen en producció depenen de dades de què poden aprendre, d'on poden recuperar context o contra les quals es poden avaluar. Si les teves dades són:
- escampades per 12 sistemes amb esquemes incoherents,
- plenes de soroll històric que ningú no ha netejat,
- tancades darrere de murs de compliance que ningú no ha negociat,
...aleshores la feina d'IA és aigües avall d'un problema d'enginyeria de dades que cal resoldre primer. Saltar-se aquest pas és el motiu pel qual fracassen tants pilots.
La pregunta no és «tenim dades?», sinó «tenim dades en un format que un sistema d'IA pugui fer servir de debò?». La resposta sol ser «encara no», i la distància és considerable.
Prova 3: hi ha un circuit human-in-the-loop?
Els sistemes GenAI en producció tenen un circuit de revisió humana per als outputs que importen. La GenAI totalment autònoma en fluxos crítics de negoci és rara i difícil; la majoria de sistemes que funcionen tenen un punt de control humà en algun lloc.
Abans de començar, respon: qui revisa els outputs de la IA? Com els aprova, els rebutja o els edita? Com tornen les seves decisions al sistema per millorar-lo amb el temps? Si la resposta és «ja ho resoldrem més endavant», tens un forat en el disseny de producció que tard o d'hora aflorarà en forma de fallada.
Prova 4: l'economia unitària és defensable?
Cada inferència costa diners. A petita escala, el cost és invisible. A escala de producció, és una partida del pressupost. Abans de començar, modela:
- el cost per interacció d'usuari (inputs, outputs, eines, reintents)
- el volum esperat a l'escala objectiu
- els ingressos o l'estalvi de cost per interacció
- l'impacte en el marge brut
Si els números no surten a l'escala objectiu, el pilot produirà una cosa tècnicament impressionant però econòmicament insostenible. Val més descobrir-ho a la primera hora que al mes dotze.
Els lighthouse projects guanyen les jugades de plataforma
El model de desplegament que converteix la GenAI d'experiment en valor de negoci: els lighthouse projects.
Un lighthouse project és un sistema GenAI en producció amb tres propietats que el defineixen:
- Abast acotat — un cas d'ús, un segment d'usuaris, una mètrica d'èxit ben definida.
- Valor demostrable — produeix impacte de negoci mesurable en un domini limitat.
- Èxit visible — els altres equips el poden veure funcionar i emmirallar-hi les seves pròpies iniciatives.
L'antipatró és la «jugada de plataforma»: l'intent de construir una capacitat d'IA de propòsit general que molts equips puguin fer servir. Les jugades de plataforma fracassen més sovint que els lighthouse projects perquè no tenen un responsable concret a qui importi un resultat concret. Els lighthouse projects se'n surten perquè algú és amo del resultat.
Què fa funcionar un lighthouse project
Responsabilitat clara. Una persona — normalment un enginyer sènior o un product manager — respon del resultat de cap a cap. Pot decidir. Pot dir que no. Pot escalar quan ho necessita.
Equip petit i centrat. De 3 a 5 persones com a màxim. Amb més gent, hi entra el sobrecost de coordinació. Amb menys, no cobreixes tota l'amplada de la feina (enginyeria, dades, producte, avaluació).
Horitzó temporal curt. De 8 a 16 setmanes des de l'arrencada fins a l'impacte mesurable en producció. Més de 16 setmanes sol voler dir que l'abast és massa gran.
Framework d'avaluació explícit. Com sabrem que funciona? Quines mètriques seguim? Quin és el llindar per dir «això és un èxit»?
Producció des del primer dia. Res d'entorns pilot que després s'hagin de migrar. Construeix sobre infraestructura de producció des del principi.
Com triar el primer lighthouse
L'error més habitual és equivocar-se de primer lighthouse project. Els bons primers lighthouses tenen:
- un cas d'ús on la IA encaixa de manera evident (no només una aplicació de moda)
- stakeholders que volen el resultat amb prou força per protegir el projecte políticament
- prou dades existents perquè la IA sigui útil des del primer dia
- un camí cap a valor mesurable dins d'un trimestre
- tolerància a la imperfecció de la v1
Mals primers lighthouses:
- el cas d'ús que obsessiona algú important però on la IA no és l'eina adequada
- qualsevol cosa amb bloquejos de compliance pendents de resoldre
- aplicacions on l'error humà ja és baix (la IA no hi farà gaire diferència)
- sistemes amb requisits de precisió extrems (la v1 no arribarà al llistó)
Les decisions d'arquitectura que importen
La GenAI en producció no és només un model: és una pila de decisions, i cadascuna afecta el cost, la latència, la fiabilitat i la mantenibilitat.
Les que importen:
Selecció de model
El model adequat depèn del cas d'ús:
- Tasques de raonament intens (anàlisi, planificació, fluxos multipas) → un model de frontera (Claude Opus, el nivell més potent de GPT)
- Tasques rutinàries a escala (classificació, resum, extracció) → models més barats i ràpids (Sonnet, Haiku, les variants mini)
- Tasques de domini amb dades pròpies → models petits amb fine-tuning, allà on el ROI justifiqui l'esforç
La majoria d'equips abusen dels models de frontera. Un bon patró del 2025: dirigeix cada tasca al model més barat que doni una qualitat acceptable, i recorre a un de millor només quan calgui.
Retrieval i context
La GenAI en producció normalment necessita accedir a les teves dades. La capa de retrieval — bases de dades vectorials, embeddings, cerca híbrida, grafs de coneixement — sovint és on es guanya o es perd la qualitat.
El patró que funciona: inverteix en qualitat de retrieval abans d'optimitzar la tria de model. Un model de frontera amb mal retrieval produirà pitjors resultats que un model més barat amb bon retrieval.
Pipeline d'avaluació
La diferència entre una demo i un sistema en producció és que el sistema en producció s'avalua contínuament. Cada output es puntua (eval automàtica, revisió humana o totes dues). Les degradacions es detecten i es corregeixen. Les actualitzacions de model es proven contra el set d'eval abans de desplegar-les.
Els equips que es salten l'avaluació construeixen sistemes que es degraden en silenci.
Observabilitat
La GenAI en producció demana observabilitat especialitzada:
- ús de tokens i cost per petició
- distribucions de latència (P50, P95, P99)
- mètriques de qualitat del pipeline d'avaluació
- modes d'error i la seva freqüència
- senyals de feedback dels usuaris
Si hi vas a cegues, no podràs millorar el sistema amb el temps.
Seguretat i governança
Per a qualsevol sistema que toqui outputs de cara al client:
- moderació de contingut i aplicació de polítiques
- defenses contra la injecció de prompts
- traçabilitat de les decisions que afecten clients
- resposta a incidents quan els outputs de la IA surten malament
Saltar-se la governança és la via directa a un problema de reputació.
L'equip equivocat enfonsa el cas d'ús encertat
La majoria d'iniciatives GenAI fracassen perquè l'equip no és l'adequat. Els modes de fallada típics:
Massa ML, poca enginyeria. L'equip sap entrenar models però no sap posar sistemes en producció.
Massa enginyeria, poc producte. L'equip construeix funcionalitats que tècnicament funcionen però no resolen cap problema real d'usuari.
Massa recerca, poca iteració. L'equip produeix papers, no productes.
La composició que funciona per a un lighthouse project:
- 1 enginyer de producte sènior amb experiència en IA (sap dissenyar prompts, avaluar outputs i pensar en UX)
- 1 enginyer sènior de backend/dades (construeix el retrieval, les APIs i el pipeline d'avaluació)
- 1 product manager o expert de domini (defineix què vol dir «bo» i vetlla perquè es lliuri valor)
- Un especialista en ML a temps parcial (disponible quan cal fine-tuning, disseny d'evals o criteri per triar models)
Fixa't en el que no hi ha en aquest equip: cap «arquitecte d'IA» dedicat sense experiència posant sistemes en producció, cap «prompt engineer» que no escriu codi, cap consultor de proveïdor que hi és per vendre més serveis.
Per a les organitzacions que no tenen aquesta forma d'equip a dins, és aquí on els partners especialitzats aporten valor. Un squad nearshore amb la barreja adequada — enginyers de producte sèniors, enginyers de backend i suport ML a temps parcial — es pot desplegar en un lighthouse project en qüestió de setmanes. Els números surten perquè els lighthouse projects estan acotats: quan el projecte arriba a producció, redueixes l'equip o el redirigeixes.
Cada lighthouse abarateix el següent
Els lighthouse projects no importen només pel valor del projecte individual: cada lighthouse que reïx fa créixer la capacitat de l'organització per posar-ne més en producció.
Quan el primer lighthouse arriba a producció:
- l'equip té llibreries de prompts, frameworks d'eval i patrons de desplegament reutilitzables
- l'organització té proves que la GenAI pot aportar valor mesurable
- la direcció té un èxit per ensenyar quan financi la iniciativa següent
- la resta d'equips tenen un patró que funciona per emmirallar-s'hi
Després de 2–3 lighthouses reeixits:
- l'arquitectura s'ha consolidat en primitives d'IA componibles
- l'organització té expertesa interna real, no només relacions amb proveïdors
- el cost de desplegar una nova funcionalitat d'IA cau de manera significativa
- la roda comença a girar: cada funcionalitat nova és més fàcil que l'anterior
Aquest efecte compost és el motiu pel qual començar amb lighthouses d'abast acotat guanya a començar amb jugades de plataforma ambicioses. No estàs lliurant només una funcionalitat: estàs construint capacitat organitzativa.
El cost de no començar també es compon
Ja has vist les projeccions macro: tots els decks de consultoria prometen que la GenAI expandirà els marges en algun percentatge espectacular i en algun calendari ple de confiança. No repetiré números que no puc verificar. Tracta'ls com a orientativament útils i idiosincràticament equivocats: el teu impacte real dependrà de les teves dades, dels teus fluxos de treball i de la teva execució.
El que sí que és cert a nivell de CTO individual: el cost de no començar creix. Cada trimestre sense una capacitat GenAI en producció és un trimestre en què els teus competidors potser n'estan construint una. L'efecte compost dels lighthouse projects fa que una empresa amb dos anys d'experiència GenAI en producció vagi estructuralment per davant d'una que en porta dos mesos.
El contraargument més fort mereix una resposta directa: esperar és barat. Els models milloren i s'abarateixen cada trimestre, així que l'equip que comenci l'any que ve heretarà una infraestructura millor a un preu més baix. És cert — per a la infraestructura. No ho és per als frameworks d'eval, per a la fontaneria de dades ni per al coneixement, guanyat a pols, del que els teus usuaris acceptaran de debò. Res d'això no ve amb la propera versió del model. Només es compon si estàs construint.
No et cal guanyar la cursa de la IA. El que et cal és estar-hi corrent.
Per on començar ara mateix
Si encara no has arrencat cap lighthouse project, el patró que funciona:
- Aquesta setmana: identifica 3–5 casos d'ús candidats que passin les quatre proves. Ordena'ls per impacte × viabilitat.
- Les dues setmanes següents: tria'n un. Posa nom al responsable. Defineix la mètrica d'èxit. Confirma que les dades estan a punt.
- Setmanes 3–4: munta l'equip (intern, nearshore o híbrid). Aixeca el framework d'avaluació abans d'escriure cap prompt.
- Setmanes 5–16: construeix, avalua, itera, posa-ho en producció. Mesura.
- Setmana 16 en endavant: declara la victòria o el fracàs segons la mètrica d'èxit. Extreu els patrons. Arrenca el lighthouse següent.
Això no és un programa de transformació. És un projecte. La transformació és el que passa després del tercer projecte que surt bé, no del primer.
A punt per arrencar un lighthouse project però sense l'equip per executar-lo? Parla amb un CTO sobre com desplegar un squad nearshore de GenAI amb enginyers preparats per a la IA i expertesa ML a temps parcial.
