All’indomani della pubblicazione del Digital Omnibus AI (Reg. UE 2026/1744) che aggiorna l’AI Act, e dell’entrata in vigore delle norme sulla trasparenza art. 50, resta fondamentale il tema della responsabilità civile di tutti gli attori della catena, con particolare riferimento al deployer, cioè all’utilizzatore professionale di sistemi AI. L’equivoco nasce infatti dal ritenere sufficiente il rispetto degli obblighi di cui all’AI Act per andare esenti da responsabilità, in particolare civile: non è così.
Indice degli argomenti:
Il deployer nell’AI Act tra obblighi e responsabilità civile
Sappiamo invero che gli obblighi derivanti dall’AI Act si declinano in base al ruolo (fornitore, deployer, importatore, ecc.) e al tipo di sistema o modello AI (vietato, ad alto rischio, soggetto a obblighi di trasparenza, a finalità generali).
Fermo restando che, come spesso accade con normative in materia tecnologica, il legislatore rincorre il mercato (si pensi agli AI Agent, che attualmente non trovano una precisa collocazione nelle fonti considerate), i professionisti coinvolti nella filiera dell’intelligenza artificiale si trovano a dover gestire la propria responsabilità nei rapporti con gli altri fornitori e con il cliente finale di fronte a casistiche a volte non previste dall’AI Act.
Focalizzando l’attenzione sul deployer, il quale, pur non essendo il creatore della tecnologia, è spesso la prima controparte contrattuale del cliente o del destinatario del servizio, occorre definire quali siano i suoi principali obblighi di compliance, dunque inderogabili, e quali siano invece gli aspetti che possono essere gestiti pattiziamente con le controparti.
Il punto non è soltanto stabilire chi abbia sviluppato il modello o il sistema AI, ma capire quale obbligazione sia stata dedotta in contratto dal deployer e chi controlli in concreto il fattore che ha generato l’errore, che – ricordiamo – è fattore ineliminabile dell’AI e come tale va gestito in base al rischio cui espone.
Gli obblighi inderogabili per i sistemi ad alto rischio
Tanto premesso e fermo restando il divieto di alcuni tipi di “pratiche” individuate dall’art. 5 dell’AI Act, quanto ai sistemi ad alto rischio gli obblighi del deployer sono espressi con chiarezza.
L’AI Act impone di adottare misure tecniche e organizzative idonee a garantire l’uso conforme alle istruzioni, di affidare la sorveglianza umana a persone dotate di competenza, formazione e autorità adeguate, di assicurare – nei limiti del controllo esercitato – che i dati di input siano pertinenti e sufficientemente rappresentativi, ecc. Ciò in quanto i rischi dell’Ai non derivano solo dalla progettazione, ma anche dal modo in cui il sistema è utilizzato nel contesto reale.
Accanto a questi obblighi, per i sistemi ad alto rischio opera un autonomo dovere di trasparenza “tecnica” verso il deployer. L’AI Act richiede che tali sistemi siano progettati e sviluppati in modo da rendere il loro funzionamento sufficientemente trasparente da consentire al deployer di interpretarne l’output e usarlo adeguatamente, e che siano accompagnati da istruzioni per l’uso concise, complete, corrette, accessibili e comprensibili.
Le tre aree della responsabilità del deployer
Vi è poi una seconda area, diversa dai sistemi ad alto rischio, in cui l’AI Act impone obblighi specifici di trasparenza, si pensi ai sistemi Ai che generano o manipolano un testo pubblicato allo scopo di informare il pubblico su questioni di interesse pubblico oppure ai contenuti generati o manipolati in forma di deep fake.
Per entrambe queste aree, il contratto non può certo spostare sul provider gli obblighi che l’AI Act pone direttamente sul deployer, ma può rendere tali obblighi, e più in generale le condotte dovute, attuabili, verificabili e difendibili.
Il problema più delicato si colloca tuttavia nella terza area, quella (i) dei sistemi che non sono ad alto rischio e che neppure rientrano nei casi coperti dagli specifici obblighi di trasparenza dell’AI Act, oppure (ii) dei sistemi che, pur rientrando nelle prime due aree, estendono la loro applicabilità ad aspetti non disciplinati dall’AI Act.
Sul punto il regolamento europeo tace. Il risultato è che la responsabilità non scompare ma si sposta principalmente sul contratto e sul diritto civile comune.
Il contratto del deployer tra obblighi, controllo e prova
Ne deriva che, per ciascuna delle tre aree sopra descritte, la funzione del contratto non è “neutralizzare” la responsabilità dichiarandosi compliant con l’AI Act (previsione ricorrente nella prassi ma tecnicamente superflua, trattandosi di obbligo inderogabile di legge), bensì svolgere tre operazioni, ovviamente da declinare in base al tipo di sistema AI.
1. Concretizzare gli obblighi nell’uso dell’AI
La prima è concretizzare l’obbligo. Nozioni come uso conforme, sorveglianza umana, adeguatezza degli input, accuratezza, rischio prevedibile e affidabilità ragionevolmente attesa dell’output restano troppo elastiche se non vengono tradotte in parametri operativi.
Sul piano contrattuale, questo significa definire finalità prevista, limiti d’uso, qualità minima degli input, soglie prestazionali, tempi di reazione alle anomalie, procedure di escalation, condizioni di sospensione del sistema e regole di riesame umano, a maggior ragione quando il sistema non è coperto da obblighi derivanti dall’AI Act.
2. Allocare le sfere di controllo nella filiera
La seconda è allocare le sfere di controllo. Occorre distinguere ciò che dipende dalla progettazione del sistema, dalle istruzioni del fornitore, dalla configurazione del deployer, dagli input caricati, dalla verifica umana effettuata od omessa, e dalla condotta del cliente.
Questa mappa è essenziale sia per prevenire il danno sia per attribuirne correttamente la causa. In mancanza, il deployer rischia di rispondere verso il cliente come unico debitore della prestazione, senza poter poi ricostruire con precisione la responsabilità interna nella filiera.
3. Predisporre le prove per un eventuale contenzioso
La terza è predisporre la prova. In un eventuale contenzioso conteranno la versione del sistema usata, i log disponibili, gli aggiornamenti intervenuti, le istruzioni ricevute, i dati di input, gli alert prodotti e le verifiche umane svolte.
Per questo accesso ai log, loro conservazione ed esportabilità non sono soltanto dettagli tecnici, ma anche condizioni di difesa. La centralità della trasparenza come condizione di imputabilità e verificabilità è del resto coerente anche con la giurisprudenza amministrativa sull’uso di algoritmi, che richiede la comprensibilità delle modalità di funzionamento, delle istruzioni impartite e della possibilità di verificare la logicità e correttezza degli esiti.
Deployer e provider: due diligence e allocazione del rischio
Il contratto a monte con il provider costituisce un presidio importante, ma nella pratica è spesso predisposto unilateralmente e non negoziabile. Il deployer deve quindi svolgere una due diligence contrattuale e tecnica, verificando se e con quale livello di dettaglio siano disciplinati almeno i seguenti profili: identificazione del sistema e della finalità prevista, disponibilità di informazioni e istruzioni adeguate, livelli di servizio e prestazioni verificabili, comunicazione degli aggiornamenti e delle modifiche significative, cooperazione nella gestione degli incidenti, accesso a log e documentazione, nonché allocazione delle responsabilità per difetti originari, istruzioni fuorvianti, omissioni informative o violazioni degli impegni assunti dal provider, clausole di limitazione degli importi risarcibili.
L’assenza o l’insufficienza di tali previsioni deve essere considerata nella valutazione del rischio da parte del deployer e, ove necessario, compensata mediante ulteriori misure organizzative, tecniche o procedurali (anche a livello di cybersecurity).
Il contratto con il cliente e i confini della responsabilità
Il contratto a valle con il cliente richiede invece un equilibrio diverso. Il deployer non dovrebbe limitarsi a dichiarare che “usa l’AI”, ma descrivere la prestazione in modo coerente con la tecnologia impiegata: se l’output è una raccomandazione, una previsione o un elemento di supporto decisionale; quali verifiche umane sono comprese; quali dati devono essere forniti dal cliente; quando è possibile chiedere un riesame o contestare l’esito; quali sono le condotte per cui il solo cliente è responsabile; ove possibile, prevedere limitazioni di responsabilità e dell’importo risarcibile.
Ad esempio, una clausola che neghi in astratto ogni affidamento sull’output rischia di essere contraddittoria e quindi impugnabile se il servizio venduto è proprio quello di produrre un risultato destinato a orientare decisioni. La chiarezza verso il cliente non è soltanto tema di correttezza informativa, bensì il presupposto per delimitare il perimetro della responsabilità.
La responsabilità civile del deployer oltre la compliance
Alla luce di quanto indicato, nell’economia reale dell’AI il deployer è spesso il ruolo più ricorrente e, insieme, il più esposto. Non perché responsabile di ogni difetto del sistema, ma perché è il soggetto che usa la tecnologia nel contesto concreto, promette una prestazione al cliente e deve dimostrare di aver governato l’errore, i limiti e il rischio.
L’AI Act gli assegna obblighi propri quando il sistema è ad alto rischio o quando ricorrono specifici doveri di trasparenza, ma la responsabilità civile va oltre il rispetto della compliance normativa e permane anche per i casi non disciplinati dall’AI Act.
Il contratto con il provider e il contratto con il cliente diventano allora il luogo primario di allocazione del rischio, di definizione delle condotte esigibili e di costruzione della prova, che consentono al deployer di ridurre sensibilmente il rischio di danni reputazionali e di pretese risarcitorie da parte dei clienti.
Partecipa alla community