No hem hagut de rescatar encara cap client d'un projecte d'IA mal lliurat. Hem vist sistemes mal documentats en altres contextos, sabem el cost real que té heretar-los, i per això tractem cada entrega com si el client hagués de continuar amb un altre proveïdor demà, encara que no sigui així.
Aquesta forma de pensar canvia com es dissenya el projecte des del principi. No s'escriu codi pensant "ja documentarem al final", no es deixen credencials en arxius personals, no s'utilitzen serveis que només una persona del nostre equip sap configurar. Cada decisió tècnica passa per un filtre senzill: si demà el client volgués portar-se aquest sistema a casa, podria fer-ho?
Aquest article explica per què els handovers en projectes d'IA són més complexos que en altres sistemes, què hauria d'incloure una entrega ben feta, i quines són les senyals d'alerta abans de signar amb qualsevol proveïdor que prometi "sistemes intel·ligents".
Per què un handover d'IA és més complex que un altre
En un projecte web tradicional, un handover ben fet implica codi documentat, accessos i un README clar. La gran majoria del coneixement està en el codi: si una persona nova el llegeix, en pot deduir què fa el sistema i com mantenir-lo.
En un projecte d'IA, això no és suficient. El comportament del sistema no està només al codi: està en els prompts, en les configuracions del model, en les eines connectades, en els fluxos d'orquestració, en els evals que defineixen què és una resposta correcta i en les decisions arquitectòniques que sovint només es justifiquen amb el context del cas concret. Un nou equip pot llegir el codi i entendre què fa cada funció, però sense documentació addicional no entendrà per què es va decidir aquell prompt, aquell model o aquella seqüència d'accions.
A això s'hi suma un altre factor: els sistemes d'IA són sistemes vius, no estàtics. Calen evals periòdiques, ajustos quan el comportament deriva, decisions sobre quan actualitzar models. Sense traspàs adequat d'aquesta capa operativa, el sistema funcionarà el primer mes i començarà a degradar-se lentament el segon o tercer, sense que el client sàpiga per què.
Un handover de qualitat ha de cobrir totes aquestes capes, no només el codi.
Els sis elements d'un handover ben fet
A partir de la nostra experiència construint sistemes d'IA i de la pràctica de tractar cada projecte com si fos lliurable demà, aquests són els sis elements que considerem imprescindibles en una entrega tècnica seriosa:
1. Documentació tècnica completa. No és un README de tres línies. És un conjunt estructurat que inclou: arquitectura del sistema (què hi ha, què fa cada part, com es comuniquen), decisions tècniques rellevants (per què aquest model, per què aquesta base de dades, per què aquesta orquestració), runbooks operatius (què fer quan falla X, com diagnosticar Y), i diagrames quan són útils. Si un enginyer sènior pot llegir-ho i entendre el sistema en una tarda, està ben fet.
2. Accés total a credencials i comptes. Tots els comptes, APIs, tokens, repositoris i serveis han d'estar en propietat del client, no del proveïdor. Sembla obvi però és el primer punt on molts handovers fallen: el compte de l'API està a nom del proveïdor, el repositori està al seu GitHub personal, el monitor està a un servei que el proveïdor paga. Quan el client vol marxar, té un sistema però no en té control. Un handover ben fet inverteix aquesta situació: el client té tot, el proveïdor només té accés mentre dura la relació.
3. Tests automatitzats i sistema d'evals. En IA, els evals són tan importants com els tests unitaris en software tradicional. Permeten validar que el sistema continua prenent decisions correctes quan algú toca el codi, canvia un model o ajusta un prompt. Sense evals, qualsevol modificació al sistema és un acte de fe. Un handover ben fet inclou una bateria d'evals executable amb un sol comando, datasets de test pròpies del cas i criteris clars d'èxit.
4. Sessió de transferència presencial o per videoconferència. La documentació és necessària però no suficient. Una sessió de 2-3 hores amb l'equip tècnic del client, on s'explica el sistema, es fan demostracions reals i es resolen dubtes, val per cinquanta pàgines de documentació. És on es transfereix el coneixement tàcit: aquelles coses que ningú escriu però que tothom necessita saber per operar el sistema.
5. Període d'acompanyament posterior. Un sistema mai es lliura "tancat". Sempre apareixen dubtes, comportaments inesperats o necessitats noves en els primers mesos. Un handover ben fet inclou un període de suport posterior —típicament entre 1 i 3 mesos— on l'equip que va construir el sistema queda disponible per a consultes. No és un servei premium amagat: és part de la responsabilitat del proveïdor que va construir el sistema.
6. Pla de manteniment documentat. Què cal fer cada setmana, cada mes, cada trimestre per mantenir el sistema saludable: revisar evals, mirar logs d'errors, comprovar costos, actualitzar dependències crítiques. Un pla de manteniment clar permet al client decidir si vol portar-ho internament o contractar manteniment a algú —al mateix proveïdor o a un altre—. La clau és que pugui escollir amb informació, no amb desconeixement.
Senyals d'alerta abans de signar amb un proveïdor
Si estàs avaluant proveïdors per a un projecte d'IA, aquí van quatre senyals d'alerta que indiquen que probablement no rebràs un handover decent:
Senyal 1: el proveïdor parla només de la demo i no de com es manté en producció. Si en les reunions comercials es dediquen 90% del temps a ensenyar què bonic queda el sistema funcionant i 10% (o menys) a explicar com s'opera, com es mesura i com es manté, és senyal que la seva mentalitat és "lliurar i marxar", no construir alguna cosa que duri.
Senyal 2: al pressupost no hi ha cap partida de documentació, transferència o període d'acompanyament. Si el pressupost inclou només desenvolupament i res més, vol dir que el proveïdor està pensant en mínim viable per cobrar i marxar. Un proveïdor seriós considera la documentació i la transferència com una part integral del projecte, no com un servei addicional.
Senyal 3: et demanen signar un contracte on només ells tenen accés al codi o a infraestructura. Si la propietat intel·lectual no queda clarament al client, o si els comptes principals queden a nom del proveïdor, t'estan creant dependència estructural des del minut zero. Un proveïdor seriós insisteix que tot quedi a nom del client des de l'inici.
Senyal 4: t'ofereixen un manteniment mensual obligatori sense opció de sortir o canviar de mans. Hi ha proveïdors que estructuren els contractes perquè el client quedi atrapat: només ells poden mantenir el sistema, només ells tenen accés, només ells coneixen com funciona. Aquesta no és una relació comercial, és una hipoteca tècnica. Un proveïdor seriós ofereix manteniment com una opció més, no com una necessitat imposada per disseny.
Per què escrivim sobre això sense haver hagut de rescatar ningú
Reconeixem que aquest article no es basa en l'experiència d'haver rescatat clients de proveïdors anteriors. Es basa en el criteri tècnic acumulat construint sistemes que volem que sobrevisquin a la nostra relació amb el client. Cada decisió que prenem en un projecte passa per la pregunta: si demà aquest client volgués portar-se el sistema, podria? La resposta ha de ser sempre sí.
Aquest enfocament té un cost. Significa més temps en documentació, més temps en sessions de transferència, més rigor en com es gestionen accessos i comptes. Però el cost val la pena: és el que diferencia un proveïdor que tracta cada projecte com una venda d'algú que el tracta com una relació professional.
Si estàs avaluant proveïdors per a un projecte d'IA, fes-los aquestes preguntes abans de signar: com seria un handover si demà decidíssim canviar de proveïdor? Quina documentació rebríem? Quins accessos? Hi ha període d'acompanyament inclòs? Si les respostes són vagues o defensives, ja saps el que cal saber.
Si vols parlar amb nosaltres d'un projecte concret —el teu o un que estàs avaluant—, escriu-nos. Tinguis o no tinguis intenció d'acabar treballant amb MindRise, una valoració honesta del plantejament pot estalviar-te problemes importants més endavant.