Immaginiamo un’impresa che affida a un programma di intelligenza artificiale il compito di leggere le fatture, confrontarle con gli ordini e preparare i pagamenti, e che, per le operazioni sotto una certa cifra lo autorizzi a procedere senza chiedere ogni volta il consenso di un dipendente. Un giorno il programma paga una fattura che avrebbe dovuto invece fermare: il denaro è uscito dal conto, e qualcuno deve ora spiegare come sia potuto accadere e, soprattutto, chi debba rispondere del danno. Il programma di questo esempio si chiama agente di intelligenza artificiale, ed è la ragione per cui la domanda, per molti, è nuova. Un assistente tradizionale, come quello che scrive la bozza di un’email, si ferma sulla soglia: il messaggio parte soltanto se siamo noi a inviarlo. Un agente è invece un sistema capace di svolgere una sequenza di operazioni per raggiungere un obiettivo, scegliendo alcuni passaggi entro i limiti che gli sono stati assegnati: se è collegato alla posta e gli abbiamo dato il permesso, spedisce il messaggio da solo; può inoltre cercare documenti, aggiornare un archivio o interagire con il programma di contabilità. La sua autonomia dipende quindi anche dalle porte che gli apriamo.[1]

Il problema che questo articolo vuole chiarire è semplice da enunciare: quando un agente di questo tipo sbaglia e provoca un danno, chi ne risponde davanti alla legge, e che cosa serve per dimostrarlo? Non si tratta di stabilire la «colpa» della macchina, perché un programma non è un soggetto giuridico, non può essere citato in giudizio né condannato a risarcire, e la responsabilità ricade perciò sulle persone e sulle organizzazioni che lo hanno realizzato, adattato e messo al lavoro. La difficoltà è un’altra, e si presenta in tre forme. La prima è che tra il programma e il danno si trovano più soggetti, cioè chi lo produce, chi lo adatta all’impresa e chi lo usa, e ciascuno può avere pesato in modo diverso. La seconda è che, per attribuire una responsabilità, occorre ricostruire che cosa sia realmente accaduto dentro un sistema che sceglie da sé alcuni passaggi: senza tracce, ogni versione resta la parola di uno contro quella dell’altro. La terza è che le regole europee e italiane su questa materia sono state scritte o riscritte da poco, con date di applicazione diverse, ed è facile confonderle.

La risposta in breve è che non risponde «l’intelligenza artificiale», ma rispondono, in misura che dipende dai fatti, i soggetti che stanno lungo la catena, e che il modo per stabilire quali e quanto passa dalle tracce lasciate dal programma e dalle regole che vedremo. Nelle pagine che seguono userò sempre il caso della fattura per affrontare tre domande: di chi sia la responsabilità, come si ricostruisca ciò che è accaduto e se un programma possa essere considerato un prodotto difettoso; chiarirò poi da quando le norme si applicano e che cosa conviene chiedere prima di affidare a un agente un compito che conta.

Prima domanda: di chi è la responsabilità?

Davanti al pagamento sbagliato, dire che «ha fatto tutto l’intelligenza artificiale» non risolve, ovviamente, nulla: bisogna ricostruire le scelte compiute dalle persone e dalle organizzazioni coinvolte, che sono almeno tre. Il fornitore potrebbe avere consegnato un prodotto difettoso; chi lo ha adattato all’impresa potrebbe avere impostato male i controlli; chi lo utilizza potrebbe avergli assegnato un compito inadatto, oppure ignorato un avvertimento. Si tratta di possibilità da verificare, non di colpe da distribuire in anticipo, e il fatto che il programma abbia eseguito l’ultima operazione non basta a stabilire quale soggetto debba risarcire il danno: chi preme l’ultimo tasto non è necessariamente chi ha sbagliato. Il principio da tenere fermo è che la responsabilità ha bisogno di due ingredienti: un fondamento giuridico, cioè una regola che metta quel danno a carico di quel soggetto, e un collegamento tra la sua condotta e il danno. Conservare le prove serve ad accertare l’uno e l’altro, ma non equivale a escluderli: un’impresa può avere registrato ogni passaggio e risultare ugualmente responsabile, perché proprio quelle registrazioni mostrano un errore di progettazione o un controllo omesso, mentre la mancanza di documenti può rendere molto più difficile difendersi. Chi pensasse che basti un buon archivio per mettersi al riparo da una richiesta di risarcimento giungerebbe quindi alla conclusione sbagliata.[2]

Seconda domanda: come si ricostruisce che cosa è accaduto?

Nelle telecomunicazioni, dove ho costruito operatori negli anni della liberalizzazione, il valore delle tracce mi è familiare: per verificare una fatturazione o esaminare una contestazione bisogna poter ricostruire il servizio effettivamente erogato, e la memoria del sistema, utile al lavoro di ogni giorno, diventa una prova nel momento in cui nasce una controversia. Per gli agenti IA vedo un’esigenza analoga: se un programma può compiere azioni che producono conseguenze, chi lo mette al lavoro deve organizzarsi per sapere quali azioni abbia compiuto davvero. Nel nostro esempio servirebbe sapere quale fattura sia stata letta, quali dati siano stati confrontati e quale istruzione abbia consentito il pagamento; occorrerebbe poi conoscere i permessi assegnati al programma e verificare se un dipendente abbia approvato l’operazione. Queste tracce si chiamano spesso «log», cioè registrazioni informatiche degli eventi, un po’ come il giornale di bordo di una nave. Non offrono, da sole, una spiegazione completa del funzionamento interno dell’intelligenza artificiale; aiutano però a ricostruire la successione delle operazioni, a individuare dove sia nato l’errore e a capire quali controlli abbiano funzionato.

Su questo punto il decreto legislativo italiano n. 160 del 2026 dà un rilievo particolare all’accesso alle prove. L’articolo 17 consente al giudice, alle condizioni previste, di ordinare alla controparte o a un terzo di esibire i documenti pertinenti: se una parte non collabora senza giustificazione, ne possono derivare conseguenze probatorie sfavorevoli, e per alcuni documenti indicati dalla norma il giudice, valutate le altre prove, considera riconosciuti i fatti esposti da chi li richiede. I segreti commerciali sono tutelati, ma non impediscono ogni forma di accesso.[3]

Il decreto prevede inoltre che, quando il danno deriva dalla violazione degli obblighi dell’AI Act (il regolamento europeo sull’intelligenza artificiale, di cui dirò più avanti), si presuma il collegamento tra violazione e danno, salvo prova contraria: in altre parole, il giudice parte dall’idea che la violazione abbia causato il danno, e spetta a chi viene chiamato a rispondere dimostrare il contrario. Il decreto precisa anche che rispettare l’AI Act non basta, da solo, a escludere la responsabilità, ed è quindi necessario distinguere la conformità alle regole dal comportamento concretamente tenuto nel singolo caso.[3]

Terza domanda: un programma che non funziona, può essere considerato prodotto difettoso?

La direttiva europea sui prodotti difettosi, la n. 2024/2853, risponde di sì in modo espresso, perché include il software anche quando viene utilizzato attraverso Internet. Se il programma non offre la sicurezza che legittimamente ci si può attendere, può entrare in gioco la responsabilità per prodotto difettoso, che non richiede di dimostrare una colpa del produttore. Un risultato sbagliato non coincide però automaticamente con un difetto: occorre valutare il prodotto, il danno e il collegamento tra i due; la direttiva agevola la prova in determinate circostanze e permette di contestare le presunzioni.[2] C’è però un limite decisivo per gli esempi aziendali, come quello della fattura. La direttiva tutela le persone fisiche e determinate categorie di danno; esclude i beni usati esclusivamente per fini professionali e i dati utilizzati professionalmente, e la semplice perdita economica non è coperta in modo autonomo. Un archivio aziendale cancellato o un pagamento sbagliato possono dunque richiedere il ricorso alle altre regole sulla responsabilità, comprese quelle che nascono dal contratto con il fornitore.[2, 4] Merita attenzione anche la posizione di chi modifica il software. La direttiva può considerare fabbricante, cioè responsabile come se avesse prodotto il programma, chi lo modifica in modo sostanziale fuori dal controllo del produttore e poi lo mette in servizio o lo rende disponibile sul mercato; collegare il programma ai propri dati non basta, da solo, a produrre questo effetto. Quando poi il prodotto può continuare ad apprendere dopo la vendita, questa capacità conta nella valutazione della sua sicurezza, ma non rende automaticamente il fabbricante responsabile di qualsiasi comportamento successivo.[2]

Da quando valgono queste regole

Le date vanno tenute distinte, perché riguardano strumenti diversi. La direttiva deve essere recepita dagli Stati membri, cioè tradotta in leggi nazionali, entro il 9 dicembre 2026, e una rettifica europea precisa che il suo ambito riguarda i prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre 2026. In Italia il decreto di recepimento ha ricevuto l’approvazione definitiva del Consiglio dei ministri il 28 ottobre: il via libera del Governo va però distinto dalla pubblicazione e dall’entrata in vigore, che sono passaggi successivi. Il decreto n. 160, invece, è già in vigore dal 30 settembre 2026.[3, 5, 6] L’AI Act è il regolamento europeo che stabilisce obblighi per chi fornisce e per chi utilizza sistemi di intelligenza artificiale. Per una parte dei sistemi classificati ad alto rischio, ossia impiegati in ambiti nei quali gli errori possono incidere seriamente sulle persone, l’applicazione degli obblighi è stata rinviata: il nuovo calendario indica il 2 dicembre 2027 per quelli dell’allegato III e il 2 agosto 2028 per quelli dell’allegato I, legati ai prodotti regolamentati. Questi rinvii non cancellano le altre responsabilità già previste dall’ordinamento.[7] Nei casi più gravi può intervenire anche il diritto penale. Il decreto italiano punisce determinate omissioni delle misure di sicurezza e della sorveglianza umana nei sistemi ad alto rischio, quando ne derivi il pericolo previsto dalla norma per le persone o per la sicurezza dello Stato: sono fattispecie con presupposti precisi, da non confondere con un comune errore amministrativo, e nei casi previsti può rispondere anche la società o l’organizzazione coinvolta.[3]

Che cosa chiedere prima di affidare un compito a un agente

Un dirigente non deve diventare un programmatore per governare questi strumenti; deve però ottenere risposte comprensibili dal fornitore e dai propri responsabili. Nel caso delle fatture, vorrei sapere quali operazioni il programma possa eseguire da solo e oltre quale importo serva un’approvazione, e vorrei vedere che cosa accade quando i dati non coincidono, se il pagamento possa essere fermato e chi venga avvertito. Prima di autorizzare l’uso esteso del sistema, chiederei di provarlo su casi difficili, comprese fatture duplicate o documenti incompleti.

Chiederei poi come si recuperano le tracce dopo un incidente: se per ottenerle occorre dipendere interamente dalla disponibilità del fornitore, questo limite va affrontato nel contratto. Le registrazioni dovrebbero permettere di ricostruire anche quale versione del programma fosse in uso e quali istruzioni fossero attive; per conservarle occorre stabilire chi se ne occupa e per quanto tempo, tenendo conto dei dati personali e delle informazioni riservate che possono contenere, perché la raccolta indiscriminata di tutto non sostituisce un criterio di conservazione. L’acquisto di un agente IA richiede la stessa serietà con cui si affida a qualcuno il potere di operare sui conti, sugli archivi o sui rapporti con i clienti: la promessa di risparmiare tempo merita attenzione, ma va accompagnata dalla possibilità di controllare il lavoro svolto. Se domani arriverà una contestazione, un fascicolo ben costruito non garantirà la vittoria; permetterà almeno di discutere sulla base dei fatti, invece di scoprire che l’impresa ha affidato a un programma il potere di agire senza predisporre gli strumenti per verificare come lo abbia esercitato.

Fonti e riferimenti

1. OpenAI, A practical guide to building agents, definizione degli agenti, strumenti, istruzioni e controlli. Testo della fonte

2. Direttiva UE 2024/2853, in particolare articoli 4–11 e considerando 13, 22 e 24. Testo della fonte

3. Decreto legislativo 9 settembre 2026 n. 160, GU n. 214 del 15 settembre 2026, in vigore dal 30 settembre; articoli 12, 15, 17, 18 e 19. Testo della fonte

4. Senato della Repubblica, dossier n. 535/2, scheda sulla direttiva UE 2024/2853, ambito e danni risarcibili. Testo della fonte

5. Rettifica della direttiva UE 2024/2853, GU UE del 7 maggio 2026, articolo 2 paragrafo 1. Testo della fonte

6. Comunicato del Consiglio dei ministri n. 195 del 28 ottobre 2026, approvazione definitiva del recepimento; resoconto ANCE del 29 ottobre 2026. Testo della fonte

7. Regolamento UE 2026/1744, articolo 1 punto 40, modifica del calendario dell’articolo 113 dell’AI Act. Testo della fonte