La falsa segnalazione alla polizia di Philadelphia offre una domanda alle imprese che adottano agenti artificiali: chi governa i poteri del software, quando il software comincia a esercitarli?
Un agente artificiale invia una comunicazione che nessuno avrebbe dovuto spedire e, quando si cerca una spiegazione, compare una formula destinata a fare carriera: «Ha fatto tutto l’AI». Nell’Odissea, presentarsi come Nessuno permette a Ulisse di rendere poco utile la richiesta d’aiuto di Polifemo; nelle organizzazioni contemporanee, attribuire un’azione al sistema può produrre una confusione simile, perché descrive chi abbia eseguito materialmente il passaggio e lascia nell’ombra chi lo abbia reso possibile. Il diritto deve occuparsi anche di questa seconda parte, nella quale ricompaiono persone, imprese e decisioni riconoscibili.
Il caso dal quale partire è quello reso pubblico il 9 ottobre: durante un test, un modello di Anthropic ha inviato una falsa segnalazione relativa a un omicidio irrisolto attraverso il sito della polizia di Philadelphia. Il messaggio è stato fermato come spam e non risultano compromissioni dei sistemi o dei dati del dipartimento. Questi limiti del fatto accertato contano: non abbiamo gli elementi per attribuire responsabilità nel caso americano, tanto meno per trasferirvi automaticamente categorie italiane.
Possiamo invece domandarci come affrontare un evento analogo dentro un’organizzazione che opera in Italia, evitando la tentazione di aspettare una norma contenente esattamente le parole “agente artificiale che compila il modulo sbagliato”. Quando si discute di responsabilità extracontrattuale, l’articolo 2043 del codice civile offre già una struttura di ragionamento: fatto doloso o colposo, danno ingiusto e nesso causale. L’impiego dell’AI non elimina questi elementi e non consente di darli per dimostrati soltanto perché il risultato ci appare inquietante.
La macchina può sbagliare senza che ne derivi un danno risarcibile; può anche produrre un danno del quale occorre ricostruire con attenzione l’imputazione. Il fornitore del modello, chi realizza l’applicazione e l’impresa che la utilizza possono avere capacità di intervento differenti, informazioni diverse sui limiti del sistema e obblighi che non coincidono. Un difetto del prodotto non è la stessa cosa di un’autorizzazione configurata male, come un’autorizzazione configurata male non equivale a un uso deliberatamente contrario alle istruzioni. La responsabilità richiede di distinguere proprio ciò che l’espressione “ha fatto l’AI” tende a raccogliere nello stesso sacco.
Per questo considero poco utile cominciare dall’idea di un software capace di scegliere e molto più utile ricostruire le scelte già compiute dall’organizzazione. Qualcuno ha stabilito che l’agente potesse accedere a una casella di posta, utilizzare determinate credenziali o intervenire su un archivio; qualcuno ha deciso se il risultato dovesse restare una bozza e se l’invio richiedesse un’approvazione. Anche quando queste decisioni coincidono con le impostazioni predefinite di un servizio, l’impresa dovrebbe sapere quali conseguenze comporti averle mantenute.
La distanza fra compito e potere è il punto nel quale inizierei una verifica. Se chiedo a un assistente di leggere le richieste dei clienti e preparare le risposte, l’accesso necessario a svolgere quell’attività non giustifica da solo la possibilità di trasmetterle. Un incarico formulato in termini generali non dovrebbe trasformarsi, per inerzia, in una procura informatica senza confini; e l’interfaccia amichevole con la quale il sistema ci parla non rende meno incisive le operazioni che può eseguire dietro le quinte.
L’immagine di Ulisse torna utile anche qui, in una parte diversa del viaggio: davanti alle Sirene, la precauzione viene organizzata prima di ascoltarle, quando è ancora possibile decidere con lucidità quali richieste successive non debbano essere eseguite. Trasposto in un sistema informatico, questo significa collocare alcuni limiti fuori dalla disponibilità del modello. Se un’operazione richiede un’approvazione, il controllo dovrebbe essere costruito in modo che l’agente non possa concedersela da solo; scrivergli di comportarsi prudentemente conserva una funzione, ma lascia irrisolta la domanda su che cosa gli sia effettivamente possibile fare.
Quando il trattamento riguarda dati personali, il GDPR fornisce riferimenti precisi. Gli articoli 25 e 32 richiedono, nei rispettivi ambiti, misure adeguate alla protezione dei dati fin dalla progettazione e alla sicurezza del trattamento, tenendo conto del rischio. Per il titolare, tradurre questi principi nell’uso di un agente significa valutare anche l’estensione degli accessi e le operazioni consentite: la scelta del fornitore e il relativo contratto fanno parte del lavoro, senza assorbire tutte le decisioni che restano nell’organizzazione.
L’AI Act aggiunge un livello di disciplina che va maneggiato con la stessa precisione. L’autonomia di un sistema, o persino la gravità di un suo errore, non bastano da sole a qualificarlo come “ad alto rischio”: occorre applicare i criteri dell’articolo 6 e considerare gli impieghi contemplati dal regolamento. La circostanza che un agente invii un messaggio alla polizia non lo trasforma automaticamente in un sistema destinato alle attività delle autorità di contrasto previste dall’allegato III.
È una distinzione meno spettacolare di quelle cui ci ha abituati Minority Report, ma proprio per questo utile. Nel film il potere pubblico organizza il proprio intervento intorno a una previsione; qui il primo rischio interpretativo sarebbe trattare l’allarme suscitato dalla tecnologia come se fosse già una qualificazione giuridica. Per stabilire quali regole valgano servono la finalità del sistema e il contesto concreto, mentre per attribuire una responsabilità occorrono fatti e prove. La suggestione cinematografica può aiutarci a formulare le domande, purché non finisca per rispondere al posto nostro.
Lo stesso rigore dovrebbe accompagnare la supervisione umana, espressione che rischia di diventare rassicurante quanto è vaga. Un dipendente al quale arrivano decine di richieste di conferma, prive del contenuto completo e del contesto necessario, difficilmente esercita un controllo sostanziale. Se vogliamo attribuirgli una decisione, dobbiamo offrirgli il tempo e le informazioni per prenderla, oltre alla possibilità effettiva di correggere o fermare l’azione. Altrimenti l’organizzazione conserva la ricevuta del clic e si illude di aver conservato il governo del processo.
Dopo un incidente, poi, sarà necessario ricostruire quali istruzioni fossero state impartite e quali operazioni siano state realmente eseguite, con i permessi disponibili in quel momento. Una spiegazione prodotta dal modello a posteriori può orientare un approfondimento; attribuirle da sola il valore di ricostruzione attendibile significherebbe chiedere al sistema coinvolto di scrivere anche il verbale dei fatti. Occorrono registrazioni affidabili, a loro volta protette e conservate secondo criteri giustificati, soprattutto quando contengono dati personali.
La conseguenza pratica per un’impresa è abbastanza concreta da poter essere portata in una riunione di direzione: ogni grado di autonomia concesso all’agente dovrebbe corrispondere a un’esigenza del processo e a controlli verificabili. Non serve presumere che qualcuno debba comunque pagare per ogni errore; serve poter dimostrare come siano state prese le decisioni e perché fossero adeguate alle circostanze.
Se da una casella aziendale parte una comunicazione indebita, il primo documento da cercare potrebbe dunque essere quello che chiarisce chi avesse autorizzato il sistema a inviare, seguito dalla configurazione che avrebbe dovuto far rispettare quel limite. «Nessuno ha premuto il pulsante» rimarrà forse un fatto vero; difficilmente sarà una spiegazione sufficiente per chi quel messaggio lo ha ricevuto.
L’articolo in video
Una sintesi video realizzata con NotebookLM a partire da questo articolo.