Un software di intelligenza artificiale sbaglia una previsione, e il cliente che su quella previsione aveva deciso qualcosa chiede i danni. A chi li chiede: a chi ha costruito il software, o all’azienda che glielo ha venduto? La risposta, il più delle volte, non sta nell’AI Act. Sta nel contratto firmato mesi prima, quando agli errori non pensava nessuno.
È il punto meno raccontato del regolamento europeo. Scadenze e adempimenti li abbiamo ricostruiti nella panoramica su cosa cambia per le aziende; qui si guarda cosa succede quando qualcosa va storto.
Costruisci l’AI o la usi soltanto?
La prima cosa che il regolamento chiede è capire in quale delle due caselle ci si trova. Sei un provider, il fornitore, se il sistema lo sviluppi tu, se lo metti sul mercato col tuo marchio o se lo modifichi in modo sostanziale. Sei un deployer, l’utilizzatore professionale, se usi sotto la tua responsabilità un sistema costruito da altri. L’avvocato Alessandro Vercellotti, su Agendadigitale, riassume la differenza in una riga: al primo si chiede conto della costruzione del sistema, al secondo dell’uso che ne fa. Non c’è zona franca per l’impiego interno: anche chi adopera l’AI soltanto fra le proprie mura rientra nella seconda casella.
Qui si innesta un conto che nessuna fonte fa per intero. Quasi nessuna impresa costruisce da sé i propri modelli: si appoggia a ChatGPT Enterprise, Microsoft Copilot, Google Gemini, Claude o a piattaforme che hanno l’AI già dentro. Ne segue che la stragrande maggioranza delle aziende italiane sta nel ruolo di deployer: quello a cui il regolamento dedica meno righe e che resta più esposto quando arriva la richiesta di risarcimento.
Essere in regola non vuol dire essere al riparo
C’è un equivoco che gli avvocati vedono ripetersi: rispetto gli obblighi dell’AI Act, quindi se il sistema sbaglia non ne rispondo. Non funziona così.
Gli obblighi del regolamento sono pubblici: a farli rispettare è l’autorità di vigilanza, e chi viola le regole sui sistemi ad alto rischio o sulla trasparenza rischia una multa che nel massimo tocca i 15 milioni, oppure il 3 per cento del giro d’affari mondiale annuo. La responsabilità civile è altro: è il dovere di risarcire chi ha subito un danno, e a chiedertela non è l’autorità ma il cliente. Le due partite non si annullano a vicenda: si può essere in regola e dover comunque risarcire, perché la prestazione promessa non è quella che il cliente ha ricevuto.
Luca Marasco, avvocato dello studio Eptalex, ha descritto su Agendadigitale la sproporzione che ne deriva. Il deployer non risponde di ogni difetto del sistema, ma è chi quella tecnologia la usa in un contesto reale, promette un risultato e, se le cose vanno male, deve dimostrare di aver governato l’errore. Ed è quasi sempre lui la prima controparte del cliente: quello a cui si telefona quando il risultato non torna.
La zona grigia dove la norma non arriva
Il regolamento copre bene due situazioni: i sistemi ad alto rischio, che incidono su decisioni importanti per le persone (selezione del personale, credito, assicurazioni, sanità, giustizia, servizi pubblici), e quelli con specifici obblighi di trasparenza, come i deepfake o i testi che, generati dall’AI, finiscono pubblicati per informare i cittadini su temi di rilievo collettivo.
Poi c’è tutto il resto: un sistema che non è ad alto rischio e non produce contenuti da dichiarare. Su cosa succede se sbaglia, l’AI Act tace. Rientra qui anche il caso più insidioso, un sistema pure regolato che nell’uso concreto tocca aspetti non disciplinati. La responsabilità non sparisce: si sposta dal regolamento al contratto e al diritto civile ordinario.
Il contratto non serve a scaricare la colpa
Nella prassi ricorre una clausola che dichiara il sistema conforme all’AI Act, come se bastasse. Marasco la definisce tecnicamente superflua: gli obblighi che il regolamento mette in capo al deployer sono inderogabili, nessun accordo privato può spostarli sul fornitore. Se la legge impone la sorveglianza umana, non la si appalta via contratto. Quello che il contratto può fare, secondo la sua analisi, sono tre cose diverse.
- Rendere concreti obblighi scritti in modo elastico. Formule come uso conforme o adeguatezza degli input non dicono granché finché non diventano parametri misurabili: limiti d’uso, qualità minima dei dati in ingresso, tempi di reazione alle anomalie.
- Stabilire chi controlla cosa. Un errore può nascere dalla progettazione, dalle istruzioni del fornitore, dalla configurazione scelta dal deployer, dai dati caricati o da una verifica umana saltata. Senza questa mappa, chi ha venduto il servizio rischia di rispondere da solo di tutto.
- Costruire la prova. Davanti a un giudice pesano i log, le verifiche umane effettuate, gli aggiornamenti installati e quale release del sistema fosse in funzione quel giorno. Potervi accedere, conservarli ed esportarli, osserva Marasco, non è un dettaglio tecnico ma una condizione di difesa.
Il problema: quel contratto spesso non si negozia
Qui però l’analisi incontra un ostacolo che nessuna fonte nasconde: quel contratto, nella pratica, lo scrive chi vende, e non è negoziabile. Un’azienda media che attiva un abbonamento non discute le clausole: accetta o rinuncia.
Gli avvocati Vincenzo Gallotto e Francesco Ziliotto, studiando la catena di fornitura, arrivano allo stesso punto per altra via: quel documento è ormai un presidio di governance della filiera, non un semplice atto d’acquisto. Se negoziarlo non si può, resta un solo margine reale: la due diligence, cioè verificare prima cosa contiene e cosa lascia scoperto. Livelli di servizio, comunicazione degli aggiornamenti, cooperazione sugli incidenti, accesso ai log, tetti al risarcimento, portabilità dei dati, condizioni di uscita.
E il contratto con il cliente?
A valle l’equilibrio si rovescia: non si tratta di proteggersi da un fornitore più grande, ma di descrivere onestamente cosa si vende. Dichiarare genericamente che “usiamo l’AI”, nota Marasco, non basta: conta dire di che natura sia l’esito prodotto: una previsione? una raccomandazione? un semplice appoggio a chi poi decide? E negare in astratto ogni affidamento su quell’esito rischia di risultare contraddittorio proprio là dove ciò che si vende è, appunto, un output su cui il cliente baserà le proprie scelte.
Perché la partita si è spostata sui fornitori
Le linee guida della Commissione europea, nella ricostruzione di Federica Maria Rita Livelli su Agendadigitale, tracciano il perimetro dell’alto rischio più largo di quanto il mercato si aspettasse: soluzioni date per escluse potrebbero rientrarvi. E poiché quasi tutta l’AI aziendale arriva da terze parti, è lì che il rischio si addensa.
Resta la sproporzione iniziale. Chi l’AI la usa senza averla costruita negozia da posizione più debole con chi gliela fornisce, e risponde per primo davanti al cliente finale. Su questa asimmetria il regolamento non interviene: la lascia dove l’ha trovata, sul tavolo dove si firmano i contratti.
Lascia un commento