Perché i contratti di IA continuano a pagare le ore quando il valore è altrove
La frizione maggiore nell'adozione dell'intelligenza artificiale aziendale non è tecnica. Non risiede nei modelli, né nella qualità dei dati, né nella capacità di calcolo. Risiede nel contratto. Mentre le organizzazioni investono centinaia di milioni in implementazioni di IA aspettandosi ritorni strutturali, la maggior parte continua a firmare accordi che premiano il tempo impiegato, non l'impatto generato. Questo disallineamento non è un dettaglio amministrativo: è la causa profonda per cui tante iniziative di IA rimangono intrappolate tra il pilota promettente e la scala operativa che non arriva mai.
Il più recente rapporto di McKinsey sullo stato dell'IA lo conferma con una precisione scomoda: l'adozione si è estesa, ma le sfide legate alla scalabilità persistono, e la correlazione più forte con l'impatto reale non è nell'investimento tecnologico bensì nella riprogettazione dei flussi di lavoro. In termini economici: le aziende stanno pagando per l'installazione quando dovrebbero pagare per la trasformazione.
La contrattazione basata sui risultati non è una moda passeggera. È la risposta strutturale a un problema di architettura degli incentivi che i modelli tradizionali non sono in grado di risolvere.
Il problema non è il fornitore, è la logica del contratto
I contratti a tempo e materiali, e gli accordi a prezzo fisso, sono nati per gestire la consegna di software in cui i deliverable erano definibili, le scadenze prevedibili e il valore relativamente lineare rispetto allo sforzo. L'IA rompe tutte e tre queste condizioni.
Un sistema di IA che automatizza la gestione degli incidenti nell'infrastruttura non consegna un modulo. Consegna una riduzione nel tempo di risoluzione, una diminuzione dei costi operativi, una minore dipendenza dal personale di guardia e, nel tempo, una riorganizzazione del team operativo. Nessuno di questi risultati compare in una fattura oraria. E nessuno può essere attribuito con precisione a una specifica milestone di progetto.
Il risultato è prevedibile: il fornitore fattura ciò che può misurare, ovvero le ore. Il cliente paga per qualcosa che si aspettava ma che il contratto non ha mai promesso formalmente. Quando il ROI non si materializza, nessuno è tecnicamente responsabile perché il contratto non lo richiedeva.
Esistono tre falle strutturali in questa logica. La prima è l'assenza di correlazione tra l'input e il valore generato: spendere di più in consulenza o in licenze non produce necessariamente più impatto. La seconda è la mancanza di meccanismi di responsabilità, perché senza un risultato definito contrattualmente, il fornitore non ha alcun incentivo a perseguirlo. La terza, e spesso ignorata, è il costo totale di proprietà che i contratti tradizionali rendono invisibile: la gestione del cambiamento organizzativo, l'alfabetizzazione sull'IA da parte del team, la riconversione dei processi e i costi che scompaiono quando la soluzione funziona bene, come il personale o il software che l'IA sostituisce. Tutto questo rimane fuori dal bilancio, pur determinando se l'investimento è stato redditizio.
La logica di un contratto orientato ai risultati
Un contratto basato sui risultati non è semplicemente uno in cui il fornitore riceve un bonus se le cose vanno bene. La sua architettura è più precisa e più impegnativa per entrambe le parti.
Il punto di partenza è la definizione collaborativa degli indicatori che contano, non quelli tecnici, ma quelli di business: riduzione dei costi operativi, aumento del tasso di risoluzione al primo contatto con il cliente, diminuzione del tempo di ciclo nella catena di approvvigionamento. Su questi indicatori vengono stabilite linee di base verificate, con una metodologia di misurazione concordata, e viene costruita la logica di attribuzione: quale parte del risultato può essere ragionevolmente collegata alla soluzione di IA e in quali condizioni.
Il pagamento viene strutturato a strati. Una base fissa copre i costi minimi di operatività del fornitore. Una componente variabile si attiva quando i risultati superano soglie definite. Nelle implementazioni più sofisticate si stabiliscono fasce di varianza — quelle che alcuni chiamano corridoi di tolleranza — all'interno delle quali il fornitore si assume il rischio al ribasso ma cattura anche valore al rialzo.
Questo design modifica le dinamiche di potere nella relazione commerciale. Il fornitore smette di essere un esecutore di compiti per diventare un partner con esposizione al risultato. Questo cambiamento di posizione non è retorico: ha conseguenze sul modo in cui vengono assegnati i team, sulla velocità di risposta a un problema di prestazione del modello e sulla quantità di investimento continuativo che il fornitore è disposto a fare nel rapporto con il cliente.
Affinché questo funzioni, il fornitore deve possedere capacità che i modelli tradizionali non richiedevano. Ha bisogno di consulenti che comprendano il business del cliente prima di parlare di tecnologia. Ha bisogno di ingegneri che costruiscano mentre si definisce, non dopo. E ha bisogno dell'infrastruttura per gestire il modello in produzione con continuità, inclusa la governance dei costi di inferenza e il monitoraggio del degrado delle prestazioni del modello nel corso del tempo.
L'errore di scala che si ripete più spesso
Esiste un schema di fallimento nell'adozione dell'IA che si ripete con sufficiente coerenza da poter essere considerato strutturale: le organizzazioni non sanno dove concentrare l'attenzione e oscillano tra due estremi egualmente costosi.
Alcune puntano su problemi troppo circoscritti. Costruiscono un agente per automatizzare la gestione della spesa nei confronti dei fornitori senza considerare che il problema reale riguarda l'intera catena di approvvigionamento. Il risultato è una soluzione che funziona nel suo silo e che non riesce a scalare perché non è stata progettata per connettersi con i processi che le forniscono contesto.
Altre organizzazioni tentano di ottimizzare tutto contemporaneamente e senza fasi intermedie. Cercano di trasformare le operazioni su scala senza aver prima dimostrato il modello di valore in un segmento circoscritto. Il risultato è un progetto che consuma risorse per anni, genera report di avanzamento e non produce cambiamenti osservabili negli indicatori che interessano al consiglio di amministrazione.
Ciò che accomuna entrambi gli estremi è l'assenza di un modello operativo prima di scegliere la tecnologia. Le organizzazioni che riescono a scalare l'IA in modo sostenuto lavorano con due processi simultanei: la riprogettazione dei processi e l'architettura di dati e tecnologia. Non in sequenza, ma in parallelo. E ciò che mantiene questi due processi allineati è la gestione del cambiamento, la strategia organizzativa e la gestione del prodotto come disciplina permanente.
Questo è l'argomento più solido a favore della contrattazione basata sui risultati: obbliga ad avere quella chiarezza prima di firmare. Un fornitore che accetta di essere misurato sul risultato ha bisogno di comprendere il processo che il cliente vuole migliorare. Quella conversazione precontrattuale ha un valore strategico superiore a molti mesi di consulenza successiva.
Quando l'incentivo giusto costruisce il partner giusto
La contrattazione per risultati ridistribuisce chi cattura il valore in un'implementazione di IA e come. Ma rivela anche qualcosa sui fornitori che pochissime organizzazioni analizzano prima di firmare.
Un fornitore che opera secondo questa logica deve assorbire il rischio. Per assorbire il rischio, ha bisogno di convinzione nelle proprie capacità di consegna. Quella convinzione non può essere solo commerciale: deve essere sostenuta dall'architettura tecnica, dalla storia di esecuzione e dalla governance interna che gli consenta di gestire la qualità del modello in produzione per mesi o anni, non solo al momento del lancio.
Pochi fornitori hanno oggi questa capacità. E questa scarsità ha implicazioni per gli acquirenti: il mercato dei fornitori genuinamente impegnati sui risultati è più piccolo di quanto sembri leggendo soltanto la letteratura commerciale. Filtrare chi è in grado di operare secondo questo modello e chi semplicemente lo annuncia come differenziatore commerciale richiede di porre esattamente le domande che la contrattazione per risultati obbliga a rispondere prima di firmare.
Dal punto di vista della distribuzione del valore, questo modello ha anche una virtù che i contratti tradizionali non possiedono: rende visibile ciò che in precedenza rimaneva fuori dal bilancio. I costi del cambiamento organizzativo, l'investimento nella formazione, i sistemi che diventano ridondanti, il personale che viene riassegnato — tutto questo entra a far parte dell'analisi del valore condiviso tra cliente e fornitore. Questa visibilità non garantisce equità, ma elimina la possibilità che il successo del fornitore e quello del cliente operino in universi paralleli.
Quando gli incentivi si allineano attorno al risultato, il centro di gravità della relazione commerciale si sposta dalla gestione dei costi alla massimizzazione del rendimento. Questa differenza non è semantica. È quella che determina se l'IA aziendale produce un impatto verificabile oppure si limita a produrre progetti.
