Els pilots d'IA no moren pel model: moren a la frontera de l'ERP

Hi ha dos números de l'informe de MIT NANDA que gairebé mai no se citen junts, perquè el titular se'n va endur un altre. El 60% de les organitzacions va avaluar eines d'IA empresarial a mida o de proveïdor. El 20% va arribar a pilot. El 5% va arribar a producció.

La caiguda de seixanta a vint s'explica sola: s'avalua molt més del que es prova. La interessant és l'altra. Entre el pilot i producció es perden tres de cada quatre projectes que ja havien demostrat que funcionaven.

Els mateixos autors escriuen que l'escletxa «no sembla impulsada per la qualitat del model ni per la regulació, sinó que sembla determinada per l'enfocament», i assenyalen que les solucions a mida s'encallen per «complexitat d'integració i manca d'encaix amb els fluxos de treball existents». Gartner va arribar al mateix lloc per un altre camí quan va predir el juny del 2025 que més del 40% dels projectes d'IA agèntica es cancel·larien abans d'acabar el 2027: la seva analista ho atribueix a organitzacions «encegades» davant la complexitat del desplegament, amb projectes que s'encallen abans d'arribar a producció.

Aquesta peça va d'on és exactament aquesta frontera i de les quatre preguntes que cal contestar per travessar-la. No de l'enginyeria del pas a producció, que ja vam tractar, sinó d'una cosa més estreta i més tossuda: el punt en què un agent deixa de llegir un fitxer i comença a parlar amb el sistema on viu el vostre negoci.

El pilot funcionava perquè no travessava res

Gairebé tots els pilots que he vist treballen sobre una exportació. Un CSV, una carpeta amb dos-cents documents copiats, una base de proves de fa sis mesos. Dades quietes, sense permisos, sense concurrència, sense ningú més escrivint alhora i sense conseqüències si alguna cosa surt malament.

Això no és una drecera de l'equip: és la manera sensata de provar una hipòtesi. El problema és el que se'n conclou. Quan el pilot surt bé, la conclusió que se'n treu és «el model serveix per a això». I és certa. Però la pregunta que decidia el projecte no es va arribar a fer mai, perquè l'exportació l'esquivava sencera.

Producció vol dir llegir el sistema viu. Amb el seu model de permisos, els seus camps a mitges, els seus registres duplicats, el seu històric de decisions que ningú no va documentar i altres persones modificant-lo mentre l'agent el llegeix. Tot el que feia fàcil el pilot és, literalment, l'absència d'aquesta frontera.

La frontera té tres graus, i es travessen d'un en un

L'error de planificació més car és tractar «connectar amb l'ERP» com una sola cosa. Són tres, amb costos i aprovadors diferents, i posar-les a la mateixa fase és el que fa que un projecte de vuit setmanes es converteixi en un de vuit mesos.

La regla pràctica que surt d'aquesta taula és avorrida i funciona: no barregeu els tres graus a la mateixa fase. Setmanes en lectura, amb l'agent proposant i un humà executant, ensenyen més sobre el sistema real que qualsevol anàlisi previ — i quan arriba el moment d'escriure, ja sabeu quins camps estan bruts, quins permisos falten i quines excepcions apareixen de debò.

Pregunta 1 · Amb quina identitat actua?

És la primera que cal contestar i la que més vegades es contesta per accident, en una reunió tècnica de vint minuts, triant l'opció que desbloqueja el desenvolupament.

Hi ha dues dreceres i totes dues surten cares. La primera és suplantar un empleat: l'agent fa servir les credencials d'una persona, normalment les de qui impulsa el projecte. Funciona el primer dia i trenca la traça per sempre — a partir d'aquell moment el registre del sistema diu que aquella persona va fer coses a les tres de la matinada, i quan algú auditi el procés no hi haurà manera de separar el que va fer ella del que va fer l'agent.

La segona és heretar un compte de servei que ja existia. És pitjor del que sembla, perquè aquests comptes es van crear fa anys per a integracions que ja ningú no recorda i acostumen a acumular més permisos que qualsevol humà de l'equip. L'agent no rep el permís que necessita: rep tot el que aquell compte arrossegava.

El desordre de fons està mesurat. L'informe de la Cloud Security Alliance sobre identitats no humanes situa la mediana en 45 identitats no humanes per usuari humà en una empresa normal, i fins a 144 en entorns nadius de núvol. Però la xifra que de debò descriu el problema no és aquesta: és que el 51% de les organitzacions declara no tenir una propietat clara de les identitats d'IA, i el 16% ni tan sols registra quan se'n crea una.

Convé dir d'on surten aquests números: aquell informe agrega recerca publicada per tercers en lloc de mesurar directament, així que serveix per dimensionar el desordre, no com a cens. La direcció, en canvi, coincideix amb el que es veu en qualsevol projecte: ningú no sap quants accessos automàtics té oberts la seva empresa.

La resposta que funciona és sosa: identitat pròpia, nominal, amb el permís mínim del procés concret i amb un amo humà amb nom. I una data de caducitat, perquè la integració que ningú no renova és la que continua viva tres anys després que el projecte es cancel·lés. Com s'acoten aquests permisos quan l'agent a més fa servir eines ho desenvolupem en parlar d'injecció de prompts: la seguretat d'un agent és en el que pot fer, no en el que se li demana.

Pregunta 2 · Què queda escrit, i en quin registre?

Tot sistema de registre seriós té traça d'auditoria. El problema no és que en falti: és que n'hi ha dues i no s'ajunten.

El registre de l'ERP anota què va passar: quin compte va modificar quin camp, quan, amb quin valor anterior. És el que necessita un auditor financer i fa dècades que està resolt. El registre de l'agent anota per què: què se li va demanar, quins documents va llegir, quin raonament va seguir, amb quina confiança. I viu en un altre sistema, amb un altre format, una altra retenció i sovint un altre proveïdor.

Quan algú pregunti «per què aquesta comanda es va aprovar sola?», la resposta està repartida entre tots dos i ajuntar-la és feina manual, tret que s'hagi dissenyat abans. El barat és un identificador de correlació que viatgi de l'un a l'altre; el car és reconstruir-ho sis mesos després amb captures de pantalla.

El Reglament Europeu d'IA ho converteix en obligació per als sistemes d'alt risc: el seu article 12 exigeix que permetin «el registre automàtic d'esdeveniments (registres) al llarg del cicle de vida del sistema», amb capacitat de registre suficient per identificar situacions de risc i facilitar la vigilància posterior a la comercialització. No tots els processos d'una empresa cauen en aquesta categoria —convé mirar-ho cas per cas i no assumir el pitjor— però el disseny que satisfà l'obligació és el mateix que cal per poder explicar-se davant d'un client enfadat. La peça sobre dissenyar agents que passin una auditoria desenvolupa aquesta capa.

Pregunta 3 · Què passa a la propera actualització?

Aquesta és la que mai no apareix al cas de negoci, i és la que converteix un projecte tancat en un passiu permanent.

Odoo, que és l'ERP més estès al mid-market espanyol, ho diu a la seva pròpia documentació amb una claredat que s'agraeix: «si un canvi introduït per una versió nova trenca una personalització, és responsabilitat del mantenidor del teu mòdul a mida fer-lo compatible amb la nova versió d'Odoo». I més amunt, a la pàgina d'actualització: «si la teva base de dades conté mòduls a mida, no es pot actualitzar fins que existeixi una versió d'aquests mòduls per a la versió de destinació».

Llegeix-ho un altre cop pensant en el vostre agent. La integració que esteu a punt d'aprovar entra en aquesta categoria. No és que es pugui trencar: és que bloqueja l'actualització de l'ERP fins que algú l'arregli. I aquesta mateixa frase, amb un altre nom i una altra lletra petita, és a les condicions de qualsevol sistema de registre seriós — la mateixa documentació d'Odoo, quan enumera què provar abans d'actualitzar, comença per «integracions amb programari extern (EDI, API, etc.)».

La conseqüència pràctica no és tècnica, és de pressupost i de govern: qui aprova la integració està aprovant també el seu manteniment a cada versió major, durant els anys que duri. Si aquesta línia no és al cas de negoci, el cas de negoci està incomplet, i el dia que arribi la factura la conversa serà sobre per què ningú no ho va dir.

Aquí hi ha una decisió d'arquitectura amb conseqüències llargues: com més es recolza la integració en el model intern del sistema —taules, camps, mòduls a mida—, més es trenca. Com més es recolza en la seva interfície pública i estable, menys capacitat té, però sobreviu a les versions. No hi ha resposta correcta; hi ha una tria que convé fer amb els ulls oberts i deixar escrita.

Pregunta 4 · I si el sistema s'equivoca?

Les tres primeres preguntes tenen amo: algú de sistemes, algú de procés, algú de pressupost. Aquesta quarta no en té i és la que costa més diners.

Un agent que llegeix el CRM assumeix que el CRM té raó. No té manera de no assumir-ho: és la seva única font. Un humà que veu una data de renovació impossible o un contacte amb el càrrec de fa tres feines aixeca la cella i pregunta. L'agent l'utilitza, hi construeix a sobre una resposta impecable i la deixa escrita.

El mode de fallada, per tant, no s'assembla a un error. No hi ha excepció, no hi ha traça vermella, no hi ha alerta. Hi ha una sortida plausible construïda sobre una dada falsa, i signada per un procés automàtic, que és justament el que li dona autoritat davant de qui la llegeix.

És el mateix mecanisme del qual parlàvem a propòsit dels tests generats: un sistema que només pot aprendre de l'estat actual descriu aquest estat, no el jutja. Un CRM brut no produeix un agent que falla; produeix un agent que menteix amb confiança. I per això la preparació mínima de les dades no és una fase prèvia opcional: és el que fixa el sostre del que es pot automatitzar sense supervisió.

L'ordre, que importa més que les respostes

Cap de les quatre preguntes no té una resposta universal: depenen del sistema, del sector i de quant risc estigui disposada a assumir la direcció. El que sí que és transferible és la seqüència.

Un procés abans que una plataforma. La temptació és muntar la capa d'integració bona, la que servirà per a tot. És més cara i més lenta, i sobretot ajorna l'aprenentatge: fins que un procés no arriba a producció, tot el que sabeu del sistema real són suposicions. Comenceu per un de concret i avorrit — d'avorrits n'hi ha uns quants documentats, i comparteixen que el cost actual es pot mesurar sense discutir-lo.

Lectura abans que escriptura. No per prudència genèrica, sinó perquè durant aquelles setmanes l'agent us ensenya gratis quins camps estan bruts, quins permisos faltaven i quines excepcions existeixen de debò i no al diagrama. Aquest coneixement no es pot comprar i no apareix en cap anàlisi previ.

La ruta d'excepció abans que el camí feliç. Qui rep el cas dubtós, amb quin context arriba i en quant de temps s'ha de resoldre perquè el procés no s'encalli. Si no sabeu contestar qui rep l'excepció, el procés no està llest, per bé que funcioni la demo. És la part que decideix l'adopció i la que gairebé sempre es dissenya l'última.

I el permís mínim des del primer dia, encara que freni una setmana. Ampliar permisos és una conversa de deu minuts; reduir-los, quan ja hi ha processos penjant, és un projecte. És la mateixa lògica que apliquem al mínim exigible de governança: el barat és posar-ho abans.

El que això no és

No és un argument contra els agents. El mateix informe de MIT documenta que el 5% que travessa extreu valor real i mesurable, i que qui ho aconsegueix no ho fa amb models millors sinó exigint personalització sobre processos concrets i avaluant per resultat de negoci en comptes de per benchmark.

Tampoc no és un argument a favor de muntar un programa d'integració de nou mesos abans de tocar res. Seria l'error contrari i té el mateix final: el projecte es mor de govern en lloc de morir-se de tècnica.

I convé tractar les xifres amb la mateixa honestedat amb què els seus autors les van publicar, que és més de la que es veu a gairebé totes les presentacions que les citen. L'informe de MIT es presenta com a troballes preliminars, no està revisat per parells, les seves 153 respostes es van recollir en quatre congressos —un lloc on ningú no presumeix de fracassos, i on va qui ja és a la conversa— i adverteix a les seves pròpies pàgines que els seus números són «direccionalment correctes, basats en entrevistes individuals més que en informació oficial de les companyies» i que «poden no representar patrons més amplis del mercat». Hi afegeixo una comprovació que gairebé ningú no fa en citar-lo: la pàgina oficial de Project NANDA al MIT Media Lab no allotja l'informe, tot i que el seu investigador principal figura entre els quatre autors. Res d'això no l'invalida, però fixa per a què serveix: per descriure una forma, no per calcular un ROI ni per portar-lo a un comitè com si fos un cens. La forma, en qualsevol cas, coincideix amb el que es veu a cada projecte: el model gairebé mai no és el problema, i la frontera gairebé sempre ho és.

Si la vostra empresa ja té gent fent servir IA pel seu compte —i en té—, aquesta conversa ja està passant sense vosaltres, amb dades que surten del sistema pel porta-retalls i sense cap de les quatre respostes escrites. Contestar-les no és burocràcia prèvia: és el que separa un pilot que impressiona d'un procés que es queda.

Preguntes freqüents

Per què el pilot funcionava i el desplegament no?

Perquè el pilot gairebé mai no travessa la frontera. Treballa sobre una exportació, un conjunt de documents copiats a una carpeta o una base de proves: dades quietes, sense permisos, sense concurrència i sense conseqüències. Producció vol dir llegir el sistema viu, amb el seu model de permisos, els seus registres a mitges i altres persones escrivint alhora. Tot el que feia fàcil el pilot és l'absència d'aquesta frontera. L'informe de MIT NANDA ho mesura en la caiguda: el 60% de les organitzacions va avaluar eines d'IA empresarial, el 20% va arribar a pilot i només el 5% a producció — i els autors escriuen que l'escletxa no sembla venir de la qualitat del model ni de la regulació, sinó de l'enfocament.

Amb quina identitat hauria d'actuar un agent sobre l'ERP o el CRM?

Amb una de pròpia, nominal i amb el permís mínim del procés concret — mai suplantant un empleat ni heretant un compte de servei genèric que ja existia. Suplantar trenca la traça: el registre del sistema dirà que ho va fer una persona que no hi era. Heretar un compte de servei antic acostuma a donar a l'agent més permisos que a qualsevol humà de l'equip, perquè aquests comptes es van crear per a integracions que ja ningú no recorda. El treball de la Cloud Security Alliance sobre identitats no humanes posa xifra al desordre: el 51% de les organitzacions diu que no té una propietat clara de les identitats d'IA i el 16% ni tan sols registra quan se'n crea una.

És més difícil que l'agent escrigui que no pas que llegeixi?

És un altre projecte, no el mateix projecte una mica més gran. Llegir es resol amb permisos de consulta i una conversa tècnica. Escriure obre tres fronts que no són tècnics: qui aprova que un procés automàtic modifiqui un registre comptable o comercial, què passa amb l'escriptura equivocada que ningú no detecta fins al tancament, i com es desfà. I hi ha un tercer grau que se sol confondre amb el segon: escriure amb efectes, quan l'apunt dispara un correu al client, un pagament o un assentament. Aquí l'error ja ha sortit del vostre edifici. La regla pràctica és no barrejar els tres graus en la mateixa fase del projecte.

Què passa quan actualitzem l'ERP?

Que la integració és un passiu permanent, no un projecte que es tanca. La documentació d'Odoo ho diu sense embuts per al seu propi producte: si un canvi d'una versió nova trenca una personalització, la responsabilitat de fer-la compatible és del mantenidor del mòdul a mida, i una base de dades amb mòduls a mida no es pot actualitzar fins que existeixi una versió d'aquests mòduls per a la versió de destinació. Aquesta frase, amb un altre nom, és a les condicions de qualsevol sistema de registre. La conseqüència de pressupost és la que importa: qui aprova la integració està aprovant també el seu manteniment a cada versió major, i això gairebé mai no apareix al cas de negoci.

I si la dada del sistema està malament?

L'agent no té manera de saber-ho, i aquest és el mode de fallada més car de tots perquè no s'assembla a un error. Un humà que veu un camp estrany pregunta; un agent que llegeix el mateix camp l'utilitza. El resultat no és una excepció visible sinó una resposta plausible construïda sobre una dada falsa, que a més queda escrita al sistema amb l'autoritat del procés automàtic. Per això la preparació de dades no és una fase prèvia opcional: és el que determina el sostre del que es pot automatitzar. I per això convé començar per processos on la dada d'entrada es pugui contrastar amb alguna cosa, no pels que depenen de camps que ningú no manté.

Per on es comença sense muntar un programa d'integració?

Per un procés, en lectura, amb la ruta d'excepció escrita abans que el camí feliç. Un procés concret i avorrit —no el més visible— del qual es pugui mesurar el cost actual. Només lectura durant les primeres setmanes, perquè l'error sigui reversible mentre s'aprèn com es comporta el sistema real. I la ruta d'excepció decidida abans d'arrencar: qui rep el cas dubtós, amb quin context i en quant de temps. Si no se sap contestar qui rep l'excepció, el procés no està llest per automatitzar-se, per molt que el model funcioni a la demo.

Fonts citades

• Challapally, A., Pease, C., Raskar, R. i Chari, P. — The GenAI Divide: State of AI in Business 2025 (MIT NANDA, juliol del 2025; troballes preliminars sobre 300+ iniciatives públiques, 52 organitzacions entrevistades i 153 respostes de directius recollides en quatre congressos; embut 60% → 20% → 5% i l'atribució a l'enfocament en lloc de a la qualitat del model). Enllaç a una còpia en PDF del document: la pàgina oficial de Project NANDA al MIT Media Lab no allotja l'informe, tot i que el seu investigador principal signa com a autor.
• Cloud Security Alliance, AI Safety Initiative — The Non-Human Identity Governance Vacuum: AI Agents and the Fastest-Growing Unmanaged Attack Surface (20 de maig del 2026; 45 identitats no humanes per usuari humà de mediana i fins a 144 en entorns nadius de núvol; 51% sense propietat clara de les identitats d'IA, 16% sense registre de la seva creació. Agrega recerca publicada per tercers en lloc de mesurar directament)
• Odoo — Upgrade — Odoo 19.0 documentation (documentació oficial; la responsabilitat del mantenidor del mòdul a mida, el bloqueig de l'actualització amb mòduls a mida i la llista d'integracions a provar)
• Unió Europea — Reglament d'IA, article 12 · Conservació de registres (registre automàtic d'esdeveniments al llarg del cicle de vida del sistema per als sistemes d'alt risc)
• Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (25 de juny del 2025; Anushree Verma; costos creixents, valor de negoci poc clar i controls de risc insuficients, amb organitzacions «encegades» davant la complexitat del desplegament)