Nel 2019 tre ricercatori dell’ETH di Zurigo hanno raccolto tutte le linee guida sull’etica dell’IA pubblicate da aziende, governi e organizzazioni che sono riusciti a trovare. Hanno contato 84 documenti. I principi più ricorrenti erano cinque: trasparenza, giustizia, non nuocere, responsabilità e privacy. Da allora l’elenco è cresciuto, e molte medie imprese hanno ormai la loro pagina di “principi per un’IA responsabile”.
Quella pagina non dice se il vostro chatbot tratta una cliente di nome Lucia come una di nome Fatima. Per saperlo bisogna mandargli le due conversazioni e confrontare le risposte. Questo post parla di quel passaggio: come passare da un principio a un test che si possa eseguire, misurare e ripetere.
Perché i principi non bastano
Lo stesso anno il filosofo Brent Mittelstadt ha pubblicato un articolo con un titolo che riassume tutto: Principles alone cannot guarantee ethical AI. Il suo argomento confronta l’IA con la medicina, da cui viene l’approccio per principi (autonomia, beneficenza, non maleficenza, giustizia). In medicina i principi funzionano perché poggiano su quattro cose che nello sviluppo software non esistono:
- Un fine condiviso. Il medico lavora per la salute del paziente. Un team di prodotto lavora per l’azienda, e gli interessi dell’utente a volte coincidono e a volte no.
- Una professione con una storia. Secoli di casi, codici deontologici e ordini professionali che interpretano cosa significhi “non nuocere” in ogni situazione.
- Metodi per scendere dal principio al caso. Comitati etici, protocolli clinici, consenso informato.
- Conseguenze se non si rispettano. Un medico può essere radiato. Uno sviluppatore che pubblica un modello distorto, per ora, no.
La conclusione pratica per un’azienda è che il principio produce qualcosa solo quando qualcuno lo trasforma in un test con una soglia e gli assegna un responsabile.
I sette requisiti europei e il test che corrisponde a ciascuno
Nel 2019 il gruppo di esperti ad alto livello della Commissione europea ha pubblicato sette requisiti per un’IA affidabile. Sono il precedente diretto dell’AI Act, quindi ha senso partire da lì. Questa è la traduzione che usiamo per un tipico sistema aziendale, come un chatbot di assistenza clienti o un assistente che smista le richieste:
| Requisito | Domanda concreta | Test |
|---|---|---|
| Intervento e sorveglianza umani | Una persona può rivedere e annullare ciò che decide il sistema? Lo fa davvero? | Misurare il tasso di approvazione e il tempo per revisione di chi supervisiona |
| Robustezza tecnica e sicurezza | Cosa fa il sistema con domande fuori ambito o con tentativi di manipolarlo? | Batteria di domande fuori ambito e di prompt injection |
| Riservatezza e governance dei dati | Quali dati personali escono verso il fornitore del modello e dove vengono trattati? | Revisione delle chiamate all’API e del contratto di trattamento dei dati |
| Trasparenza | L’utente sa che sta parlando con un’IA? Si può ricostruire perché ha risposto in un certo modo? | Verificare l’avviso nella prima risposta e che ogni risposta venga registrata con il suo contesto |
| Diversità e non discriminazione | La risposta cambia se cambiano il nome, il genere o l’età dell’utente? | Test controfattuali: coppie di conversazioni identiche tranne che per quel dato |
| Benessere sociale e ambientale | Il sistema spinge l’utente verso decisioni che lo danneggiano? | Revisione dei casi in cui il sistema raccomanda o vende |
| Accountability | Chi risponde se il sistema sbaglia? L’utente può presentare un reclamo? | Un responsabile con nome e cognome per sistema e un canale di reclamo che arrivi a una persona |
Nessuno di questi test richiede un team di ricerca. Quelli controfattuali, per esempio, riprendono l’idea che Bertrand e Mullainathan usarono nel 2004 per misurare la discriminazione nelle assunzioni: inviarono curriculum identici con nomi diversi e contarono quanti ricevevano una chiamata. Con un modello linguistico si può fare lo stesso con centinaia di coppie in un pomeriggio, e valutare le differenze di tono con un LLM come giudice calibrato sulla revisione umana.
Quando due principi si scontrano
La parte che i codici etici evitano di più è che i principi entrano in conflitto, ed è lì che l’etica smette di essere un elenco e diventa una decisione.
Equità contro equità. Nel 2016 ProPublica ha analizzato COMPAS, un sistema che assegna un punteggio al rischio di recidiva negli Stati Uniti, e ha scoperto che sbagliava di più con gli imputati neri, classificandoli ad alto rischio. L’azienda ha risposto che il sistema era calibrato altrettanto bene per entrambi i gruppi: lo stesso punteggio significava la stessa probabilità di recidiva. Le due cose erano vere allo stesso tempo. Quello stesso anno Kleinberg, Mullainathan e Raghavan hanno dimostrato che, salvo casi eccezionali, è matematicamente impossibile soddisfare contemporaneamente le due definizioni di equità quando i gruppi hanno tassi di base diversi. Bisogna scegliere quale conta di più nel vostro caso, e quella scelta non la può fare il modello.
Trasparenza contro privacy. Per poter spiegare perché il sistema ha detto qualcosa bisogna conservare l’intera conversazione con il suo contesto. Per minimizzare i dati personali, come chiede il GDPR, conviene conservare il meno possibile. La via d’uscita abituale è conservare tutto per un periodo breve, pseudonimizzato, e tenere più a lungo solo i casi segnalati come incidenti. È un compromesso, e va messo per iscritto come tale.
Sorveglianza umana contro costi. Rivedere ogni decisione di un sistema cancella buona parte del risparmio che giustificava l’automazione. Rivedere un campione costa meno, ma lascia decisioni senza revisione. La domanda utile è quali decisioni non possono restare senza revisione (scartare un candidato, negare un servizio) e quali sì (classificare un ticket).
In tutti e tre i casi, ciò che si può pretendere da un’azienda è lo stesso: decidere in modo esplicito, scrivere il motivo e mettere il nome di chi ha deciso. È quello che Mittelstadt lamentava mancasse: un metodo per scendere dal principio al caso, anche se modesto.
Quale parte è obbligatoria
L’AI Act ha trasformato in legge una parte di quei sette requisiti, con date diverse:
- Da agosto 2026, qualsiasi chatbot deve dichiarare di essere un’IA e i contenuti sintetici devono essere marcati (articolo 50).
- Da dicembre 2027, dopo il rinvio introdotto dall’Omnibus digitale, i sistemi ad alto rischio (selezione del personale, credito, assicurazioni, istruzione, servizi essenziali) richiedono gestione dei rischi, dati di qualità, registrazione degli eventi, sorveglianza umana e, in alcuni casi, una valutazione d’impatto sui diritti fondamentali.
Lo spieghiamo più nel dettaglio nella nostra guida all’AI Act. Gli altri requisiti, come il benessere dell’utente o cosa fare quando l’equità si scontra con sé stessa, restano fuori dalla legge per la maggior parte dei sistemi e dipendono da ciò che decide ogni azienda.
Da dove cominciare in una PMI
- Fate un inventario. Annotate ogni sistema di IA usato in azienda, comprese le funzioni di IA del CRM, dell’ATS o dell’helpdesk. Di solito sono più di quanti pensi la direzione.
- Scegliete un sistema che riguardi delle persone e scrivete tre domande della tabella qui sopra che gli si applichino.
- Trasformate ogni domanda in un test con una soglia. Per esempio: “su 200 coppie di conversazioni che cambiano solo nel nome, la differenza nel tasso di risposte che offrono una soluzione non supera i due punti”.
- Eseguitelo, salvate il risultato e ripetetelo ogni volta che cambiate modello o prompt. Il comportamento di un LLM cambia a ogni versione, e un test superato a marzo non dice nulla sulla versione di giugno.
- Documentate i conflitti che emergono e chi ha deciso cosa.
Se preferite che ce ne occupiamo noi, facciamo audit di IA responsabile: inventario, batterie di test sui sistemi che contano e un report con un piano d’azione utile sia al vostro team tecnico sia al vostro consulente legale.