Responsabilità dell’IA: chi risponde e come dimostrarlo

In sintesi

• La responsabilità dell’IA non è una qualità morale dell’impresa. Nel regolamento europeo è una posizione giuridica assegnata a un ruolo nominato, con una propria riga nell’articolo sulle sanzioni.
• Il regolamento non attribuisce mai la responsabilità dell’IA a un sistema. Individua cinque ruoli umani: fornitore, deployer, importatore, distributore e rappresentante autorizzato.
• L’articolo 25 può trasferirvi la responsabilità dell’IA senza alcun nuovo contratto. Apponete il vostro marchio, modificate sostanzialmente il sistema o cambiatene la finalità, e ne diventate il fornitore.
• Una responsabilità dell’IA che non si può documentare su richiesta resta un’intenzione. A ogni obbligo corrisponde un artefatto: documentazione tecnica, registri, designazione della sorveglianza, dichiarazione di conformità.
• L’articolo 99 tariffa l’inadempimento ruolo per ruolo, fino a 15 milioni di euro o al 3 per cento del fatturato mondiale, e il risarcimento del danno passa ormai dalla direttiva riveduta sulla responsabilità da prodotto.

Che cosa significa davvero responsabilità dell’IA

La maggior parte delle definizioni di responsabilità dell’IA si ferma a un sentimento: qualcuno dovrebbe rispondere quando un sistema di IA provoca un danno. È vero e privo di utilità pratica. Non fornisce alcun criterio per individuare quel qualcuno, nessuno per stabilire che cosa deve, nessuno per verificare che lo abbia fatto.

Il quaderno di lavoro dell’Alan Turing Institute dedicato al tema propone la scomposizione più netta disponibile. Distingue due componenti della responsabilità dell’IA: la capacità di rendere conto, cioè l’obbligo di fornire alle persone interessate giustificazioni chiare e accessibili delle decisioni e dei loro effetti, e la verificabilità, cioè la capacità dimostrabile e fondata su prove di mostrare come un sistema sia stato progettato, costruito e gestito (Alan Turing Institute). La prima riguarda ciò che dite. La seconda, ciò che potete esibire. Un’organizzazione che padroneggia la prima ma non la seconda sta facendo comunicazione.

Lo stesso quaderno aggiunge un secondo asse, di norma assente nei contenuti dei fornitori di software. La responsabilità dell’IA si dispiega in due direzioni temporali. La responsabilità anticipatoria comprende la governance, la giustificazione e la documentazione condotte prima e durante il progetto, affinché il danno non si produca. La responsabilità riparatoria raccoglie i meccanismi di ricorso, contestazione e correzione attivati dopo che l’esito si è verificato. Quasi tutti gli articoli sulla domanda su chi risponda quando l’IA sbaglia trattano solo la seconda metà, quella a cui ci si rivolge quando è ormai troppo tardi perché costi poco.

Questa distinzione cambia ciò che la responsabilità dell’IA significa un lunedì mattina. Smette di essere una dichiarazione di valori in una policy e diventa due domande concrete. Chi risponde di questo specifico sistema, per nome? E quali prove consegneremmo domani a un’autorità che ci chiedesse di dimostrarlo? La governance dell’IA è il modello operativo che rende risolvibili entrambe.

Una precisazione prima del dettaglio giuridico, dato che i risultati di ricerca ne sono pieni. La responsabilità dell’IA non coincide con la trasparenza né con la spiegabilità. Queste sono strumenti: la spiegabilità aiuta a rispondere, la registrazione aiuta a dimostrare. La responsabilità dell’IA è la relazione stessa, quella per cui una parte nominata deve rendere conto di una decisione a chi ha titolo per chiederlo.

I cinque ruoli che il regolamento rende responsabili

Quando ci si chiede se un’IA possa essere chiamata a rispondere, si pone una domanda che il diritto ha già respinto. Il regolamento europeo non attribuisce obblighi ai sistemi. Li attribuisce agli operatori, e ne nomina cinque.

Ruolo	Criterio di qualificazione	Obbligo centrale	Articolo
Fornitore	Sviluppa un sistema, o lo fa sviluppare, e lo immette sul mercato o in servizio con il proprio nome o marchio	L’intero impianto ad alto rischio: gestione dei rischi, governance dei dati, documentazione tecnica, valutazione della conformità, registrazione	Articolo 16
Deployer	Utilizza un sistema sotto la propria autorità in ambito professionale	Rispettare le istruzioni, designare la sorveglianza umana, monitorare e sospendere, conservare i registri, informare lavoratori e persone interessate	Articolo 26
Importatore	Immette sul mercato dell’Unione un sistema di un fornitore stabilito fuori dall’Unione	Verificare valutazione della conformità, documentazione e marcatura prima dell’immissione	Articolo 23
Distributore	Mette a disposizione sul mercato un sistema, senza essere fornitore né importatore	Verificare marcatura e documentazione, agire in caso di sospetta non conformità	Articolo 24
Rappresentante autorizzato	Nominato per iscritto da un fornitore di paese terzo	Verificare l’esistenza di dichiarazione e documentazione, conservarle 10 anni, dare accesso ai registri, risolvere il mandato in caso di violazione	Articolo 22

Il termine generale con cui il regolamento li designa tutti è operatore. La maggior parte delle organizzazioni che leggono queste righe sono deployer, e quasi nessuna lo ha mai messo per iscritto. Se la vostra azienda usa lo strumento di un fornitore in ambito professionale, siete il deployer di quel sistema, e gli obblighi dell’articolo 26 ricadono su di voi qualunque cosa dica il materiale commerciale del fornitore in tema di conformità. La nostra guida operativa al regolamento europeo sull’IA elenca l’insieme degli obblighi per ciascun ruolo.

Il rappresentante autorizzato merita una sosta, perché è il ruolo dotato di poteri reali. Un fornitore stabilito fuori dall’Unione deve nominarlo con mandato scritto prima di immettere sul mercato un sistema ad alto rischio. Tale rappresentante verifica che la dichiarazione di conformità UE e la documentazione tecnica siano state redatte e che la valutazione della conformità sia stata svolta, tiene la documentazione a disposizione delle autorità per dieci anni e fornisce alle autorità competenti le informazioni utili, compreso l’accesso ai registri generati automaticamente. E se giunge a ritenere che il fornitore agisca in contrasto con i propri obblighi, deve risolvere il mandato e comunicarne le ragioni all’autorità di vigilanza del mercato (articolo 22). Il legislatore ha inserito un segnalatore dentro la catena di conformità.

Articolo 25: come la responsabilità dell’IA cambia mano senza preavviso

È il meccanismo di responsabilità dell’IA che più facilmente costa caro a un deployer, ed è quasi del tutto assente dai commenti pubblicati.

Potete diventare fornitori di un sistema ad alto rischio senza firmare nulla di nuovo. L’articolo 25, paragrafo 1, prevede tre inneschi (articolo 25):

1. Apponete il vostro nome o marchio su un sistema ad alto rischio già immesso sul mercato, salvo diversa ripartizione contrattuale degli obblighi.
2. Apportate una modifica sostanziale a un sistema ad alto rischio che ne incide sulla conformità o ne cambia la finalità prevista, e il sistema resta o diventa ad alto rischio.
3. Modificate la finalità prevista di un sistema, compreso un sistema di IA per finalità generali non inizialmente classificato ad alto rischio, in modo che lo diventi ai sensi dell’articolo 6.

Il terzo innesco è quello contemporaneo. Prendete un modello per finalità generali, affinatelo sui vostri dati e orientatelo alla selezione delle candidature o alla concessione di credito. Non avete acquistato un sistema ad alto rischio: ne avete fabbricato uno, e ne siete ora il fornitore, con l’intero impianto dell’articolo 16, valutazione della conformità inclusa.

Ciò che accade al fornitore originario è altrettanto poco riportato. Ai sensi dell’articolo 25, paragrafo 2, il fornitore iniziale cessa di essere considerato il fornitore di quel sistema. Non è però liberato all’istante: deve cooperare strettamente con il nuovo fornitore e trasmettere la documentazione tecnica, i limiti e le modalità di guasto noti e l’accesso tecnico mirato necessario alla conformità. Una riserva merita comunque di comparire in ogni trattativa di acquisto. Questo dovere di cooperazione viene meno se il fornitore iniziale ha espressamente escluso che il proprio sistema possa essere trasformato in un sistema ad alto rischio. Un fornitore può sottrarsi contrattualmente all’obbligo di aiutarvi, e molti lo faranno.

L’articolo 25, paragrafo 4, chiude il cerchio imponendo a fornitori e terzi fornitori di componenti di precisare per accordo scritto le informazioni, l’accesso tecnico e l’assistenza necessari alla conformità. I componenti liberi e open source ne sono esclusi, e l’Ufficio per l’IA può pubblicare clausole contrattuali tipo volontarie. Se assemblate sistemi a partire da componenti, quell’accordo scritto è il vostro strumento di responsabilità dell’IA, e il suo posto è nella due diligence sui fornitori, non nella revisione legale tre giorni prima del rilascio.

Che cosa deve produrre ciascun ruolo

Una responsabilità dell’IA che non potete documentare è un’affermazione, non una posizione. Il regolamento è insolitamente preciso sugli artefatti, ed è qui che la responsabilità dell’IA diventa operativa anziché declamatoria.

• La documentazione tecnica redatta prima dell’immissione sul mercato e tenuta aggiornata, secondo l’allegato IV. È il fascicolo madre che attesta scelte progettuali, governance dei dati e test. Si veda la nostra analisi dei requisiti di documentazione.
• I registri generati automaticamente, previsti fin dalla progettazione ai sensi dell’articolo 12 affinché gli eventi siano tracciati lungo la vita del sistema, e conservati dal deployer ai sensi dell’articolo 26, paragrafo 6, per un periodo adeguato alla finalità e comunque non inferiore a sei mesi, salvo diversa disposizione del diritto dell’Unione o nazionale.
• Una designazione documentata della sorveglianza umana, che nomini le persone fisiche che la esercitano, ai sensi dell’articolo 26, paragrafo 2.
• La dichiarazione di conformità UE prevista dall’articolo 47, firmata dal fornitore: il momento in cui la responsabilità dell’IA viene formalmente assunta per iscritto.
• Il monitoraggio successivo all’immissione sul mercato previsto dall’articolo 72 e la segnalazione degli incidenti gravi al fornitore e all’autorità di vigilanza del mercato ai sensi dell’articolo 73. La nostra guida alla segnalazione degli incidenti precisa tempi e soglie.

Letti come insieme, questi artefatti costituiscono il versante verificabilità della definizione dell’Alan Turing Institute, tradotto in obblighi giuridici. Ciascuno risponde a una domanda che un’autorità può porre: che cosa avete costruito, che cosa ha fatto, chi sorvegliava, chi ha firmato, e che cosa avete fatto quando è andata storta.

La responsabilità dell’IA ha un listino

La prova più netta che la responsabilità dell’IA sia un ruolo e non una virtù è che il regolamento la tariffa ruolo per ruolo.

L’articolo 99, paragrafo 4, fissa sanzioni amministrative fino a 15 000 000 di euro o al 3 per cento del fatturato mondiale totale annuo, se superiore, e poi ne elenca i destinatari: i fornitori ai sensi dell’articolo 16, i rappresentanti autorizzati ai sensi dell’articolo 22, gli importatori ai sensi dell’articolo 23, i distributori ai sensi dell’articolo 24, i fornitori e gli operatori ai sensi dell’articolo 25, paragrafi 2 e 4, i deployer ai sensi dell’articolo 26, gli organismi notificati, nonché fornitori e deployer soggetti agli obblighi di trasparenza dell’articolo 50 (articolo 99). Le pratiche vietate dell’articolo 5 stanno più in alto, fino a 35 000 000 di euro o al 7 per cento. Fornire informazioni inesatte, incomplete o fuorvianti a un organismo notificato o a un’autorità nazionale competente espone fino a 7 500 000 euro o all’1 per cento.

Su quest’ultimo scaglione vale la pena fermarsi: il conto che rendete è esso stesso regolato. Sbagliare deliberatamente la risposta costituisce un illecito autonomo.

L’azione pubblica copre solo metà del terreno. Il risarcimento segue una via separata, che di recente si è spostata. La proposta di direttiva sulla responsabilità in materia di IA è stata ritirata dalla Commissione nel febbraio 2025: le domande delle persone lese passano quindi ora per la direttiva riveduta (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, che tratta software e sistemi di IA come prodotti, applica una responsabilità oggettiva che esonera l’attore dal provare la colpa, amplia la platea degli operatori economici responsabili e introduce presunzioni probatorie a favore del danneggiato. Gli Stati membri devono recepirla entro il 9 dicembre 2026 (EUR-Lex). Due regimi, due attori diversi, un solo complesso di fatti.

Nominare le persone: competenza, formazione e autorità

L’articolo 26, paragrafo 2, contiene tre parole che mandano silenziosamente in crisi la maggior parte dei dispositivi di sorveglianza. I deployer devono affidare la sorveglianza umana a persone fisiche dotate della competenza, della formazione e dell’autorità necessarie, oltre che del sostegno occorrente (articolo 26).

Competenza e formazione si acquistano. L’autorità no. Significa che la persona designata può effettivamente fermare il sistema. L’articolo 26, paragrafo 5, lo rende tangibile: quando il deployer ha motivo di ritenere che l’uso presenti un rischio, deve sospendere l’uso del sistema e informarne il fornitore. Un incarico di sorveglianza affidato a chi non può interrompere un servizio in produzione senza tre approvazioni non soddisfa questo requisito, qualunque cosa dica la matrice delle responsabilità. La differenza tra sorveglianza umana nel ciclo e sul ciclo è esattamente quella tra detenere l’autorità e limitarsi a osservare.

Due altri riferimenti convergono qui, il che rende poco costosa la corrispondenza se siete già certificati. Il punto 5.3 della norma ISO/IEC 42001 impone all’alta direzione di assegnare, comunicare e autorizzare i ruoli del sistema di gestione dell’IA, producendo linee documentate di responsabilità dell’IA e abilitando le persone designate a verificare la conformità e a riferire alla direzione sulle prestazioni. Gli auditor leggono quel punto come una richiesta di titolari nominati lungo tutto il ciclo di vita, non di un comitato. La nostra analisi dell’incastro tra ISO 42001 e regolamento europeo mostra dove punto e articolo si incontrano. Sul versante statunitense, la funzione GOVERN del quadro NIST per la gestione del rischio dell’IA richiede strutture di responsabilità affinché i team e le persone competenti siano abilitati, responsabilizzati e formati (NIST AI 100-1).

Dove la responsabilità dell’IA si rompe nella pratica

Quattro modalità di guasto spiegano quasi tutte le rotture di responsabilità dell’IA.

Nessun ruolo, per assenza di inventario. Non si può assegnare la responsabilità dell’IA per un sistema di cui si ignora l’esistenza. La shadow AI è un fallimento di responsabilità prima che una falla di sicurezza: uno strumento non censito non ha né fornitore individuato, né deployer individuato, né sorvegliante nominato.

Il problema delle molte mani nelle catene agentiche. Un flusso che attraversa un modello di base, uno strato di orchestrazione, un archivio vettoriale e tre fornitori diluisce il contributo causale al punto che nessuno si sente tenuto a rispondere. La risposta del regolamento è l’accordo scritto dell’articolo 25, paragrafo 4, che obbliga a mettere per iscritto la ripartizione prima che serva, anziché contenderla dopo.

Il mito del contratto. Le pattuizioni commerciali tra fornitore e deployer ripartiscono il rischio tra quelle due parti. Non spostano gli obblighi di legge che ciascuno deve alle autorità e alle persone interessate. Un deployer che si è fatto manlevare ha cambiato chi paga, non chi risponde.

Il mito del rinvio. Il regolamento omnibus digitale sull’IA, regolamento (UE) 2026/1744, è entrato in vigore il 27 luglio 2026 e ha spostato al 2 dicembre 2027 gli obblighi per i sistemi ad alto rischio dell’allegato III e al 2 agosto 2028 quelli dell’allegato I. Non ha sospeso tutto. Le pratiche vietate si applicano dal 2 febbraio 2025 e gli obblighi di trasparenza dell’articolo 50 restano invariati. Leggete lo slittamento come tempo per costruire bene la mappatura, non come una dispensa. La nostra lettura del panorama normativo ricostruisce che cosa si è mosso e che cosa no.

Costruire la mappa della responsabilità dell’IA in questo trimestre

Sette passi per mappare la responsabilità dell’IA, in quest’ordine.

1. Censite ogni sistema di IA in uso, compresi quelli acquistati con carta aziendale e quelli incorporati in software che già possedete.
2. Qualificate ciascuno rispetto all’allegato III e all’articolo 6 per stabilire se scattano gli obblighi ad alto rischio.
3. Assegnate il vostro ruolo sistema per sistema, non a livello di organizzazione. Sarete deployer della maggior parte e fornitori di qualcuno.
4. Nominate la persona fisica che esercita la sorveglianza su ciascun sistema ad alto rischio e confermate per iscritto che detiene il potere di sospensione previsto dall’articolo 26, paragrafo 5.
5. Elencate l’artefatto che assolve ciascun obbligo e dove è conservato: documentazione, registri e periodo di conservazione, dichiarazione di conformità, procedura di incidente.
6. Confrontate la vostra tabella di marcia con gli inneschi dell’articolo 25. Ogni progetto di marchio proprio, affinamento o riconversione entra in una lista di sorveglianza prima dell’avvio degli sviluppi.
7. Fissate una cadenza di riesame e un titolare per la mappa stessa, perché i ruoli cambiano appena un sistema viene modificato.

I passi da 1 a 3 sono quelli che le organizzazioni saltano, e ogni passo successivo dipende da essi. Un audit dell’IA avviato senza di essi passa la prima settimana a ricostruire l’inventario.

Domande frequenti

Un’IA può essere giuridicamente chiamata a rispondere?

No. Nessun ordinamento riconosce personalità giuridica ai sistemi di IA, e il regolamento europeo non ci prova. Attribuisce gli obblighi a operatori, persone fisiche o giuridiche: fornitori, deployer, importatori, distributori e rappresentanti autorizzati. Quando il dibattito chiede se l’IA possa rispondere, la traduzione operativa è individuare quale ruolo di operatore occupate per un dato sistema e che cosa quel ruolo deve ai sensi del suo articolo. Il sistema è oggetto dell’obbligo, mai il suo titolare passivo.

Perché la responsabilità dell’IA è un problema?

Perché il contributo causale è distribuito e le tracce sono effimere. Un singolo esito può riflettere dati di addestramento scelti da una parte, un affinamento da una seconda, un’istruzione di orchestrazione da una terza e una decisione di adozione da una quarta. Aggiungete sistemi probabilistici che cambiano a ogni riaddestramento e la ordinaria catena probatoria si spezza. La risposta normativa consiste nell’ancorare la responsabilità dell’IA a ruoli e nell’imporre artefatti durevoli, registri e documentazione, perché il rendiconto sopravviva alla dispersione.

Che differenza c’è tra responsabilità dell’IA e IA responsabile?

L’IA responsabile indica un approccio: progettare e gestire sistemi con cura, equità e prudenza. La responsabilità dell’IA è relazionale e retrospettiva: una parte nominata deve rendere conto di una decisione a chi ha titolo per esigerlo, e ne sopporta le conseguenze se il rendiconto manca. Si può agire con cura senza dover conto a nessuno in particolare. Nel regolamento europeo prevale la seconda nozione, perché arriva con un interlocutore definito, un artefatto definito e una sanzione definita.

Un contratto con il nostro fornitore trasferisce la responsabilità dell’IA?

Non verso le autorità. Un contratto ripartisce il rischio commerciale tra le parti e può rilevare ai sensi dell’articolo 25, paragrafo 1, lettera a), dove la qualificazione tramite marchio opera salvo diversa pattuizione contrattuale. Ma gli obblighi di legge dovuti alle autorità di vigilanza del mercato e alle persone interessate non sono cedibili per accordo privato. Se siete il deployer, l’articolo 26 si applica a voi qualunque cosa dica il contratto di servizi sul fatto che la conformità spetti al fornitore.

Che cosa deve contenere un dispositivo di responsabilità dell’IA?

Come minimo: un inventario dei sistemi, una qualificazione del ruolo per ciascun sistema, una classificazione del rischio, un sorvegliante nominato con potere di sospensione, una mappa delle prove che colleghi ogni obbligo al suo artefatto e al suo periodo di conservazione, un percorso di incidente e ricorso, e un innesco di revisione che riqualifichi i ruoli appena un sistema viene modificato. I dispositivi che si fermano ai principi falliscono sul versante verificabilità, perché un principio non si esibisce su richiesta.

Chi risponde quando un modello per finalità generali provoca un danno a valle?

La responsabilità dell’IA dipende qui da che cosa ne avete fatto. Il fornitore del modello assume gli obblighi propri dei modelli per finalità generali. Se lo avete affinato o riconvertito al punto che il sistema risultante diventa ad alto rischio ai sensi dell’articolo 6, l’articolo 25, paragrafo 1, lettera c), fa di voi il fornitore di quel sistema, con l’intero impianto dell’articolo 16. Se lo avete adottato tal quale per la sua finalità originaria, gravano su di voi gli obblighi di deployer dell’articolo 26. La domanda riguarda sempre l’atto che avete compiuto, mai il logo apposto sul modello.

Conclusione

Il materiale pubblicato sulla responsabilità dell’IA abbonda di principi, e i principi non sono la parte difficile. La parte difficile è che, nel diritto europeo, la responsabilità è una posizione che si occupa, talvolta senza volerlo, e che ogni posizione porta con sé un numero di articolo, un artefatto e una sanzione. Cominciate dall’inventario, assegnate il ruolo sistema per sistema, nominate la persona che può spegnere tutto, e archiviate le prove dove potrete produrle in un giorno. In questo consiste la responsabilità dell’IA nella pratica. Il resto è commento. Per il modello operativo che racchiude tutto questo, partite dalla governance dell’IA.