Francesco ZinghinìConsulenza tecnica di parte

Contenziosi sui sistemi di intelligenza artificiale: cosa si può davvero accertare

Pubblicato il · Autore: Francesco Zinghinì

Su questo terreno circolano due affermazioni opposte e ugualmente false: che un sistema generativo sia una scatola nera su cui non si può accertare nulla, e che esistano strumenti capaci di dire se un testo sia stato scritto da una macchina. Vale la pena mettere in fila che cosa si può dimostrare e che cosa no, prima di impostare una causa su un'aspettativa sbagliata.

Un sistema non è un modello

La confusione da sciogliere per prima è fra il modello e il sistema costruito attorno ad esso. Il modello è la parte statisticamente opaca: pesi numerici addestrati, il cui comportamento non è deducibile per ispezione. Il sistema che interroga quel modello, invece, è software ordinario, e come tale è ispezionabile pezzo per pezzo:

  • quale modello viene interrogato e in quale versione;
  • quali istruzioni di sistema vengono anteposte alla richiesta dell'utente — è la parte che determina il comportamento più di quanto si immagini;
  • quali documenti vengono recuperati e forniti al modello al momento della richiesta, nelle architetture di tipo RAG, e con quale criterio di selezione;
  • quali strumenti esterni il sistema può azionare, e con quali autorizzazioni;
  • quali controlli sono posti sull'output prima che raggiunga l'utente;
  • quali parametri governano la casualità della generazione.

Nella maggioranza delle cause su forniture, la risposta sta qui e non nel modello: non nel comportamento statistico, ma in che cosa il fornitore ha costruito e in che cosa aveva dichiarato di costruire. È un accertamento su codice e configurazione, il più tradizionale dei lavori peritali.

I registri delle inferenze

Un sistema serio conserva traccia delle interazioni, perché senza quella non lo si può far funzionare né migliorare. Dove esistono, quei registri permettono di ricostruire ogni singola richiesta con precisione: il testo inviato dall'utente, il contesto aggiunto automaticamente, la risposta prodotta, il modello e la versione impiegati, gli strumenti eventualmente invocati, spesso i costi e la latenza.

È materiale ordinario di analisi forense: si acquisisce, si verifica l'integrità e si legge come qualunque altro registro. Il problema non è tecnico, è di tempo: molti fornitori li conservano per finestre brevi, e la conservazione è configurabile. Nella causa su un output generativo la prima azione utile è chiederne il congelamento, prima ancora di formulare i quesiti.

Va anche verificato, e non dato per scontato, che i registri esistessero al momento del fatto. L'assenza di registrazione in un sistema che prende decisioni rilevanti è essa stessa un dato, e in sede di valutazione della diligenza può pesare parecchio.

Riproducibilità: il punto delicato

«Può dimostrare che quel sistema, a quella domanda, rispondeva così?» La risposta onesta è: si può dimostrare che può rispondere così, non che l'abbia necessariamente fatto in quel momento.

Ci sono due ragioni, ed entrambe vanno spiegate nella relazione.

La prima è che i modelli generativi sono per costruzione non deterministici: a parità di ingresso la risposta può variare, perché la generazione include una componente casuale governata da parametri. Esistono configurazioni che riducono o azzerano quella variabilità, ma vanno impostate, e nei sistemi in esercizio spesso non lo sono.

La seconda è che il sistema cambia nel tempo, e cambia in modi che raramente sono versionati pubblicamente: il fornitore aggiorna il modello, le istruzioni di sistema vengono riscritte, i documenti recuperati dall'archivio sono diversi perché l'archivio è diverso.

Ne discende un'asimmetria che è bene mettere per iscritto: una riproduzione riuscita è un elemento probatorio forte, perché mostra che l'output contestato rientra nel comportamento del sistema. Una riproduzione fallita prova molto meno di quanto sembri, perché può dipendere da un aggiornamento intervenuto nel frattempo. Chi presenta il secondo risultato come dimostrazione che l'output non è mai stato prodotto sta forzando la conclusione.

I rilevatori di testo generato non sono prova

Esistono strumenti che promettono di stabilire se un testo sia stato scritto da un modello linguistico. Compaiono in contestazioni disciplinari, accademiche e talvolta in giudizio. Sul punto conviene essere netti: non sono utilizzabili come prova.

Funzionano su proprietà statistiche del testo — quanto le parole scelte siano prevedibili, quanto vari la struttura delle frasi — che non sono esclusive della generazione automatica. Un testo tecnico scritto in modo piano, una traduzione, un documento redatto seguendo un modello, e in particolare un testo scritto da chi non ha quella lingua come madrelingua, presentano le stesse caratteristiche. I tassi di errore misurati sono alti e, cosa più grave, sistematicamente sfavorevoli proprio a quelle categorie: un falso positivo non è distribuito a caso, colpisce prevedibilmente alcune persone più di altre.

Un consulente che fondi una conclusione su questi strumenti espone la parte a una contestazione facile e fondata. È diverso il caso dei metadati e delle marche tecniche: alcuni sistemi di generazione inseriscono nei file prodotti informazioni sulla provenienza o filigrane, e il documento in cui un testo è stato scritto conserva quasi sempre una cronologia delle revisioni che racconta se il testo sia stato digitato progressivamente o incollato in blocco. Questi sono elementi indiziari reali, che si acquisiscono e si valutano come qualunque altro dato.

I dati di addestramento

È la domanda più difficile e va affrontata senza illusioni. Stabilire dall'esterno se un'opera determinata sia stata usata per addestrare un modello è, nella generalità dei casi, tecnicamente non accertabile: i pesi non contengono i documenti, li hanno metabolizzati. Esistono tecniche di ricerca che tentano di inferire l'appartenenza di un campione all'insieme di addestramento, ma danno risultati probabilistici e fragili, non trasferibili in un'aula come accertamento.

Ciò che invece si accerta bene sono due cose diverse e spesso più utili. La prima è la somiglianza dell'output con l'opera protetta: è un confronto fra testi o immagini, con metodi consolidati, che risponde alla domanda giuridicamente rilevante nella maggior parte dei casi. La seconda è la documentazione del fornitore: le fonti dichiarate, i contratti di licenza sui dati, le registrazioni interne di acquisizione dei corpora. Nei rapporti fra imprese è quasi sempre lì che si trova la risposta, e non nel modello.

Sul versante dei dati personali il ragionamento è analogo: se il sistema restituisce informazioni riferibili a una persona, ciò dimostra che quelle informazioni sono in qualche forma disponibili al sistema — che sia per addestramento o per recupero al momento della richiesta è a sua volta oggetto di accertamento, e la distinzione non è secondaria.

Che cosa chiedere, in pratica

Le prime richieste, in ordine di urgenza

  1. Congelamento dei registri delle interazioni per il periodo rilevante, prima che la rotazione li cancelli.
  2. Esibizione della configurazione del sistema alla data del fatto: modello e versione, istruzioni di sistema, parametri di generazione, controlli sull'output.
  3. Documentazione contrattuale e tecnica di ciò che era stato promesso, comprese le soglie di qualità eventualmente pattuite e il modo in cui dovevano essere misurate.
  4. Registrazioni delle modifiche al sistema nel periodo considerato: chi ha cambiato che cosa e quando.

Quesiti formulati su questi oggetti producono risposte verificabili. Un quesito formulato come «se l'intelligenza artificiale abbia sbagliato» non ne produce nessuna.

Sistemi di intelligenza artificiale: come intervengo → · Torna agli approfondimenti

Ha una questione in corso?

Mi scriva che cosa è successo e che cosa deve dimostrare. Le dico in una prima risposta se la strada tecnica esiste, quali dati servono e con che tempi — prima di qualunque impegno.

Richiedi una valutazione