Contratti AI in outsourcing: non accettate solo l'accuratezza del modello. Pretendete queste 4 metriche

Inserire in contratto la clausola “l’accuratezza del modello non deve essere inferiore al valore concordato” equivale quasi a non stabilire alcun criterio di collaudo. È una constatazione dura, ma supportata dai fatti: secondo un’analisi di RAND su oltre 2.400 progetti AI aziendali, l’80,3% dei progetti non riesce a generare il valore di business atteso. Il superamento dei test tecnici e il fallimento del progetto a livello operativo si verificano molto spesso contemporaneamente.

L’accuratezza del modello dovrebbe servire unicamente come metrica interna per il fornitore e come valutazione preliminare prima del rilascio; non deve rappresentare il criterio principale di collaudo contrattuale. I contratti di sviluppo AI in outsourcing dovrebbero invece essere strutturati attorno a quattro categorie di indicatori: risultati di business, perimetro di copertura, latenza e disponibilità, gestione degli errori e responsabilità di riaddestramento.

L’accuratezza indica semplicemente la percentuale di risposte corrette fornite dal modello in un ambiente di prova. Non dice nulla su dove si verificano gli errori né su quanto costano all’azienda.

Ipotizziamo il caso di un’azienda manifatturiera che affida in outsourcing un sistema di controllo qualità visivo basato su AI, stabilendo in contratto che “l’accuratezza media sul test set non deve essere inferiore a quanto promesso dal fornitore”. Una volta installato in fabbrica, in presenza di forti riflessi di luce il sistema genera un numero elevato di falsi allarmi sui prodotti conformi. Per evitare il blocco continuo della produzione, gli operatori finiscono per disattivare il sistema, lasciando passare pezzi difettosi verso i clienti. Dal canto suo, il fornitore dimostra che l’accuratezza pattuita su carta è stata raggiunta.

Questo esempio mostra come i dati aggregati possano mascherare la reale distribuzione degli errori e il loro impatto sui costi operativi. A ciò si aggiunge il problema della qualità dei dati: le ricerche di Gartner attribuiscono l’85% dei fallimenti dei progetti AI alla scarsa qualità dei dati aziendali, un problema che raramente emerge nei dati di test e si manifesta solo dopo la messa in produzione. Se il contratto non regola i risultati operativi e le responsabilità di aggiornamento, l’acquirente rischia di pagare per un semplice punteggio teorico.

1. Risultati di business: valutare i processi, non i punteggi del modello

Le metriche relative ai risultati di business devono essere estratte dai sistemi aziendali reali, non dai dataset di test del fornitore. I dataset di test sono come un esame preparato da chi deve superarlo; i sistemi aziendali rappresentano i problemi reali che si ripresentano ogni giorno in produzione.

Nel caso di una PMI manifatturiera che commissiona un sistema AI per il controllo qualità visivo, il contratto dovrebbe stabilire che, durante un periodo di osservazione concordato per il collaudo:

• Il tasso di difetti non rilevati (falsi negativi) su una determinata linea non superi il X%.
• Il volume di controlli manuali richiesti per turno non superi i Y pezzi.
• I fermi macchina causati da falsi allarmi non superino i Z minuti.

I valori di X, Y e Z devono essere misurati prima dell’avvio del progetto basandosi sui dati operativi reali dell’azienda, senza ricorrere a stime arbitrarie.

Se l’outsourcing riguarda un assistente AI per la gestione dei clienti esteri, gli indicatori opportuni possono essere:

• Il tasso di errore nell’estrazione delle informazioni dalle richieste commerciali.
• La percentuale di ordini che richiedono l’intervento manuale di un operatore.
• La frequenza con cui i clienti formulano più volte la stessa domanda.

L’aspetto fondamentale consiste nel definire nel contratto la formula di calcolo, la fonte dei dati e la durata del periodo di verifica.

Un ulteriore vantaggio delle metriche di business è prevenire il fenomeno dei “piloti vincenti che falliscono su scala”. Questo problema è analizzato nell’articolo Perché i progetti pilota di AI funzionano ma falliscono quando si passa alla produzione. Senza indicatori aziendali precisi, il collaudo si riduce a una dimostrazione formale dei dati di test all’interno di una sala riunioni.

2. Perimetro di copertura: definire chiaramente i limiti

La principale causa di controversia nei contratti AI non è l’inadeguatezza del modello, ma la contestazione “questo scenario non era incluso nell’accordo”. Può accadere che un modello funzioni correttamente sulla linea di produzione A, ma fallisca sulla linea B a causa di differenti condizioni di illuminazione; oppure che gestisca bene le richieste in cinese e in inglese, ma traduca in modo confuso quelle in italiano. Se il contratto menziona solo un’accuratezza generica, presuppone implicitamente che tutti gli scenari siano coperti, quando nella realtà non è così.

Il perimetro di copertura descritto nel capitolato deve specificare chiaramente:

• I modelli di prodotto o codici SKU gestiti.
• Le tipologie di difetti o di richieste ammesse.
• Le lingue e i canali di comunicazione supportati.
• Le condizioni di ingresso dei dati, i macchinari interessati e i limiti operativi dell’utente.

È altrettanto necessario contrattualizzare la gestione delle variazioni fuori perimetro. Se dopo il rilascio compare una nuova tipologia di difetto, il fornitore è tenuto ad estendere il sistema? In assenza di clausole specifiche, il fornitore tratterà l’esigenza come un nuovo progetto a prezzo di listino. L’acquirente deve quindi distinguere nel contratto tra “ottimizzazione nel perimetro” e “integrazione fuori perimetro”, definendo per ciascuna categoria tempi di risposta e condizioni economiche.

I grandi fornitori di tecnologia considerano l’adattabilità agli scenari reali una competenza di consegna fondamentale. A settembre 2025 Alibaba Cloud ha ottenuto la certificazione di Livello 5 (il grado più elevato) dal CAICT in Cina per l’implementazione di modelli AI di grandi dimensioni, con parametri di valutazione che coprono 34 capacità operative, tra cui l’analisi dei requisiti, l’ottimizzazione del modello, l’adattamento agli scenari e le garanzie di manutenzione. A prescindere dalle dimensioni del fornitore scelto, la capacità di definire chiaramente i confini applicativi costituisce un indicatore diretto della sua affidabilità tecnologica.

3. Latenza e disponibilità reale: oltre la trappola del 99,9%

Molti contratti di fornitura indicano genericamente un “livello di disponibilità del sistema non inferiore al 99,9%”. Nella pratica aziendale, questa formula offre garanzie limitate.

Prendendo come riferimento lo SLA pubblico di Azure OpenAI, la disponibilità mensile promessa del 99,9% misura esclusivamente se il servizio invia una risposta, prescindendo dal tempo impiegato per fornirla. Inoltre, le interruzioni inferiori a 43,2 minuti non danno diritto ad alcun rimborso; per interruzioni superiori, il rimborso è limitato al 10% del canone mensile, raggiungendo il 25% solo se il disservizio supera le 7 ore e 12 minuti. Ciò significa che fenomeni come latenze elevate, rallentamenti o blocchi della coda di elaborazione — che causano danni operativi diretti all’azienda — potrebbero non essere affatto risarciti dallo SLA del cloud provider.

Quando un’azienda adotta soluzioni AI tramite un system integrator o un fornitore esterno, i rischi di latenza non coperti dai provider cloud a monte devono essere garantiti dal fornitore finale tramite contratto, oppure compensati da un’adeguata struttura di prezzo.

È raccomandabile definire nel contratto la disponibilità effettiva, stabilendo ad esempio che:

• Il tempo di risposta p95 non debba superare X secondi (il p95 misura il tempo entro cui viene gestita la quasi totalità delle richieste, evitando che casi estremi isolati alterino la media).
• Il superamento prolungato di questo valore per un intervallo di tempo prestabilito costituisca un inadempimento prestazionale.
• Siano definiti espressamente il numero massimo di richieste simultanee gestibili, le regole di accodamento e le modalità di gestione nei momenti di picco.

È opportuno concordare penali sotto forma di trattenute sui pagamenti o rimborsi diretti, evitando che la compensazione sia limitata a crediti utilizzabili solo su acquisti futuri. La latenza non è un mero dettaglio tecnico, ma un fattore economico: se un sistema AI di controllo qualità impiega troppi secondi per fornire un esito, la linea di produzione potrebbe non riuscire ad attenderlo e l’intero sistema rischia di essere aggirato.

4. Gestione degli errori e riaddestramento: evitare costi imprevisti dopo il rilascio

Dopo la messa in produzione, qualsiasi modello AI affronterà inevitabilmente dati nuovi ed errori imprevisti. Se il contratto non stabilisce le modalità di intervento post-rilascio, il fornitore tenderà a fatturare qualsiasi regolazione successiva come una variante di progetto a pagamento.

Il contratto dovrebbe regolare almeno quattro aspetti fondamentali:

1. Classificazione degli errori:

   • Gravità P0: incidenti di sicurezza, violazioni normative o malfunzionamenti che causano la perdita diretta di clienti.
   • Gravità P1: malfunzionamenti di funzionalità primarie.
   • Gravità P2: anomalie minori. Per ciascun livello devono essere definiti precisi tempi di presa in carico e di risoluzione.

2. Monitoraggio del Data Drift: Poiché i dati reali cambiano nel tempo rispetto a quelli usati per l’addestramento (fenomeno noto come data drift), le prestazioni del modello tendono a degradarsi. Occorre stabilire chi ha la responsabilità di monitorare lo scostamento degli indicatori e con quale frequenza debbano essere forniti i report di controllo.

3. Condizioni per il riaddestramento: Qualora il tasso di errore superi la soglia concordata o vengano introdotte nuove lingue o nuove tipologie di difetti, il fornitore deve presentare un piano di riaddestramento entro un numero stabilito di giorni lavorativi. È necessario chiarire se tali interventi siano inclusi nel canone di manutenzione del primo anno.

4. Proprietà dei dati e degli asset: Deve essere definita esplicitamente la titolarità dei dati di addestramento, delle annotazioni, dei prompt di sistema e dei set di valutazione, garantendo all’azienda il diritto di conservarli e portarli con sé alla scadenza del contratto.

Qualora il progetto coinvolga basi di conoscenza aziendali (knowledge base), la definizione dei ruoli e dei meccanismi di aggiornamento diventa prioritaria. Come approfondito nell’articolo Gestione della base di conoscenza aziendale: tre meccanismi da verificare prima dell’avvio, un archivio informativo richiede regole di governance, incentivi all’aggiornamento e criteri di obsolescenza; in mancanza di tali clausole contrattuali, si rischia di acquistare un sistema destinato a diventare rapidamente obsoleto.

Casi in cui questo approccio richiede adattamenti

Se l’azienda acquista una soluzione SaaS standardizzata anziché uno sviluppo personalizzato in outsourcing, i margini di negoziazione contrattuale sono ridotti. In questo contesto, le quattro categorie di indicatori non potranno essere inserite integralmente nel contratto, ma serviranno come criteri per la selezione del fornitore: verificare se i limiti del servizio sono chiari, se lo SLA sulla latenza prevede rimborsi per i rallentamenti, se per il peggioramento della qualità del modello sia previsto un percorso di escalation. Come minimo, si può scegliere un fornitore con standard di consegna e implementazione più maturi.

Nel caso di progetti pilota sperimentali di ridotta entità finanziaria, pretendere indicatori vincolanti sui risultati di business potrebbe risultare eccessivo. Durante una fase pilota, l’obiettivo principale è verificare la fattibilità tecnica; il contratto dovrà quindi concentrarsi sulla definizione del perimetro del test, sulle procedure di emergenza in caso di esito negativo e sui vincoli da rispettare prima di un eventuale passaggio in produzione.

Resta una questione non ancora risolta: molte PMI non hanno uno storico dati sufficiente e, al momento della firma, non riescono nemmeno a misurare i valori di riferimento. Conviene spendere prima per costruire una base dati, oppure firmare una clausola che rinvii la misurazione a un periodo concordato dopo il rilascio? Propendo per la seconda opzione, ma lascia al fornitore margini di contestazione, e potrebbe essere necessario vincolarla alle scadenze di pagamento.

Questo articolo non fornisce un modello di contratto. La logica dietro le quattro categorie si riassume in una frase: il collaudo deve dimostrare che il problema operativo è stato risolto, non che il modello fa bella figura.

Fonti e Riferimenti

• 首个！阿里云通过中国信通院5级认证_热门资讯-阿里云政企业务
• Azure OpenAI SLA: Credits, Latency and Support Plans | Redress
• AI Project Failure Rate in 2026: What the Data Shows | Folio3 AI