Articolo 15 per l’IA delle infrastrutture critiche: accuratezza, robustezza e cibersicurezza
Come si applica l’articolo 15 (accuratezza, robustezza, cibersicurezza) all’IA delle infrastrutture critiche: l’aggancio dell’allegato III, punto 2, le date, i ruoli di fornitore e deployer e le sanzioni.
I fornitori di sistemi di IA ad alto rischio per le infrastrutture critiche devono progettarli con accuratezza, robustezza e cibersicurezza adeguate (articolo 15).
Il regolamento non ha un regime generale per le infrastrutture critiche; l’aggancio è l’allegato III, punto 2, dal 2 dicembre 2027. Il fornitore dichiara i livelli e le metriche di accuratezza nelle istruzioni per l’uso (articolo 15, paragrafo 3). Le sanzioni arrivano a 15 milioni di EUR o, per un’impresa, al 3 % del fatturato mondiale annuo, se superiore (articolo 99, paragrafo 4). Prossimo passo: elencate le metriche che dichiarerete.
L’articolo 15 chiede un livello adeguato, non un numero fisso
L’articolo 15 fissa requisiti di progettazione per il fornitore. Non indica alcun valore di accuratezza per alcun settore.
- art. 15(1)Livello adeguato, per tutto il ciclo di vita
I sistemi di IA ad alto rischio devono essere progettati e sviluppati in modo da raggiungere un adeguato livello di accuratezza, robustezza e cibersicurezza e da funzionare in modo coerente in tal senso per tutto il loro ciclo di vita.
- art. 15(2)I parametri di riferimento li promuove la Commissione
La Commissione promuove, se del caso, lo sviluppo di parametri di riferimento e di metodologie di misurazione, in cooperazione con portatori di interessi quali le autorità di metrologia e di analisi comparativa. Non è un obbligo del fornitore.
- art. 15(3)Dichiarare livelli e metriche
I livelli di accuratezza e le metriche di accuratezza pertinenti devono essere dichiarati nelle istruzioni per l’uso che accompagnano il sistema.
- art. 15(4)Resilienza agli errori e circuiti di feedback
I sistemi devono essere il più resilienti possibile rispetto a errori, guasti o incongruenze che possono verificarsi nel sistema o nell’ambiente in cui opera, in particolare a causa dell’interazione con persone fisiche o altri sistemi. Devono essere adottate misure tecniche e organizzative; ridondanza tecnica, piani di backup o di sicurezza intrinseca sono citati come opzioni. Un sistema che continua ad apprendere dopo l’immissione sul mercato deve essere sviluppato in modo da eliminare o ridurre il più possibile il rischio che output distorti influenzino input futuri (circuiti di feedback).
- art. 15(5)Cibersicurezza contro terzi non autorizzati
I sistemi devono essere resilienti ai tentativi di terzi non autorizzati di alterarne l’uso, gli output o le prestazioni sfruttando le vulnerabilità. Le soluzioni tecniche comprendono, se del caso, misure contro l’avvelenamento dei dati, l’avvelenamento del modello, gli esempi avversari o l’elusione del modello, gli attacchi alla riservatezza e le carenze del modello.
Quale IA delle infrastrutture critiche deve rispettare l’articolo 15
L’articolo 15 vincola solo i sistemi di IA ad alto rischio. Le righe seguenti mostrano quando l’IA delle infrastrutture critiche diventa ad alto rischio.
Il regolamento non ha un regime generale per le infrastrutture critiche
Il regolamento non ha un regime settoriale generale per energia, acqua o trasporti. Questo sito usa la parola per l’IA impiegata nella fornitura di elettricità, gas, riscaldamento e acqua, nel traffico stradale e nelle infrastrutture digitali. Questa IA rientra nel regolamento tramite l’allegato III, punto 2, l’ambito ad alto rischio intitolato «infrastrutture critiche». Il regolamento definisce le infrastrutture critiche rinviando alla direttiva (UE) 2022/2557 (articolo 3, punto 62); il considerando 55 collega le infrastrutture digitali critiche al punto 8 dell’allegato di tale direttiva. Il punto 2 nomina le infrastrutture digitali critiche, il traffico stradale e la fornitura di acqua, gas, riscaldamento o elettricità. Non nomina le ferrovie, l’aviazione, il trasporto marittimo né gli strumenti di previsione e ottimizzazione; l’appartenenza di un sistema al punto 2 dipende dalla finalità prevista (articolo 3, punto 12).
Allegato III, punto 2: componenti di sicurezza
L’allegato III, punto 2, riguarda i sistemi di IA destinati a essere utilizzati come componenti di sicurezza nella gestione e nel funzionamento delle infrastrutture digitali critiche, del traffico stradale o nella fornitura di acqua, gas, riscaldamento o elettricità. Un componente di sicurezza è un componente di un prodotto o di un sistema di IA che svolge una funzione di sicurezza o il cui guasto o malfunzionamento mette a rischio la salute e la sicurezza delle persone o dei beni; un componente svolge una funzione di sicurezza quando la sua finalità prevista è prevenire o attenuare rischi per la salute e la sicurezza delle persone o dei beni (articolo 3, punto 14). I sistemi di IA usati esclusivamente per aspetti non legati alla sicurezza, come l’assistenza all’utente, l’ottimizzazione delle prestazioni, l’efficienza del servizio, l’automazione, la comodità o il controllo della qualità, non sono componenti di sicurezza; i sistemi di IA il cui guasto o malfunzionamento metterebbe a rischio la salute e la sicurezza lo sono (articolo 6, paragrafi 1 bis e 1 ter). Il considerando 55, che non è una disposizione normativa, aggiunge che i componenti destinati a essere utilizzati esclusivamente per finalità di cibersicurezza non dovrebbero essere considerati componenti di sicurezza. L’articolo 6, paragrafo 5, prevede orientamenti della Commissione con un elenco completo di esempi pratici di casi d’uso ad alto rischio e non ad alto rischio, entro il 2 febbraio 2026. Ai sensi dell’articolo 6, paragrafo 2, i sistemi di IA di cui all’allegato III sono considerati ad alto rischio. Il fornitore che ritiene che un tale sistema non sia ad alto rischio ai sensi dell’articolo 6, paragrafo 3 deve documentare la propria valutazione prima che il sistema sia immesso sul mercato o messo in servizio, e registrarlo a norma dell’articolo 49, paragrafo 2. La deroga non si applica mai quando il sistema esegue profilazione di persone fisiche. Per profilazione si intende la profilazione quale definita all’articolo 4, punto 4), del regolamento (UE) 2016/679 (articolo 3, punto 52).
Le ferrovie non sono nominate: allegato I, sezione B
Un sistema che è un componente di sicurezza di un prodotto disciplinato dalla direttiva (UE) 2016/797 relativa all’interoperabilità del sistema ferroviario dell’Unione europea (punto 17 della sezione B dell’allegato I) e che è ad alto rischio ai sensi dell’articolo 6, paragrafo 1 rientra nell’articolo 2, paragrafo 2: si applicano solo l’articolo 6, paragrafo 1, l’articolo 60 bis e gli articoli da 102 a 112, e gli articoli 57, 58 e 59 si applicano solo nella misura in cui i requisiti per i sistemi di IA ad alto rischio previsti dal regolamento sono stati integrati in tale normativa di armonizzazione dell’Unione. Gli articoli da 9 a 15, 17 e 26 non ne fanno parte.
Fornitore e deployer
Il fornitore sviluppa il sistema di IA, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome (articolo 3, punto 3); può essere un produttore di software di controllo o di protezione o un’azienda di servizi che sviluppa un sistema per uso proprio. Una persona fisica o giuridica, un’autorità pubblica, un’agenzia o un altro organismo che utilizza un sistema sotto la propria autorità è un deployer (articolo 3, punto 4); per esempio, un gestore di reti elettriche, del gas o del riscaldamento, un’azienda idrica, un’autorità stradale o un gestore di data center. Un deployer diventa fornitore se appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, ne apporta una modifica sostanziale che lo lascia ad alto rischio, o modifica la finalità prevista di un sistema non ad alto rischio in modo che lo diventi (articolo 25, paragrafo 1).
Date
L’allegato III, punto 2 si applica dal 2 dicembre 2027 (articolo 113, lettera c)). Un sistema immesso sul mercato o messo in servizio prima di tale data è coperto solo se dopo subisce modifiche significative della progettazione; in ogni caso, i fornitori e i deployer di sistemi di IA ad alto rischio destinati a essere utilizzati da autorità pubbliche devono adottare le misure necessarie per conformarsi entro il 2 agosto 2030 (articolo 111, paragrafo 2).
Sanzioni
La violazione degli obblighi dei fornitori (articolo 16) e dei deployer (articolo 26) può essere punita con sanzioni amministrative pecuniarie fino a 15 milioni di EUR o, per un’impresa, fino al 3 % del fatturato mondiale totale annuo dell’esercizio precedente, se superiore (articolo 99, paragrafo 4). Per le PMI, comprese le start-up, ogni sanzione arriva al massimo all’importo più basso (articolo 99, paragrafo 6). Lo stesso massimale vale per le piccole imprese a media capitalizzazione (articolo 3, punto 14 ter, articolo 99, paragrafo 6 bis). Ogni Stato membro stabilisce le norme sulla misura in cui possono essere imposte sanzioni amministrative pecuniarie alle autorità e agli organismi pubblici istituiti in tale Stato membro (articolo 99, paragrafo 8).
Limiti dell’ambito di applicazione del regolamento
Il regolamento si applica ai fornitori che immettono sul mercato o mettono in servizio sistemi di IA nell’Unione, o immettono sul mercato modelli di IA per finalità generali nell’Unione, indipendentemente da dove siano stabiliti (articolo 2, paragrafo 1, lettera a)), e ai fornitori e ai deployer stabiliti in un paese terzo quando l’output del sistema di IA è utilizzato nell’Unione (lettera c)). Non si applica ai settori che non rientrano nell’ambito di applicazione del diritto dell’Unione e non pregiudica le competenze degli Stati membri in materia di sicurezza nazionale; non si applica nemmeno ai sistemi di IA utilizzati esclusivamente per scopi militari, di difesa o di sicurezza nazionale (articolo 2, paragrafo 3). Il regolamento non si applica ai sistemi o modelli di IA, compreso il loro output, specificamente sviluppati e messi in servizio al solo scopo di ricerca e sviluppo scientifici (articolo 2, paragrafo 6). Non si applica neppure alle attività di ricerca, prova e sviluppo precedenti all’immissione sul mercato o alla messa in servizio di un sistema o modello; le prove in condizioni reali non rientrano in tale esclusione (articolo 2, paragrafo 8). Non si applica ai sistemi di IA rilasciati con licenza libera e open source, a meno che siano immessi sul mercato o messi in servizio come sistemi di IA ad alto rischio o come sistemi di IA che rientrano nell’articolo 5 o 50 (articolo 2, paragrafo 12).
Che cosa il regolamento lascia aperto per le infrastrutture critiche
Nessun valore di accuratezza per le infrastrutture critiche
L’articolo 15 non indica per alcun settore una metrica di accuratezza, un valore minimo, un metodo di prova o una norma, né per le infrastrutture critiche. Il fornitore dichiara i livelli e le metriche pertinenti (articolo 15, paragrafo 3). Le norme armonizzate i cui riferimenti sono pubblicati nella Gazzetta ufficiale danno una presunzione di conformità nella misura in cui coprono i requisiti (articolo 40, paragrafo 1); un certificato di cibersicurezza pubblicato ai sensi del regolamento (UE) 2019/881 la dà per i requisiti di cibersicurezza nella misura in cui li copre (articolo 42, paragrafo 2). I sistemi che rientrano nell’ambito di applicazione del regolamento (UE) 2024/2847 e soddisfano le condizioni dell’articolo 12, paragrafo 1, di tale regolamento si considerano conformi ai requisiti di cibersicurezza dell’articolo 15 (articolo 42, paragrafo 3). La Commissione elabora orientamenti sull’applicazione dei requisiti e degli obblighi degli articoli da 8 a 15 e degli articoli 25 e 26 (articolo 96, paragrafo 1, lettera a)).
La normativa sulla cibersicurezza esterna al regolamento sull’IA
Il regolamento non menziona la direttiva (UE) 2022/2555 (spesso chiamata NIS2). I suoi collegamenti espressi con altre norme sulla cibersicurezza sono le presunzioni dell’articolo 42, paragrafo 2 (certificazione ai sensi del regolamento (UE) 2019/881) e dell’articolo 42, paragrafo 3 (regolamento (UE) 2024/2847, il regolamento sulla ciberresilienza). L’applicabilità della NIS2 a un’organizzazione è stabilita da tale direttiva e dal diritto nazionale, non dal regolamento sull’IA. La Commissione elabora orientamenti sul rapporto del regolamento con altre norme pertinenti del diritto dell’Unione (articolo 96, paragrafo 1, lettera e)).
Esempio: metriche dichiarate per un componente di sicurezza
Esempio, non un requisito del regolamento: il fornitore di un componente di sicurezza per una rete idrica o elettrica potrebbe dichiarare quali metriche di accuratezza ha misurato e indicare il tipo di rete e la configurazione dei sensori su cui le ha misurate.
Esempio: documentare il comportamento di sicurezza intrinseca
Esempio, non un requisito del regolamento: il fornitore potrebbe documentare che cosa fa il sistema quando i dati di input mancano o sono inverosimili, ad esempio cedendo il controllo alla logica di controllo esistente senza IA, come modo per descrivere i piani di sicurezza intrinseca citati all’articolo 15, paragrafo 4.
Domande sull’articolo 15 nelle infrastrutture critiche
L’articolo 15 fissa valori di accuratezza per l’IA di reti, acqua o traffico?
No. L’articolo 15, paragrafo 1, richiede un livello adeguato e l’articolo 15, paragrafo 3, impone al fornitore di dichiarare i livelli e le metriche pertinenti nelle istruzioni per l’uso. Il regolamento non indica alcun valore, metrica o metodo di prova per le infrastrutture critiche.
L’articolo 15 rende obbligatoria la conformità alla NIS2?
No. Il regolamento sull’IA non menziona la direttiva (UE) 2022/2555. L’articolo 15, paragrafo 5, richiede che i sistemi di IA ad alto rischio siano resilienti ai tentativi di terzi non autorizzati di alterarne l’uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema. Ai sensi dell’articolo 42, paragrafo 3, i sistemi che rientrano nell’ambito di applicazione del regolamento (UE) 2024/2847 e soddisfano le condizioni dell’articolo 12, paragrafo 1, di tale regolamento si considerano conformi ai requisiti di cibersicurezza dell’articolo 15.
Chi deve rispettare l’articolo 15 quando un gestore di rete acquista un sistema con componenti di sicurezza?
Il fornitore progetta il sistema in modo che rispetti l’articolo 15 (articolo 16, lettera a)). Il gestore di rete è un deployer e usa il sistema secondo le istruzioni per l’uso (articolo 26, paragrafo 1). Il deployer che appone il proprio nome sul sistema, effettua una modifica sostanziale o cambia la finalità prevista diventa fornitore (articolo 25, paragrafo 1).
Uno strumento di ottimizzazione della rete o di manutenzione predittiva è soggetto all’articolo 15?
Solo se è un sistema di IA ad alto rischio. L’allegato III, punto 2, riguarda i sistemi destinati a essere utilizzati come componenti di sicurezza. I sistemi di IA usati esclusivamente per aspetti non legati alla sicurezza, come l’ottimizzazione delle prestazioni, l’efficienza del servizio, l’automazione o il controllo della qualità, non sono componenti di sicurezza; quelli il cui guasto o malfunzionamento metterebbe a rischio la salute e la sicurezza lo sono (articolo 6, paragrafi 1 bis e 1 ter). Il regolamento non nomina l’ottimizzazione della rete né la manutenzione predittiva; decide la finalità prevista (articolo 3, punto 12). L’articolo 6, paragrafo 5, prevede orientamenti della Commissione con esempi pratici di casi d’uso ad alto rischio e non ad alto rischio.
Pagine correlate
Articolo 15 regolamento IA: accuratezza, robustezza e cibersicurezza
L’articolo 15 per tutti i settori: requisiti, date e sanzioni.
Regolamento IA infrastruttura critica: conformità
Panoramica sulle infrastrutture critiche: come il regolamento raggiunge l’IA in energia, acqua, traffico stradale e infrastrutture digitali.
Articolo 17 per l’IA delle infrastrutture critiche: sistema di gestione della qualità
L’IA delle infrastrutture critiche e l’articolo 17: i 13 aspetti e chi è il fornitore.
Allegato III in dettaglio: le 8 categorie ad alto rischio
Gli otto ambiti dell’allegato III, comprese le infrastrutture critiche.
Scanara prepara evidenze dai vostri repository
Scanara legge i vostri repository GitHub collegati ed esegue scansioni basate su regole per individuare pattern comuni di IA e machine learning. Può non rilevare il codice non standard. Separatamente genera bozze di documentazione a partire da modelli e dalle vostre risposte alle valutazioni, come evidenze per il vostro lavoro di conformità. La classificazione la decidete voi.