Un sistema di Intelligenza Artificiale non è quasi mai un “prodotto unico”: è, più spesso, un ecosistema fatto di software, modelli (anche di terzi), dati, servizi cloud, integrazioni, sensori/edge, aggiornamenti continui e – soprattutto – comportamenti che possono cambiare nel tempo. In questo scenario, i contratti non servono solo a “vendere” o “comprare” tecnologia: servono a governare rischio, responsabilità, dati, aggiornamenti e catena di fornitura.
Chi offre soluzioni AI (software, piattaforme, AI-as-a-Service) e chi le utilizza in processi operativi (PA, sanità, industria, finanza, legal, HR, sicurezza, ecc.) ha un’esigenza comune: rendere prevedibili obblighi e rimedi in un contesto in cui l’AI può essere opaca (black box) e non sempre pienamente spiegabile o prevedibile ex ante.
Di seguito una guida pratica (in ottica business e compliance) su perché e come impostare i contratti:
- con i clienti/fruitori del sistema AI;
- con i fornitori delle componenti (software, modelli, dati, cloud, servizi digitali).
1) Perché i contratti AI sono diversi dai contratti IT “tradizionali”
a) L’AI è spesso una “black box” e può generare esiti emergenti
Nei sistemi avanzati (machine learning, reti neurali) non sempre è possibile spiegare adeguatamente “come” e “perché” una certa decisione o output sia stato prodotto; questa opacità incide su trasparenza, controllo e oneri di verifica.
In parallelo, le buone pratiche contrattuali spingono verso logiche di human-in-command e verso misure di trasparenza/controllo, pur sapendo che i produttori non sempre possono prevedere con precisione il comportamento del sistema in ambiente operativo né spiegarlo ex post.
b) Il rischio non è statico: aggiornamenti, patch e “duty to update”
Per prodotti/servizi digitali e sistemi con componenti AI, la sicurezza e la conformità sono fortemente legate alla capacità di monitorare e aggiornare nel tempo. È significativo che, sul piano civilistico/consumeristico, la mancata fornitura di aggiornamenti contrattualmente previsti (o aggiornamenti difettosi/incompleti) venga letta come difetto di conformità; e l’obbligo di aggiornare si calibra su aspettative ragionevoli e finalità del contratto.
c) Catena di fornitura complessa: più attori, più punti di rottura
Nei sistemi connessi (IoT/AI-powered) la molteplicità dei soggetti coinvolti rende difficile il riparto delle responsabilità, anche perché il danno può dipendere non dal singolo “pezzo” difettoso, ma dalla difettosità dell’interazione fra componenti di diversi produttori.
Questa è una ragione strutturale per cui, in ambito AI, “senza contratti” si litiga quasi sempre su chi doveva fare cosa (e quando).
2) Contratti con i clienti/fruitori del sistema AI: le clausole che fanno la differenza
Di seguito le aree che, in un contratto AI, dovrebbero essere trattate in modo esplicito (non con formule generiche).
2.1 Oggetto, “intended use” e confini d’uso
- descrizione del sistema (modelli inclusi/terzi, componenti, integrazioni);
- scopo dichiarato e casi d’uso;
- attività vietate (es. decisioni automatizzate “sensibili”, utilizzi non autorizzati, contesti ad alto rischio senza presidî umani);
- responsabilità del cliente su input, qualità dati, configurazioni e istruzioni operative.
Qui si innesta un punto pratico: più l’uso è “aperto”, più cresce il rischio di output inattesi. La contrattualizzazione dello scenario operativo è una forma di riduzione del rischio.
2.2 Prestazioni, metriche e SLA (ma con una logica “AI-aware”)
Nei contratti AI è opportuno distinguere:
- disponibilità del servizio (uptime, tempi di ripristino);
- prestazioni misurabili (latenza, throughput);
- qualità/accuratezza: da definire con metriche realistiche (precision/recall, tasso di falsi positivi/negativi, soglie e dataset di test concordati);
- condizioni di accettazione e collaudo.
In assenza di metriche, l’aspettativa del cliente tende a diventare “il sistema doveva essere perfetto”, aspettativa incompatibile con la natura probabilistica di molti modelli.
2.3 Trasparenza, explainability, audit e “diritto di verifica”
Poiché l’AI può essere opaca e la ricostruzione tecnica del funzionamento può essere difficile, il contratto deve prevedere strumenti sostitutivi della spiegazione piena:
- documentazione tecnica (model card, data sheet, logica generale di funzionamento);
- logging e tracciamento (input/output, versioni modello, parametri, eventi);
- audit di terza parte e certificazioni (quando disponibili);
- procedure di verifica in caso di contestazione.
È utile ricordare che l’opacità può dipendere anche da vincoli di segreto industriale e da difficoltà tecniche di reverse engineering; per questo, l’impostazione “si controllerà tutto caso per caso” è spesso irrealistica e conviene costruire percorsi di validazione ex ante e gestione strutturata di aggiornamenti/manutenzione.
2.4 Dati: ruoli, liceità, sicurezza, riuso per training
Molti sistemi (specie generativi) evolvono anche grazie all’interazione con l’utente e ai dati che “vedono” in esercizio.
Per questo è decisivo stabilire contrattualmente:
- ruoli privacy (titolare/responsabile; contitolarità dove davvero necessaria);
- basi giuridiche, istruzioni, misure di sicurezza, data retention;
- divieti o condizioni di riutilizzo dei dati del cliente per addestramento/ottimizzazione (opt-in/opt-out, segregazione tenant, anonimizzazione/pseudonimizzazione);
- gestione data breach e incidenti.
2.5 Aggiornamenti, patch, change management e fine vita
L’AI “vive” di versioni. Il contratto dovrebbe disciplinare:
- quali aggiornamenti sono inclusi, con che tempi e con quali impatti;
- gestione vulnerabilità, patch di sicurezza, rollback;
- compatibilità e deprecazioni (fine vita, migrazioni);
- effetti sulle performance/metriche concordate.
Anche a livello di principi, l’idea che l’aggiornamento sia parte della conformità del servizio digitale (e non un “favore”) è un punto chiave.
2.6 Responsabilità, limitazioni, indennizzi e assicurazioni
In ambito AI, la responsabilità va gestita su due piani:
- verso il cliente (inadempimento, non conformità, interruzioni, data breach);
- verso terzi (danni da prodotto/servizio digitale integrato, errori di output, interazioni fra componenti).
Il contratto deve prevedere: cap di responsabilità, esclusione danni indiretti (nei limiti di legge), obblighi di mitigazione, franchigie, e – dove sensato – coperture assicurative.
3) Contratti con i fornitori delle componenti: la “supply chain legale” dell’AI
Se il contratto col cliente è la facciata, i contratti con i fornitori sono le fondamenta. È qui che si decide se, in caso di problema, il rischio resta tutto sul fornitore “finale” oppure si redistribuisce correttamente lungo la catena.
3.1 Mappare le componenti e trasformarle in obblighi contrattuali
Un sistema AI può includere:
- modelli di terzi (API/LLM), librerie, middleware;
- servizi cloud “correlati” al funzionamento;
- dataset e pipeline dati;
- componenti edge/hardware.
Questa mappa serve per inserire clausole “a cascata” (flow-down): ciò che si promette al cliente deve essere garantito (in tutto o in parte) dai fornitori.
3.2 Il nodo responsabilità: componenti e servizi digitali integrati
Sul piano della responsabilità da prodotto, è rilevante che il danneggiato possa agire anche verso il produttore della componente (secondary producer) se la difettosità della componente ha causato o contribuito al danno.
Inoltre, si affaccia una lettura in cui anche taluni servizi digitali integrati (servizi “correlati”) incidono sul funzionamento/sicurezza del prodotto, con conseguenze di responsabilità incrociata tra fornitore del servizio e produttore del prodotto finito.
Traduzione pratica: senza un contratto solido col fornitore (warranty + indemnity + SLA + security), il rischio tende a ricadere su chi “firma” col cliente finale.
3.3 Dati di training e diritti: attenzione a un punto spesso trascurato
Interessante (e molto concreto) è il tema di chi fornisce i training data: può non essere qualificabile come “produttore di componente” ai fini della product liability, con la conseguenza che certe tutele “automatiche” non scattano.
Per questo i contratti con data provider devono includere:
- garanzie su provenienza/liceità raccolta e selezione dati;
- diritti di utilizzo e manleve per violazioni (privacy, IP, database);
- qualità, bias, aggiornamento dataset;
- auditabilità (nei limiti praticabili).
3.4 Obblighi di aggiornamento e sicurezza “a monte”
Se sul lato cliente l’obbligo di aggiornare è essenziale, sul lato fornitore deve essere:
- imposto come obbligo (patching, vulnerability disclosure, supporto versioni);
- legato a tempi (SLA di sicurezza);
- accompagnato da rimedi chiari (crediti, sostituzione, risoluzione, indennizzo).
L’idea di doveri post-market di monitoraggio e aggiornamento – specialmente per prodotti ad alto contenuto tecnologico – è un asse portante della gestione del rischio.
4) Una checklist essenziale (pronta per essere trasformata in clausole)
Nel contratto col cliente:
- intended use + limiti d’uso + human oversight;
- SLA + metriche AI + collaudo;
- trasparenza minima, logging, audit/certificazioni;
- data governance (privacy, security, riuso per training);
- aggiornamenti e change management;
- responsabilità/limitazioni/indennizzi/assicurazioni;
- incident response e gestione contestazioni.
Nei contratti con i fornitori:
- mappa componenti e flow-down;
- garanzie su sicurezza, continuità, compliance, diritti;
- patching e supporto versioni;
- manleve (IP, data, security) coerenti col rischio reale;
- audit e disclosure controllata (anche per black box/segretazione);
- regole su subfornitori e sostituzioni componenti.
Conclusione: il contratto non è “carta”, è governance del rischio AI
In un sistema AI, il rischio non nasce solo da un bug: nasce dalla combinazione di opacità, dinamicità degli aggiornamenti, e frammentazione della supply chain.
Per questo un buon contratto – lato cliente e lato fornitori – è lo strumento che consente di:
- rendere misurabili le aspettative,
- costruire trasparenza “realistica” (non teorica),
- distribuire correttamente responsabilità e rimedi,
- proteggere il business prima che arrivi la contestazione.
Se l’obiettivo è commercializzare o adottare sistemi AI con serenità (e con contratti che reggono davvero in caso di incidente), NetworkLex può supportare: dalla costruzione del framework contrattuale (MSA/SLA/DPA), alle clausole supplier, fino alla negoziazione e alla gestione del rischio regolatorio e di responsabilità.
