L’adozione di sistemi di intelligenza artificiale all’interno dei processi aziendali ha reso evidente un problema che i modelli di compliance tradizionali, pensati per flussi di dati statici e prevedibili, non erano attrezzati a governare: la natura dinamica, auto-apprendente e spesso opaca degli algoritmi di machine learning. Un sistema di raccomandazione, un modello di scoring creditizio o un motore di screening curriculare non processano dati personali secondo logiche documentabili una tantum, bensì secondo pattern statistici che evolvono nel tempo, che possono incorporare bias latenti nei dataset di addestramento e che restituiscono output non pienamente spiegabili nemmeno a chi li ha progettati.
In questo scenario, il Regolamento (UE) 2016/679, il GDPR, resta il perimetro normativo cogente per qualsiasi trattamento di dati personali effettuato tramite sistemi di IA, ma da solo non fornisce gli strumenti organizzativi per gestire rischi che sono specifici della tecnologia algoritmica, quali il drift del modello, la robustezza, la qualità e la rappresentatività dei dataset, la tracciabilità delle decisioni automatizzate e la gestione del ciclo di vita del modello stesso. È proprio in questo spazio che si inserisce ISO/IEC 42001:2023, pubblicata da ISO/IEC nel dicembre 2023 e riconosciuta come il primo standard internazionale certificabile per un sistema di gestione dell’intelligenza artificiale, denominato AIMS, acronimo di AI Management System.
Indice degli argomenti
AIMS ISO 42001 GDPR: il quadro normativo di riferimento
Lo scopo di questo articolo è illustrare come costruire un AIMS ISO 42001 che non sia un adempimento parallelo al programma di data protection già in essere, bensì un’estensione strutturata di quest’ultimo, capace di assorbire anche gli obblighi emergenti dal Regolamento (UE) 2024/1689, il cosiddetto AI Act. Prima di affrontare la metodologia costruttiva è indispensabile fissare le coordinate normative, particolarmente mobili in questa fase storica. Il GDPR resta la base giuridica primaria per ogni trattamento di dati personali nel ciclo di vita di un sistema di IA, dalla raccolta dei dataset di addestramento fino alla conservazione degli output: i principi di liceità, minimizzazione, limitazione della finalità ed esattezza sanciti dall’articolo 5, la base giuridica di cui all’articolo 6, gli obblighi informativi degli articoli 13 e 14, la disciplina delle decisioni automatizzate dell’articolo 22 e l’obbligo di valutazione d’impatto dell’articolo 35 si applicano integralmente a qualunque sistema algoritmico che tratti dati personali.
Il Regolamento (UE) 2024/1689 introduce invece obblighi specifici per fornitori e deployer di sistemi di IA classificati come ad alto rischio secondo l’Allegato III, riguardanti la gestione del rischio ai sensi dell’articolo 9, la data governance ai sensi dell’articolo 10, la sorveglianza umana ai sensi dell’articolo 14, oltre a trasparenza, documentazione tecnica e registrazione in una banca dati europea. È opportuno segnalare, per correttezza tecnica e per l’attualità del tema, che il calendario attuativo è stato di recente modificato: il cosiddetto Digital Omnibus sull’intelligenza artificiale, concordato in via provvisoria il 7 maggio 2026 e formalmente adottato da Parlamento e Consiglio nel giugno 2026, ha posticipato l’applicazione degli obblighi per i sistemi ad alto rischio autonomi dell’Allegato III dal 2 agosto 2026 al 2 dicembre 2027, e per i sistemi integrati in prodotti regolamentati dall’Allegato I dal 2 agosto 2027 al 2 agosto 2028, senza tuttavia intaccare le scadenze già vigenti relative ai divieti dell’articolo 5, in vigore dal 2 febbraio 2025, e agli obblighi per i modelli di IA per finalità generali, in vigore dal 2 agosto 2025. Chi oggi predispone un piano di adeguamento deve quindi calibrare le priorità temporali su questo nuovo calendario, senza tuttavia interrompere le attività di gap analysis e di data governance, che restano comunque presupposto di ogni futura conformità e che, in ogni caso, incidono già oggi sugli obblighi GDPR pienamente vigenti.
ISO/IEC 42001:2023, dal canto suo, non è un obbligo di legge ma uno standard volontario e certificabile che adotta la Harmonized Structure comune alle norme ISO di sistema di gestione, allineata a ISO/IEC 27001, a ISO 9001 e a ISO/IEC 27701, il che ne consente un’integrazione naturale con i sistemi di gestione per la sicurezza delle informazioni e con i sistemi di gestione della privacy eventualmente già implementati. È proprio questa compatibilità strutturale la leva operativa più efficace per un’organizzazione che voglia costruire un AIMS senza ripartire da zero.
La struttura di ISO/IEC 42001:2023: clausole 4-10 e Annex A
Come ogni standard a Harmonized Structure, ISO 42001 si articola in requisiti di sistema, contenuti nelle clausole da 4 a 10 e obbligatori ai fini certificativi, e in controlli operativi elencati nell’Annex A, la cui applicabilità è determinata da un esercizio di risk assessment documentato nella Dichiarazione di Applicabilità, la Statement of Applicability.
La clausola 4, “Contesto dell’organizzazione”, si articola nei punti 4.1, relativo alla comprensione dei fattori interni ed esterni rilevanti, 4.2, dedicato all’identificazione delle parti interessate e delle loro aspettative, 4.3, che richiede la determinazione del perimetro dell’AIMS, e 4.4, che impone la formale istituzione del sistema di gestione. Per un’organizzazione già soggetta al GDPR, questa fase va condotta in parallelo alla mappatura dei trattamenti già presente nel Registro ex articolo 30, individuando quali sistemi di IA insistono su dati personali e con quale ruolo, di titolare, contitolare o responsabile del trattamento.
La clausola 5, “Leadership”, si compone dei punti 5.1 sulla leadership e l’impegno dell’alta direzione, 5.2 sull’adozione formale di una AI Policy e 5.3 sull’assegnazione di ruoli, responsabilità e autorità all’interno dell’organizzazione, tipicamente affidati a un AI Governance Committee o a un AI Officer, che deve operare in stretto raccordo funzionale con il Responsabile della protezione dei dati. È proprio in questo punto della norma che occorre esplicitare, nella policy, il rapporto gerarchico tra AI Officer e DPO, per evitare sovrapposizioni o conflitti di competenza sulle valutazioni di impatto.
La clausola 6, “Pianificazione”, è il cuore tecnico dello standard e il punto di massima convergenza con il GDPR. Il punto 6.1.1 richiede un approccio generale alla gestione di rischi e opportunità; il punto 6.1.2, l’AI risk assessment, impone un processo strutturato di identificazione, analisi e valutazione dei rischi legati all’intelligenza artificiale, quali il bias, la mancanza di spiegabilità, la robustezza e la sicurezza; il punto 6.1.3, l’AI risk treatment, richiede la selezione di misure di trattamento del rischio, confrontando le scelte organizzative con i controlli di riferimento dell’Annex A e documentando nella Statement of Applicability ogni esclusione, come previsto dalla relativa nota esplicativa; il punto 6.1.4, l’AI system impact assessment, richiede una valutazione degli impatti prodotti dai singoli sistemi di IA su individui, gruppi e società. Seguono il punto 6.2, dedicato alla definizione di obiettivi dell’AIMS misurabili, e il punto 6.3, relativo alla pianificazione delle modifiche al sistema di gestione. Il rischio privacy va trattato come sottoinsieme del rischio IA complessivo disciplinato da questa clausola, e non come un processo separato e scollegato.
La clausola 7, “Supporto”, copre ai punti 7.1 e 7.2 le risorse e le competenze, incluse quelle in materia di IA responsabile e di data protection, al punto 7.3 la consapevolezza del personale, al punto 7.4 la comunicazione interna ed esterna e al punto 7.5 la gestione dell’informazione documentata. La formazione continua di sviluppatori, data scientist e personale di business sulle implicazioni privacy dei modelli è un requisito che un audit di certificazione verifica sempre con particolare attenzione.
La clausola 8, “Attività operative”, disciplina ai punti 8.1 e 8.2 la pianificazione e il controllo operativo del ciclo di vita dei sistemi di IA, al punto 8.3 l’AI system impact assessment nella sua declinazione operativa e al punto 8.4 la gestione dei fornitori terzi, inclusi i fornitori di modelli fondazionali. È qui che trovano collocazione naturale la data governance sui dataset di addestramento, validazione e test, nonché le procedure di sorveglianza umana sulle decisioni algoritmiche.
La clausola 9, “Valutazione delle prestazioni”, richiede al punto 9.1 il monitoraggio e la misurazione, al punto 9.2 l’audit interno e al punto 9.3 il riesame di direzione, con indicatori di performance del sistema di IA che includano metriche di equità, accuratezza e conformità normativa. La clausola 10, “Miglioramento”, gestisce al punto 10.1 le non conformità e le azioni correttive e al punto 10.2 il miglioramento continuo, in coerenza con il ciclo Plan-Do-Check-Act che permea l’intera architettura dello standard.
L’Annex A, infine, raccoglie trentotto controlli organizzati in nove aree, dalla A.2 alla A.10: la A.2 riguarda le politiche per l’IA, la A.3 l’organizzazione interna e l’assegnazione di responsabilità, la A.4 le risorse per i sistemi di IA, la A.5 la valutazione d’impatto dei sistemi, la A.6 il ciclo di vita del sistema di IA, la A.7 i dati impiegati nei sistemi di IA, la A.8 l’informazione destinata alle parti interessate, la A.9 l’uso responsabile dei sistemi di IA e la A.10 le relazioni con fornitori e clienti terzi. Trattandosi di controlli di riferimento e non di requisiti prescrittivi, la loro applicabilità va sempre giustificata, in senso positivo o negativo, nella Statement of Applicability, alla luce degli esiti del risk assessment condotto ai sensi del punto 6.1.2.
Metodologia per costruire un AIMS integrato con il GDPR
La costruzione di un AIMS realmente efficace richiede di superare l’approccio a compartimenti stagni tra compliance privacy e governance dell’intelligenza artificiale. Ritengo, in qualità di Lead Auditor, che la metodologia più solida per un’organizzazione italiana di medie dimensioni debba muoversi lungo alcune direttrici operative strettamente interconnesse, da affrontare in sequenza logica prima ancora che cronologica.
Inventario dei sistemi di intelligenza artificiale
Il primo passo consiste nella costruzione di un inventario dei sistemi di intelligenza artificiale, distinto ma organicamente collegato al Registro dei trattamenti previsto dall’articolo 30 del GDPR, funzionale a soddisfare quanto richiesto dai punti 4.3 e 6.1.2 della norma. Per ogni sistema censito occorre documentare la finalità perseguita, la tipologia di modello impiegato, se basato su regole, su machine learning supervisionato oppure generativo, la natura dei dati di input, personali o non personali, ordinari o rientranti tra le categorie particolari di cui all’articolo 9 del GDPR, il fornitore, che può essere interno, terzo oppure un modello fondazionale acquisito in licenza, il grado di autonomia decisionale del sistema e infine la sua classificazione di rischio secondo l’AI Act, che può risultare vietata, alto rischio, rischio limitato o rischio minimo. Questo inventario costituisce il presupposto sia per lo screening DPIA richiesto dal GDPR sia per la classificazione richiesta dall’AI Act, ed è tipicamente il primo elemento che un auditor richiede in un audit documentale, il cosiddetto Stage 1.
DPIA, FRIA e AI system impact assessment
Uno degli aspetti tecnicamente più delicati riguarda l’articolazione tra tre strumenti valutativi che, pur distinti quanto a base normativa, condividono larga parte della metodologia sottostante. Da un lato vi è la DPIA prevista dall’articolo 35 del GDPR, obbligatoria quando il trattamento presenta un rischio elevato per i diritti e le libertà degli interessati, come nei casi di profilazione sistematica o di trattamento su larga scala di categorie particolari di dati. Dall’altro vi è la valutazione d’impatto sui diritti fondamentali, la FRIA, prevista dall’articolo 27 dell’AI Act e richiesta ad alcuni deployer di sistemi ad alto rischio prima della loro prima messa in esercizio, che lo stesso AI Act qualifica espressamente come complementare e non sostitutiva della DPIA. A questi due strumenti si affianca infine l’AI system impact assessment disciplinato dai punti 6.1.4 e 8.3 dello standard ISO 42001, che presenta un perimetro più ampio, includendo impatti sulla sicurezza, sull’equità, sull’ambiente e sulla società, non limitati ai soli dati personali.
L’approccio metodologicamente corretto, quello che un auditor si attende in fase di verifica documentale, non consiste nel produrre tre documenti scollegati, bensì nel costruire un modello di valutazione unico e modulare, in cui la sezione dedicata ai dati personali alimenta automaticamente la DPIA, la sezione dedicata ai diritti fondamentali alimenta la FRIA e l’insieme complessivo costituisce l’AI system impact assessment richiesto dall’AIMS. Questa impostazione evita duplicazioni, riduce sensibilmente l’onere documentale e garantisce coerenza sostanziale tra le conclusioni raggiunte nei tre strumenti, un’esigenza che le linee guida congiunte in corso di elaborazione tra l’EDPB e l’AI Office della Commissione europea stanno peraltro esplicitamente promuovendo.
Data governance e controlli dell’Annex A
Il controllo dell’area A.7 dell’Annex A, relativo ai dati impiegati nei sistemi di IA, deve tradursi, sul piano GDPR, in procedure documentate che coprano l’individuazione della base giuridica per l’addestramento di modelli su dati personali, che può risiedere nel contratto, nel legittimo interesse purché accompagnato da un bilanciamento documentato, oppure nel consenso, a condizione che quest’ultimo sia realmente granulare e non generico o aggregato, tenendo conto dell’orientamento delle autorità di controllo che scoraggiano proprio basi giuridiche indistinte. Le medesime procedure devono presidiare la qualità e la rappresentatività dei dataset, con verifiche dei bias che si integrano con il principio di esattezza sancito dall’articolo 5, paragrafo 1, lettera d, del GDPR, la minimizzazione dei dati mediante tecniche di anonimizzazione, pseudonimizzazione o generazione sintetica quando compatibili con la finalità del modello, e la gestione dei prompt, delle cronologie di conversazione e degli output prodotti dai sistemi di IA generativa, che l’EDPB considera vettori di rischio specifici da trattare esplicitamente nella DPIA in quanto spesso contengono identificatori diretti o indiretti.
A questo si aggiunge la disciplina della conservazione e della cancellazione, con criteri differenziati per i dati impiegati in attività di fine-tuning o di retrieval-augmented generation, e la gestione dell’ipotesi, sempre più frequente nella prassi delle autorità di controllo, di modelli addestrati in violazione del GDPR, per i quali l’EDPB ha chiarito che la disattivazione integrale del modello non costituisce l’unica misura correttiva possibile, potendosi valutare interventi di remediation caso per caso.
Fornitori, modelli fondazionali e trasferimenti extra-UE
Il punto 8.4 della norma, relativo alla gestione dei fornitori e l’area A.10 dell’Annex A richiedono il controllo dei fornitori di componenti di intelligenza artificiale, piattaforme cloud impiegate per il training e i servizi di annotazione dei dati.
Sul piano GDPR questo si traduce nella necessità di qualificare correttamente il fornitore di modello come responsabile del trattamento ai sensi dell’articolo 28, come sub-responsabile oppure, in alcune circostanze, come contitolare, a seconda delle modalità con cui i dati vengono eventualmente riutilizzati dal fornitore per addestrare i propri modelli, nella verifica delle clausole contrattuali relative all’uso dei prompt e dei dati di input per finalità di miglioramento del modello del fornitore, spesso previste in regime di opt-out anziché di opt-in nelle condizioni standard dei grandi provider e nella gestione dei trasferimenti extra-UE di dati personali verso infrastrutture di training al di fuori dello Spazio economico europeo, da presidiare con le garanzie previste dal Capo V del GDPR, tra cui le clausole contrattuali standard e le valutazioni di trasferimento.
Trasparenza e sorveglianza umana
Un ultimo profilo riguarda la trasparenza verso gli interessati e la sorveglianza umana sulle decisioni algoritmiche. L’articolo 13 dell’AI Act impone ai fornitori di sistemi ad alto rischio di fornire informazioni che il deployer deve poi impiegare nella propria DPIA, generando un flusso informativo che l’AIMS deve formalizzare come procedura strutturata, evitando che tale informazione resti confinata alla documentazione tecnica del solo fornitore.
Allo stesso modo l’articolo 14 dell’AI Act, in materia di sorveglianza umana, va letto in stretta correlazione con l’articolo 22 del GDPR sul diritto degli interessati a non essere sottoposti a una decisione basata unicamente su un trattamento automatizzato: l’AIMS, in coerenza con l’area A.9 dell’Annex A dedicata all’uso responsabile, deve documentare non soltanto l’esistenza di un intervento umano, ma la sua natura sostanziale ed effettiva, quella che la prassi definisce meaningful human review (revisione umana significativa nel contesto dell’Intelligenza Artificiale, indica un controllo umano che deve essere reale ed effettivo, non una semplice approvazione formale dell’output prodotto dall’IA), requisito su cui gli orientamenti delle autorità di controllo si stanno progressivamente irrigidendo.
Roadmap
Per un’organizzazione che intenda costruire un AIMS conforme, certificabile e realmente integrato con il proprio programma privacy, ritengo opportuna una sequenza operativa che si sviluppa attraverso cinque momenti distinti ma tra loro comunicanti. Si parte da una fase diagnostica, della durata indicativa di quattro-sei settimane, dedicata alla costituzione dell’inventario dei sistemi di IA, alla gap analysis rispetto alle clausole 4-10 e ai controlli dell’Annex A, alla mappatura delle sovrapposizioni con il sistema di gestione per la sicurezza delle informazioni o con il sistema di gestione della privacy eventualmente già esistenti, e alla classificazione preliminare dei sistemi censiti secondo l’AI Act. Segue una fase di governance e pianificazione, di durata comparabile, nella quale si adotta la AI Policy richiesta dal punto 5.2, si definiscono i ruoli previsti dal punto 5.3, comprensivi del raccordo tra AI Officer, DPO ed eventualmente RSPP per i profili di sicurezza rilevanti, si struttura la metodologia di risk assessment specifica per l’intelligenza artificiale ai sensi del punto 6.1.2 e si redige la Statement of Applicability.
La terza fase, più estesa e articolata su otto-dodici settimane, è dedicata alla costruzione degli strumenti operativi veri e propri: il modello integrato che unifica DPIA, FRIA e AI system impact assessment, le procedure di data governance richieste dall’area A.7, l’aggiornamento delle informative e delle basi giuridiche dei trattamenti coinvolti, la revisione contrattuale dei fornitori ai sensi del punto 8.4 e dell’area A.10, e le procedure di sorveglianza umana e di gestione degli incidenti algoritmici richieste dall’area A.9. Parallelamente, e con carattere di continuità piuttosto che di fase circoscritta, si sviluppa l’attività di implementazione e formazione, che dà attuazione concreta ai punti 7.2 e 7.3 dello standard attraverso il rollout delle procedure e una formazione differenziata per ruolo, rivolta a sviluppatori, business owner e personale addetto alla protezione dei dati. La sequenza si chiude con una fase di verifica e certificazione, della durata indicativa di otto-dieci settimane, comprendente l’audit interno previsto dal punto 9.2, il riesame di direzione previsto dal punto 9.3 ed eventualmente l’audit di certificazione vero e proprio, articolato secondo prassi in uno Stage 1 di natura documentale e in uno Stage 2 di natura operativa, condotto da un organismo di certificazione accreditato.
Audit ISO 42001 e documenti da verificare
Un audit di certificazione ISO 42001, così come un audit interno condotto con pari rigore, verifica tipicamente la coerenza sostanziale, prima ancora che l’esistenza formale, di un insieme di documenti tra loro collegati: la AI Policy approvata dall’alta direzione ai sensi del punto 5.2, il registro dei sistemi di IA con la relativa classificazione di rischio, la Statement of Applicability corredata dalla giustificazione di ogni esclusione ai sensi della nota al punto 6.1.3, i verbali del risk assessment e i relativi piani di trattamento del rischio, le valutazioni di impatto integrate che uniscono DPIA, FRIA e AI system impact assessment per i sistemi ad alto rischio, le procedure di data governance e i log delle attività di training e di validazione, la documentazione contrattuale intercorsa con i fornitori di componenti di intelligenza artificiale, le evidenze delle attività formative erogate al personale, i verbali degli audit interni e dei riesami di direzione, e infine il registro delle non conformità e delle relative azioni correttive previsto dal punto 10.1. È proprio la coerenza cronologica e sostanziale tra questi documenti, più della loro mera esistenza formale, a costituire l’elemento su cui un Lead Auditor fonda il proprio giudizio circa l’effettiva operatività dell’AIMS, distinguendo un sistema di gestione realmente funzionante da un mero esercizio cartaceo predisposto in vista dell’audit.
Perché un AIMS integrato anticipa GDPR e AI Act
ISO/IEC 42001:2023 non sostituisce né il GDPR né l’AI Act, ma offre l’infrastruttura organizzativa che consente di adempiere a entrambi in modo coerente, evitando la proliferazione di processi paralleli che caratterizza ancora oggi molte organizzazioni nell’attuale fase di transizione normativa. Il recente slittamento, disposto dal Digital Omnibus, degli obblighi dell’AI Act per i sistemi ad alto rischio non riduce l’urgenza di questo lavoro: sposta la scadenza regolamentare, ma non elimina il rischio reputazionale, contrattuale e di data protection che un sistema di intelligenza artificiale mal governato continua comunque a generare fin da subito, in ragione degli obblighi GDPR già pienamente vigenti. Per un DPO o per un consulente privacy, l’investimento nella costruzione di un AIMS integrato rappresenta oggi la scelta metodologicamente più solida per anticipare obblighi che, prima o poi, diventeranno cogenti, mantenendo nel frattempo un vantaggio competitivo dimostrabile nei confronti di clienti e partner sempre più attenti alla governance algoritmica.
Partecipa alla community