Procedure obbligatorie e buone prassi nella conformità al GDPR e alla normativa sull'intelligenza artificiale: una guida sistematica per il titolare e il responsabile del trattamento

Il principio di accountability come fondamento interpretativo del sistema documentale

Prima di procedere alla disamina delle singole procedure, occorre richiamare il principio su cui l'intero sistema documentale del Regolamento (UE) 2016/679, di seguito "GDPR" o "Regolamento", si fonda: il principio di responsabilizzazione (accountability), sancito dall'articolo 5, paragrafo 2, il quale stabilisce che «il titolare del trattamento è competente per il rispetto del paragrafo 1 e in grado di comprovarlo». Il comprovare implica documentare, tracciare, argomentare le proprie scelte. Il GDPR non si limita a prescrivere obblighi di condotta, ma impone al titolare del trattamento l'onere della prova della propria conformità rispetto all'intera catena di adempimenti che il Regolamento prevede.

Questa architettura normativa rende la distinzione tra obbligatorio e raccomandato più articolata di quanto sembri a una prima lettura. Talune procedure non sono letteralmente previste da una singola norma come "obbligo di redigere un documento nominato", ma la loro assenza renderebbe impossibile dare prova del rispetto di obblighi che il Regolamento pone espressamente in capo al titolare. Altre procedure, invece, sono esplicitamente prescritte da specifiche disposizioni con indicazione del contenuto minimo e delle conseguenze sanzionatorie in caso di inadempimento. La trattazione che segue distingue queste due categorie, analizzando ciascuna nel suo contesto normativo, e integra, nella sezione conclusiva, le principali procedure richieste dalla normativa sull'intelligenza artificiale, il Regolamento (UE) 2024/1689 (AI Act) e la legge italiana 23 settembre 2025, n. 132, con le quali il quadro di conformità delle organizzazioni che adottano sistemi di IA deve necessariamente confrontarsi.

Le procedure e la documentazione obbligatorie ai sensi del GDPR

Il Registro delle attività di trattamento (articolo 30)

Il registro delle attività di trattamento costituisce il documento fondamentale dell'approccio accountability-centrico del GDPR e il primo pilastro documentale obbligatorio. L'articolo 30 impone a ogni titolare del trattamento di tenere «un registro di tutte le attività di trattamento svolte sotto la propria responsabilità», con un correlato obbligo speculare in capo al responsabile del trattamento, il cui registro presenta tuttavia un contenuto parzialmente diverso.

Il registro del titolare deve contenere:

• il nome e i dati di contatto del titolare e, ove applicabile, del contitolare, del rappresentante e del Responsabile della Protezione dei Dati;
• le finalità del trattamento;
• una descrizione delle categorie di interessati e delle categorie di dati personali;
• le categorie di destinatari, compresi quelli di paesi terzi od organizzazioni internazionali;
• ove applicabili, i trasferimenti verso paesi terzi e le garanzie adottate;
• ove possibile, i termini ultimi previsti per la cancellazione;
• ove possibile, una descrizione generale delle misure di sicurezza di cui all'articolo 32.

Il registro del responsabile contiene invece:

• le categorie dei trattamenti effettuati per conto di ciascun titolare,
• le categorie di dati e di destinatari,
• l'indicazione dei trasferimenti verso paesi terzi,
• una descrizione generale delle misure di sicurezza adottate.

L'obbligo ammette un'esenzione formale, prevista dall'articolo 30, paragrafo 5, per le imprese o organizzazioni con meno di 250 dipendenti che trattano dati solo occasionalmente, senza rischi per i diritti e le libertà degli interessati, e senza trattamenti di categorie particolari di dati. Tuttavia il Gruppo di lavoro Articolo 29 ha chiarito con forza che questa esenzione ha portata assai limitata: un trattamento non è "occasionale" se viene condotto su base regolare nell'ambito della normale attività dell'organizzazione, come avviene per qualsiasi piccola impresa che tratti dati relativi ai propri dipendenti. Come evidenziato dal Garante italiano, il registro costituisce «il primo passo verso la accountability in quanto consente di valutare i rischi sui diritti e la libertà delle persone e di attuare misure tecniche e organizzative adeguate».

Le informative agli interessati (articoli 13 e 14)

Gli articoli 13 e 14 del GDPR impongono al titolare del trattamento di fornire all'interessato, al momento della raccolta dei dati o entro un termine ragionevole nel caso in cui i dati non siano stati raccolti direttamente presso di lui, un insieme preciso e tassativamente elencato di informazioni. Si tratta di un obbligo di trasparenza attiva che incombe sul titolare senza che l'interessato debba avanzare alcuna richiesta, e che si traduce nella redazione delle cosiddette informative privacy o privacy notice.

L'informativa deve contenere almeno:

• l'identità e i dati di contatto del titolare e dell'eventuale RPD;
• le finalità e la base giuridica del trattamento;
• gli eventuali destinatari dei dati;
• i trasferimenti verso paesi terzi con le relative garanzie;
• il periodo di conservazione;
• i diritti degli interessati (accesso, rettifica, cancellazione, limitazione, portabilità, opposizione);
• il diritto di proporre reclamo all'autorità di controllo;
• ove possibile, il trattamento si basi sul legittimo interesse, l'indicazione di tale interesse legittimo.

La redazione delle informative non è una scelta discrezionale: la loro assenza o inadeguatezza configura una violazione dell'articolo 5, paragrafo 1, lettera a), e degli articoli 13 e 14, sanzionabile ai sensi dell'articolo 83, paragrafo 5, con sanzioni fino a 20.000.000 di euro o al 4% del fatturato mondiale annuo.

La documentazione del consenso (articolo 7, paragrafo 1)

Quando il titolare fonda il trattamento sulla base giuridica del consenso dell'interessato ai sensi dell'articolo 6, paragrafo 1, lettera a), ovvero sui consensi speciali previsti dall'articolo 9, paragrafo 2, lettera a), per le categorie speciali di dati, l'articolo 7, paragrafo 1, impone che il titolare sia «in grado di dimostrare che l'interessato ha prestato il proprio consenso al trattamento dei propri dati personali».

Questa disposizione non prescrive una specifica forma documentale, ma impone al titolare l'onere della prova: in assenza di un sistema di documentazione idoneo a dimostrare l'avvenuta acquisizione di un consenso libero, specifico, informato e inequivocabile, la base giuridica del trattamento risulta priva di fondamento. In pratica, ciò richiede la predisposizione e conservazione di meccanismi di raccolta e registrazione del consenso, tracce di log in ambiente digitale, moduli cartacei sottoscritti, consent management platform, che consentano di dimostrare, per ogni singolo interessato, quando, come e per quale finalità il consenso è stato prestato, nonché se e quando è stato revocato.

Il contratto o atto giuridico con il responsabile del trattamento (articolo 28)

Ogniqualvolta il titolare del trattamento si avvale di un soggetto esterno che tratta dati personali per suo conto, questo soggetto riveste il ruolo di responsabile del trattamento ai sensi dell'articolo 4, punto 8. 

L'articolo 28, paragrafo 3, impone che tale trattamento sia «disciplinato da un contratto o da altro atto giuridico», stipulato in forma scritta, anche in formato elettronico, con un contenuto minimo inderogabile.

Il contratto deve definire oggetto, durata, natura e finalità del trattamento,il tipo di dati personali e le categorie di interessati, gli obblighi e i diritti del titolare. 

Deve inoltre stabilire che il responsabile:

• tratti i dati soltanto su istruzione documentata del titolare;
• garantisca la riservatezza delle persone autorizzate;
• adotti tutte le misure di sicurezza ai sensi dell'articolo 32;
• si avvalga di sub-responsabili solo con consenso scritto del titolare;
• assista il titolare nell'adempimento degli obblighi verso gli interessati, nella DPIA e nella gestione dei data breach;
• restituisca o cancelli i dati al termine del contratto;
• metta a disposizione del titolare tutte le informazioni necessarie a dimostrare il rispetto degli obblighi del Regolamento. 

L'assenza del Data Processing Agreement espone sia il titolare sia il responsabile a responsabilità solidale verso gli interessati e a sanzioni amministrative.

La designazione formale del Responsabile della Protezione dei Dati (articolo 37)

L'articolo 37 del GDPR impone la designazione obbligatoria del RPD in tre categorie di casi:

• quando il trattamento è effettuato da un'autorità pubblica o da un organismo pubblico;
• quando le attività principali del titolare o del responsabile consistono in trattamenti che richiedono il monitoraggio regolare e sistematico degli interessati su larga scala;
• quando le attività principali consistono nel trattamento su larga scala di categorie particolari di dati o di dati relativi a condanne penali e a reati.

Quando ricorrono questi presupposti, la designazione deve essere formalizzata in un apposito atto di designazione o, in caso di RPD esterno, in un contratto di servizi. Come precisa il Garante italiano nelle proprie FAQ, «l'atto di designazione è parte costitutiva dell'adempimento» e deve individuare in maniera inequivocabile il soggetto che opererà come RPD, riportandone le generalità, i compiti e le funzioni, nonché le motivazioni che hanno indotto il titolare a selezionarlo, al fine di consentire la verifica del rispetto dei requisiti di cui all'articolo 37, paragrafo 5.

Una volta designato, il titolare è tenuto a pubblicare i dati di contatto del RPD sul proprio sito web e a comunicarli al Garante attraverso l'apposita procedura online.

Il RPD nominato su base volontaria da soggetti non obbligati soggiace alle medesime norme e condizioni del RPD nominato obbligatoriamente.

La Valutazione di Impatto sulla Protezione dei Dati e DPIA (articolo 35)

La DPIA è un documento obbligatorio che il titolare deve redigere prima di iniziare trattamenti che possano presentare un rischio elevato per i diritti e le libertà delle persone fisiche. L'articolo 35, paragrafo 1, pone l'obbligo in capo al titolare, e il paragrafo 3 elenca esemplificativamente le tipologie che ne richiedono sempre lo svolgimento: trattamento sistematico e su larga scala di dati sensibili; valutazione sistematica e globale di aspetti personali di persone fisiche compresa la profilazione; monitoraggio sistematico su larga scala di zone accessibili al pubblico.

Il Garante italiano ha adottato, sulla base dell'articolo 35, paragrafo 4, un elenco delle tipologie di trattamenti per i quali la DPIA è obbligatoria nel contesto nazionale.

La DPIA deve contenere:

• una descrizione sistematica dei trattamenti previsti e delle finalità;
• una valutazione della necessità e proporzionalità dei trattamenti;
• una valutazione dei rischi per i diritti e le libertà degli interessati;
• le misure previste per affrontare i rischi e dimostrare la conformità con il Regolamento.

Il mancato svolgimento della DPIA quando è obbligatoria espone il titolare a sanzioni fino a 10.000.000 di euro o al 2% del fatturato mondiale annuo. 

Qualora dalla DPIA emerga che il rischio residuale rimane elevato nonostante le misure adottate, il titolare è tenuto a consultare preventivamente l'autorità di controllo ai sensi dell'articolo 36 prima di procedere al trattamento.

La procedura di testing e verifica regolare delle misure di sicurezza (articolo 32, paragrafo 1, lettera d)

Questo adempimento merita una trattazione autonoma e attenta, poiché è spesso classificato come buona prassi anziché come obbligo normativo esplicito. L'articolo 32, paragrafo 1, lettera d), del GDPR prescrive che tra le misure di sicurezza obbligatorie che il titolare e il responsabile del trattamento devono adottare figuri espressamente «una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento».

Il testo normativo utilizza il termine procedura deliberatamente, e distingue tre livelli di controllo attraverso l'uso di tre verbi distinti:

• testare (verifica tecnica operativa, come penetration test, vulnerability assessment, verifiche funzionali dei sistemi di backup e di ripristino);
• verificare (accertamento dell'effettiva applicazione delle misure nei processi organizzativi, come il controllo che le policy di accesso siano concretamente rispettate dagli autorizzati);
• valutare (giudizio sull'efficacia complessiva delle misure rispetto al livello di rischio del trattamento e all'evoluzione del contesto tecnologico e delle minacce).

Il tutto deve avvenire con cadenza regolare, termine che il Regolamento non quantifica in un numero preciso di giorni o mesi, ma che va interpretato in relazione alla natura dei trattamenti, al livello di rischio e all'evoluzione delle minacce informatiche.

L'EDPB, nelle Guidelines on Data Protection by Design and by Default (v. 2.0), ha ulteriormente chiarito che i titolari «dovrebbero effettuare revisioni periodiche delle misure di sicurezza poste a presidio e tutela dei dati personali, nonché della procedura per la gestione delle violazioni dei dati», includendo tra gli elementi rilevanti: un sistema di gestione della sicurezza delle informazioni (Information Security Management System) che operi sulle politiche e procedure per la sicurezza; un'analisi del rischio continuativa; una security by design con test costanti; attività di manutenzione con revisione periodica di software, hardware e servizi; e una gestione del controllo degli accessi verificata nel tempo.

La mancanza di questa procedura, o la sua esistenza meramente formale senza effettiva attuazione, può integrare una violazione autonoma dell'articolo 32, sanzionabile ai sensi dell'articolo 83, paragrafo 4, con sanzioni fino a 10.000.000 di euro o al 2% del fatturato mondiale annuo, cumulabili con quelle irrogabili per eventuali violazioni conseguenti all'inadeguatezza delle misure.

Il Registro delle violazioni dei dati personali (articolo 33, paragrafo 5)

L'articolo 33, paragrafo 5, prescrive che «il titolare del trattamento documenta qualsiasi violazione dei dati personali, comprese le circostanze a essa relative, le sue conseguenze e i provvedimenti adottati per porvi rimedio». Questo obbligo di documentazione interna, il cosiddetto registro dei data breach, è incondizionato e prescinde dal fatto che la singola violazione debba o meno essere notificata all'autorità di controllo: anche le violazioni valutate come non notificabili, perché ritenute improbabilmente rischiose per i diritti degli interessati, devono essere documentate, unitamente alla motivazione di tale valutazione. La mancata corretta documentazione può comportare l'esercizio dei poteri correttivi dell'autorità di controllo e l'imposizione di sanzioni ai sensi dell'articolo 83.

La notifica della violazione all'autorità di controllo e la comunicazione agli interessati (articoli 33 e 34)

In continuità con il registro delle violazioni, la notifica al Garante è obbligatoria ogniqualvolta la violazione sia suscettibile di presentare un rischio per i diritti e le libertà delle persone fisiche.

Deve essere effettuata senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui il titolare ne viene a conoscenza, tramite la procedura telematica disponibile sul sito del Garante, come disposto dal Garante con il Provvedimento n. 209 del 27 maggio 2021.

Qualora la violazione presenti un rischio elevato, è altresì obbligatoria la comunicazione diretta agli interessati ai sensi dell'articolo 34, da effettuarsi senza ingiustificato ritardo con linguaggio semplice e chiaro.

La designazione degli autorizzati al trattamento (articolo 29 GDPR e articolo 2-quaterdecies del Codice Privacy)

L'articolo 29 del GDPR stabilisce che chiunque agisca sotto l'autorità del titolare o del responsabile e abbia accesso ai dati personali non possa trattarli se non su istruzione del titolare.

L'articolo 2-quaterdecies del Codice Privacy italiano attribuisce al titolare o al responsabile la facoltà di delegare specifiche attività di trattamento a persone fisiche autorizzate, operanti sotto la loro diretta autorità.

La designazione degli autorizzati deve avvenire mediante atto scritto che indichi in modo specifico i trattamenti consentiti, limitando l'accesso ai soli dati strettamente necessari per lo svolgimento delle mansioni assegnate. L'assenza di tale atto formale viola il principio di riservatezza, il principio di minimizzazione e il principio di sicurezza del trattamento di cui all'articolo 5.

L'accordo di contitolarità (articolo 26)

Quando due o più soggetti determinano congiuntamente le finalità e i mezzi del trattamento, l'articolo 26 impone che essi stabiliscano in modo trasparente, mediante un accordo interno, le rispettive responsabilità riguardo all'adempimento degli obblighi derivanti dal Regolamento, in particolare chi sia responsabile dell'adempimento degli obblighi verso gli interessati e come debba avvenire il coordinamento tra i contitolari.

I punti essenziali dell'accordo devono essere resi disponibili agli interessati.

Le procedure non obbligatorie ma raccomandate come buona prassi nel GDPR

La procedura interna strutturata di gestione del data breach

L'EDPB, nelle Guidelines 9/2022 on Personal Data Breach Notification, afferma che «sarebbe vantaggioso tanto per il titolare del trattamento quanto per il responsabile del trattamento disporre di una procedura di notifica documentata, che stabilisca la procedura da seguire una volta individuata una violazione, ivi compreso come contenere, gestire e porre rimedio all'incidente, valutare il rischio e notificare la violazione».

Tale procedura operativa, distinta dal registro delle violazioni che è invece obbligatorio, non è prescritta come documento formale autonomo, ma la sua assenza si riflette inevitabilmente sulla capacità di risposta dell'organizzazione e sulla possibilità di rispettare il termine di 72 ore. Una procedura ben strutturata dovrebbe definire ruoli e responsabilità interne, modalità di segnalazione interna, criteri di valutazione del rischio, modelli di notifica al Garante e procedure di comunicazione agli interessati.

La Valutazione del Legittimo Interesse e LIA (Legitimate Interest Assessment)

Quando il titolare fonda il trattamento sul legittimo interesse ai sensi dell'articolo 6, paragrafo 1, lettera f), è tenuto a dimostrare il bilanciamento tra il proprio interesse e i diritti e le libertà degli interessati. Il GDPR non prescrive esplicitamente un documento formale, ma la dimostrazione di tale bilanciamento, che può essere richiesta dall'autorità di controllo o contestata dagli interessati che esercitino il diritto di opposizione ai sensi dell'articolo 21, rende necessaria in pratica la tenuta di un documento scritto.

Una LIA strutturata include tipicamente:

• l'identificazione del legittimo interesse perseguito;

• la verifica della necessità del trattamento rispetto alle finalità;

• la valutazione dell'impatto sui diritti degli interessati e il bilanciamento complessivo.

Sebbene non obbligatoria come forma, la sua redazione è fortemente raccomandata come strumento di accountability preventiva. 

Come segnalato nelle linee guida WP260 sulla trasparenza, la prassi migliore prevede che il titolare possa fornire all'interessato informazioni tratte dal test di bilanciamento su richiesta: elemento che presuppone necessariamente l'esistenza di un documento scritto che tale test documenti.

La security policy e la documentazione dell'analisi del rischio ex articolo 32

L'articolo 32, nei suoi paragrafi 1 e 2, impone al titolare e al responsabile di mettere in atto misure tecniche e organizzative adeguate, tenuto conto dello stato dell'arte, dei costi e del profilo di rischio del trattamento. Tali misure, pseudonimizzazione, cifratura, capacità di ripristino, testing regolare, devono essere selezionate all'esito di una valutazione del rischio.

Il GDPR non prescrive formalmente la redazione di un documento denominato security policy o analisi del rischio, ma la dimostrazione di aver effettuato tale valutazione, richiesta dall'articolo 5, paragrafo 2, in sede ispettiva o in caso di data breach, rende di fatto necessaria la sua documentazione.

Una security policy formale che registri le scelte di sicurezza adottate, le ragioni che le giustificano e il piano di aggiornamento periodico è dunque una buona prassi di importanza capitale, che si integra con l'obbligo di testing regolare di cui alla lettera d) del medesimo articolo.

La procedura per la gestione dei diritti degli interessati (articoli 15-22)

Gli articoli da 15 a 22 del GDPR attribuiscono agli interessati diritti fondamentali, accesso, rettifica, cancellazione, limitazione, portabilità, opposizione il cui esercizio deve essere gestito entro termini precisi.

Il GDPR non prescrive formalmente una procedura interna, ma la complessità operativa, con il termine generale di risposta di un mese prorogabile di ulteriori due, rende la predisposizione di un processo documentato una buona prassi di rilevanza pratica fondamentale, specialmente per le organizzazioni che ricevono un numero significativo di richieste.

Tale procedura dovrebbe individuare i responsabili interni, i flussi di escalation verso il RPD, i modelli di risposta e i registri di tracciatura.

La Privacy by Design documentation (articolo 25)

L'articolo 25 del GDPR impone l'integrazione della protezione dei dati fin dalla progettazione di nuovi sistemi o processi (privacy by design) e la configurazione delle impostazioni predefinite in modo da trattare solo i dati necessari (privacy by default). Tali obblighi riguardano le misure operative, non un documento specifico.

Tuttavia, la documentazione delle valutazioni effettuate in fase progettuale, registrando come i principi di protezione dei dati siano stati integrati nelle scelte tecniche e organizzative, costituisce una buona prassi che dimostra la conformità all'articolo 25, rafforzando significativamente la posizione del titolare in sede di verifica.

Per i trattamenti a rischio elevato, questa documentazione si sovrappone frequentemente con gli obblighi documentali della DPIA.

Le attività di formazione del personale documentate

Sebbene il GDPR non prescriva formalmente la documentazione delle attività formative come adempimento autonomo, l'articolo 39, paragrafo 1, lettera b), assegna al RPD il compito di sorvegliare «la sensibilizzazione e la formazione del personale che partecipa ai trattamenti».

L'EDPB ha sottolineato che dimostrare che i dipendenti conoscono le procedure applicabili contribuisce a provare il rispetto del Regolamento.

La documentazione delle attività formative svolte, registri di partecipazione, materiali formativi, test di verifica dell'apprendimento, non è obbligatoria in senso stretto, ma rappresenta una prova di conformità molto apprezzata dalle autorità di controllo in sede ispettiva.

I codici di condotta e le certificazioni (articoli 40-43)

Gli articoli 40 e 42 prevedono rispettivamente l'adozione di codici di condotta e il conseguimento di certificazioni come meccanismi per dimostrare la conformità.

Si tratta di strumenti assolutamente facoltativi, ma di crescente rilevanza pratica: l'adesione a un codice di condotta approvato dall'autorità di controllo può essere considerata per attenuare sanzioni in caso di violazione (articolo 83, paragrafo 2, lettera j), e costituisce un elemento utile nell'ambito della DPIA ai sensi dell'articolo 35, paragrafo 8.

Le certificazioni rilasciate da organismi accreditati ai sensi dell'articolo 43 non riducono la responsabilità del titolare, ma possono dimostrare le misure tecniche e organizzative adottate.

Le procedure richieste dalla normativa sull'intelligenza artificiale

L'entrata in vigore del Regolamento (UE) 2024/1689 (AI Act) e la sua progressiva applicazione, con le prime disposizioni operative già in vigore dal febbraio 2025, unitamente alla legge italiana 23 settembre 2025, n. 132, recante «Disposizioni e deleghe al Governo in materia di intelligenza artificiale», introducono un ulteriore strato di obblighi documentali e procedurali per le organizzazioni che sviluppano, commercializzano o deplorano sistemi di IA.

La legge n. 132/2025 stabilisce espressamente all'articolo 1, comma 5, che «la presente legge non produce nuovi obblighi rispetto a quelli previsti dal regolamento (UE) 2024/1689 per i sistemi di intelligenza artificiale e per i modelli di intelligenza artificiale per finalità generali», configurandosi dunque come norma di principio e di coordinamento istituzionale che rimanda all'AI Act per il dettaglio degli obblighi tecnico-documentali.

La documentazione tecnica dei sistemi di IA ad alto rischio (articolo 11 dell'AI Act)

I fornitori (providers) di sistemi di IA ad alto rischio, elencati nell'Allegato III dell'AI Act, tra cui i sistemi di selezione e valutazione dei lavoratori, i sistemi di assegnazione di punteggio al credito, i sistemi di riconoscimento biometrico, sono tenuti a predisporre e aggiornare una documentazione tecnica completa del sistema prima della sua immissione sul mercato o messa in servizio.

Questa documentazione deve dimostrare che il sistema soddisfa i requisiti prescritti dall'AI Act e fornire alle autorità di vigilanza le informazioni necessarie per valutarne la conformità.

Deve contenere:

• la descrizione generale del sistema,
• le specifiche di progettazione e sviluppo,
• le informazioni sulla gestione del rischio,
• i dati di addestramento e validazione,
• i risultati delle prove di accuratezza, robustezza e sicurezza informatica,
• una descrizione del sistema di monitoraggio successivo all'immissione sul mercato.

Il sistema di gestione del rischio per i sistemi di IA ad alto rischio (articolo 9 dell'AI Act)

I fornitori di sistemi di IA ad alto rischio devono istituire, attuare, documentare e mantenere un sistema di gestione del rischio, che costituisce un processo iterativo continuo nel ciclo di vita del sistema.

Tale sistema deve identificare e analizzare i rischi noti e prevedibili associati al sistema di IA, valutare i rischi che possono emergere dai casi d'uso prevedibili, e adottare misure adeguate di gestione del rischio. Il sistema di gestione del rischio deve essere esaminato e aggiornato sistematicamente, e deve essere documentato.

Per i trattamenti di dati personali che si inseriscono nell'utilizzo di sistemi di IA ad alto rischio, questo obbligo si sovrappone e si coordina con la DPIA prevista dall'articolo 35 del GDPR, con il risultato che spesso un'unica procedura valutativa deve soddisfare i requisiti di entrambe le normative.

I log automatici e il mantenimento della documentazione delle attività (articolo 12 dell'AI Act)

I sistemi di IA ad alto rischio devono essere progettati e sviluppati con capacità di logging automatico, ossia di registrazione automatica degli eventi rilevanti («log») durante il loro funzionamento.

Questi log devono consentire, quanto meno, di stabilire il periodo di funzionamento del sistema, il database di riferimento rispetto al quale il sistema ha effettuato verifiche, i dati di ingresso che hanno prodotto risultati ed i risultati prodotti, nonché informazioni sulle persone fisiche coinvolte nella verifica.

Le registrazioni devono essere conservate per la durata prescritta dalla normativa applicabile e messe a disposizione delle autorità di vigilanza su richiesta.

La dichiarazione di conformità UE e la marcatura CE per i sistemi di IA ad alto rischio (articolo 47 dell'AI Act)

Prima che un sistema di IA ad alto rischio sia immesso sul mercato o messo in servizio, il fornitore deve redigere una dichiarazione di conformità UE che attesti che il sistema soddisfa tutti i requisiti applicabili dell'AI Act.

Questa dichiarazione, che deve essere tenuta a disposizione delle autorità nazionali per un periodo di dieci anni dopo la messa in servizio, si affianca all'obbligo di apposizione della marcatura CE e alla registrazione nel database europeo dei sistemi di IA ad alto rischio di cui all'articolo 71 del Regolamento.

Le istruzioni per l'uso destinate ai deployer (articolo 13 dell'AI Act)

I fornitori di sistemi di IA ad alto rischio devono fornire ai deployer (coloro che utilizzano il sistema nell'ambito della propria attività professionale) istruzioni per l'uso chiare, complete e comprensibili, che consentano ai deployer di utilizzare il sistema in modo informato e conforme.

Queste istruzioni devono contenere l'identità del fornitore, le caratteristiche, le capacità e i limiti di prestazione del sistema, le eventuali circostanze nelle quali il sistema potrebbe produrre rischi per la salute, la sicurezza o i diritti fondamentali, le misure di supervisione umana richieste, le istruzioni per il corretto utilizzo e le azioni che i deployer devono intraprendere in caso di malfunzionamento. Questo obbligo interagisce direttamente con gli obblighi di trasparenza verso gli interessati previsti dal GDPR e con il diritto all'informazione sull'utilizzo di sistemi di IA sancito dall'articolo 7, comma 3, della legge n. 132/2025 in ambito sanitario.

Le misure di sorveglianza umana e la designazione delle responsabilità per i deployer (articoli 26 e 29 dell'AI Act)

I deployer di sistemi di IA ad alto rischio sono tenuti, tra l'altro, a: adottare misure tecniche e organizzative adeguate per garantire che i sistemi siano utilizzati conformemente alle istruzioni per l'uso; assegnare la sorveglianza umana a persone fisiche competenti e con l'autorità e le risorse necessarie; garantire che i dati di ingresso siano pertinenti in relazione allo scopo previsto.

Quando il deployer è anche un datore di lavoro, come tipicamente avviene per i sistemi di IA impiegati nella gestione del rapporto di lavoro, disciplinati dall'articolo 11 della legge n. 132/2025, deve informare i lavoratori dell'utilizzo di sistemi di IA ai sensi dell'articolo 1-bis del decreto legislativo n. 152/1997 e, ove necessario, procedere a una consultazione sindacale.

La documentazione delle misure adottate e delle responsabilità assegnate costituisce un obbligo implicito di accountability che si affianca agli obblighi espliciti dell'AI Act.

La DPIA integrata per i sistemi di IA che trattano dati personali

Quando un sistema di IA ad alto rischio tratta dati personali, il deployer che sia anche titolare del trattamento è tenuto a valutare se il trattamento possa presentare un rischio elevato ai sensi dell'articolo 35 del GDPR, con conseguente obbligo di DPIA.

Il Garante italiano ha incluso in via generale tra le tipologie di trattamenti che richiedono la DPIA il trattamento sistematico e su larga scala di dati attraverso sistemi automatizzati e, in particolare, il trattamento che utilizzi sistemi di IA per il monitoraggio e la valutazione delle persone.

L'EDPB ha chiarito che la DPIA per sistemi di IA deve valutare non solo i rischi per la protezione dei dati personali in senso stretto, ma anche i rischi per i diritti e le libertà degli interessati derivanti dalla logica algoritmica e dall'automazione delle decisioni. In questo quadro, la DPIA ex articolo 35 del GDPR e il sistema di gestione del rischio ex articolo 9 dell'AI Act devono essere concepiti come procedure complementari e, ove possibile, integrate in un unico processo valutativo.

Le buone prassi raccomandate per la governance dell'IA: la AI policy interna

La legge n. 132/2025, che all'articolo 3, comma 1, enuncia i principi di trasparenza, proporzionalità, sicurezza, protezione dei dati personali, riservatezza, accuratezza, non discriminazione, parità dei sessi e sostenibilità come criteri guida per lo sviluppo e l'utilizzo di sistemi di IA, non prescrive formalmente la redazione di una AI policy interna da parte delle organizzazioni che adottano sistemi di IA.

Tuttavia, la predisposizione di tale documento, che definisca le finalità per le quali il sistema di IA viene adottato, i criteri di selezione dei fornitori, i meccanismi di supervisione umana, le procedure di aggiornamento e monitoraggio, le responsabilità interne e i canali di segnalazione in caso di malfunzionamento, costituisce una buona prassi di governance fortemente raccomandata sia ai fini della conformità integrata GDPR-AI Act sia ai fini della tutela dei diritti dei lavoratori e degli interessati.

Orientamento operativo conclusivo

La mappa degli adempimenti documentali che emerge da questa analisi integrata rivela un sistema di conformità in cui le procedure obbligatorie del GDPR, registro delle attività di trattamento, informative, documentazione del consenso, contratti con i responsabili, designazione del RPD, DPIA, procedura di testing ex articolo 32 lettera d), registro delle violazioni, si affiancano alle obbligazioni documentali dell'AI Act per i soggetti che sviluppano o utilizzano sistemi di intelligenza artificiale, creando un corpus di adempimenti che richiede una gestione integrata e coerente.

La distinzione tra obbligatorio e raccomandato nel sistema GDPR non va intesa come una cesura netta e definitiva. Il principio di accountability che attraversa il Regolamento fa sì che la linea di confine tenda ad assottigliarsi nel tempo: una buona prassi documentale, inizialmente facoltativa, diviene de facto necessaria nel momento in cui un titolare deve difendere la propria conformità di fronte all'autorità di controllo o in giudizio. In questo senso, le procedure obbligatorie garantiscono la conformità minima legale, mentre le buone pratiche costruiscono la resilienza organizzativa e la capacità di dimostrazione della conformità in ogni circostanza.

La convergenza di GDPR e AI Act produce inoltre sinergie documentali che un'organizzazione avveduta dovrebbe sfruttare:

• la DPIA e il sistema di gestione del rischio dell'AI Act possono essere condotti in modo integrato;
• la procedura di testing ex articolo 32, lettera d), del GDPR e il monitoraggio post-mercato previsto dall'AI Act possono essere coordinati in un unico processo;
• le informative agli interessati devono dare conto sia delle modalità di trattamento dei dati personali sia del fatto che vengono utilizzati sistemi di IA nelle decisioni che li riguardano.

Costruire un sistema di conformità integrato, piuttosto che gestire i due framework come silos separati, è non solo la scelta organizzativamente più efficiente, ma la risposta più coerente alla logica di protezione dei diritti fondamentali che anima entrambe le normative.