Valutazione dei fornitori di IA: le dodici domande mancanti

In sintesi

• La valutazione dei fornitori è stata concepita per una catena di fornitura che consegnava software immutabile. Accerta che un fornitore sia solvibile, assicurato e certificato, ma non dice nulla sui dati con cui un modello è stato addestrato né su come esso cambierà dopo la firma.
• Ai sensi dell’articolo 25, paragrafo 4 dell’AI Act, la verifica di un fornitore di IA non è più una buona pratica ma un obbligo giuridico. Un accordo scritto deve precisare informazioni, capacità e accesso tecnico necessari.
• L’articolo 25, paragrafo 1 contiene la trappola che quasi nessun acquirente considera: apporre il proprio marchio, modificare sostanzialmente il sistema o mutarne la finalità vi rende fornitori a tutti gli effetti.
• La norma ISO/IEC 42001 (A.10.3) e il NIST AI RMF (GOVERN 6.1) convergono su un principio: la responsabilità non si trasferisce al fornitore.
• L’evento che deve far ripartire il riesame non è la scadenza annuale del contratto, ma il cambio di versione del modello.

Che cosa copre oggi la valutazione dei fornitori

Chiedete a una qualsiasi piattaforma di gestione del rischio di terze parti che cosa debba contenere un riesame e otterrete una risposta sorprendentemente uniforme. La valutazione dei fornitori indica il processo precontrattuale con cui si accerta che a un terzo possa essere affidata una funzione aziendale. La griglia consueta si articola in sei o sette voci: assetto giuridico e societario, titolari effettivi, solidità finanziaria, attestazioni di sicurezza e riservatezza quali SOC 2 o ISO/IEC 27001, resilienza operativa e continuità aziendale, infine screening regolamentare su sanzioni, contenziosi e stampa avversa. I programmi maturi cominciano col graduare i fornitori per criticità, così che un gestore delle buste paga sia esaminato più a fondo di un fornitore di cancelleria. Raccolgono poi le evidenze, le confrontano con una propensione al rischio definita e fissano una periodicità di riesame già al momento dell’ingresso in relazione. Nulla di tutto questo è sbagliato. Si tratta di un processo solido, affinato da vent’anni di esternalizzazioni, e resta il fondamento di qualunque impianto di governance dell’IA. Il problema è più circoscritto: ciascuna di quelle voci descrive l’azienda da cui state acquistando. Nessuna descrive il modello che state acquistando.

Valutazione dei fornitori e due diligence commerciale

La confusione fra i due termini è abbastanza diffusa da meritare un chiarimento. La due diligence commerciale verifica se mercato, portafoglio clienti e ricavi di una società obiettivo giustifichino una valorizzazione, e appartiene al mondo delle operazioni straordinarie. La valutazione dei fornitori verifica invece se un fornitore possa erogare un servizio senza introdurre nella vostra organizzazione un rischio inaccettabile. Nel lessico delle transazioni la locuzione inglese vendor due diligence designa per giunta una relazione che il venditore commissiona su se stesso per accelerare una cessione. In queste pagine il termine va inteso nel primo senso: siete voi ad acquistare, ed è il fornitore a consegnarvi un sistema di IA.

Perché la checklist standard non regge davanti a un fornitore di IA

Una relazione SOC 2 di tipo II è il giudizio di un revisore secondo cui un’azienda ha applicato per un certo periodo i controlli dichiarati. Vi dice che i locali sono chiusi, che gli accessi vengono riesaminati e che i backup sono collaudati. Non vi dice con quali dati sia stato addestrato il modello, se quei dati fossero licenziati, su quali popolazioni il modello sia stato valutato, né che cosa sia cambiato nel suo comportamento con l’ultimo rilascio. Sono domande di natura diversa su un oggetto diverso, e il questionario consueto non le pone. Quattro caratteristiche dei fornitori di IA mandano in crisi il riesame tradizionale. Il prodotto non è deterministico. Il software convenzionale restituisce lo stesso risultato a parità di input, sicché un collaudo una tantum è sufficiente a descriverne il comportamento. Un modello di IA non offre la stessa garanzia. La prova che un sistema si sia comportato adeguatamente in fase pilota ha dunque un valore probatorio inferiore rispetto al medesimo esito su uno strumento deterministico, e un riesame costruito attorno a un collaudo puntuale finisce per sopravvalutare tacitamente ciò che ha dimostrato. Il prodotto cambia senza che cambi il contratto. I fornitori riaddestrano, sostituiscono il modello di base e ritoccano di continuo le istruzioni di sistema. Un sistema approvato a marzo può comportarsi in modo sensibilmente diverso a giugno, senza atto aggiuntivo, senza preavviso e senza nuova attestazione. Gli acquisti tradizionali non prevedono un evento del genere, perché il software classico usciva per versioni annunciate su una tabella di marcia visibile. La catena arriva più in fondo del vostro registro. Il vostro fornitore è spesso un sottile strato applicativo poggiato sul modello di base di un terzo, a sua volta erogato da un quarto operatore. L’esposizione ai subfornitori non è una novità, ma nell’IA è il subfornitore a determinare il comportamento di ciò che avete comprato, e non soltanto la sua disponibilità. La maggior parte dei registri fornitori si ferma alla controparte diretta. La trasparenza si scontra con il segreto industriale. Il NIST osserva che i fornitori rifiutano con regolarità di comunicare la composizione dei dati di addestramento, l’architettura o i risultati delle valutazioni, invocando la riservatezza commerciale, e che GOVERN 6.1, il controllo dedicato ai terzi, figura fra quelli che più spesso non superano gli audit indipendenti. Quel rifiuto è di per sé un esito di verifica, e un riesame che tratti «il fornitore non ha risposto» come una casella vuota anziché come una classificazione di rischio non sta assolvendo al proprio compito. Una quinta difficoltà sfugge del tutto al questionario. I fornitori aggiungono funzioni di IA a strumenti che già possedete, sicché l’IA entra in azienda attraverso un rinnovo e non attraverso un acquisto. È il volto contrattuale della shadow AI, e nessun rigore precontrattuale la intercetta se nulla riapre il fascicolo.

L’obbligo giuridico che quasi nessun acquirente considera: l’articolo 25 dell’AI Act

La letteratura di settore presenta l’esame dei fornitori come prudente gestione del rischio. Per una porzione consistente delle applicazioni europee si tratta ormai di un obbligo giuridico ancorato a una disposizione precisa, il che muta tanto l’urgenza quanto la natura delle prove da conservare.

L’obbligo di accordo scritto

L’articolo 25, paragrafo 4 stabilisce che il fornitore di un sistema di IA ad alto rischio e il terzo che fornisce un sistema, strumenti, servizi, componenti o processi utilizzati o integrati in tale sistema precisano, mediante accordo scritto, le informazioni, le capacità, l’accesso tecnico e ogni altra assistenza necessari a conformarsi al regolamento, sulla base dello stato dell’arte generalmente riconosciuto. Questa disposizione va letta come un’istruzione di acquisto. Se sviluppate o immettete sul mercato un sistema ad alto rischio e una parte di esso proviene dall’esterno, il relativo flusso informativo deve trovare posto nel contratto. Non basta la rassicurazione verbale di un ingegnere prevendita, e non basta un questionario compilato che giace su una cartella condivisa. L’obbligo consiste nell’avere concordato per iscritto, prima di averne bisogno, che cosa il fornitore vi comunicherà e quale accesso vi aprirà.

Quando l’acquirente diventa fornitore

L’articolo 25, paragrafo 1 è la disposizione che trasforma una decisione di acquisto in un impegno di conformità. Un distributore, un importatore, un deployer o qualunque altro terzo è considerato fornitore di un sistema ad alto rischio, e soggetto agli obblighi dell’articolo 16, in tre casi: quando appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, quando apporta a tale sistema una modifica sostanziale, oppure quando muta la finalità prevista di un sistema non classificato ad alto rischio in modo tale che esso lo diventi. Ciascuna di queste ipotesi descrive una prassi corrente che nessuno percepisce come atto regolamentare. Commercializzare in marchio proprio una soluzione acquistata ricade nella lettera a). Un affinamento sui propri dati spinto fino a uscire dal perimetro della valutazione di conformità iniziale ricade nella lettera b). Orientare uno strumento di selezione generico verso decisioni di assunzione ricade nella lettera c). L’articolo 3, punto 23 definisce la modifica sostanziale come un cambiamento non previsto né pianificato nella valutazione di conformità iniziale, per effetto del quale risulta compromessa la conformità ai requisiti del capo III, sezione 2, oppure risulta modificata la finalità prevista. Per i modelli per finalità generali gli orientamenti della Commissione propongono un riferimento quantitativo indicativo: un affinamento che impieghi più di circa un terzo della potenza di calcolo dell’addestramento originario depone nel senso che il soggetto a valle assuma gli obblighi di fornitore sul modello modificato. La nostra guida all’IA per finalità generali illustra come tali obblighi a monte si intreccino con i vostri. Sul piano pratico ne discende una domanda da inserire nel questionario: intendiamo modificare questo sistema? La risposta determina quale regime di obblighi state acquistando. Gli studi sui sistemi agentici, fra cui AI Agents Under EU Law, rilevano come la deriva comportamentale in esecuzione mal si concili con il confine tracciato dall’articolo 3, punto 23, poiché un sistema che muta il proprio comportamento dopo il rilascio può varcare una linea che i redattori immaginavano varcata deliberatamente da una persona.

Che cosa vi deve il fornitore iniziale

L’obbligo non è unidirezionale. L’articolo 25, paragrafo 2 impone al fornitore iniziale di cooperare strettamente con ogni nuovo fornitore, mettendo a disposizione le informazioni necessarie nonché l’accesso tecnico e l’assistenza ragionevolmente attesi affinché questi possa adempiere ai propri obblighi, in particolare quanto alla valutazione di conformità. Se il contratto del vostro fornitore esclude in radice tale cooperazione, la clausola si pone in tensione con il regolamento: è legittimo sollevarla in negoziazione anziché accettarla come formula di stile. La nostra guida operativa al regolamento UE sull’IA illustra nel complesso la ripartizione fra ruolo di fornitore e ruolo di deployer.

Che cosa richiedono ISO 42001, NIST AI RMF e DORA alla valutazione dei fornitori

Tre riferimenti affrontano la gestione dei fornitori per strade diverse, e una valutazione che soddisfi tutti e tre risulta difendibile nella maggior parte degli ordinamenti.

ISO/IEC 42001: la responsabilità non si trasferisce

Il controllo A.10 dell’allegato A disciplina i rapporti con terzi e clienti. Il controllo A.10.2 impone di ripartire con chiarezza ruoli e responsabilità fra tutte le parti esterne che intervengono nel ciclo di vita del sistema di IA, dai fornitori di dati agli sviluppatori di modelli, dai gestori di piattaforma agli integratori, affinché nessun obbligo cada nell’intercapedine fra due organizzazioni ciascuna convinta che se ne occupasse l’altra. Il controllo A.10.3 impone una gestione attiva dei fornitori di IA, così che modelli, insiemi di dati e componenti acquisiti restino allineati ai vostri obiettivi di IA responsabile, con evidenza data da valutazioni dei fornitori e da clausole contrattuali su trasparenza e distorsioni. Il principio che sorregge entrambi i controlli pesa più della loro lettera: la responsabilità non si trasferisce. Restate voi a rispondere dell’esito anche quando a determinarlo è stato un fornitore. La nostra presentazione della ISO 42001 colloca l’allegato A nel sistema di gestione complessivo.

NIST AI RMF: il controllo che fa fallire gli audit

La funzione GOVERN 6 tratta i rischi derivanti da software, dati e catene di fornitura di terzi. Il controllo GOVERN 6.1 estende la vostra governance ai modelli dei fornitori, alle interfacce applicative esterne, agli insiemi di dati preaddestrati e ai componenti open source, e afferma senza ambiguità che l’esposizione giuridica per violazione della proprietà intellettuale, per dati di addestramento protetti dal diritto d’autore e per lesioni della riservatezza incorporate in un modello di terzi resta in capo all’organizzazione che lo utilizza. Il controllo GOVERN 6.2 richiede processi di continuità in caso di guasto di un terzo, comprensivi di soluzioni di ripiego e di criteri per la dismissione. La nostra guida al NIST AI RMF ne espone l’architettura completa.

DORA: il registro e le clausole obbligatorie

Gli enti finanziari sopportano un livello ulteriore. Il regolamento DORA, applicabile dal 17 gennaio 2025, impone agli articoli da 28 a 30 la tenuta di un registro informativo di tutti gli accordi contrattuali con fornitori terzi di servizi TIC, distinguendo quelli a supporto di funzioni essenziali o importanti dagli altri. L’articolo 30 prescrive le clausole che devono comparire in tali contratti: descrizione del servizio e livelli di prestazione, ubicazione dei dati, notifica delle modifiche, diritti di audit, segnalazione degli incidenti, continuità operativa e diritti di recesso. I fornitori di IA e di grandi modelli linguistici possono rientrare nel perimetro in qualità di fornitori terzi di servizi TIC. Nel novembre 2025 le autorità europee di vigilanza hanno designato i primi diciannove fornitori terzi critici, un elenco dominato dalle piattaforme cloud su cui poggia la maggior parte dei servizi di IA. In Italia la Banca d’Italia veicola queste aspettative verso gli intermediari vigilati, mentre il Garante per la protezione dei dati personali e l’AgID presidiano rispettivamente il versante dei dati personali e quello dell’amministrazione digitale.

Le dodici domande di IA da aggiungere al questionario di valutazione dei fornitori

Queste domande si affiancano alle vostre sezioni esistenti su sicurezza, solidità finanziaria e continuità, senza sostituirle. Per ciascuna conta la prova attesa, non la risposta in sé. L’articolazione che segue riprende quella della guida a licenza aperta AI Vendor Security and Safety Assessment Guide di Dennis Ah-king, pensata per innestarsi su un processo di gestione del rischio di terze parti già esistente.

Provenienza e dati

1. Con quali dati è stato addestrato il modello e sotto quale licenza? Attendetevi una dichiarazione documentata che indichi fonti e base giuridica. «Dati pubblicamente disponibili» non è una risposta. 2. I nostri dati addestrano i vostri modelli, in via predefinita o su opzione? Attendetevi un impegno contrattuale, non la schermata di un’impostazione. Verificate se il valore predefinito muti al rinnovo. 3. Quali subfornitori e quali fornitori di modelli operano dietro questo servizio? Attendetevi un elenco nominativo accompagnato da un impegno di notifica. Se il fornitore rivende un modello di base, vi riguardano anche le condizioni del fornitore a monte.

Comportamento del modello e cambiamenti

4. Quali valutazioni sono state condotte, su quali popolazioni e con quali risultati? Attendetevi relazioni con risultati disaggregati. Un’accuratezza complessiva nasconde proprio i modi di fallimento da cui nasce l’esposizione giuridica. 5. Come ci comunicherete un cambio di versione del modello e con quale preavviso? Attendetevi un termine e un canale definiti. È la risposta di gran lunga più preziosa dell’intero elenco. 6. Come rilevate e segnalate il degrado delle prestazioni dopo il rilascio? Attendetevi un monitoraggio i cui esiti siano visibili a voi, preferibilmente un indicatore che ricevete anziché un cruscotto che consultano loro. 7. Qual è la finalità prevista del sistema secondo la vostra valutazione? Attendetevi una dichiarazione scritta. Un impiego previsto che se ne discosti è la via più rapida verso gli obblighi di fornitore.

Catena e dipendenze

8. Questo sistema è classificato ad alto rischio ai sensi dell’AI Act e su quale base? Attendetevi una classificazione motivata. Un disaccordo su questo punto va risolto prima della firma. 9. Se affiniamo il modello o vi apponiamo il nostro marchio, come cambia la ripartizione delle responsabilità? Attendetevi una risposta che affronti espressamente l’articolo 25. Un fornitore che non ci abbia riflettuto vi sta già dicendo qualcosa. 10. Quale documentazione tecnica fornirete e sarà tenuta aggiornata? Attendetevi un impegno coerente con ciò che voi stessi dovete alla vostra autorità. La nostra guida alla documentazione dei sistemi di IA ne fissa la soglia minima.

Prove e uscita

11. Di quali diritti di audit disponiamo e si estendono al vostro fornitore di modelli? Attendetevi diritti che superino il confine del subfornitore, poiché è lì che il comportamento viene realmente determinato. 12. Alla cessazione, che fine fanno i nostri dati, i pesi affinati e le rappresentazioni vettoriali? Attendetevi un impegno di cancellazione che copra gli artefatti derivati e non soltanto i dati di origine. Quando un fornitore rifiuta di rispondere, verbalizzate il rifiuto, classificate il rischio residuo e indirizzatelo a chi ha il potere di accettarlo. Una domanda declinata è un risultato.

Le clausole contrattuali che rendono vincolanti le risposte

Le risposte a un questionario non vincolano nessuno. Le clausole che le trasformano in obbligazioni sono proprio quelle che più spesso mancano ai contratti di IA, perché un contratto software generico non è stato redatto per un prodotto non deterministico. Le guide destinate ai legali che negoziano con fornitori di IA individuano invariabilmente lo stesso insieme: limiti all’uso dei dati del cliente a fini di addestramento, titolarità e licenza degli output del modello, diritti di notifica e di approvazione sulle modifiche del modello, consenso su subfornitori e fornitori di modelli, diritti di audit che raggiungano il fornitore a monte, obblighi di test e correzione delle distorsioni, livelli di servizio adeguati a un output probabilistico e, infine, previsioni di uscita che smontino pesi affinati e rappresentazioni vettoriali e non soltanto i dati archiviati. Due meritano un rilievo particolare. Le clausole di modifica unilaterale, ordinarie nei contratti software, assumono ben altra portata quando l’oggetto modificato è il modello stesso. E i massimali di responsabilità fissati a dodici mensilità di corrispettivo erano tarati su interruzioni di servizio, non su un accertamento di discriminazione originato da un modello che non avete costruito. La nostra guida alla conformità IA colloca questi elementi in un quadro più ampio.

Riesame: gli eventi che devono riaprire il fascicolo

La maggior parte dei programmi riesamina i fornitori una volta l’anno, oppure al rinnovo del contratto. Per un fornitore di IA quella cadenza è disallineata rispetto al rischio, perché l’oggetto esaminato muta al ritmo dei rilasci del fornitore e non a quello del vostro calendario di acquisti. Sostituite o integrate il calendario con eventi scatenanti:

• Un cambio di versione del modello, o un cambio del modello di base sottostante
• L’ingresso nella catena di un nuovo subfornitore o fornitore di modelli
• Un ampliamento delle capacità, in particolare quando apra al sistema nuove azioni o nuovi strumenti
• Una modifica della finalità dichiarata, a opera dell’una o dell’altra parte
• Ogni decisione da parte vostra di affinare, marchiare o riorientare il sistema, poiché attiva l’articolo 25, paragrafo 1
• Un incidente segnalabile, presso il fornitore come nel vostro stesso impiego
• Una deriva misurata che superi una soglia definita all’avvio del rapporto

Gli ultimi due collegano questo processo a controlli che forse già gestite e che la nostra guida alla gestione del rischio IA descrive. Agganciare il riesame dei fornitori a questi segnali, anziché a una data, è ciò che rende il dispositivo adeguato al comportamento reale dei fornitori di IA.

Domande frequenti

Che differenza c’è fra adeguata verifica della clientela e valutazione dei fornitori? L’adeguata verifica della clientela nasce dall’antiriciclaggio: identità, titolari effettivi e posizione sanzionatoria di un cliente vengono accertate prima dell’avvio del rapporto, per impulso della normativa finanziaria. La valutazione dei fornitori percorre la direzione opposta e riguarda un soggetto da cui verrete a dipendere. Le due condividono tecniche di screening e spesso le medesime banche dati, il che spiega la confusione, ma rispondono a domande diverse davanti ad autorità diverse. Che differenza c’è fra valutazione dei fornitori e due diligence commerciale? La due diligence commerciale accerta se un’impresa valga il prezzo che un acquirente si accinge a pagare, esaminandone posizione di mercato, concentrazione della clientela e qualità dei ricavi: appartiene a un’operazione straordinaria. La valutazione dei fornitori accerta se un fornitore possa erogare senza introdurre un rischio inaccettabile nelle vostre operazioni, e appartiene agli acquisti e alla gestione del rischio di terze parti. Una relazione SOC 2 è sufficiente per un fornitore di IA? No. Una relazione SOC 2 è un giudizio sull’effettiva applicazione dei controlli dichiarati lungo un periodo, fra cui gestione degli accessi, gestione delle modifiche e monitoraggio. È utile e non dice nulla su provenienza dei dati di addestramento, esiti delle valutazioni, test sulle distorsioni o gestione delle versioni del modello. Consideratela necessaria ma non sufficiente e aggiungete le domande specifiche sul modello. Quando l’acquisto di un sistema di IA ci rende suoi fornitori? Ai sensi dell’articolo 25, paragrafo 1 dell’AI Act, in tre situazioni: apponete il vostro nome o marchio su un sistema ad alto rischio già immesso sul mercato, vi apportate una modifica sostanziale, oppure ne mutate la finalità prevista al punto da renderlo ad alto rischio. Ciascuna vi trasferisce gli obblighi di fornitore dell’articolo 16, fra cui sistema di gestione della qualità, documentazione tecnica e valutazione di conformità. Con quale frequenza va riesaminato un fornitore di IA? Mantenete un riesame annuale per continuità e solidità finanziaria e aggiungete eventi scatenanti per tutto ciò che attiene al modello. Un cambio di versione, un nuovo subfornitore, un ampliamento delle capacità, un incidente o una deriva misurata devono riaprire il fascicolo a prescindere dalla data dell’ultimo esame. Riesaminare un fornitore sulla sola base del calendario significa valutare un sistema che forse non è più quello che avevate valutato. Che fare se un fornitore rifiuta di comunicare i dati di addestramento? Verbalizzate il rifiuto come esito di verifica e non come domanda rimasta senza risposta, quindi classificate di conseguenza il rischio residuo. Il NIST tratta la mancata divulgazione per segreto industriale come una caratteristica riconosciuta di questo mercato, non come un’anomalia. Posizioni accettabili restano possibili per altre vie: una manleva contrattuale per pretese in materia di proprietà intellettuale e riservatezza derivanti dai dati di addestramento, l’attestazione di un terzo, oppure una garanzia più circoscritta sulla base giuridica delle licenze anziché la divulgazione integrale.

Conclusione

La disciplina dispone di un buon processo. Vent’anni di gestione del rischio di terze parti hanno prodotto un riesame che accerta con affidabilità se un fornitore esisterà ancora l’anno prossimo e se la sua rete interna regge. Ciò per cui non è mai stato concepito è descrivere un modello: da dove provengano i suoi dati di addestramento, come si comporti con le persone che servite e che cosa sia cambiato al suo interno la settimana scorsa. L’articolo 25, paragrafo 4 ha già trasformato quello scarto in una questione giuridica per le applicazioni ad alto rischio in Europa, e tanto la ISO/IEC 42001 quanto il NIST AI RMF vi giungono per via di governance anziché di legge. Il rimedio non consiste nel costruire un nuovo programma. Sta in dodici domande in più, in una manciata di clausole che rendano vincolanti le risposte e in un evento scatenante che scatti a un cambio di versione anziché a una data. Per collocare la prova sul fornitore in un insieme di controlli più ampio, partite dalla nostra guida al rischio IA.