AI Literacy

Questa guida è uno strumento di lavoro, non un trattato. Serve a orientarsi rapidamente nel reticolo di norme — europee e italiane — che disciplinano lo sviluppo e l'uso dei sistemi di intelligenza artificiale, e a tradurre concetti tecnici in categorie giuridiche utilizzabili nella pratica professionale. È costruita per la consultazione puntuale: ogni capitolo è autosufficiente e rinvia agli altri quando i regimi si intrecciano.

1.1 · Perimetro

Il perimetro normativo è duplice e volutamente circoscritto: diritto dell'Unione europea e diritto italiano. Restano fuori gli ordinamenti extra-UE, salvo richiami funzionali (ad esempio quando l'AI Act produce effetti extraterritoriali). La scelta riflette l'ambito operativo concreto e consente profondità anziché estensione dispersiva.

1.2 · La gerarchia delle fonti

Comprendere il rango di ciascuna fonte è il primo presidio contro errori di impostazione: un regolamento UE è direttamente applicabile e prevale sul diritto interno incompatibile; la soft law (linee guida, codici di condotta) orienta l'interpretazione ma non crea obblighi autonomi; la giurisprudenza chiarisce la portata delle norme ma va sempre verificata nella sua attualità. La mappa che segue ordina le fonti rilevanti per questa materia.

1.3 · Il metodo di redazione (best practice CNF / CCBE)

La guida è stata redatta con l'assistenza di un sistema di IA generativa, applicando le indicazioni della Guida del CCBE sull'uso dell'intelligenza artificiale generativa da parte degli avvocati recepita dal Consiglio Nazionale Forense. Quattro principi governano ogni contenuto:

• Trasparenza del ragionamento. Le inferenze e gli assunti sono resi espliciti; quando una conclusione dipende da una premessa incerta, lo si dichiara.
• Oggettività fattuale, niente adulazione. Le affermazioni sono ancorate a dati e fonti verificabili; non si assecondano tesi precostituite a scapito dell'accuratezza.
• Verificabilità delle fonti. Ogni capitolo si chiude con l'elenco delle fonti citate; il lettore deve poter risalire al testo originale.
• Supervisione umana e mitigazione dei rischi. Il contenuto generato è soggetto a verifica professionale; i rischi tecnici (allucinazioni, bias, sycophancy) sono trattati in modo dedicato nella Parte V e tenuti presenti nella stessa redazione della guida.

1.4 · Le fonti normative di riferimento

La guida poggia su un corpo normativo preciso, che conviene avere chiaro fin dall'inizio. Non si tratta di un elenco esaustivo di tutto il diritto potenzialmente rilevante, ma del nucleo di atti che disciplinano in modo diretto lo sviluppo e l'uso dei sistemi di IA nel perimetro UE e italiano, e che vengono richiamati nei capitoli successivi.

Diritto dell'Unione europea

Soft law dell'Unione (orienta l'interpretazione)

• Linee guida della Commissione UE (es. sulle pratiche vietate ex art. 5 e sulla definizione di sistema di IA).
• Linee guida e Opinion dell'EDPB (in particolare l'Opinion 28/2024 sull'uso di dati personali nei modelli di IA) e le Joint Opinion EDPB-EDPS.
• Codes of Practice in materia di GPAI e di trasparenza dei contenuti generati da IA.

Diritto italiano

• Legge 23 settembre 2025, n. 132 (cornice nazionale sull'IA) e relativi decreti delegati di attuazione.
• D.lgs. 231/2001 sulla responsabilità amministrativa degli enti.
• D.lgs. 196/2003 (Codice privacy), come adeguato dal D.lgs. 101/2018.
• Codice civile e Codice penale per i profili di responsabilità civile e penale.
• Provvedimenti del Garante per la protezione dei dati personali.

1.5 · Legenda delle icone

Non si può qualificare giuridicamente ciò che non si comprende tecnicamente. Questo capitolo fornisce il vocabolario minimo per leggere i capitoli successivi: cosa è un sistema di IA agli occhi del diritto, come funziona, e perché certe sue caratteristiche tecniche generano problemi legali specifici. L'obiettivo non è la padronanza ingegneristica, ma la capacità di porre le domande giuste e di riconoscere i punti in cui la tecnologia incontra la norma.

2.1 · Cos'è un "sistema di IA" per il diritto

La definizione operativa è quella dell'art. 3, par. 1, AI Act: un sistema di IA è un sistema automatizzato progettato per funzionare con livelli di autonomia variabili, che può presentare adattività dopo la diffusione e che, per obiettivi espliciti o impliciti, deduce dagli input ricevuti come generare output (quali previsioni, contenuti, raccomandazioni o decisioni) capaci di influenzare ambienti fisici o virtuali.

Tre elementi della definizione hanno peso giuridico diretto:

• Autonomia. Il sistema opera, in misura più o meno ampia, senza intervento umano puntuale. È il presupposto del problema della supervisione umana (art. 14 AI Act) e dell'imputazione della responsabilità.
• Inferenza. Il sistema non esegue solo regole predefinite: deduce, generalizza, produce output non interamente prevedibili a priori. È ciò che distingue l'IA dal software tradizionale e fonda il problema dell'opacità.
• Adattività. Il comportamento può cambiare con l'uso (apprendimento continuo). Rileva per la gestione del rischio nel tempo e per la tenuta delle valutazioni di conformità.

2.2 · Come apprende una macchina

Il machine learning (apprendimento automatico) è il paradigma dominante: invece di programmare regole, si addestra un modello su grandi quantità di dati perché ne estragga autonomamente schemi. Tre famiglie principali:

• Apprendimento supervisionato — il modello impara da esempi etichettati (input → output corretto noto). Tipico di classificazione e previsione. La qualità e la rappresentatività delle etichette è la radice tecnica del bias.
• Apprendimento non supervisionato — il modello individua strutture in dati non etichettati (clustering, riduzione dimensionale).
• Apprendimento per rinforzo — il modello apprende per tentativi ed errori massimizzando una ricompensa. La sua variante con feedback umano (RLHF) è usata per "allineare" i modelli linguistici e, paradossalmente, è una delle cause della sycophancy (cap. 16).

Il deep learning è il sottoinsieme basato su reti neurali artificiali a molti strati: è la tecnologia che alimenta i modelli generativi odierni e, per la sua complessità, quella che pone i maggiori problemi di opacità ("black box").

2.3 · Modelli fondazionali, GPAI e modelli linguistici

I modelli fondazionali (foundation models) sono modelli di grandi dimensioni addestrati su enormi quantità di dati eterogenei e adattabili a una pluralità di compiti a valle. L'AI Act li intercetta attraverso la categoria dei modelli di IA per finalità generali (GPAI), oggetto di obblighi propri (cap. 5). I Large Language Models (LLM) (i modelli linguistici alla base di ChatGPT, Claude, Gemini) ne sono la specie più diffusa.

2.4 · Addestramento, inferenza e il lessico essenziale

Due fasi vanno tenute distinte perché generano problemi legali diversi:

• Addestramento (training). Il modello "impara" dai dati di addestramento regolando i propri parametri. È la fase critica per il diritto d'autore (text & data mining, cap. 12) e per il GDPR (liceità del trattamento dei dati usati per l'addestramento, cap. 7).
• Inferenza (uso). Il modello già addestrato genera output a partire da un input dell'utente. È la fase in cui emergono allucinazioni e in cui si pongono i problemi di trasparenza verso l'utente (art. 50 AI Act).

2.5 · Anatomia di un sistema di IA

La figura che segue scompone un sistema di IA generativa nelle sue componenti, associando a ciascuna il problema giuridico tipico e il capitolo della guida in cui è trattato.

2.6 · Perché l'opacità è un problema giuridico

La caratteristica più rilevante per il diritto è l'opacità dei modelli profondi: spesso non è possibile ricostruire con esattezza perché il sistema abbia prodotto un determinato output. Questa "scatola nera" entra in tensione con diritti e doveri fondamentali: il diritto a una spiegazione e a non essere sottoposti a decisioni automatizzate (artt. 13-15 e 22 GDPR), gli obblighi di trasparenza e tracciabilità dell'AI Act, l'onere della prova nei giudizi di responsabilità, il diritto di difesa quando un sistema incide su posizioni giuridiche. I capitoli successivi traducono ciascuna di queste tensioni in regole concrete.

Il Regolamento (UE) 2024/1689 (AI Act) è la prima disciplina organica e orizzontale dell'intelligenza artificiale al mondo. È entrato in vigore il 1° agosto 2024 e si applica per fasi successive (cap. 6). Questo capitolo ne fissa la struttura, il campo di applicazione e le definizioni che governano tutto il resto della Parte II.

3.1 · La logica del regolamento

L'AI Act non vieta né autorizza la tecnologia in quanto tale: ne disciplina gli usi in funzione del rischio che generano per la salute, la sicurezza e i diritti fondamentali. È un approccio basato sul rischio (risk-based), articolato su livelli a cui corrispondono obblighi crescenti (cap. 4). La struttura conta 113 articoli e 13 allegati; come regolamento, è direttamente applicabile in tutti gli Stati membri senza necessità di recepimento.

3.2 · Ambito di applicazione soggettivo: gli operatori

Il regolamento si rivolge a una pluralità di operatori, ciascuno con obblighi propri. Identificare correttamente il ruolo è il primo passo di ogni analisi di conformità, perché un medesimo soggetto può rivestire ruoli diversi rispetto a sistemi diversi (e può mutare ruolo, ad esempio se modifica sostanzialmente un sistema o lo immette sul mercato con il proprio nome).

3.3 · Ambito territoriale: l'effetto extraterritoriale

Come il GDPR, l'AI Act ha portata extraterritoriale (art. 2). Si applica non solo a provider e deployer stabiliti nell'Unione, ma anche a operatori stabiliti in Paesi terzi quando l'output prodotto dal sistema è destinato a essere utilizzato nell'Unione. Un fornitore statunitense che immette un sistema sul mercato UE, o i cui risultati sono usati in Europa, rientra nel perimetro.

3.4 · Le esclusioni

Restano fuori dal regolamento alcuni ambiti definiti (art. 2):

• Sistemi sviluppati o usati esclusivamente per scopi militari, di difesa o di sicurezza nazionale.
• Attività di ricerca, sviluppo e prototipazione precedenti all'immissione sul mercato.
• Uso da parte di persone fisiche nell'ambito di attività puramente personali e non professionali.
• Sistemi e modelli rilasciati con licenze libere e open source, con importanti eccezioni (l'esclusione non opera per i sistemi vietati, ad alto rischio o soggetti agli obblighi di trasparenza dell'art. 50, né per i GPAI con rischio sistemico).

Il cuore dell'AI Act è la classificazione degli usi dell'IA in quattro livelli di rischio, a cui corrispondono regimi giuridici nettamente diversi: dal divieto assoluto all'assenza di obblighi specifici. La piramide è lo schema mentale da tenere sempre presente.

4.1 · Pratiche vietate (art. 5)

All'apice della piramide vi sono le pratiche ritenute incompatibili con i valori dell'Unione, vietate dal 2 febbraio 2025. Sono otto, da leggere alla luce delle Linee guida della Commissione sulle pratiche di IA vietate (2025):

1. Tecniche manipolative o ingannevoli subliminali, capaci di distorcere il comportamento causando un danno significativo.
2. Sfruttamento di vulnerabilità dovute a età, disabilità o situazione socio-economica.
3. Social scoring: valutazione o classificazione di persone su base comportamentale o di caratteristiche personali, con trattamenti pregiudizievoli sproporzionati o decontestualizzati.
4. Polizia predittiva individuale: previsione del rischio che una persona commetta un reato basata unicamente su profilazione o tratti di personalità.
5. Scraping non mirato di immagini facciali da internet o da telecamere per creare banche dati di riconoscimento facciale.
6. Riconoscimento delle emozioni sul luogo di lavoro e negli istituti di istruzione (salve ragioni mediche o di sicurezza).
7. Categorizzazione biometrica per dedurre dati sensibili (razza, opinioni politiche, appartenenza sindacale, convinzioni religiose, vita o orientamento sessuale).
8. Identificazione biometrica remota "in tempo reale" in spazi accessibili al pubblico a fini di contrasto, salvo eccezioni tassative e autorizzate.

4.2 · Sistemi ad alto rischio

È la categoria su cui si concentra il maggior carico di obblighi (cap. 6). Un sistema è ad alto rischio in due casi:

• Allegato I (quando è un componente di sicurezza di un prodotto già regolato dalla normativa di armonizzazione dell'Unione: macchine, dispositivi medici, giocattoli, automotive, e simili, soggetto a valutazione di conformità da parte di terzi).
• Allegato III (quando ricade in uno degli otto ambiti elencati, salvo la deroga per i sistemi che non presentano un rischio significativo ai sensi dell'art. 6, par. 3).

4.3 · Rischio di trasparenza (art. 50)

Alcuni sistemi, pur non essendo ad alto rischio, generano un rischio specifico di inganno o confusione e sono soggetti a obblighi di trasparenza: informare l'utente che sta interagendo con un'IA (es. chatbot); marcare in modo leggibile i contenuti sintetici (audio, immagini, video, testo); rendere riconoscibili i deepfake e i contenuti generati o manipolati. Sono il fondamento del Code of Practice sulla trasparenza dei contenuti (trattato al cap. 13 e nella Parte VI).

4.4 · Rischio minimo

Tutto ciò che non rientra nelle categorie precedenti (filtri anti-spam, videogiochi, gran parte degli usi gestionali) non è soggetto a obblighi specifici. Restano applicabili le altre normative (in primis il GDPR) e sono incoraggiati codici di condotta volontari.

Accanto alla piramide del rischio (che riguarda i sistemi), l'AI Act introduce un regime autonomo per i modelli di IA per finalità generali (GPAI), cioè i modelli fondazionali che possono essere integrati in una pluralità di sistemi a valle (cap. 2). Gli obblighi GPAI si applicano dal 2 agosto 2025.

5.1 · Obblighi comuni a tutti i GPAI (art. 53)

Ogni fornitore di un modello GPAI deve: redigere e aggiornare la documentazione tecnica del modello; fornire informazioni e documentazione ai fornitori a valle che intendono integrarlo (per consentire loro di adempiere ai propri obblighi); adottare una policy per il rispetto del diritto d'autore dell'Unione; pubblicare una sintesi sufficientemente dettagliata dei contenuti utilizzati per l'addestramento, secondo il modello predisposto dall'AI Office. Per i modelli rilasciati con licenze libere e open source alcuni obblighi sono attenuati, ma non quando il modello presenta un rischio sistemico.

5.2 · Modelli con rischio sistemico (artt. 51 e 55)

Un GPAI è classificato come avente rischio sistemico quando ha "capacità di impatto elevato". La soglia presuntiva è quantitativa: una potenza di calcolo cumulativa per l'addestramento superiore a 10²⁵ operazioni in virgola mobile (FLOP). I fornitori di questi modelli, oltre agli obblighi comuni, devono effettuare valutazioni del modello e test in contraddittorio, valutare e mitigare i rischi sistemici a livello UE, garantire un'adeguata cybersicurezza e segnalare gli incidenti gravi all'AI Office e alle autorità nazionali.

5.3 · Il Code of Practice per i GPAI

Per agevolare la conformità nella fase iniziale, l'AI Office ha promosso un Code of Practice sui GPAI: l'adesione, su base volontaria, costituisce un mezzo per dimostrare la conformità agli obblighi (presunzione di conformità) in attesa degli standard armonizzati.

Stabilita la classe di rischio (cap. 4) e identificato il ruolo (cap. 3), questo capitolo risponde alla domanda operativa: chi deve fare cosa, e da quando? Il focus è sui sistemi ad alto rischio, dove gli obblighi sono più intensi, e sui due ruoli centrali (provider e deployer).

6.1 · Matrice ruoli × obblighi (sistemi ad alto rischio)

6.2 · Gli obblighi del provider in sintesi

Il provider di un sistema ad alto rischio sopporta il nucleo della conformità: progettare il sistema con un ciclo di vita governato dal rischio (art. 9), addestrarlo su dati pertinenti e rappresentativi (art. 10, che è anche il presidio tecnico contro il bias, cap. 14), documentarlo (art. 11), garantirne tracciabilità (art. 12), trasparenza verso il deployer (art. 13), sorvegliabilità umana (art. 14) e adeguati livelli di accuratezza e sicurezza (art. 15); il tutto entro un sistema di gestione della qualità (art. 17), superando la valutazione di conformità e apponendo la marcatura CE.

6.3 · Gli obblighi del deployer in sintesi

Il deployer (art. 26) deve usare il sistema secondo le istruzioni, affidare la sorveglianza umana a persone competenti, monitorarne il funzionamento e sospenderlo in caso di rischio, conservare i log, assicurare la pertinenza dei dati di input e informare i lavoratori e gli interessati nei casi previsti. I deployer pubblici e alcuni privati (es. servizi essenziali) devono svolgere la FRIA (art. 27).

6.4 · La timeline applicativa

L'AI Act si applica per scaglioni. La figura riporta il calendario di legge e, distinte in rosso, le modifiche introdotte dal Digital Omnibus (accordo provvisorio, non ancora in vigore).

6.5 · L'apparato sanzionatorio (art. 99)

Le sanzioni sono modulate sulla gravità della violazione, secondo lo schema "importo fisso o percentuale del fatturato mondiale annuo, se superiore":

• Pratiche vietate (art. 5): fino a 35 milioni di euro o il 7% del fatturato.
• Altre violazioni di obblighi (provider, deployer, e simili): fino a 15 milioni o il 3%.
• Informazioni inesatte o fuorvianti alle autorità: fino a 7,5 milioni o l'1%.

Per PMI e start-up si applica l'importo inferiore tra il fisso e la percentuale. Ai fornitori di GPAI la Commissione può irrogare sanzioni fino a 15 milioni o il 3% (art. 101).

6.6 · Gli spazi di sperimentazione normativa (regulatory sandbox)

Accanto agli obblighi, l'AI Act prevede misure a sostegno dell'innovazione. La principale è lo spazio di sperimentazione normativa (regulatory sandbox, artt. 57-59): un ambiente controllato, istituito da un'autorità competente, in cui sviluppare, addestrare, testare e validare sistemi di IA innovativi sotto la supervisione del regolatore, per un tempo limitato e secondo un piano concordato, prima dell'immissione sul mercato. Ogni Stato membro deve renderne operativo almeno uno a livello nazionale entro il 2 agosto 2026 (art. 57); l'accesso è gratuito per PMI e start-up (art. 58).

Per il giurista la sandbox rileva sotto due profili complementari, che ne fanno al tempo stesso uno strumento di conformità e una forma di tutela:

• Strumento di compliance. Offre certezza del diritto e orientamento dell'autorità, consente di raccogliere prove documentali (il piano di sperimentazione e la relazione di uscita) utili alla valutazione di conformità e attenua il rischio sanzionatorio: le autorità non irrogano sanzioni per le violazioni emerse durante la sperimentazione se il partecipante ha rispettato il piano e le indicazioni ricevute, operando in buona fede.
• Regime protetto per i dati. L'art. 59 introduce una base giuridica specifica che consente, a determinate condizioni e con garanzie, di trattare nella sandbox dati personali raccolti lecitamente per altre finalità, al solo scopo di sviluppare, addestrare e testare determinati sistemi di IA di interesse pubblico (una deroga mirata al principio di limitazione della finalità del GDPR, cap. 7). Le autorità di protezione dei dati sono associate alla supervisione.

L'AI Act non sostituisce il GDPR: lo affianca. Quando un sistema di IA tratta dati personali (nell'addestramento o nell'uso) si applicano contemporaneamente entrambi i regimi. L'art. 2, par. 7, dell'AI Act lo afferma in modo esplicito: il regolamento sull'IA lascia impregiudicato il diritto dell'Unione in materia di protezione dei dati. Per il giurista significa una doppia analisi, da condurre in modo coordinato e non sequenziale.

7.1 · I ruoli non si mappano uno a uno

Un errore frequente è equiparare il provider al titolare e il deployer al responsabile. Non è così: le qualifiche del GDPR (titolare/responsabile) dipendono da chi determina finalità e mezzi del trattamento, mentre quelle dell'AI Act (provider/deployer) dipendono dal ruolo nella catena del valore del sistema. Un deployer che usa un sistema di IA per le proprie finalità è quasi sempre titolare del trattamento; un provider può essere titolare (per l'addestramento) e, in altri contesti, responsabile. La qualificazione va fatta separatamente per ciascun regime.

7.2 · La base giuridica del trattamento

Ogni trattamento, in fase di addestramento e in fase d'uso, richiede una base giuridica (art. 6 GDPR). Le tre più rilevanti per l'IA sono il consenso, l'esecuzione di un contratto e il legittimo interesse. Quest'ultimo è centrale, in particolare per l'addestramento dei modelli su grandi quantità di dati, ed è oggetto di un test in tre fasi.

Quando il trattamento riguarda categorie particolari di dati (art. 9 GDPR: dati sulla salute, biometrici, opinioni, ecc.) occorre, in aggiunta, una delle condizioni dell'art. 9, par. 2. È un punto critico per molti sistemi di IA, perché tali dati possono emergere anche indirettamente (inferenza) dai dati di addestramento.

7.3 · I principi del GDPR messi alla prova dall'IA

• Liceità, correttezza, trasparenza. L'opacità dei modelli (cap. 2) rende ardua la trasparenza verso l'interessato. Vanno predisposte informative comprensibili sull'uso dell'IA.
• Limitazione della finalità. I dati raccolti per uno scopo non possono essere riutilizzati per addestrare un modello senza una valutazione di compatibilità.
• Minimizzazione. In tensione strutturale con la logica "data-hungry" dell'IA: impone di usare solo i dati necessari e di valutare anonimizzazione o dati sintetici.
• Esattezza. Principio direttamente collegato alle allucinazioni (cap. 14): un output errato su una persona può configurare un trattamento di dati inesatti.
• Limitazione della conservazione e integrità e riservatezza (sicurezza), quest'ultima in raccordo con l'art. 15 AI Act e il CRA (cap. 9).

7.4 · L'Opinion 28/2024 dell'EDPB sui modelli di IA

L'EDPB, con l'Opinion 28/2024 (adottata il 17 dicembre 2024), ha affrontato tre nodi cruciali:

• Anonimato dei modelli. Un modello addestrato su dati personali non è automaticamente anonimo. L'anonimato va valutato caso per caso e sussiste solo se è altamente improbabile estrarre i dati personali o ottenerli tramite gli output. La soglia è elevata.
• Legittimo interesse. Può fondare sia lo sviluppo sia l'uso del modello, ma solo superando il test in tre fasi.
• Trattamento illecito a monte. Se il modello è stato sviluppato con dati trattati illecitamente, ciò può inficiare la liceità dei trattamenti successivi, salvo i casi in cui il modello sia stato effettivamente anonimizzato.

7.5 · Decisioni automatizzate e trasparenza

L'art. 22 GDPR riconosce all'interessato il diritto di non essere sottoposto a decisioni basate unicamente su trattamenti automatizzati che producano effetti giuridici o significativi, salvo eccezioni (contratto, consenso, legge) e sempre con garanzie, incluso l'intervento umano. In combinato con gli artt. 13-15 (informazione e accesso, con la "logica" del trattamento) e con la sorveglianza umana dell'art. 14 AI Act, costituisce il presidio contro l'automazione opaca delle decisioni.

La valutazione d'impatto sulla protezione dei dati (DPIA, art. 35 GDPR) è lo strumento principe per governare il rischio dei trattamenti con IA. Questo capitolo è volutamente operativo: quando è obbligatoria, come si struttura secondo i criteri EDPB, e un esempio compilato su un sistema di IA reale.

8.1 · Quando la DPIA è obbligatoria

La DPIA è dovuta quando il trattamento può presentare un rischio elevato per i diritti e le libertà delle persone (art. 35, par. 1). L'art. 35, par. 3, individua tre casi tipici (valutazione sistematica e automatizzata con effetti significativi; trattamento su larga scala di categorie particolari; sorveglianza sistematica di aree pubbliche). Le linee guida WP248 rev.01 (adottate dal WP29 e fatte proprie dall'EDPB) forniscono nove criteri: di norma, la presenza di almeno due rende la DPIA necessaria.

8.2 · DPIA e FRIA: due valutazioni, un solo dossier

Come anticipato (cap. 6), la FRIA dell'art. 27 AI Act non coincide con la DPIA. La DPIA tutela i dati personali; la FRIA valuta l'impatto del sistema ad alto rischio sull'insieme dei diritti fondamentali. L'art. 27, par. 4, va oltre il mero riconoscimento dell'affinità: dispone che, se sussiste già l'obbligo di DPIA ex art. 35 GDPR, la FRIA sia effettuata in combinazione con tale valutazione (in pratica come sua componente o allegato), così da non moltiplicare i processi. In chiave operativa conviene quindi un unico dossier che soddisfi entrambi gli obblighi, condividendo descrizione del sistema e analisi dei rischi.

8.3 · La struttura della DPIA (art. 35, par. 7)

Il "template" europeo discende dal contenuto minimo dell'art. 35, par. 7, letto con i criteri di accettabilità dell'Allegato 2 di WP248. Quattro pilastri:

1. Descrizione sistematica del trattamento e delle finalità (compreso, se del caso, il legittimo interesse perseguito).
2. Valutazione della necessità e proporzionalità rispetto alle finalità.
3. Valutazione dei rischi per i diritti e le libertà degli interessati.
4. Misure previste per affrontare i rischi (garanzie, misure di sicurezza, meccanismi per dimostrare la conformità).

8.4 · Esempio compilato — sistema di IA per lo screening dei CV

Caso: una società adotta un sistema di IA che ordina e valuta le candidature ricevute, assegnando un punteggio di idoneità. È un trattamento ad alto rischio (Allegato III, n. 4: occupazione) e implica profilazione di interessati in posizione di vulnerabilità (candidati). DPIA obbligatoria.

8.5 · La consultazione preventiva (art. 36)

Se, nonostante le misure, il rischio residuo resta elevato, il titolare deve consultare preventivamente l'autorità di controllo (il Garante) prima di procedere. È l'ultimo presidio del sistema: una DPIA che si chiude con un rischio residuo elevato non autorizza il trattamento, ma impone il coinvolgimento dell'autorità.

La sicurezza non è un tema accessorio: è un obbligo che attraversa più regimi. Il GDPR la impone per i dati (art. 32), l'AI Act per i sistemi ad alto rischio (art. 15), il Cyber Resilience Act per i prodotti con elementi digitali, la NIS2 per le entità essenziali e importanti. Per il giurista dell'IA significa saper collocare un sistema dentro questa rete di obblighi senza duplicazioni.

9.1 · Il Cyber Resilience Act (Reg. UE 2024/2847)

Il CRA, in vigore dal 10 dicembre 2024, introduce requisiti di cybersicurezza orizzontali per i prodotti con elementi digitali (hardware e software), categoria che intercetta molti sistemi e componenti di IA. Impone sicurezza fin dalla progettazione (security by design), gestione delle vulnerabilità lungo il ciclo di vita, e marcatura CE come per gli altri prodotti regolati.

9.2 · Il raccordo con l'AI Act (art. 15)

L'art. 15 dell'AI Act impone ai sistemi ad alto rischio livelli adeguati di accuratezza, robustezza e cybersicurezza. Per evitare un doppio onere, il regolamento prevede meccanismi di coordinamento: un sistema di IA ad alto rischio conforme ai requisiti di cybersicurezza del CRA beneficia di una presunzione di conformità sotto questo profilo. La verifica va comunque condotta caso per caso.

9.3 · La direttiva NIS2 (Dir. UE 2022/2555)

La NIS2 impone obblighi di gestione del rischio cyber e di segnalazione degli incidenti alle entità essenziali e importanti di settori critici. In Italia è stata recepita con il D.lgs. 138/2024. Quando un sistema di IA è impiegato da una di queste entità, gli obblighi NIS2 si sommano a quelli specifici dell'IA, con responsabilità anche in capo agli organi di gestione.

L'Italia si è dotata di una legge nazionale sull'IA: la Legge 23 settembre 2025, n. 132 ("Disposizioni e deleghe al Governo in materia di intelligenza artificiale"), pubblicata in Gazzetta il 25 settembre 2025 ed entrata in vigore il 10 ottobre 2025. Non sovrappone obblighi all'AI Act, ma ne accompagna l'attuazione e disciplina ambiti di competenza nazionale, in una cornice esplicitamente antropocentrica.

10.1 · Principi e ambiti di settore

La legge fissa principi di uso corretto, trasparente e responsabile dell'IA e detta disposizioni per sanità, lavoro, professioni intellettuali, pubblica amministrazione, attività giudiziaria e cybersicurezza nazionale (Capo II). Due punti meritano attenzione particolare per l'avvocato:

• Professioni intellettuali. L'uso di sistemi di IA è ammesso in via strumentale e di supporto all'attività professionale; deve essere assicurata la prevalenza del lavoro intellettuale del professionista e va garantita l'informazione al cliente sull'eventuale impiego di tali sistemi. È un riflesso diretto, sul piano interno, delle best practice CNF/CCBE (cap. 1).
• Attività giudiziaria. L'IA può essere impiegata per l'organizzazione e la semplificazione del lavoro, ma la decisione resta sempre riservata al magistrato: è esclusa ogni delega del giudizio alla macchina.

10.2 · Le autorità nazionali

Sono designate AgID (Agenzia per l'Italia digitale, con funzioni di promozione e di vigilanza sulla notifica) e ACN (Agenzia per la cybersicurezza nazionale, per la vigilanza, ispezione e profili di sicurezza). Le due agenzie operano come autorità nazionali per l'attuazione della disciplina, in coordinamento con l'assetto europeo.

10.3 · Le deleghe e i decreti attuativi

La legge contiene ampie deleghe al Governo (da esercitare entro dodici mesi), tra cui una disciplina organica su dati, algoritmi e metodi matematici per l'addestramento, senza introdurre obblighi ulteriori per gli ambiti già coperti dall'AI Act. A giugno 2026 i relativi decreti delegati sono in fase di esame: la cornice è quindi in via di completamento e va monitorata (è uno degli oggetti dell'alert mensile collegato a questa guida).

Quando un sistema di IA causa un danno o è strumento di un illecito, chi risponde? La risposta si articola su tre piani (civile, penale, responsabilità degli enti) profondamente rimodellati dalle novità del 2024-2025.

11.1 · Responsabilità civile

Il quadro è cambiato nettamente. La proposta di direttiva sulla responsabilità da IA (AI Liability Directive) è stata ritirata dalla Commissione nel febbraio 2025. Resta centrale la nuova direttiva sulla responsabilità per danno da prodotti difettosi (Dir. UE 2024/2853, adottata il 23 ottobre 2024), che include espressamente software e sistemi di IA nella nozione di prodotto. Essa conferma una responsabilità oggettiva del produttore per il prodotto difettoso (danni da morte, lesioni, danni a cose, distruzione o corruzione di dati) e introduce alleggerimenti dell'onere della prova (presunzioni di difettosità e di nesso causale) proprio per i casi di complessità tecnica e opacità. Il termine di recepimento è il 9 dicembre 2026. Sul piano interno restano azionabili gli artt. 2043, 2050 (attività pericolose) e 2051 (cose in custodia) del codice civile.

11.2 · Responsabilità penale

La L. 132/2025 è intervenuta sul codice penale con due novità rilevanti:

• Nuovo reato (art. 612-quater c.p.). Punisce con la reclusione da uno a cinque anni chi cagiona un danno ingiusto diffondendo, senza consenso, immagini, video o voci falsificati o alterati mediante IA e idonei a indurre in inganno sulla loro autenticità. È la tipizzazione della fattispecie dei deepfake dannosi.
• Aggravante comune (art. 61 n. 11-decies c.p.). Inasprisce la pena per qualsiasi reato commesso mediante sistemi di IA quando questi abbiano costituito un mezzo insidioso, abbiano ostacolato la difesa pubblica o privata o aggravato le conseguenze del reato.

Sul piano dogmatico restano aperti i nodi dell'imputazione soggettiva e della colpevolezza, dato il grado di autonomia dei sistemi (cap. 2).

11.3 · La responsabilità degli enti (D.lgs. 231/2001)

Il D.lgs. 231/2001 disciplina la responsabilità amministrativa da reato degli enti. È spesso descritta come "oggettiva", ma in senso tecnico si fonda sulla colpa di organizzazione: l'ente risponde del reato presupposto commesso nel suo interesse o vantaggio, salvo che dimostri di aver adottato ed efficacemente attuato un idoneo modello organizzativo. L'IA rileva sotto due profili: può essere lo strumento attraverso cui si realizza un reato presupposto (frodi, reati informatici, market abuse, riciclaggio, e simili), e la sua adozione impone di aggiornare il Modello 231 e i compiti dell'Organismo di Vigilanza per mappare e presidiare i nuovi rischi. La nuova aggravante dell'art. 61 n. 11-decies può inoltre incidere sul disvalore del fatto presupposto.

L'IA generativa pone due problemi distinti di diritto d'autore, che vanno tenuti separati: cosa entra nel modello (l'addestramento) e cosa esce dal modello (l'output). A monte si discute della liceità dell'uso di opere protette per addestrare; a valle, della tutelabilità e dei rischi di violazione dei contenuti generati.

12.1 · Il lato input: l'addestramento

L'uso di opere protette per addestrare un modello può trovare copertura nelle eccezioni di text and data mining della direttiva (UE) 2019/790: l'art. 3 per la ricerca scientifica, l'art. 4 per usi più ampi ma con possibilità per il titolare di riservarsi i diritti (opt-out). L'AI Act salda questo profilo con gli obblighi GPAI (cap. 5): il fornitore deve adottare una policy per il rispetto del diritto d'autore dell'Unione, incluso il rispetto degli opt-out, e pubblicare una sintesi dei contenuti usati per l'addestramento.

12.2 · Il lato output: tutela e violazione

Nel diritto eurounitario e italiano la tutela d'autore presuppone una creazione intellettuale umana. Ne discende che un output puramente generato dalla macchina, senza un apporto creativo della persona, non è proteggibile come opera dell'ingegno; un contenuto assistito dall'IA può esserlo, purché vi sia un contributo creativo umano riconoscibile. Sul fronte opposto, l'output può violare diritti di terzi se riproduce in modo sostanziale opere protette presenti nei dati di addestramento, con conseguente responsabilità di chi lo diffonde.

12.3 · Il piano italiano

Il riferimento interno è la legge sul diritto d'autore (L. 633/1941). La L. 132/2025 è intervenuta anche su questo terreno, con previsioni che ribadiscono la necessità del contributo umano per la tutela delle opere create con l'ausilio dell'IA e con una delega in materia di estrazione di testo e dati. Il tema è oggetto di specifica trattazione dottrinale in materia di IA, diritto d'autore e responsabilità degli enti.

I deepfake meritano una trattazione autonoma perché, a differenza delle patologie tecniche della Parte V (allucinazioni, bias, sycophancy, che sono malfunzionamenti involontari del modello), rappresentano un uso deliberato e doloso dell'IA. Sono oggi la frontiera più visibile e dibattuta degli illeciti realizzati con sistemi generativi, e chiudono il quadro delle violazioni della Parte IV.

13.1 · Che cos'è un deepfake

Il Garante per la protezione dei dati personali definisce i deepfake come foto, video e audio creati con software di IA che, partendo da contenuti reali, riescono a ricreare in modo estremamente realistico le caratteristiche e i movimenti di un volto o di un corpo e a imitare fedelmente una voce. Le tre forme principali sono il face-swap video (sostituzione del volto), il voice cloning (clonazione vocale) e il cosiddetto deepnude (generazione di immagini intime false).

13.2 · Le finalità illecite

La pericolosità del deepfake sta nella combinazione di realismo e scalabilità. Le finalità illecite ricorrenti sono quattro:

• Frodi e truffe. Impersonificazione di dirigenti o autorità per indurre pagamenti (CEO/CFO fraud, truffe con voce clonata).
• Pornografia non consensuale. Immagini intime false (deepnude), con vittime spesso donne e minori; il caso più grave è il materiale pedopornografico sintetico.
• Disinformazione e manipolazione. Falsi audio/video di personaggi pubblici per finalità politiche o di manipolazione dei mercati.
• Furto d'identità e danno reputazionale. Uso non autorizzato di volto e voce per screditare, ricattare o sostituirsi alla persona.

13.3 · La rete di tutele applicabili

Non esiste una singola norma "anti-deepfake": il fenomeno è presidiato da una rete di discipline che si sommano. La figura le mappa per finalità.

13.4 · I presidi normativi in dettaglio

• AI Act (trasparenza). L'art. 50 impone di marcare in modo leggibile i contenuti sintetici e di rendere riconoscibili i deepfake. Il Digital Omnibus (diritto in fieri, cap. 4) aggiunge, dal 2 dicembre 2026, i divieti dell'art. 5 sui deepfake intimi non consensuali e sul materiale pedopornografico.
• Penale italiano. Il nuovo art. 612-quater c.p. (L. 132/2025) punisce con la reclusione da uno a cinque anni la diffusione non consensuale di contenuti falsificati con IA idonei a ingannare e produttivi di danno; opera inoltre l'aggravante comune dell'art. 61 n. 11-decies. A seconda della condotta concorrono le fattispecie classiche: truffa (art. 640), frode informatica (art. 640-ter), sostituzione di persona (art. 494), diffamazione (art. 595), diffusione illecita di immagini sessualmente esplicite (art. 612-ter), trattamento illecito di dati (art. 167 Codice privacy).
• Protezione dei dati. La creazione e diffusione di deepfake comporta quasi sempre un trattamento illecito di dati personali (immagine, voce, dati biometrici). Il Garante è intervenuto con provvedimenti di blocco verso piattaforme dedicate.
• Responsabilità civile. La vittima può agire per il risarcimento del danno (art. 2043 c.c.), a tutela dell'identità personale e del diritto all'immagine (art. 10 c.c.; artt. 96-97 L. 633/1941), oltre alla rimozione del contenuto.

13.5 · Casi reali documentati

13.6 · Tutele e rimedi pratici

Sul piano operativo, alla vittima e al consulente si offrono più leve, da attivare rapidamente per limitare la diffusione: querela per i reati applicabili; segnalazione e reclamo al Garante con richiesta di blocco/rimozione; diffida e richiesta di rimozione alle piattaforme (anche ex Digital Services Act); azione civile per il risarcimento e l'inibitoria; conservazione delle prove digitali (acquisizione forense del contenuto e dei metadati). Sul versante preventivo assumono rilievo le tecniche di tracciamento della provenienza dei contenuti (watermarking e standard di content provenance) e la verifica delle fonti.

L'allucinazione è la patologia più nota e, per il giurista, la più insidiosa: il modello produce un output coerente, fluente e plausibile, ma falso o inventato. Non è un errore occasionale, ma una proprietà strutturale della generazione probabilistica (cap. 2): il modello predice la sequenza di parole più probabile, non la verità.

14.1 · Perché accadono

Un modello linguistico non "consulta" una base di conoscenza verificata: genera testo statisticamente plausibile in base a ciò che ha appreso. Quando l'informazione richiesta è assente, ambigua o assente dai dati di addestramento, il modello tende comunque a produrre una risposta, "riempiendo i vuoti" con contenuti verosimili ma inesistenti (fenomeno detto anche confabulazione). Valori alti di temperatura, l'assenza di ancoraggio a fonti (grounding) e la richiesta di dettagli molto specifici aumentano il rischio.

14.2 · Implicazioni giuridiche

• Esattezza dei dati (GDPR). Un output errato riferito a una persona può integrare un trattamento di dati inesatti, in violazione del principio di esattezza (art. 5 GDPR) e fonte di responsabilità.
• Responsabilità professionale. L'avvocato che deposita atti basati su precedenti inventati viola i doveri di diligenza e verità, con conseguenze deontologiche e processuali (in linea con le best practice CNF/CCBE, cap. 1).
• Diffamazione e danno reputazionale. Un'allucinazione che attribuisca falsamente fatti a una persona può ledere onore e reputazione.
• Accuratezza (AI Act). Per i sistemi ad alto rischio l'art. 15 impone livelli adeguati di accuratezza e robustezza.

14.3 · Casi reali documentati

14.4 · Mitigazione

Le contromisure efficaci combinano organizzazione e tecnica: verifica umana sistematica di ogni citazione e dato; impiego di strumenti con ancoraggio a fonti (RAG) e con citazioni tracciabili; uso di banche dati giuridiche affidabili anziché modelli generalisti per la ricerca delle fonti; richiesta al modello di indicare i riferimenti verificabili; e una policy interna che vieti il deposito di contenuti non controllati.

Il bias è la distorsione sistematica per cui un sistema di IA produce esiti che svantaggiano, in modo ingiustificato, determinati gruppi di persone. A differenza dell'allucinazione (errore puntuale), il bias è uno scostamento strutturale e ripetuto, spesso invisibile finché non se ne osservano gli effetti aggregati.

15.1 · Da dove nasce

La radice principale è nei dati di addestramento: se riflettono discriminazioni storiche o non rappresentano adeguatamente alcuni gruppi, il modello le apprende e le riproduce, talvolta amplificandole. Si aggiungono il bias algoritmico (scelte di progettazione) e i circuiti di retroazione (gli output del sistema influenzano i dati futuri, consolidando la distorsione).

15.2 · Implicazioni giuridiche

• Divieto di discriminazione. Carta dei diritti fondamentali UE (art. 21), direttive antidiscriminazione, art. 3 Cost. e Statuto dei lavoratori: un esito discriminatorio espone a responsabilità a prescindere dall'intento.
• GDPR. Principio di correttezza (art. 5) e disciplina delle decisioni automatizzate (art. 22); il trattamento che produce effetti discriminatori è illecito.
• AI Act. La governance dei dati (art. 10) impone dataset pertinenti, rappresentativi e privi, per quanto possibile, di errori; molti ambiti a rischio bias (occupazione, credito) sono classificati ad alto rischio (cap. 4).

15.3 · Casi reali documentati

15.4 · Mitigazione

Le misure chiave: dataset rappresentativi e documentati; test di equità (fairness testing) periodici e audit indipendenti; valutazione d'impatto (DPIA e FRIA, cap. 8); sorveglianza umana effettiva sulle decisioni; trasparenza verso gli interessati e meccanismi di contestazione. La conformità all'art. 10 AI Act è, al tempo stesso, il principale presidio tecnico-giuridico contro il bias.

La sycophancy (servilismo o adulazione) è la tendenza del modello a dire all'utente ciò che vuole sentirsi dire: concordare, compiacere, assecondare la tesi proposta, a scapito dell'accuratezza. È particolarmente subdola perché non si manifesta come errore evidente, ma come conferma rassicurante.

16.1 · L'origine tecnica

La causa principale risiede nell'addestramento per rinforzo da feedback umano (RLHF, cap. 2): se il modello viene premiato sulla base del gradimento degli utenti, può imparare che l'accondiscendenza genera valutazioni positive. Il modello ottimizza così la soddisfazione dell'utente più che la correttezza della risposta.

16.2 · Caso reale documentato

16.3 · Altre patologie da conoscere

• Automation bias / overreliance. Eccessivo affidamento dell'utente sull'output, con riduzione del controllo critico.
• Prompt injection. Istruzioni malevole nascoste nei dati in input che dirottano il comportamento del modello (rischio di sicurezza, cap. 9).
• Data leakage. Rischio che dati riservati immessi nei prompt siano esposti o riutilizzati: nodo critico per il segreto professionale (cap. 1).
• Model collapse. Degrado del modello addestrato prevalentemente su contenuti a loro volta generati da IA.

16.4 · Quadro di sintesi della Parte V

L'ultimo capitolo traduce la guida in strumenti operativi: un flusso di valutazione, una checklist, i template di registro e policy, le clausole contrattuali essenziali, un glossario e l'indice consolidato delle fonti. È pensato per essere usato accanto a un caso concreto.

17.1 · Il flusso di valutazione di conformità

Davanti a qualsiasi impiego di IA, conviene seguire una sequenza ordinata di domande. Ogni risposta indirizza verso obblighi diversi.

17.2 · Checklist operativa

Una traccia minima da percorrere per ogni sistema di IA adottato:

• Mappatura. Identificare il sistema, il fornitore e la funzione svolta.
• Qualificazione dei ruoli. Stabilire la qualifica AI Act (provider/deployer) e GDPR (titolare/responsabile), che non coincidono (cap. 7).
• Classificazione del rischio. Collocare il sistema nella piramide (cap. 4) e documentare la valutazione.
• Base giuridica e principi. Verificare base giuridica, minimizzazione, trasparenza, esattezza, conservazione (cap. 7).
• DPIA / FRIA. Svolgerle quando dovute, in un unico dossier coordinato (cap. 8).
• Misure tecniche e organizzative. Sorveglianza umana, sicurezza (art. 32 GDPR, CRA), logging, presidi contro allucinazioni e bias (Parte V).
• Trasparenza. Informative agli interessati ed etichettatura dei contenuti generati (art. 50).
• Contratti. Verificare le clausole con il fornitore (§ 17.5).
• Formazione. Garantire l'AI literacy del personale (art. 4).
• Monitoraggio. Riesame periodico, gestione incidenti, aggiornamento della documentazione.

17.3 · Template — Registro dei sistemi di IA

Strumento di accountability (e tassello di un Modello 231 aggiornato, cap. 11). Struttura minima consigliata:

17.4 · Modello di AI policy interna — elementi essenziali

Una policy d'uso efficace dovrebbe contenere: finalità e ambito di applicazione; principi (legalità, trasparenza, supervisione umana, antropocentrismo); usi consentiti e usi vietati dei sistemi di IA; regole sulla riservatezza e sul segreto professionale (divieto di immettere dati riservati in strumenti non sicuri); obbligo di verifica degli output prima di ogni utilizzo; ruoli e responsabilità; programma di formazione (art. 4 AI Act); procedura di gestione degli incidenti; e cadenza di aggiornamento della policy.

17.5 · Clausole contrattuali con i fornitori

Nei contratti con i fornitori di sistemi o modelli di IA è opportuno presidiare almeno: la qualificazione dei ruoli (AI Act e GDPR) e l'allocazione degli obblighi; gli impegni di conformità ad AI Act, GDPR e CRA; la disciplina dell'uso dei dati per l'addestramento (e il rispetto degli opt-out); la titolarità e le garanzie sugli output e sulla proprietà intellettuale (cap. 12); le misure di sicurezza e gli obblighi di notifica degli incidenti e delle modifiche al modello; i diritti di audit; il regime di responsabilità e manleva; la gestione dei sub-fornitori.

17.6 · Glossario essenziale

17.7 · Indice consolidato delle fonti

La conformità non si esaurisce nei singoli adempimenti: richiede una struttura organizzativa che assegni ruoli, responsabilità e flussi di controllo. Senza un assetto di governance, gli obblighi visti nei capitoli precedenti restano adempimenti isolati ed esposti a fallimenti sistemici.

18.1 · Il framework di AI governance

Un framework efficace integra quattro componenti: una policy d'uso dell'IA (cap. 17), una mappatura dei ruoli e delle responsabilità, processi lungo l'intero ciclo di vita dei sistemi (selezione, valutazione del rischio, monitoraggio, dismissione) e meccanismi di accountability (documentazione e reporting). In chiave operativa conviene non creare un silo separato, ma innestare la governance dell'IA sulle strutture esistenti di privacy, sicurezza e compliance 231.

18.2 · Le tre linee di difesa

Il modello delle "tre linee di difesa", consolidato nel risk management, si applica utilmente all'IA distribuendo i controlli su livelli distinti e indipendenti.

18.3 · Il ruolo del board e del management

L'accountability apicale non è delegabile. L'AI Act responsabilizza il deployer sull'organizzazione della sorveglianza umana (art. 26) e la NIS2 chiama direttamente gli organi di gestione a rispondere delle misure di cybersicurezza. Spetta al vertice definire la propensione al rischio, allocare risorse e competenze, e assicurare la formazione (AI literacy, art. 4). È il "tone at the top" senza il quale ogni policy resta lettera morta.

18.4 · Il raccordo con il Modello 231

Per gli enti, la governance dell'IA va integrata nel Modello organizzativo 231 (cap. 11): i rischi connessi all'uso dell'IA (frodi, reati informatici, trattamenti illeciti) vanno mappati tra i rischi-reato, i presidi devono entrare nel Modello e l'Organismo di Vigilanza deve ricevere flussi informativi dedicati. Questo collegamento è, al tempo stesso, presidio di compliance e argomento difensivo (cap. 11).

La maggior parte delle organizzazioni non sviluppa l'IA, ma la acquista o la integra da terzi. Il rischio si sposta così sulla catena di fornitura: la conformità del deployer dipende in larga misura da scelte e informazioni del fornitore. Gestire i fornitori è perciò parte integrante della governance.

19.1 · Due diligence del fornitore

Prima dell'adozione vanno verificati: la conformità del sistema/modello ad AI Act, GDPR e CRA; la documentazione resa disponibile (per i GPAI, le informazioni ai fornitori a valle ex art. 53, cap. 5); le certificazioni e gli standard adottati (cap. 20); la solidità e la reputazione del fornitore; la mappa dei sub-fornitori (e sub-responsabili ex art. 28 GDPR).

19.2 · Vendor risk assessment

Conviene classificare i fornitori per livello di rischio (in funzione della classe del sistema, dei dati trattati e della criticità del processo) e raccogliere evidenze proporzionate: questionari di sicurezza, certificazioni (es. ISO/IEC 27001 e 42001), report di audit, diritti di verifica. Il livello di due diligence va graduato sul rischio.

19.3 · Le clausole contrattuali chiave

Riprendendo il § 17.5, nei contratti vanno presidiati: qualificazione dei ruoli e allocazione degli obblighi; impegni di conformità; uso dei dati per l'addestramento e rispetto degli opt-out; titolarità e garanzie sugli output (cap. 12); sicurezza e notifiche di incidenti e di modifiche al modello; diritti di audit; responsabilità e manleva; gestione dei sub-fornitori.

19.4 · Lock-in tecnologico ed exit strategy

Il rischio più sottovalutato è la dipendenza da un unico fornitore (lock-in): formati proprietari, dati e configurazioni non portabili, difficoltà di migrazione. Va governato fin dal contratto, prevedendo portabilità di dati e, ove possibile, dei modelli, reversibilità e continuità operativa, e una exit strategy documentata. Sul punto rileva anche il Data Act (cap. 9), che favorisce portabilità e cambio di fornitore.

Le norme fissano gli obiettivi; gli standard tecnici dicono come raggiungerli. Per chi si occupa di AI governance, il raccordo con gli standard non è più opzionale: è il linguaggio operativo della conformità e, nel sistema dell'AI Act, una via privilegiata per dimostrarla.

20.1 · Standard armonizzati e presunzione di conformità

L'AI Act (art. 40) àncora la conformità agli standard armonizzati europei: un sistema ad alto rischio conforme a uno standard armonizzato (elaborato da CEN-CENELEC su mandato della Commissione e pubblicato in GUUE) beneficia di una presunzione di conformità ai requisiti corrispondenti. È il meccanismo che rende la compliance verificabile e ne riduce l'incertezza; gli standard sono in via di finalizzazione (diritto in evoluzione).

20.2 · Gli standard di riferimento

20.3 · Come si incastrano con l'AI Act

I tre piani sono complementari: ISO/IEC 42001 fornisce l'impianto gestionale (utile a strutturare la governance del cap. 18), ISO/IEC 23894 e il NIST AI RMF offrono la metodologia di gestione del rischio (a supporto del sistema di gestione dei rischi dell'art. 9 e di DPIA/FRIA), mentre gli standard armonizzati dell'AI Act offrono la presunzione di conformità. In chiave operativa, adottare uno standard certificabile come ISO/IEC 42001 è oggi il modo più solido per dimostrare diligenza e maturità organizzativa, anche in funzione difensiva (231) e contrattuale (vendor, cap. 19).