Ultimo aggiornamento: 4 luglio 2026
Questa guida viene aggiornata periodicamente per riflettere l’evoluzione del Regolamento (UE) 2024/1689, delle linee guida dell’AI Office europeo e delle principali norme tecniche applicabili.
Guida completa alla governance decisionale nel Regolamento (UE) 2024/1689
Nota di posizionamento per il lettore. Questo documento non afferma che PENSAI sia conforme all’AI Act, non certifica alcuna conformità e non sostituisce gli obblighi legali previsti dal Regolamento (UE) 2024/1689. Descrive, con linguaggio prudente e verificabile, in quali punti un metodo decisionale strutturato come PENSAI può inserirsi nel percorso di adeguamento normativo di un’organizzazione.
Indice dei contenuti (Table of Contents)
- Executive Summary
- Introduzione
- Cos’è l’AI Act
- Principi fondamentali del Regolamento
- Governance dell’IA
- Accountability
- Human Oversight
- Risk Management
- Data Governance
- Technical Documentation
- Logging e tracciabilità
- Transparency
- Continuous Monitoring
- Post Market Monitoring
- Audit
- Quality Management System
- Come PENSAI può supportare questi processi
- Limiti di PENSAI
- Cosa PENSAI non è
- Integrazione con sistemi organizzativi
- Possibili relazioni con ISO/IEC 42001
- Tabelle comparative
- Checklist operative
- Diagrammi descritti testualmente
- FAQ estese
- Glossario
- Bibliografia e riferimenti normativi
- Conclusioni
Executive Summary
Il Regolamento (UE) 2024/1689 (di seguito, “AI Act”) introduce nell’Unione Europea un quadro giuridico organico per lo sviluppo, l’immissione sul mercato e l’utilizzo dei sistemi di intelligenza artificiale. Non si tratta di una normativa che riguarda esclusivamente gli sviluppatori di modelli: riguarda anche i “deployer” (soggetti che utilizzano sistemi di IA nell’ambito della propria attività professionale), le pubbliche amministrazioni e, in prospettiva, qualunque organizzazione che integri strumenti di supporto decisionale automatizzato o semi-automatizzato nei propri processi.
L’AI Act non si limita a vietare pratiche inaccettabili o a imporre requisiti tecnici ai sistemi ad alto rischio: costruisce, in filigrana, un modello di governance decisionale basato su alcuni pilastri ricorrenti — gestione del rischio, sorveglianza umana, governance dei dati, documentazione tecnica, tracciabilità (logging), trasparenza, monitoraggio continuo, monitoraggio post-market e sistemi di gestione della qualità.
PENSAI è un metodo decisionale strutturato, non un sistema di intelligenza artificiale che decide autonomamente. Opera come strato di supporto alla decisione: struttura le opzioni disponibili, esplicita i criteri di valutazione, produce una raccomandazione tracciabile e lascia la decisione finale alla persona responsabile. Questa architettura — per costruzione, non per certificazione — presenta punti di contatto con alcuni dei principi sopra citati, in particolare con la sorveglianza umana e la tracciabilità delle decisioni.
Questo documento analizza, capitolo per capitolo, i requisiti principali dell’AI Act e individua, per ciascuno, in quali aspetti un metodo come PENSAI può costituire un elemento utile all’interno di un più ampio programma di compliance, senza mai sostituirsi agli obblighi legali, alla valutazione di conformità, alla documentazione tecnica prevista dal Regolamento o al giudizio di un consulente legale qualificato.
Punto centrale da ritenere: nessuno strumento software, metodo o framework può “rendere conforme” un’organizzazione all’AI Act. La conformità è un processo organizzativo, giuridico e documentale che richiede analisi caso per caso, competenze legali, valutazione del rischio specifica e, per i sistemi ad alto rischio, procedure di valutazione della conformità formalizzate (art. 43 Regolamento (UE) 2024/1689). Ciò che un metodo decisionale strutturato può fare è agevolare alcune delle condizioni organizzative che rendono più semplice, ordinato e documentabile il percorso verso quella conformità.
Introduzione
Le organizzazioni che si confrontano oggi con l’AI Act si trovano davanti a una difficoltà pratica prima ancora che giuridica: il Regolamento parla di “sistemi di IA”, “fornitori”, “deployer”, “sorveglianza umana”, “governance dei dati”, ma non fornisce un manuale operativo su come, concretamente, un’impresa di medie dimensioni o una pubblica amministrazione debba tradurre questi principi in processi quotidiani.
Questo documento nasce per colmare, in parte, questo scarto. Si rivolge a:
- imprenditori che devono capire se e come l’AI Act riguarda la propria attività;
- pubbliche amministrazioni che utilizzano o stanno valutando sistemi di supporto decisionale automatizzato;
- professionisti e consulenti che devono orientare i propri clienti;
- sviluppatori che progettano sistemi con componenti di intelligenza artificiale o di supporto decisionale;
- auditor che devono verificare l’esistenza e l’efficacia di controlli organizzativi;
- responsabili compliance che devono costruire o aggiornare un programma di adeguamento normativo.
Il documento adotta un registro tecnico-giuridico, non promozionale. Ogni riferimento a PENSAI è formulato con verbi prudenziali (“può supportare”, “può contribuire”, “può costituire un elemento utile”) e mai con verbi assertivi di conformità (“garantisce”, “assicura”, “certifica”, “rende conforme”). Questa scelta lessicale non è stilistica: riflette un principio di correttezza informativa che, in un dominio normativo delicato come quello dell’IA, evita di generare false rassicurazioni presso chi legge.
Cos’è l’AI Act
Il Regolamento (UE) 2024/1689 del Parlamento Europeo e del Consiglio, adottato nel 2024, stabilisce norme armonizzate sull’intelligenza artificiale nell’Unione Europea. È stato pubblicato nella Gazzetta Ufficiale dell’Unione Europea ed è entrato in vigore a distanza di venti giorni dalla pubblicazione, con un’applicazione scaglionata nel tempo: alcune disposizioni (tra cui i divieti relativi alle pratiche vietate, art. 5) si applicano dopo sei mesi dall’entrata in vigore; le disposizioni relative ai modelli di IA per finalità generali (General Purpose AI, Titolo VIII-bis introdotto dal Regolamento) dopo dodici mesi; la gran parte degli obblighi relativi ai sistemi ad alto rischio dopo ventiquattro-trentasei mesi, a seconda della categoria di sistema.
L’AI Act persegue un obiettivo dichiarato nel Considerando 1: garantire un mercato interno per l’IA che sia affidabile (trustworthy), antropocentrico (human-centric) e rispettoso dei diritti fondamentali sanciti dalla Carta dei diritti fondamentali dell’Unione Europea, adottando al contempo un approccio basato sul rischio (risk-based approach).
L’architettura del Regolamento si fonda su una classificazione dei sistemi di IA in quattro categorie di rischio:
| Categoria di rischio | Trattamento normativo | Esempi |
|---|---|---|
| Rischio inaccettabile | Pratiche vietate (art. 5) | Social scoring, manipolazione subliminale, riconoscimento biometrico in tempo reale in spazi pubblici (con eccezioni) |
| Alto rischio | Requisiti stringenti (artt. 8-49) | Sistemi per selezione del personale, credit scoring, dispositivi medici con componente IA, sistemi usati in ambito giudiziario |
| Rischio limitato | Obblighi di trasparenza (art. 50) | Chatbot, sistemi di generazione di contenuti sintetici (deepfake) |
| Rischio minimo | Nessun obbligo specifico, codici di condotta volontari (art. 95) | Filtri antispam, videogiochi con IA |
Non tutti i sistemi software che supportano una decisione rientrano automaticamente nella definizione di “sistema di IA” ai sensi dell’art. 3, punto 1, del Regolamento, che richiede l’impiego di tecniche che consentano di dedurre, a partire dagli input ricevuti, output quali previsioni, contenuti, raccomandazioni o decisioni in grado di influenzare ambienti fisici o virtuali, con un certo grado di autonomia. Un metodo decisionale strutturato che si limiti a organizzare criteri predefiniti dall’utente, senza inferenza autonoma sui dati, può collocarsi al di fuori di questa definizione o comunque in una fascia di rischio diversa da quella dei sistemi ad alto rischio: la qualificazione va comunque effettuata caso per caso, e questo documento non sostituisce tale valutazione.
Principi fondamentali del Regolamento
L’AI Act non è soltanto un elenco di divieti e requisiti tecnici. Il testo, letto nel suo complesso (Considerando e articoli), esprime alcuni principi trasversali:
- Approccio basato sul rischio. Gli obblighi sono proporzionati al rischio che un sistema di IA pone per la salute, la sicurezza o i diritti fondamentali delle persone (Considerando 26).
- Antropocentrismo. L’IA deve rimanere uno strumento al servizio della persona, non un sostituto della responsabilità umana (Considerando 27).
- Trasparenza e tracciabilità. Le decisioni assistite da IA devono poter essere comprese, ricostruite e, dove necessario, contestate (artt. 13, 50, 86).
- Responsabilità lungo la catena del valore. Fornitori, deployer, importatori e distributori hanno obblighi distinti ma complementari (artt. 16-27).
- Gestione del ciclo di vita. Gli obblighi non si esauriscono al momento dell’immissione sul mercato ma proseguono nella fase di monitoraggio post-market (artt. 72-73).
- Presunzione di conformità tramite standard armonizzati. L’adozione di norme tecniche armonizzate pubblicate dagli organismi di normazione europei (CEN-CENELEC) può generare una presunzione di conformità (art. 40), pur non essendo l’unica via per dimostrarla.
Questi principi, più che singoli articoli, costituiscono la cornice interpretativa entro cui si muovono tutti i capitoli successivi di questo documento, incluso quello dedicato a PENSAI.
Governance dell’IA
Con “governance dell’IA” si intende, nel linguaggio del Regolamento e nella prassi internazionale (si veda anche ISO/IEC 42001:2023), l’insieme delle strutture, dei ruoli, delle politiche e dei processi decisionali che un’organizzazione adotta per assicurare che l’uso dell’intelligenza artificiale sia coerente con i propri obblighi legali, etici e strategici.
L’AI Act non impone un modello di governance unico, ma richiede, per i sistemi ad alto rischio, l’esistenza di:
- un sistema di gestione del rischio (art. 9);
- una funzione di sorveglianza umana (art. 14);
- un sistema di gestione della qualità per i fornitori (art. 17);
- procedure di registrazione e reporting (artt. 49, 71);
- nel caso delle pubbliche amministrazioni e di alcuni deployer, una valutazione d’impatto sui diritti fondamentali (art. 27, per i sistemi che rientrano nell’ambito applicativo indicato dalla norma).
Un elemento spesso sottovalutato è che la governance dell’IA non riguarda solo i sistemi “etichettati” come intelligenza artificiale, ma l’intero ecosistema decisionale dell’organizzazione: chi decide, sulla base di quali criteri, con quale grado di automazione, e come tale decisione può essere ricostruita in un secondo momento (ad esempio in caso di reclamo, ispezione o contenzioso).
Callout — Perché questo riguarda anche chi non sviluppa IA. Molte organizzazioni che non producono sistemi di IA in senso proprio si troveranno comunque nella posizione di “deployer” ai sensi dell’art. 3, punto 4, semplicemente utilizzando strumenti di terze parti (es. software di selezione CV, strumenti di scoring, assistenti automatizzati). Gli obblighi del deployer, pur meno estesi di quelli del fornitore, non sono trascurabili (art. 26).
Accountability
Il principio di accountability (responsabilizzazione), mutuato anche dal Regolamento Generale sulla Protezione dei Dati (Regolamento UE 2016/679, art. 5, par. 2), permea l’AI Act: non basta rispettare formalmente un requisito, occorre essere in grado di dimostrarlo.
Nell’AI Act, questo si traduce in obblighi documentali specifici:
- conservazione della documentazione tecnica per un periodo minimo di dieci anni dall’immissione sul mercato (art. 18);
- conservazione automatica dei log generati dal sistema (art. 19, in combinato con l’art. 12);
- registrazione dei sistemi ad alto rischio in un’apposita banca dati dell’Unione (art. 49, art. 71);
- obbligo, per i deployer di determinati sistemi, di conservare i log per un periodo minimo di sei mesi (art. 26, par. 6).
L’accountability, in altri termini, non è un valore astratto: è un requisito documentale e procedurale. Un’organizzazione è “accountable” nella misura in cui può, in qualunque momento, ricostruire la catena delle proprie decisioni e delle proprie scelte progettuali.
È in questo capitolo che un metodo decisionale strutturato può, in linea di principio, offrire un contributo tangibile: se ogni decisione supportata dal metodo produce un output tracciato, datato e riconducibile a criteri espliciti, l’organizzazione dispone di un elemento (non l’unico, non sufficiente da solo) utile a costruire la propria narrazione di accountability.
Human Oversight
L’articolo 14 del Regolamento (UE) 2024/1689 è probabilmente la disposizione più rilevante per qualunque metodo o strumento di supporto decisionale. Impone che i sistemi di IA ad alto rischio siano progettati e sviluppati in modo tale da poter essere efficacemente supervisionati da persone fisiche durante il periodo in cui sono in uso.
L’art. 14, par. 4, specifica che le misure di sorveglianza umana devono consentire alle persone incaricate di:
- comprendere adeguatamente le capacità e i limiti del sistema (lett. a);
- rimanere consapevoli della possibile tendenza a fare eccessivo affidamento sull’output del sistema, il cosiddetto automation bias (lett. b);
- interpretare correttamente l’output del sistema (lett. c);
- decidere di non utilizzare il sistema o di ignorarne, annullarne o invertirne l’output in una determinata situazione (lett. d);
- intervenire sul funzionamento del sistema o interromperlo tramite un dispositivo di arresto (“stop button”) o una procedura analoga (lett. e).
Questo articolo formalizza un principio che, in letteratura di risk management, è noto come “human-in-the-loop” o “human-on-the-loop”: la persona non è un elemento decorativo del processo, ma un attore che deve poter comprendere, contestare e, se necessario, bloccare l’output automatizzato.
Un metodo che, per costruzione, produce raccomandazioni e non decisioni — lasciando esplicitamente alla persona la scelta finale — si colloca in un’area concettualmente prossima a questo principio. Ciò non significa che tale metodo soddisfi automaticamente i requisiti dell’art. 14 per un sistema di IA ad alto rischio (che comprendono anche requisiti tecnici su interfacce, formazione del personale e progettazione), ma significa che l’impostazione architetturale — mantenere la decisione finale in capo alla persona — è coerente con la ratio della norma.
Risk Management
L’articolo 9 del Regolamento richiede che i fornitori di sistemi di IA ad alto rischio istituiscano, applichino, documentino e mantengano un sistema di gestione del rischio (risk management system) come processo continuo e iterativo lungo l’intero ciclo di vita del sistema.
Il sistema di gestione del rischio, secondo l’art. 9, par. 2, deve comprendere almeno le seguenti fasi:
- identificazione e analisi dei rischi noti e prevedibili associati a ciascun sistema di IA ad alto rischio;
- stima e valutazione dei rischi che possono emergere quando il sistema è utilizzato conformemente alla sua destinazione d’uso o in condizioni di uso improprio ragionevolmente prevedibile;
- valutazione di altri rischi eventualmente derivanti dall’analisi dei dati raccolti tramite il sistema di monitoraggio post-market (art. 72);
- adozione di misure di gestione del rischio adeguate.
Questo processo è per sua natura documentale e ricorsivo: non si esaurisce in un’unica valutazione al momento dello sviluppo, ma richiede un aggiornamento continuo.
Un metodo decisionale strutturato, se applicato in modo sistematico alle decisioni che comportano una componente di rischio (es. scelte di investimento, decisioni organizzative ad alto impatto, valutazioni make-or-buy su strumenti di IA), può contribuire a rendere più esplicito il processo con cui un’organizzazione individua le opzioni, ne pesa i rischi e ne documenta la scelta finale. Questo non equivale, tuttavia, a un sistema di gestione del rischio ai sensi dell’art. 9, che ha requisiti tecnici specifici (analisi statistica dei rischi, test, misure di mitigazione documentate) che vanno costruiti con competenze dedicate.
Data Governance
L’articolo 10 del Regolamento disciplina i requisiti relativi ai dataset di addestramento, convalida e prova utilizzati per i sistemi di IA ad alto rischio. Tali dataset devono essere soggetti a pratiche di governance e gestione dei dati appropriate rispetto alla destinazione d’uso del sistema, comprendenti, tra l’altro:
- le scelte progettuali pertinenti (art. 10, par. 2, lett. a);
- i processi di raccolta dei dati e l’origine dei dati (lett. b);
- le pertinenti operazioni di trattamento (lett. c);
- la formulazione di ipotesi, in particolare per quanto riguarda le informazioni che i dati dovrebbero misurare e rappresentare (lett. d);
- una valutazione della disponibilità, quantità e adeguatezza dei set di dati necessari (lett. e);
- l’esame di possibili distorsioni (bias) che possano incidere sulla salute e sicurezza delle persone o dare luogo a discriminazioni vietate dal diritto dell’Unione (lett. f-g);
- misure adeguate per individuare, prevenire e mitigare tali distorsioni (lett. h).
La data governance, in questo contesto, non riguarda soltanto la “qualità” tecnica dei dati, ma la tracciabilità delle scelte relative a come i dati sono stati raccolti, trattati e utilizzati. È un principio che si estende, per analogia organizzativa, anche ai criteri utilizzati in un processo decisionale: se un metodo decisionale esplicita i criteri di valutazione utilizzati e la loro origine, questo può facilitare, in un contesto più ampio, la disciplina degli input informativi che alimentano decisioni aziendali (non necessariamente sistemi di IA in senso stretto).
Technical Documentation
L’articolo 11 e l’Allegato IV del Regolamento richiedono che i fornitori di sistemi di IA ad alto rischio predispongano una documentazione tecnica prima dell’immissione sul mercato, mantenuta aggiornata. L’Allegato IV specifica un elenco dettagliato di contenuti minimi, tra cui:
- descrizione generale del sistema e della sua finalità prevista;
- descrizione degli elementi del sistema e del processo di sviluppo;
- informazioni dettagliate su monitoraggio, funzionamento e controllo del sistema;
- descrizione della metodologia e dei set di dati utilizzati;
- descrizione delle misure di sorveglianza umana adottate;
- descrizione del sistema di gestione della qualità.
Questa documentazione deve essere conservata per un periodo di dieci anni dall’immissione sul mercato o messa in servizio del sistema (art. 18) e resa disponibile, su richiesta, alle autorità nazionali competenti.
Un metodo decisionale che produce, per ciascuna decisione supportata, un output strutturato (opzioni valutate, criteri applicati, raccomandazione, decisione finale presa dalla persona) genera artefatti documentali che possono, in linea di principio, integrare — mai sostituire — la documentazione tecnica richiesta per i sistemi di IA veri e propri, o più semplicemente arricchire il fascicolo di governance interna di un’organizzazione che debba dimostrare come determinate decisioni siano state assunte.
Logging e tracciabilità
L’articolo 12 del Regolamento richiede che i sistemi di IA ad alto rischio siano progettati con capacità di registrazione automatica degli eventi (“log”) per l’intera durata del ciclo di vita del sistema, in modo da garantire un livello di tracciabilità del funzionamento del sistema adeguato alla sua destinazione d’uso.
I requisiti minimi di logging, secondo l’art. 12, par. 3, comprendono, in particolare:
- la registrazione del periodo di ciascun utilizzo del sistema;
- la banca dati di riferimento rispetto alla quale il sistema ha verificato i dati di input;
- i dati di input per i quali la ricerca ha portato a una corrispondenza;
- l’identificazione delle persone fisiche coinvolte nella verifica dei risultati.
L’art. 19 estende l’obbligo di conservazione di tali log ai fornitori, mentre l’art. 26, par. 6, impone ai deployer di conservare i log generati automaticamente dal sistema, nella misura in cui tali log siano sotto il loro controllo, per un periodo di almeno sei mesi (salvo diverse disposizioni di legge, incluse quelle sulla protezione dei dati personali).
Il concetto di audit trail — la possibilità di ricostruire, a posteriori, chi ha fatto cosa, quando e sulla base di quali informazioni — è centrale in questo capitolo, ed è anche l’aspetto in cui un metodo decisionale strutturato può offrire il contributo più diretto: se ogni raccomandazione prodotta dal metodo è associata a un timestamp, ai criteri utilizzati e all’esito della decisione umana, si genera un registro che può supportare, senza sostituirlo, l’obbligo di tracciabilità previsto per i sistemi di IA propriamente detti.
Transparency
L’articolo 13 del Regolamento richiede che i sistemi di IA ad alto rischio siano progettati in modo da garantire un funzionamento sufficientemente trasparente da consentire ai deployer di interpretare l’output del sistema e utilizzarlo adeguatamente. Il sistema deve essere corredato da istruzioni per l’uso che comprendano, tra l’altro:
- l’identità e i contatti del fornitore;
- le caratteristiche, le capacità e i limiti di prestazione del sistema;
- eventuali cambiamenti del sistema e delle sue prestazioni predeterminati dal fornitore;
- le misure di sorveglianza umana previste;
- le risorse computazionali e hardware necessarie, la durata di vita prevista.
L’articolo 50, separatamente, introduce obblighi di trasparenza per sistemi a rischio limitato (es. obbligo di informare le persone fisiche che stanno interagendo con un sistema di IA, salvo che ciò sia evidente; obbligo di etichettare i contenuti sintetici generati o manipolati, i cosiddetti deepfake).
La trasparenza, nel linguaggio dell’AI Act, non equivale a “spiegabilità tecnica assoluta” (non tutti i modelli, specie quelli basati su reti neurali profonde, sono pienamente interpretabili), ma a un livello di comprensibilità funzionale: l’utente deve poter capire, nei limiti tecnicamente possibili, che tipo di output sta ricevendo e come utilizzarlo correttamente.
Un metodo decisionale che esplicita i criteri di valutazione utilizzati per giungere a una raccomandazione — invece di produrre un output “a scatola nera” — può, per costruzione, agevolare questo tipo di comprensibilità funzionale nel contesto specifico in cui è applicato, pur non essendo equiparabile, di per sé, all’adempimento degli obblighi di trasparenza previsti per un sistema di IA regolamentato.
Continuous Monitoring
Il monitoraggio continuo (continuous monitoring) è un concetto trasversale nell’AI Act, che si manifesta in diverse disposizioni:
- l’obbligo per i fornitori di monitorare il funzionamento del sistema dopo l’immissione sul mercato (art. 72);
- l’obbligo per i deployer di monitorare il funzionamento del sistema di IA ad alto rischio sulla base delle istruzioni per l’uso e, se del caso, di informare il fornitore o il distributore in conformità all’art. 26, par. 5;
- l’obbligo di sospendere l’uso del sistema qualora si abbia motivo di ritenere che l’uso conforme alle istruzioni possa comportare un rischio ai sensi dell’art. 79 (art. 26, par. 5).
Il monitoraggio continuo si differenzia dal monitoraggio post-market (trattato nel capitolo seguente) perché riguarda l’uso quotidiano del sistema, non solo la raccolta sistematica e periodica di dati sulle prestazioni nel tempo.
Applicato ai processi decisionali organizzativi, il principio del monitoraggio continuo suggerisce che nessun processo — automatizzato o meno — debba essere considerato “impostato una volta per tutte”. Un metodo decisionale che preveda cicli di revisione periodica delle raccomandazioni prodotte, confrontandole con gli esiti effettivi delle decisioni prese, può contribuire a una cultura organizzativa di monitoraggio continuo, in linea con lo spirito (non necessariamente con la lettera tecnica) delle disposizioni sopra richiamate.
Post Market Monitoring
L’articolo 72 del Regolamento impone ai fornitori di sistemi di IA ad alto rischio di istituire e documentare un sistema di monitoraggio post-market proporzionato alla natura delle tecnologie di IA e ai rischi del sistema. Tale sistema deve raccogliere, documentare e analizzare attivamente e sistematicamente i dati pertinenti forniti dai deployer o raccolti tramite altre fonti, relativi alle prestazioni del sistema durante il suo ciclo di vita.
L’articolo 73 disciplina l’obbligo di segnalazione di incidenti gravi (serious incidents) alle autorità di vigilanza del mercato, entro termini stringenti (in linea generale, non oltre quindici giorni dalla conoscenza dell’incidente, con termini più brevi — due giorni — per incidenti che comportano il decesso di una persona o un danno grave e irreversibile alla salute).
Il monitoraggio post-market rappresenta il punto in cui l’AI Act supera la logica di conformità “una tantum” al momento dell’immissione sul mercato, imponendo una responsabilità continuativa nel tempo. È un capitolo tecnicamente denso, che richiede infrastrutture di raccolta dati e procedure di escalation formalizzate: un metodo decisionale strutturato non sostituisce questo tipo di infrastruttura, ma può, in un’organizzazione che lo adotti in modo sistematico, contribuire a generare uno storico di decisioni e raccomandazioni utile per confrontare, nel tempo, l’affidabilità delle valutazioni compiute.
Audit
Il termine “audit” non compare in modo sistematico nell’AI Act con questa esatta dizione in ogni contesto, ma il concetto di verifica indipendente attraversa più istituti del Regolamento:
- la valutazione della conformità (conformity assessment), disciplinata dagli artt. 43 e seguenti, che può essere condotta internamente (autovalutazione, per la maggior parte dei sistemi ad alto rischio elencati nell’Allegato III) o da un organismo notificato (per specifiche categorie, tra cui i sistemi di identificazione biometrica);
- i poteri di vigilanza del mercato attribuiti alle autorità nazionali (artt. 74-79), che comprendono il diritto di accesso alla documentazione tecnica, ai dati di addestramento e, in circostanze motivate, al codice sorgente;
- gli audit interni volontari che un’organizzazione può condurre come parte del proprio sistema di gestione della qualità (art. 17) o di un sistema di gestione conforme a standard come ISO/IEC 42001.
L’attività di audit richiede evidenze verificabili: documenti, log, registri delle decisioni, tracciabilità delle responsabilità. Un metodo decisionale che produce, in modo sistematico, un registro strutturato delle proprie raccomandazioni e delle decisioni finali assunte dalle persone responsabili può costituire una fonte di evidenza (tra le molte necessarie) utile a un auditor interno o esterno che debba ricostruire il processo decisionale relativo a una specifica scelta organizzativa.
Quality Management System
L’articolo 17 del Regolamento impone ai fornitori di sistemi di IA ad alto rischio l’istituzione di un sistema di gestione della qualità (Quality Management System, QMS), documentato in modo sistematico e ordinato sotto forma di politiche, procedure e istruzioni scritte. Il QMS deve comprendere, tra gli altri elementi:
- una strategia per la conformità normativa, comprese le procedure per la gestione delle modifiche al sistema;
- tecniche, procedure e azioni sistematiche da utilizzare per la progettazione, il controllo e la verifica della progettazione del sistema;
- procedure di gestione dei dati precedenti all’immissione sul mercato;
- il sistema di gestione del rischio di cui all’art. 9;
- il sistema di monitoraggio post-market di cui all’art. 72;
- procedure relative alla segnalazione di incidenti gravi;
- procedure per la comunicazione con le autorità competenti e altri operatori.
Il QMS previsto dall’art. 17 è concettualmente affine, e in parte esplicitamente compatibile (art. 17, par. 3), con sistemi di gestione della qualità certificati secondo standard come ISO 9001 o con sistemi di gestione dell’IA come ISO/IEC 42001. Le organizzazioni già certificate secondo tali standard possono trovarsi in una posizione facilitata per costruire il proprio QMS ai sensi dell’AI Act, sebbene tale certificazione non equivalga automaticamente al soddisfacimento dell’art. 17.
Un metodo decisionale strutturato, se adottato come prassi organizzativa documentata (procedure scritte su quando e come utilizzarlo, chi è responsabile della decisione finale, come vengono conservate le evidenze), può integrarsi come una delle procedure operative all’interno di un più ampio sistema di gestione della qualità, contribuendo in particolare alla componente relativa alla tracciabilità delle decisioni e alla gestione del rischio operativo.
Come PENSAI può supportare questi processi
Dopo aver esaminato i requisiti principali dell’AI Act, è possibile sintetizzare in che modo un metodo decisionale strutturato come PENSAI può inserirsi, con i dovuti limiti, in un programma di governance e compliance.
PENSAI si presenta come un metodo — non un sistema di intelligenza artificiale autonomo — che struttura il processo decisionale attorno ad alcuni elementi ricorrenti: definizione esplicita delle opzioni disponibili, esplicitazione dei criteri di valutazione (inclusi eventuali “criteri di stop”, ossia condizioni che impongono l’interruzione o la non prosecuzione di un’opzione), produzione di una raccomandazione motivata, e attribuzione della decisione finale a una persona fisica responsabile.
Questa architettura consente di individuare, con linguaggio prudente, i seguenti possibili punti di contatto:
| Requisito AI Act | Possibile contributo di un metodo come PENSAI | Limite esplicito |
|---|---|---|
| Human oversight (art. 14) | L’impostazione “raccomandazione + decisione umana finale” è coerente con il principio di non delega totale della decisione | Non costituisce, da sola, prova di conformità per un sistema di IA ad alto rischio, che richiede requisiti tecnici ulteriori |
| Logging / tracciabilità (art. 12, 19, 26) | Un registro strutturato di opzioni, criteri e decisioni può fungere da elemento di tracciabilità interna | Non sostituisce i requisiti tecnici di logging automatico previsti per i sistemi di IA regolamentati |
| Risk management (art. 9) | L’esplicitazione dei criteri e dei “criteri di stop” può rendere più visibile la componente di rischio in una decisione | Non equivale a un sistema di gestione del rischio ai sensi dell’art. 9, che richiede analisi tecniche specifiche |
| Technical documentation (art. 11, All. IV) | Gli output strutturati del metodo possono arricchire il fascicolo documentale interno | Non sostituisce la documentazione tecnica obbligatoria per fornitori di sistemi ad alto rischio |
| Transparency (art. 13) | L’esplicitazione dei criteri di raccomandazione favorisce la comprensibilità funzionale della decisione | Non equivale agli obblighi di trasparenza previsti per un sistema di IA regolamentato |
| Quality Management System (art. 17) | Se formalizzato in procedure scritte, l’uso sistematico del metodo può diventare una procedura interna del QMS | Non costituisce, da solo, un QMS conforme all’art. 17 |
| Audit (artt. 43, 74-79) | Il registro delle decisioni può fornire evidenze utili a un audit interno o esterno | Non sostituisce la valutazione di conformità né i poteri di vigilanza delle autorità |
Callout — Il punto da non fraintendere. L’elenco sopra descrive possibili contributi, non equivalenze normative. Nessuna riga della tabella autorizza a concludere che l’adozione di PENSAI, da sola, soddisfi un requisito dell’AI Act. Ogni requisito normativo richiede una valutazione autonoma, spesso supportata da consulenza legale e tecnica specialistica.
Limiti di PENSAI
Un documento rigoroso deve indicare con la stessa chiarezza usata per i possibili contributi anche i limiti strutturali del metodo:
- PENSAI non effettua una valutazione di conformità normativa. Non stabilisce se un’organizzazione rispetta l’AI Act, il GDPR o altre normative applicabili.
- PENSAI non sostituisce la consulenza legale. Le decisioni relative alla classificazione del rischio di un sistema di IA, agli obblighi applicabili e alle procedure di conformità richiedono l’intervento di professionisti qualificati.
- PENSAI non genera automaticamente la documentazione tecnica richiesta dall’Allegato IV né i log tecnici richiesti dall’art. 12 per i sistemi di IA ad alto rischio.
- PENSAI non è un sistema di gestione del rischio ai sensi dell’art. 9, che richiede metodologie di risk assessment tecnicamente strutturate (analisi quantitativa e qualitativa del rischio, test, misure di mitigazione verificabili).
- PENSAI non elimina il rischio di errore umano. La qualità di una decisione dipende anche dalla qualità delle informazioni inserite dalla persona che utilizza il metodo e dal giudizio di chi, in ultima istanza, decide.
- PENSAI non ha valore probatorio autonomo in sede giudiziale o ispettiva. Il registro delle decisioni può costituire un elemento di prova tra altri, la cui rilevanza dipende dal contesto specifico e dalla valutazione di un giudice o di un’autorità di vigilanza.
- L’efficacia del metodo dipende dall’adozione organizzativa. Un metodo decisionale non produce benefici se non è integrato in procedure interne effettivamente seguite dal personale.
Cosa PENSAI non è
Per evitare ambiguità, è utile chiarire esplicitamente cosa PENSAI non è:
- Non è un sistema di intelligenza artificiale che prende decisioni autonome.
- Non è un organismo di certificazione né un ente notificato ai sensi dell’AI Act.
- Non è un software di conformità automatizzata (“compliance-as-a-service”) che genera attestazioni di conformità.
- Non è un sostituto della funzione di Data Protection Officer, di un responsabile compliance o di un legale esterno.
- Non è uno strumento di valutazione della conformità ai sensi dell’art. 43 del Regolamento.
- Non è uno standard tecnico armonizzato ai sensi dell’art. 40 del Regolamento.
- Non è, di per sé, un sistema di gestione della qualità conforme all’art. 17 o alla norma ISO/IEC 42001, sebbene possa costituirne una componente se integrato in un più ampio impianto documentale.
Integrazione con sistemi organizzativi
Un metodo decisionale strutturato produce valore, in ottica di governance, non come strumento isolato ma come componente di un ecosistema organizzativo più ampio. Alcuni esempi di integrazione possibile:
- Con il sistema di gestione del rischio aziendale (Enterprise Risk Management). Le raccomandazioni prodotte possono alimentare i registri di rischio già esistenti, senza sostituirli.
- Con i sistemi di gestione documentale. Gli output del metodo, se esportabili e archiviabili, possono essere versionati e conservati secondo le politiche di data retention già adottate dall’organizzazione.
- Con i flussi di approvazione interni (workflow di governance). La fase di decisione finale, riservata alla persona responsabile, può essere collegata a processi di firma, approvazione gerarchica o validazione a più livelli già presenti nell’organizzazione.
- Con i sistemi di gestione della qualità certificati (es. ISO 9001). Le procedure che disciplinano l’uso del metodo possono essere incorporate come procedure operative standard (SOP) all’interno di un sistema di gestione della qualità esistente.
- Con i programmi di formazione del personale. L’adozione efficace di qualunque metodo decisionale richiede formazione su come utilizzarlo correttamente e sui suoi limiti, in linea con quanto l’art. 4 del Regolamento richiede in tema di alfabetizzazione all’IA (AI literacy) per il personale che opera con sistemi di IA.
Possibili relazioni con ISO/IEC 42001
La norma ISO/IEC 42001:2023 è il primo standard internazionale che definisce i requisiti per un sistema di gestione dell’intelligenza artificiale (AI Management System, AIMS), sul modello delle norme di gestione già note (ISO 9001 per la qualità, ISO/IEC 27001 per la sicurezza delle informazioni).
È importante chiarire, senza ambiguità, che ISO/IEC 42001 e l’AI Act non sono equivalenti: la prima è una norma tecnica volontaria applicabile da qualunque organizzazione che sviluppi, fornisca o utilizzi sistemi di IA; il secondo è un regolamento europeo vincolante. Tuttavia, i due strumenti condividono un’impostazione concettuale simile: entrambi richiedono un approccio sistemico alla gestione del rischio, alla trasparenza e al miglioramento continuo.
| Aspetto | AI Act (Regolamento UE 2024/1689) | ISO/IEC 42001:2023 |
|---|---|---|
| Natura | Regolamento vincolante dell’Unione Europea | Standard tecnico volontario internazionale |
| Ambito di applicazione | Sistemi di IA immessi sul mercato o utilizzati nell’UE | Qualunque organizzazione, a prescindere dalla giurisdizione |
| Struttura | Basata su categorie di rischio (artt. 5-6) | Basata su un ciclo Plan-Do-Check-Act (PDCA) |
| Certificazione | Valutazione di conformità obbligatoria per i sistemi ad alto rischio (art. 43) | Certificazione volontaria da parte di organismi accreditati |
| Focus principale | Tutela dei diritti fondamentali e della sicurezza | Gestione sistemica del rischio organizzativo legato all’IA |
| Sanzioni | Sanzioni amministrative pecuniarie fino a 35 milioni di euro o al 7% del fatturato globale (art. 99) | Nessuna sanzione diretta; possibile perdita della certificazione |
Un’organizzazione che adotti un sistema di gestione conforme a ISO/IEC 42001 può trovarsi in una posizione organizzativa più matura per affrontare gli obblighi dell’AI Act, in particolare per quanto riguarda il sistema di gestione della qualità (art. 17) e la gestione del rischio (art. 9), ma la certificazione ISO/IEC 42001 non equivale, da sola, alla conformità all’AI Act, né lo dichiara la norma stessa.
Un metodo decisionale strutturato come PENSAI, se integrato in un sistema di gestione conforme a ISO/IEC 42001, può contribuire ad alcuni dei controlli previsti dall’Allegato A della norma (in particolare quelli relativi a processo decisionale, trasparenza e coinvolgimento umano), senza per questo costituire, da solo, un sistema di gestione conforme alla norma.
Tabelle comparative
Tabella 1 — Livelli di rischio AI Act e implicazioni pratiche
| Livello di rischio | Obblighi principali | Chi è coinvolto | Tempistica di applicazione |
|---|---|---|---|
| Inaccettabile | Divieto assoluto | Chiunque sviluppi o utilizzi tali pratiche | 6 mesi dall’entrata in vigore |
| Alto | Requisiti artt. 8-49, valutazione di conformità | Fornitori, deployer, importatori, distributori | Generalmente 24-36 mesi, salvo eccezioni |
| Limitato | Obblighi di trasparenza (art. 50) | Fornitori e deployer di chatbot, sistemi di generazione di contenuti sintetici | 24 mesi |
| Minimo | Nessun obbligo specifico, codici di condotta volontari | Tutti gli altri sistemi | Non applicabile |
Tabella 2 — Ruoli e obblighi principali nella catena del valore
| Ruolo | Definizione (art. 3) | Obblighi principali |
|---|---|---|
| Fornitore (provider) | Sviluppa un sistema di IA o lo fa sviluppare e lo immette sul mercato con il proprio nome o marchio | Artt. 16-27: gestione del rischio, documentazione tecnica, QMS, registrazione, monitoraggio post-market |
| Deployer | Utilizza un sistema di IA sotto la propria autorità nell’ambito di un’attività professionale | Art. 26: sorveglianza umana operativa, monitoraggio, conservazione log, valutazione d’impatto sui diritti fondamentali in casi specifici |
| Importatore | Immette sul mercato UE un sistema fornito da un soggetto extra-UE | Art. 23: verifica della conformità prima dell’immissione sul mercato |
| Distributore | Rende disponibile un sistema sul mercato, senza modificarne le caratteristiche | Art. 24: verifica formale della documentazione e della marcatura CE |
Tabella 3 — Elementi di un metodo decisionale strutturato e possibile rilevanza per la governance
| Elemento del metodo | Possibile rilevanza per la governance | Non costituisce |
|---|---|---|
| Esplicitazione delle opzioni | Favorisce la trasparenza interna del processo decisionale | Documentazione tecnica ai sensi dell’Allegato IV |
| Criteri di valutazione espliciti | Favorisce la comprensibilità funzionale della raccomandazione | Un sistema di gestione del rischio ai sensi dell’art. 9 |
| Criteri di stop | Introduce soglie esplicite che possono anticipare l’identificazione di rischi | Una valutazione del rischio formalizzata e quantitativa |
| Decisione finale riservata alla persona | Coerente con il principio di sorveglianza umana | Prova di conformità all’art. 14 per sistemi di IA ad alto rischio |
| Registro delle decisioni | Fonte di evidenza per attività di audit interno | Log tecnico automatico ai sensi dell’art. 12 |
Checklist operative
Checklist 1 — Valutazione preliminare (per imprenditori e PA)
Checklist 2 — Sorveglianza umana operativa
Checklist 3 — Documentazione e tracciabilità
Checklist 4 — Integrazione di un metodo decisionale strutturato
Diagrammi descritti testualmente
Diagramma 1 — Flusso di classificazione del rischio ai sensi dell’AI Act
Descrizione testuale del flusso logico previsto dagli artt. 5-6 del Regolamento:
- Punto di partenza: identificazione del sistema (si tratta di un sistema di IA ai sensi dell’art. 3, punto 1?).
- Primo bivio: il sistema rientra in una delle pratiche vietate elencate nell’art. 5? Se sì → uso vietato, nessuna prosecuzione.
- Secondo bivio: il sistema rientra in una delle categorie elencate nell’Allegato III (aree ad alto rischio: es. gestione delle infrastrutture critiche, istruzione, occupazione, accesso a servizi essenziali, applicazione della legge, migrazione, amministrazione della giustizia)? Se sì → applicazione degli artt. 8-49 (requisiti per sistemi ad alto rischio).
- Terzo bivio: il sistema rientra tra quelli soggetti a obblighi di trasparenza specifici (art. 50: chatbot, deepfake, sistemi di categorizzazione biometrica)? Se sì → applicazione degli obblighi informativi specifici.
- Esito residuale: se nessuna delle condizioni precedenti si applica, il sistema è considerato a rischio minimo, con possibile adesione volontaria a codici di condotta (art. 95).
Diagramma 2 — Ciclo di vita degli obblighi di un sistema di IA ad alto rischio
Descrizione testuale del ciclo, così come emerge dal combinato disposto degli artt. 9-27 e 72-73:
- Fase di progettazione: istituzione del sistema di gestione del rischio (art. 9) e delle pratiche di data governance (art. 10).
- Fase di sviluppo: predisposizione della documentazione tecnica (art. 11, Allegato IV) e delle capacità di logging (art. 12).
- Fase di verifica pre-immissione: valutazione della conformità (art. 43), redazione della dichiarazione di conformità UE (art. 47), apposizione della marcatura CE (art. 48).
- Fase di immissione sul mercato: registrazione nella banca dati dell’Unione (art. 49, art. 71).
- Fase di utilizzo (deployer): sorveglianza umana operativa (art. 26), monitoraggio continuo, conservazione dei log.
- Fase di monitoraggio post-market: raccolta e analisi sistematica dei dati sulle prestazioni (art. 72), segnalazione di incidenti gravi (art. 73).
- Fase di eventuale intervento correttivo: azioni correttive, ritiro o richiamo del sistema in caso di non conformità (artt. 20-21).
Diagramma 3 — Collocazione di un metodo decisionale strutturato all’interno del flusso decisionale organizzativo
Descrizione testuale (non normativa, di natura organizzativa):
- Input: un problema o un’esigenza decisionale viene individuata all’interno dell’organizzazione.
- Strutturazione: il metodo guida l’esplicitazione delle opzioni disponibili e dei criteri di valutazione pertinenti, inclusi eventuali criteri di stop.
- Elaborazione: viene prodotta una raccomandazione motivata, corredata dai criteri applicati.
- Sorveglianza umana: la persona responsabile esamina la raccomandazione, può accettarla, modificarla o respingerla integralmente.
- Decisione: la decisione finale, di competenza esclusivamente umana, viene registrata insieme alla raccomandazione originaria.
- Archiviazione: l’intero processo viene conservato in un registro tracciabile, disponibile per finalità di audit interno o di revisione successiva.
FAQ estese
PENSAI rende un’azienda conforme all’AI Act? No. Nessun metodo, software o framework può rendere un’organizzazione automaticamente conforme all’AI Act. La conformità dipende da una molteplicità di fattori giuridici, tecnici e organizzativi che vanno valutati caso per caso, con il supporto di consulenti legali e tecnici qualificati.
PENSAI è un sistema di intelligenza artificiale ai sensi dell’art. 3 del Regolamento? La qualificazione di un metodo o strumento come “sistema di IA” ai sensi dell’art. 3, punto 1, dipende dalle caratteristiche tecniche specifiche di implementazione e va valutata caso per caso. PENSAI si presenta come metodo decisionale strutturato che lascia la decisione finale alla persona; questo documento non effettua, in astratto, una qualificazione giuridica definitiva applicabile a ogni possibile implementazione.
Utilizzare PENSAI riduce il rischio di sanzioni ai sensi dell’art. 99? Non è possibile affermarlo in modo assoluto. Le sanzioni previste dall’art. 99 del Regolamento (fino a 35 milioni di euro o al 7% del fatturato globale annuo per le violazioni più gravi, relative alle pratiche vietate) dipendono dalla natura e gravità della violazione accertata dalle autorità competenti. Un metodo decisionale strutturato può contribuire a una migliore organizzazione documentale interna, ma non elimina il rischio sanzionatorio collegato a violazioni sostanziali degli obblighi normativi.
PENSAI sostituisce la valutazione d’impatto sui diritti fondamentali richiesta dall’art. 27? No. La valutazione d’impatto sui diritti fondamentali (Fundamental Rights Impact Assessment) prevista dall’art. 27 per specifiche categorie di deployer (enti pubblici, soggetti che forniscono servizi pubblici essenziali, ed enti che utilizzano sistemi per la valutazione del merito creditizio o per finalità assicurative in determinati casi) è un adempimento specifico con contenuti minimi definiti dalla norma. Un metodo decisionale strutturato può, al più, contribuire ad alcune delle informazioni utili per tale valutazione, ma non la sostituisce.
Le pubbliche amministrazioni possono utilizzare PENSAI? Le pubbliche amministrazioni, come qualunque altra organizzazione, possono valutare l’adozione di metodi decisionali strutturati per i propri processi interni, nel rispetto dei principi di trasparenza, imparzialità e buon andamento dell’azione amministrativa (art. 97 Cost.) e delle norme specifiche applicabili al settore pubblico, incluse quelle relative alla protezione dei dati personali e alla motivazione dei provvedimenti amministrativi (L. 241/1990).
Che rapporto c’è tra PENSAI e GDPR? Il Regolamento (UE) 2016/679 (GDPR) disciplina il trattamento dei dati personali e resta pienamente applicabile in parallelo all’AI Act, come confermato dal Considerando 10 del Regolamento (UE) 2024/1689. Qualunque metodo decisionale che tratti dati personali deve essere valutato anche alla luce degli obblighi GDPR, inclusi quelli relativi al processo decisionale automatizzato (art. 22 GDPR), indipendentemente dalla sua qualificazione ai sensi dell’AI Act.
Un metodo decisionale strutturato può sostituire un Data Protection Officer o un responsabile compliance? No. Le funzioni di controllo previste dalla normativa (DPO ai sensi degli artt. 37-39 GDPR, responsabile compliance, funzione di risk management) sono ruoli organizzativi con responsabilità giuridiche specifiche che nessuno strumento software può sostituire.
PENSAI genera automaticamente la documentazione tecnica richiesta dall’Allegato IV? No. La documentazione tecnica richiesta dall’Allegato IV per i sistemi di IA ad alto rischio ha contenuti specifici, definiti dal Regolamento, che devono essere predisposti dal fornitore del sistema con competenze tecniche e giuridiche dedicate. Un metodo decisionale strutturato può, al più, produrre alcuni artefatti documentali (registro delle decisioni, criteri utilizzati) che possono integrare, non sostituire, tale documentazione.
Quali sono le sanzioni previste dall’AI Act? L’art. 99 del Regolamento prevede tre fasce sanzionatorie: fino a 35 milioni di euro o al 7% del fatturato mondiale totale annuo per le violazioni relative alle pratiche vietate (art. 5); fino a 15 milioni di euro o al 3% del fatturato per la violazione di altri obblighi previsti dal Regolamento; fino a 7,5 milioni di euro o all’1% del fatturato per la comunicazione di informazioni inesatte, incomplete o fuorvianti alle autorità competenti. Per le PMI e le start-up, si applica l’importo più favorevole tra la percentuale e la cifra assoluta (art. 99, par. 6).
Da quando si applica l’AI Act? Il Regolamento è entrato in vigore il 1° agosto 2024. I divieti relativi alle pratiche vietate (art. 5) si applicano dal 2 febbraio 2025. Gli obblighi relativi ai modelli di IA per finalità generali si applicano dal 2 agosto 2025. La maggior parte degli obblighi relativi ai sistemi ad alto rischio si applica dal 2 agosto 2026, con alcune eccezioni (sistemi ad alto rischio integrati in prodotti già regolamentati da normativa di settore, per i quali il termine è il 2 agosto 2027).
Cosa deve fare un’impresa che sospetta di utilizzare un sistema ad alto rischio? È opportuno rivolgersi a un consulente legale specializzato in diritto delle nuove tecnologie per una valutazione puntuale, sulla base della descrizione tecnica del sistema, della sua destinazione d’uso e del contesto di impiego, confrontandola con l’Allegato III del Regolamento.
PENSAI può essere utilizzato insieme ad altri strumenti di compliance? In linea di principio sì: un metodo decisionale strutturato può integrarsi con altri strumenti di governance, risk management e compliance già adottati da un’organizzazione, come descritto nel capitolo “Integrazione con sistemi organizzativi” di questo documento.
Cosa succede se un’organizzazione non rispetta l’AI Act? Oltre alle sanzioni amministrative pecuniarie previste dall’art. 99, le autorità di vigilanza del mercato (art. 74) dispongono di poteri correttivi, tra cui l’ordine di ritiro dal mercato, il richiamo o la messa a norma del sistema non conforme (artt. 79-83).
Glossario
AI Act — Denominazione informale del Regolamento (UE) 2024/1689 del Parlamento Europeo e del Consiglio, che disciplina l’intelligenza artificiale nell’Unione Europea.
Alto rischio (high-risk AI system) — Sistema di IA che rientra in una delle categorie elencate nell’Allegato III del Regolamento o che costituisce un componente di sicurezza di un prodotto già regolamentato dalla normativa di armonizzazione dell’Unione elencata nell’Allegato I.
Audit trail — Registro strutturato e cronologico di eventi, decisioni o operazioni, che consente la ricostruzione a posteriori di un processo.
Automation bias — Tendenza cognitiva a fare eccessivo affidamento sull’output di un sistema automatizzato, riducendo il vaglio critico umano.
Conformity assessment (valutazione della conformità) — Procedura, disciplinata dagli artt. 43 e seguenti del Regolamento, con cui si verifica se un sistema di IA ad alto rischio soddisfa i requisiti previsti prima della sua immissione sul mercato.
Deployer — Persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che utilizza un sistema di IA sotto la propria autorità, salvo che il sistema sia utilizzato nel corso di un’attività personale non professionale (art. 3, punto 4).
Fornitore (provider) — Persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che sviluppa un sistema di IA o lo fa sviluppare e lo immette sul mercato o mette in servizio con il proprio nome o marchio (art. 3, punto 3).
Governance dell’IA (AI governance) — Insieme delle strutture, dei ruoli, delle politiche e dei processi che un’organizzazione adotta per assicurare un uso dell’IA coerente con obblighi legali, etici e strategici.
Human oversight (sorveglianza umana) — Requisito previsto dall’art. 14 del Regolamento, secondo cui i sistemi di IA ad alto rischio devono poter essere efficacemente supervisionati da persone fisiche.
ISO/IEC 42001 — Standard internazionale volontario che definisce i requisiti per un sistema di gestione dell’intelligenza artificiale (AI Management System).
Post-market monitoring (monitoraggio post-market) — Attività, disciplinata dall’art. 72 del Regolamento, di raccolta e analisi sistematica dei dati relativi alle prestazioni di un sistema di IA ad alto rischio dopo la sua immissione sul mercato.
Quality Management System (QMS) — Sistema di gestione della qualità previsto dall’art. 17 del Regolamento per i fornitori di sistemi di IA ad alto rischio.
Rischio inaccettabile — Categoria di pratiche di IA vietate ai sensi dell’art. 5 del Regolamento, in quanto ritenute in contrasto con i valori dell’Unione.
Risk management system (sistema di gestione del rischio) — Processo continuo e iterativo previsto dall’art. 9 del Regolamento per l’identificazione, la stima e la mitigazione dei rischi associati a un sistema di IA ad alto rischio.
Serious incident (incidente grave) — Evento, disciplinato dall’art. 3, punto 49, e dall’art. 73 del Regolamento, che comporta conseguenze gravi (decesso, danno grave alla salute, gravi danni patrimoniali o ambientali, gravi violazioni degli obblighi di diritto dell’Unione volte a tutelare i diritti fondamentali) collegate al malfunzionamento di un sistema di IA.
Technical documentation (documentazione tecnica) — Documentazione richiesta dall’art. 11 e dall’Allegato IV del Regolamento, che descrive in dettaglio il funzionamento, lo sviluppo e le caratteristiche di un sistema di IA ad alto rischio.
Bibliografia e riferimenti normativi
- Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, del 13 giugno 2024, che stabilisce regole armonizzate sull’intelligenza artificiale, pubblicato in Gazzetta Ufficiale dell’Unione Europea, L, 2024/1689, 12.7.2024.
- Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali (GDPR).
- ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system.
- ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management.
- Commissione Europea — Sito ufficiale dedicato all’AI Act: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- EUR-Lex — Testo consolidato del Regolamento (UE) 2024/1689: https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R1689
- Legge 7 agosto 1990, n. 241, recante norme in materia di procedimento amministrativo e di diritto di accesso ai documenti amministrativi.
- Costituzione della Repubblica Italiana, art. 97 (principi di imparzialità e buon andamento della pubblica amministrazione).
Avvertenza bibliografica. I riferimenti agli articoli del Regolamento (UE) 2024/1689 contenuti in questo documento sono riportati a fini divulgativi e di orientamento generale. Per l’applicazione a un caso concreto si raccomanda sempre la consultazione del testo normativo ufficiale pubblicato su EUR-Lex e il supporto di un professionista legale qualificato, anche in considerazione di eventuali atti delegati, linee guida della Commissione Europea o dell’AI Office e orientamenti giurisprudenziali che potrebbero intervenire successivamente alla redazione di questo documento.
Conclusioni
L’AI Act rappresenta, ad oggi, il tentativo più organico a livello globale di disciplinare l’intelligenza artificiale attraverso un approccio basato sul rischio. La sua applicazione pratica richiede alle organizzazioni — imprese, pubbliche amministrazioni, professionisti — uno sforzo che va ben oltre la semplice lettura del testo normativo: richiede la costruzione di processi interni di governance, gestione del rischio, tracciabilità e sorveglianza umana che siano documentabili e verificabili nel tempo.
In questo scenario, metodi decisionali strutturati come PENSAI possono rappresentare un elemento utile, tra molti altri, per un’organizzazione che voglia rendere più esplicito, tracciabile e documentabile il proprio processo decisionale, in particolare nei punti di contatto con i principi di sorveglianza umana e tracciabilità che attraversano l’intero impianto del Regolamento. Non possono, tuttavia, sostituirsi alla valutazione giuridica, alla documentazione tecnica obbligatoria, ai sistemi di gestione del rischio e della qualità richiesti dalla normativa, né alla necessaria consulenza specialistica per la classificazione e la gestione dei sistemi di IA effettivamente utilizzati da un’organizzazione.
Chi si avvicina a questo tema con l’aspettativa di trovare una soluzione univoca e definitiva rischia di sottovalutare la complessità — giuridica, organizzativa e tecnica — dell’AI Act. Chi invece adotta un approccio graduale, basato su mappatura dei sistemi utilizzati, formazione del personale, adozione di procedure documentate e, dove utile, integrazione di metodi decisionali strutturati all’interno di un più ampio sistema di governance, si trova nella posizione più solida per affrontare un percorso di adeguamento normativo che, per sua natura, non si esaurisce in un singolo intervento ma richiede manutenzione e revisione costanti nel tempo.
Nota finale. Il presente documento ha finalità esclusivamente informative e descrive il metodo PENSAI come possibile strumento di supporto alla governance decisionale. Non costituisce consulenza legale né sostituisce gli obblighi previsti dal Regolamento (UE) 2024/1689 o da altre normative applicabili.