sistemi ad alto rischio

AI Act, certificazione a più velocità: quando serve un organismo terzo


Indirizzo copiato

L’AI Act non prevede un’unica certificazione: procedure e controlli cambiano secondo il sistema. Tra autovalutazione, organismi notificati e norme armonizzate, la conformità coinvolge tecnologia, dati, sicurezza e capacità organizzativa del fornitore

Pubblicato il 18 set 2026

Garibaldi Conte

consulente nell’ambito dell’ICT e della Sicurezza ICT



AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti
certificazione AI Act




L’entrata in vigore del Regolamento (UE) 2024/1689 – Artificial Intelligence Act (AI Act), introduce nell’Unione Europea un nuovo modello regolamentare, basato sul rischio, destinato a modificare profondamente il modo in cui i sistemi di intelligenza artificiale vengono progettati, sviluppati, immessi sul mercato e monitorati nel corso del loro ciclo di vita.

Uno degli aspetti più rilevanti riguarda i sistemi di AI ad alto rischio, per i quali il Regolamento introduce un insieme articolato di requisiti obbligatori e, soprattutto, specifiche procedure di valutazione della conformità prima dell’immissione sul mercato o della messa in servizio.

Parlare genericamente di “certificazione AI” è tuttavia riduttivo. Il modello dell’AI Act si basa infatti su una valutazione di conformità secondo una logica molto vicina a quella già utilizzata dalla legislazione europea sui prodotti (vedi CRA). In funzione della tipologia di sistema, la conformità può essere dimostrata attraverso un controllo interno oppure con il coinvolgimento di un Conformity Assessment Body (CAB), che, una volta notificato dallo Stato membro, assume il ruolo di Notified Body.

Questa impostazione presenta interessanti punti di contatto con il Cyber Resilience Act (CRA), soprattutto per quanto riguarda il ruolo degli organismi di valutazione della conformità, l’accreditamento, la notifica e i requisiti di competenza, indipendenza e cybersecurity.

Classificazione dei sistemi AI ad alto rischio

Il primo passaggio che un fornitore di sistemi di AI deve fare è classificare il proprio sistema e verificare se esso sia un sistema ad alto rischio.

L’articolo 6 dell’AI Act identifica principalmente due situazioni nelle quali un sistema rientra nella categoria dei sistemi AI ad alto rischio:

  • Sistemi legati a prodotti regolamentati (Allegato I): sistemi di IA utilizzati come componenti di sicurezza in prodotti già soggetti a certificazione di terzi (es. dispositivi medici, ascensori, macchinari industriali, giocattoli, apparecchiature radio);
  • Sistemi ad alto rischio autonomi (Allegato III): algoritmi impiegati in settori ad alto impatto sociale ed economico, tra cui:
    • biometria (identificazione e categorizzazione remota);
    • gestione e sicurezza delle infrastrutture critiche (acqua, gas, elettricità, traffico);
    • istruzione e formazione professionale (valutazione degli studenti, ammissioni);
    • occupazione e gestione dei lavoratori (selezione del personale, tracciamento delle prestazioni);
    • accesso a servizi privati ed essenziali (credit scoring, merito creditizio, valutazioni assicurative);
    • forze dell’ordine, gestione dell’immigrazione, asilo e amministrazione della giustizia.

Requisiti obbligatori per i sistemi AI ad alto rischio

Nel caso in cui il sistema risulta essere ad alto rischio, allora il fornitore del sistema deve implementare ed essere conforme ai seguenti requisiti obbligatori:

  • Sistema di Gestione dei Rischi (Art. 9): definizione e implementazione di un processo continuo e iterativo di identificazione, analisi e mitigazione dei rischi noti e prevedibili associati al sistema;
  • Governance dei Dati (Art. 10): i dataset di addestramento, convalida e test devono rispettare elevati standard di qualità, essere pertinenti, rappresentativi e privi di bias sistematici;
  • Documentazione Tecnica (Art. 11): il fornitore deve predisporre, prima dell’immissione sul mercato del sistema, un fascicolo tecnico dettagliato che contenga tutte le evidenze che dimostrano la conformità del sistema durante tutto il suo ciclo di vita creando così una traccia verificabile delle decisioni e dei controlli adottati dal fornitore.
  • Tracciabilità e Registrazione degli Eventi (Art. 12): capacità del sistema di registrare automaticamente i log operativi per garantire la tracciabilità delle decisioni e il monitoraggio del funzionamento.
  • Trasparenza e Informazioni agli Utenti (Art. 13): istruzioni per l’uso chiare che spieghino le capacità, i limiti, l’accuratezza e le prestazioni del sistema al soggetto che lo impiega (deployer).
  • Sorveglianza Umana (Art. 14): architettura progettata per consentire a persone fisiche di supervisionare il sistema, prevenire o fermare comportamenti anomali;
  • Accuratezza, Robustezza e Cybersicurezza (Art. 15): Resilienza del sistema contro errori, guasti accidentali e attacchi informatici (es. adversarial attacks o data poisoning).

L’articolo 17 del regolamento attribuisce un ruolo centrale al sistema di gestione della qualità. Il QMS deve garantire la conformità al Regolamento e coprire, tra gli altri, strategia e procedure di compliance, progettazione e sviluppo, verifica e validazione, gestione dei dati, risk management, monitoraggio post introduzione sul mercato, gestione degli incidenti, modifiche e controllo documentale.

Esiste una naturale convergenza con standard come ISO 9001, ISO/IEC 27001 e ISO/IEC 42001. Tuttavia, una certificazione ISO non equivale automaticamente alla conformità o alla certificazione AI Act, anche se gli standard possono costituire evidenza e struttura di supporto. La conformità deve comunque essere dimostrata rispetto ai requisiti del Regolamento.

Aspetto interessante è legato alla cybersicurezza in quanto troviamo dei riferimenti sia agli schemi di certificazione europea dei prodotti (Cyber Security Act – CSA) che al Cyber Resilience Act (CRA).

L’aggancio con il CRA è diretto. Infatti, nell’articolo 12, il CRA stabilisce che, per soddisfare i requisiti di cybersicurezza, il sistema di AI deve soddisfare i requisiti essenziali previsti dal CRA. Tale verifica deve essere integrata nella verifica di conformità del sistema di AI eseguita in ambito conformità all’AI Act.

Processo di certificazione dei sistemi di AI ad alto rischio

Il regolamento identifica di fatto tre possibili scenari con diverse modalità di validazione dei sistemi.

Scenario 1: AI integrata in prodotti regolamentati

In primo scenario riguarda i sistemi AI che sono componenti di sicurezza o prodotti soggetti alla legislazione di armonizzazione europea indicata nell’Allegato I del regolamento.

In questo caso l’AI Act non crea una procedura parallela. La conformità AI viene integrata nella procedura di valutazione della conformità prevista dalla normativa di prodotto.

I CAB già designati nell’ambito di tali normative possono effettuare anche la verifica dei requisiti AI, purché siano state valutate le competenze specifiche richieste dall’AI Act.

Questo rappresenta uno dei punti di maggiore interesse anche rispetto al CRA: il sistema europeo tende a riutilizzare l’infrastruttura esistente di valutazione della conformità anziché creare organismi completamente separati.

Scenario 2: sistemi di AI ad alto rischio identificati nell’Allegato III – punti 2-8

Per i sistemi di AI ad alto rischio ricompresi nei punti 2-8 dell’Allegato III, il fornitore effettua direttamente la valutazione della conformità secondo la procedura descritta nell’Allegato VI. Non è quindi previsto il coinvolgimento di un CAB.

Il fornitore deve dimostrare il rispetto dei requisiti dell’AI Act descritti in precedenza e il risultato sarà una Dichiarazione di Conformità EU, senza un certificato rilasciato da un organismo terzo.

Questa è la modalità che la Commissione europea ha scelto come regola generale per gran parte dei sistemi ad alto rischio non incorporati in prodotti regolamentati, almeno nella fase iniziale di applicazione del Regolamento. Il considerando 125 del regolamento spiega infatti che il ricorso alla certificazione di terza parte è stato inizialmente limitato, anche tenendo conto della disponibilità ancora limitata di organismi con esperienza specifica nella certificazione AI.

Scenario 3: sistemi biometrici ad alto rischio

Per i sistemi indicati al punto 1 dell’Allegato III del regolamento, relativi alla biometria, il modello di certificazione cambia e sono previsti due percorsi diversi che il fornitore può scegliere:

  • controllo interno (vedi allegato VI del regolamento), detto anche self assessment, prevede che il fornitore applichi le norme armonizzate opportunamente predisposte e pubblicate sulla Gazzetta Europea, oppure, quando applicabili, le specifiche comuni predisposte dalla Commissione EU.
  • valutazione da parte di un CAB (vedi Allegato VII del regolamento).

Il coinvolgimento del CAB diventa invece obbligatorio quando:

  • non esistono norme armonizzate applicabili e non sono disponibili neanche specifiche comuni;
  • le norme armonizzate sono state applicate solo parzialmente;
  • le specifiche comuni disponibili non sono state applicate;
  • la norma armonizzata è stata pubblicata con restrizioni e non copre tutti i requisiti richiesti.

Norme armonizzate e specifiche comuni nell’AI Act

Come si può intuire, le norme armonizzate europee rappresentano uno degli strumenti principali per dimostrare la conformità all’AI Act. Quando una norma armonizzata viene pubblicata nella Gazzetta Ufficiale dell’Unione europea, la sua applicazione può generare una presunzione di conformità ai requisiti dell’AI Act coperti dalla norma.

Il loro utilizzo non è necessariamente obbligatorio poiché il fornitore può utilizzare altri strumenti tecnici per dimostrare la conformità. Tuttavia, le norme armonizzate costituiscono una via particolarmente importante per rendere il percorso di compliance ripetibile, verificabile e difendibile.

Altro strumento rilevante per la valutazione della conformità all’AI Act da parte di un sistema AI ad alto rischio sono le specifiche comuni che sono emesse dalla Commissione EU. Queste sono delle specifiche tecniche che traducono i requisiti dell’AI Act in soluzione e/o criteri tecnici concretamente applicabili da un fornitore e che garantiscono a questi la cosiddetta presunzione di conformità ai requisiti dell’AI Act.

Queste specifiche comuni vengono emesse dalla Commissione EU quando:

  • è stata richiesta ad un ente di normazione europeo (es CENELEC, ETSI,..) una norma armonizzata, ma questa non è ancora disponibile oppure non è stata ancora accettata dalla Commissione;
  • la norma armonizzata elaborata dall’ente normativo europeo non affronta adeguatamente determinati aspetti/requisiti e quindi va integrata;
  • non esiste una norma armonizzata pubblicata nella Gazzetta Ufficiale dell’UE che copra gli stessi requisiti.

Va comunque osservato che il fornitore non è obbligato in assoluto ad applicare le specifiche comuni. Può scegliere una soluzione tecnica alternativa, ma deve giustificare adeguatamente di aver adottato soluzioni che garantiscono un livello di conformità almeno equivalente ai requisiti dell’AI Act.

Il ruolo dei CAB e il processo di accreditamento

Un Conformity Assessment Body (CAB) è l’organismo che svolge attività di valutazione della conformità. Quando viene designato e notificato dall’Autorità di Notifica di uno Stato membro alla Commissione per operare nell’ambito dell’AI Act (articoli 28–31 del regolamento) esso diventa un Notified Body.

L’AI Act prevede che ogni Stato membro designi almeno una Notifying Authority, responsabile della valutazione, designazione, notifica e sorveglianza dei CAB. Lo Stato membro può decidere di affidare le attività di assessment e monitoraggio dei CAB al proprio National Accreditation Body (in Italia ACCREDIA), secondo il Regolamento (CE) 765/2008.

Nel processo di valutazione della conformità di un sistema di AI ad alto rischio, il Notified Body non si limita a verificare il software o il modello AI come prodotto isolato. La valutazione riguarda l’insieme dei processi e dei controlli attraverso i quali il fornitore sviluppa, gestisce e mantiene il sistema.

L’attività comprende, in particolare, la valutazione del Quality Management System, della documentazione tecnica, dei processi di sviluppo, verifica e validazione, della gestione del rischio, dei dati, del monitoraggio post entrata sul mercato, delle modifiche e delle misure adottate per mantenere la conformità nel tempo.

Il focus è quindi sul sistema AI e sulla capacità organizzativa e tecnica del fornitore di governarne il ciclo di vita.

Il Notified Body deve possedere requisiti di competenza tecnica, indipendenza, imparzialità, organizzazione, personale qualificato, gestione dei conflitti di interesse, riservatezza, risorse adeguate e capacità di svolgere le attività previste.

Il sistema europeo segue la logica di accreditamento, designazione e notifica degli organismi di valutazione della conformità. L’autorità notificante competente valuta l’organismo e, quando ricorrono le condizioni, procede alla notifica alla Commissione europea.

Va osservato che i requisiti richiesti per i CAB/Notified Body, sono gli stessi richiesti del CRA, a meno delle competenze specifiche.

La differenza principale è invece l’oggetto della valutazione: il CRA è focalizzato sulla cybersecurity dei prodotti con elementi digitali, mentre l’AI Act valuta un insieme più ampio di caratteristiche dei sistemi AI, tra cui gestione del rischio, qualità dei dati, trasparenza, supervisione umana, accuratezza, robustezza e cybersecurity.

Per questo motivo, un CAB già attivo nel CRA dispone potenzialmente di una parte significativa dell’infrastruttura organizzativa necessaria per operare anche nell’AI Act, ma deve incrementare le proprie competenze con quelle specifiche richieste dall’AI Act per la valutazione dei sistemi AI.

Modelli di AI per finalità generali GPAI

Per i modelli di AI per finalità generali (GPAI), l’AI Act non prevede una vera e propria procedura di valutazione della conformità analoga a quella prevista dall’art. 43 per i sistemi di AI ad alto rischio.

Il principio generale per un modello GPAI è che il fornitore deve innanzitutto dimostrare e documentare la conformità del modello agli obblighi dell’articolo 53 e, se applicabile, quelli dell’articolo 55 (sistemi di AI GPAI a rischio sistemico).

L’AI Act distingue tra due diversi modelli di AI:

  • sistemi di AI GPAI non a rischio sistemico;
  • sistemi di AI GPAI a rischio sistemico.

Per i primi (non a rischio sistemico) gli obblighi principali riguardano la documentazione tecnica del modello, le informazioni da fornire ai fornitori downstream, la politica sul rispetto del copyright e la pubblicazione della sintesi dei contenuti utilizzati per l’addestramento. La Commissione ha chiarito che questi obblighi sono in vigore dal 2 agosto 2025.

Per i modelli AI GPAI con rischio sistemico, il processo richiesto dall’AI Act è molto più simile ad una vera attività di assurance.

In pratica, il fornitore deve:

  • identificare/classificare il modello come GPAI con rischio sistemico;
  • notificare il sistema alla Commissione e all’AI Office;
  • predisporre la documentazione tecnica e il sistema di gestione della sicurezza;
  • effettuare una valutazione del modello che deve utilizzare protocolli e strumenti standardizzati che riflettano lo stato dell’arte;
  • effettuare e documentare l’adversarial testing che deve essere finalizzato soprattutto a individuare e mitigare i rischi sistemici;
  • valutare e mitigare i rischi sistemici non solo considerando il comportamento del modello, ma anche i rischi derivanti dal suo sviluppo, dalla commercializzazione e dall’utilizzo lungo la catena del valore;
  • implementare una cybersecurity adeguata, ovvero la protezione deve riguardare sia il modello GPAI sia l’infrastruttura fisica che lo supporta;
  • monitorare gli incidenti, ovvero tracciare, documentare e segnalare senza indebito ritardo all’AI Office e, se appropriato, alle Autorità Nazionali, gli incidenti gravi.

Per dimostrare la conformità ai requisiti suddetti, l’articolo 55 dell’AI Act prevede per i modelli di AI GPAI le seguenti opzioni:

  • utilizzo di una norma armonizzata europea che consente di dichiarare la presunzione di conformità, per gli aspetti coperti dalla norma;
  • in assenza della norma armonizzata, il fornitore può utilizzare il Codice di buone pratiche (vedi articolo 56) per dimostrare la conformità del sistema;
  • se il fornitore non aderisce al Codice e non applica una norma armonizzata, può utilizzare mezzi alternativi adeguati di conformità che però devono essere dimostrati e sottoposti alla valutazione dell’AI Office.

In sintesi, la differenza sostanziale tra i sistemi di AI ad alto rischio e i sistemi di AI tra i sistemi GPAI è che per quest’ultimi l’AI Act non costruisce un sistema generale di certificazione tramite organismi notificati, ma costruisce invece un sistema di accountability, documentazione, testing, gestione dei rischi e sorveglianza da parte dell’AI Office.

Conclusioni

Il processo di certificazione previsto dall’AI Act non è una semplice certificazione di prodotto, ma combina classificazione del rischio e gestione del rischio, qualità dei dati, cybersecurity, supervisione umana, documentazione tecnica, sistema di gestione della qualità, testing e monitoraggio dopo l’introduzione sul mercato.

Un aspetto interessante è che il legislatore ha scelto un approccio proporzionato, nel quale la valutazione interna rappresenta la regola per molti sistemi di AI, mentre la valutazione di terza parte è utilizzata per un numero limitato di tipologie di sistemi, almeno per il momento.

Analogamente, non cerca di creare un sistema di valutazione della conformità separato e parallelo agli altri, ma si inserisce nel New Legislative Framework (NLF) che è il quadro europeo il quale, dal 2008, stabilisce le regole comuni per la commercializzazione dei prodotti nel mercato interno, creando un modello omogeneo per requisiti di prodotto, valutazione della conformità, accreditamento, organismi notificati, marcatura CE e sorveglianza del mercato. Lo dimostra il fatto che quando un sistema di AI è integrato in un prodotto/sistema regolamentato, si integra la norma di riferimento inserendo requisiti specifici per l’AI e l’onere della valutazione della conformità rimane in capo alla norma del prodotto regolamentato.

Altro aspetto interessante è relativo ai CAB/Notified Body. L’articolo 29 prevede infatti che, nel caso di organismi già designati nell’ambito di altre legislazioni di armonizzazione dell’Unione, la documentazione e i certificati relativi alle precedenti designazioni possano essere utilizzati, quando appropriato, a supporto della nuova designazione.

Un CAB che opera già, ad esempio, nell’ambito di una normativa europea di prodotto (vedi CRA) potrebbe quindi avere una base organizzativa, procedurale e tecnica già molto vicina a quella richiesta dall’AI Act e dovrà solo dimostrare le competenze specifiche richieste per la valutazione dei sistemi AI.

Ultimo aspetto di interesse da segnalare è la relazione con le altre normative europee in ambito e standard di settore. Tralasciando il CRA e il CSA con i quali c’è un diretto riferimento nell’AI Act per gli aspetti di cybersecurity, le altre normative (es. NIS2, DORA, GDPR,..) e standard di riferimento (es. ISO 42001, ISO 9001, ISO 27001,..) possono comunque essere funzionali al raggiungimento della conformità dei sistemi di AI ai requisiti dell’AI Act. Infatti, tutte queste normative/standard richiedono l’implementazione di sistemi di gestione dei rischi, della qualità, dei dati, della cybersecurity che prevedono rigorosi requisiti per la governance aziendale, il controllo dei processi, la data governance, le attività di due diligence, la documentazione a supporto, il testing e così via. Questo crea di fatto un ambiente adatto per un’agevole recepimento dei requisiti previsti per la conformità all’AI Act.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x