Comprare AI: la due diligence sul fornitore prima di firmare

Il fornitore ti manda una slide: «il nostro software è conforme all'AI Act». È una dichiarazione, non una prova. La domanda giusta, prima di firmare, è un'altra: quali documenti mi consegni, quali controlli mi lasci, e cosa succede se domani il sistema cambia? Quando l'autorità busserà, il fornitore non risponderà al tuo posto: ciascuno risponde del proprio ruolo.

Il contratto è il punto in cui la conformità diventa verificabile

Il Regolamento UE 2024/1689 (AI Act) assegna obblighi diversi a chi fornisce un sistema di AI e a chi lo utilizza sotto la propria autorità (il deployer). Se compri un software, quasi sempre sei un deployer — ma gli obblighi del deployer (art. 26) si possono adempiere solo se il fornitore ti ha consegnato certe cose: istruzioni per l'uso complete, strumenti di supervisione umana, log estraibili.

Il legislatore lo dice apertamente. L'art. 25(4) impone che il fornitore di un sistema ad alto rischio e i terzi che gli forniscono strumenti, servizi o componenti regolino per accordo scritto le informazioni, le capacità e l'accesso tecnico necessari alla conformità (con esenzione per i componenti rilasciati con licenza libera e open source). La stessa logica vale a valle, verso di te: se non è nel contratto, non lo avrai.

Non è un problema solo teorico. L'art. 99(4) prevede sanzioni fino a 15 milioni di euro o al 3% del fatturato mondiale annuo per la violazione, tra gli altri, degli obblighi degli articoli 25(2) e (4), 26 e 50. Per le PMI e le start-up l'art. 99(6) applica il valore minore tra i due: una mitigazione, non un'esenzione.

Le tre porte da cui si diventa fornitore senza accorgersene

L'art. 25(1) elenca tre situazioni in cui chi ha comprato un sistema diventa fornitore, ereditando gli obblighi dell'art. 16:

1. Il marchio. Apponi il tuo nome o marchio su un sistema ad alto rischio già immesso sul mercato o messo in servizio: il classico white label.
2. La modifica sostanziale. Modifichi in modo sostanziale un sistema ad alto rischio che resta tale. L'art. 3(23) definisce sostanziale la modifica non prevista nella valutazione di conformità iniziale, che incide sulla conformità ai requisiti o cambia la finalità prevista.
3. Il cambio di finalità. Cambi la finalità prevista di un sistema — anche di un sistema di AI per finalità generali — non classificato ad alto rischio, così che lo diventi.

Due righe di offerta commerciale ("personalizzazione con logo cliente", "fine-tuning sui vostri dati") possono spostare su di te l'intero peso normativo. Vanno lette con attenzione e, se serve, riscritte.

Le domande da fare prima di firmare

Cosa sto comprando, esattamente

• Il prodotto è un sistema di AI ai sensi dell'art. 3(1)? Integra un modello di AI per finalità generali di terzi? Quale, e con quale versione?
• Qual è la finalità prevista dichiarata, e il mio caso d'uso ci rientra? Uscirne è il modo più rapido per ricadere nell'art. 25(1)(c).
• Secondo il fornitore il sistema ricade nell'Allegato III? Chi ha fatto la classificazione, e su quale documentazione?

Documentazione che deve arrivare, non "essere disponibile su richiesta"

• Istruzioni per l'uso conformi all'art. 13(3): identità e contatti del fornitore; finalità prevista, contesto e condizioni d'uso; livello di accuratezza con le relative metriche, robustezza e cibersicurezza; circostanze note o prevedibili che possono generare rischi per salute, sicurezza o diritti fondamentali; specifiche sui dati di input; misure di supervisione umana; risorse necessarie, vita utile attesa e manutenzione; descrizione dei meccanismi di registrazione dei log.
• Se sotto c'è un modello GPAI di terzi: la documentazione che il suo fornitore deve mettere a disposizione di chi lo integra, ai sensi dell'art. 53(1)(b) e dell'Allegato XII.

Controllo operativo: potrò davvero rispettare l'art. 26?

• Log. Il sistema li genera, io posso estrarli e conservarli? L'art. 26(6) chiede al deployer di conservarli per almeno sei mesi, salvo diversa previsione di legge. Se restano nel cloud del fornitore e non sono esportabili, l'obbligo è irrealizzabile.
• Supervisione umana. Quali strumenti tecnici mi date per interpretare l'output e intervenire? L'art. 26(2) mi impone di affidare la supervisione a persone con competenza, formazione e autorità adeguate: senza strumenti, quell'autorità è finzione.
• Dati di input. Quando li controllo io, l'art. 26(4) chiede che siano pertinenti e sufficientemente rappresentativi rispetto alla finalità prevista. Che indicazioni mi date per garantirlo?
• Incidenti e modifiche. Con quale canale, e in quali tempi, mi segnalate malfunzionamenti, incidenti gravi o il cambio del modello sottostante?

Dati personali e obblighi paralleli

• Accordo sul trattamento ex art. 28 GDPR, con un punto da chiarire sempre: i miei dati e i prompt dei miei dipendenti vengono usati per addestrare i vostri modelli? Se sì, come lo escludo?
• Le informazioni dell'art. 13 mi arrivano in forma utilizzabile per la mia DPIA? L'art. 26(9) presuppone esattamente questo passaggio.
• Se il sistema genera contenuti sintetici o interagisce con persone: chi appone marcature e informative dell'art. 50, voi nel prodotto o io a valle?
• Se lo userò sul lavoro, l'art. 26(7) mi impone di informare i rappresentanti dei lavoratori e i lavoratori interessati prima della messa in servizio.

Le clausole modello UE: un capitolato già scritto

Non serve partire da zero. Il 5 marzo 2025 la Community of Practice on Public Procurement of AI, con il supporto della Commissione europea, ha pubblicato la versione aggiornata delle clausole contrattuali modello per l'appalto di IA (MCC-AI): una versione completa, allineata ai requisiti del Capo III per i sistemi ad alto rischio; una versione light, personalizzabile, per i sistemi non ad alto rischio; e un commentario che spiega come e quando usarle. Sono disponibili in 24 lingue.

Due avvertenze d'uso: sono volontarie — nessuna norma le impone — e sono scritte per gli acquirenti pubblici. Per una PMI privata restano però il miglior punto di partenza gratuito disponibile: usale come checklist di negoziazione su trasparenza, gestione del rischio, governance dei dati, supervisione umana, cibersicurezza e monitoraggio lungo il ciclo di vita, anche quando non le adotti alla lettera.

Le date contano più di quanto sembri

Un contratto software dura tipicamente tre-cinque anni; il quadro normativo, nel frattempo, si muove. Dopo il Regolamento (UE) 2026/1744 ("Digital Omnibus" sull'IA, pubblicato in GU UE il 24 luglio 2026 e in vigore dal 27 luglio 2026) il calendario è questo:

La conseguenza pratica è una sola: il sistema che compri oggi come "non ad alto rischio" può essere riclassificato — da un cambio del tuo caso d'uso o da orientamenti successivi. Metti a contratto un impegno del fornitore a mantenere la conformità alle date di applicazione future, con obbligo di preavviso e diritto di recesso se non ci arriva.

E ricorda che alcune regole sono già operative oggi: il divieto delle pratiche vietate dell'art. 5, l'obbligo di alfabetizzazione dell'art. 4 — riformulato dall'Omnibus in termini di misure "effettive e proporzionate", senza pretendere un livello garantito per ciascun individuo — e, in Italia, l'informativa al cliente sull'uso dell'IA introdotta dalla Legge 132/2025 per i professionisti intellettuali.

Da dove partire

Prima di negoziare serve sapere che cosa stai comprando e in quale ruolo ti mette. Un gap assessment indipendente sul parco applicativo — quali sistemi hai, quale rischio portano, quali documenti mancano — trasforma una trattativa fatta di dichiarazioni in un capitolato con requisiti verificabili. È l'ora meglio spesa del progetto: costa molto meno di una migrazione decisa dopo.