ia2023

Glossario dell’Intelligenza Artificiale

Glossario Intelligenza Artificiale

Glossario dell’Intelligenza Artificiale

Versione 1.0 – data revisione: 19-8-2025

Compilato a partire da

 

Realizzato per uso didattico e professionale. Questo glossario non sostituisce il testo ufficiale delle norme o del regolamento.

Indice (ordine alfabetico)

Accountability (Responsabilizzazione)

Nell’ecosistema dell’IA, l’accountability è la condizione per cui persone o organizzazioni sono chiamate a rispondere di azioni, decisioni e prestazioni legate a sistemi di IA. Non coincide con la mera “responsabilità legale”, ma attiene all’assegnazione chiara di ruoli, criteri e mezzi di verifica: chi fa cosa, rispetto a che standard, con quale tracciabilità e con quali conseguenze. Le norme ISO insistono sul legame tra accountability e allocazione di responsabilità lungo tutto il ciclo di vita (sviluppo, messa in servizio, uso, sorveglianza post-market), nonché sulla necessità di documentare scelte, assunzioni e controlli. In pratica, un’organizzazione “accountable” dimostra, in modo verificabile, come assicura sicurezza, affidabilità e conformità del proprio sistema di IA. Questa dimostrabilità si concretizza in documentazione tecnica, registri, piani di monitoraggio e procedure di miglioramento continuo che permettono audit e controlli esterni efficaci.

Accuratezza (Accuracy)

Misura il grado con cui gli output di un sistema di IA corrispondono ai risultati attesi rispetto alla sua finalità prevista. È una proprietà osservabile tramite metriche e test, e va contestualizzata per popolazioni, scenari e soglie operative: un sistema può essere accurato in media ma meno preciso su gruppi specifici. Le buone pratiche richiedono che la documentazione tecnica descriva le metriche usate per misurare accuratezza e robustezza, i risultati dei test e gli impatti potenzialmente discriminatori, promuovendo una valutazione tracciabile e verificabile delle prestazioni. Nell’impostazione ISO/IEC 22989 l’accuratezza rientra nella più ampia “performance”, intesa come risultato misurabile del sistema che va osservato con metodi appropriati lungo il ciclo di vita. È essenziale definire soglie accettabili, controlli di validazione su dataset indipendenti e piani per il monitoraggio operativo, così da intercettare tempestivamente il degrado delle prestazioni (drift).

Audit (Auditabilità)

L’auditabilità indica quanto un’organizzazione e il suo sistema di IA possono essere esaminati da terzi (interni o esterni) per comprovare conformità, controlli e prestazioni. Un sistema auditabile è progettato e gestito per rendere disponibili evidenze: log strutturati, documentazione tecnica completa, istruzioni per l’uso, piani di test e tracciabilità delle decisioni. ISO/IEC 42001 prevede audit interni periodici del sistema di gestione per l’IA e richiede che funzioni, procedure e registrazioni consentano verifiche efficaci. Nell’ecosistema regolatorio, i moduli di valutazione della conformità possono includere audit di vigilanza da parte di organismi notificati sul sistema di gestione della qualità e sulla documentazione tecnica, con possibilità di prove supplementari e obbligo di reportistica. La vera auditabilità dipende da governance dei dati, chiarezza dei processi e completezza dei dossier tecnici lungo l’intero ciclo di vita.

Audit interno (per i sistemi di gestione IA)

Processo sistematico, indipendente e documentato con cui un’organizzazione verifica a intervalli pianificati se il proprio sistema di gestione per l’IA è conforme ai requisiti interni e allo standard, ed è efficacemente attuato e mantenuto. Include la definizione di un programma di audit (frequenza, metodi, responsabilità), criteri e obiettivi dell’audit, selezione di auditor imparziali e la reportistica ai responsabili competenti. Gli esiti alimentano il riesame della direzione e il miglioramento continuo. La norma richiede di mantenere “documented information” sia sul programma sia sui risultati degli audit, così da poter dimostrare conformità ed efficacia del sistema. Un programma robusto di audit interno favorisce la prevenzione delle non conformità, la prontezza alle verifiche esterne e la maturità organizzativa nel governo dell’IA.

Autonomia e livello di automazione

Un sistema “automatico” esegue funzioni senza intervento umano in condizioni specificate; l’“autonomia” è la capacità di modificare obiettivi o dominio d’uso senza controllo esterno. ISO/IEC 22989 distingue i concetti, ricordando che i sistemi di IA operano con livelli variabili di automazione e che l’oversight umano resta necessario almeno in addestramento e validazione. La corretta progettazione deve esplicitare dove il controllo umano entra nel ciclo decisionale (prima, durante o dopo l’azione), come si applicano arresti o procedure di handover, e quali limiti operativi prevengono derive non intenzionali. Definire chiaramente il livello di automazione consente di calibrare responsabilità, competenze richieste, interfacce uomo-macchina e requisiti di sicurezza, garantendo coerenza tra obiettivi, rischio e contesto d’uso.

Banca dati UE dei sistemi di IA (registrazione)

Per aumentare trasparenza e vigilanza, il quadro europeo introduce una banca dati per i sistemi di IA ad alto rischio: prima dell’immissione sul mercato o della messa in servizio, il fornitore (o il suo rappresentante) registra il sistema; i deployer pubblici registrano inoltre il proprio uso. Parte dei dati è pubblica e ricercabile, con sezioni riservate per ambiti sensibili. Modifiche sostanziali vanno aggiornate e l’infrastruttura funge da supporto ad audit ex-post e monitoraggio successivo all’immissione. La registrazione crea una “memoria regolatoria” che facilita scambi tra autorità, operatori e cittadini, migliorando la tracciabilità delle tecnologie e abilitando analisi sistemiche su emergenza di rischi e pattern di utilizzo, anche in relazione ai diversi settori applicativi.

Bias (Pregiudizio) e Fairness (Equità)

Nel lessico ISO, “bias” è una differenza sistematica di trattamento tra oggetti o persone (percezione, rappresentazione, previsione, decisione). Nelle applicazioni di IA, parte del bias è inevitabile e funzionale (serve a distinguere i casi), ma l’“unfairness” è il trattamento differenziale ingiustificato che può sfociare in discriminazioni. Le fonti sono interrelate: bias umani e decisionali, bias nei dati (campionamento, etichettatura), scelte ingegneristiche. Il trattamento del bias richiede misure tecniche e organizzative su dati, modelli e processi (metriche di equità, test, mitigazioni), oltre a requisiti di governance e documentazione per la tracciabilità delle scelte. Minimizzare l’unfairness è obiettivo continuo, misurabile e auditabile, con coinvolgimento degli stakeholder e attenzione alle categorie protette e ai contesti d’uso ad alto impatto.

Bilanciamento tra trasparenza e riservatezza

La trasparenza è un requisito-ombrello che riguarda sia l’organizzazione sia i sistemi: rendere disponibili informazioni appropriate (finalità, limiti, dati, metodi, misure di qualità, livello di automazione) ai portatori di interesse. Tuttavia, la trasparenza non è assoluta: divulgazioni improprie possono violare sicurezza, privacy o confidenzialità (ad es. segreti commerciali). Perciò il “quanto” e “come” comunicare vanno calibrati sul rischio, sugli obblighi normativi e sui diritti in gioco, distinguendo tra trasparenza organizzativa e di sistema e adottando salvaguardie (controlli d’accesso, astrazione, sintesi). Questa tensione, esplicitata negli standard, guida la progettazione di dossier tecnici, istruzioni per l’uso e informative, consentendo nello stesso tempo verifiche e audit senza compromettere interessi legittimi dell’organizzazione o la sicurezza complessiva.

Categorizzazione biometrica

Per “categorizzazione biometrica” s’intende l’assegnazione di persone a categorie specifiche in base ai loro dati biometrici (es. età, sesso, tratti del volto e del corpo, caratteristiche comportamentali). Nel quadro europeo, la nozione è distinta dall’identificazione/verifica: può comportare rischi elevati per diritti e libertà, specie se applicata in spazi pubblici o su larga scala. Le implicazioni normative riguardano basi giuridiche, proporzionalità, necessità e tutele specifiche, con forti presidi informativi verso le persone interessate. È cruciale valutare accuratezza, bias e rischi di discriminazione prima del deployment, e predisporre meccanismi di sorveglianza umana, registri e controlli tecnici per minimizzare gli esiti ingiustificati, con possibilità di audit e verifiche indipendenti.

Catena del valore dell’IA (operatori e ruoli)

La catena del valore dell’IA comprende più operatori: fornitore, deployer, rappresentante autorizzato, importatore, distributore, integratore e, talvolta, terze parti che forniscono componenti o modificano una soluzione. Ognuno ha doveri specifici: etichettatura, conservazione della documentazione, log, interventi correttivi, cooperazione con le autorità. ISO/IEC 42001 invita a mappare i ruoli organizzativi (developer, tester, ML engineer, data steward, responsabile compliance) perché il ruolo influenza controlli e applicabilità dei requisiti del sistema di gestione per l’IA. Coordinare questi ruoli è essenziale per la compliance e per il governo del rischio sull’intero ciclo di vita, evitando lacune nella responsabilizzazione e nella gestione delle interfacce tra processi e attori diversi.

Cibersicurezza (Cybersecurity) dell’IA

Comprende misure tecniche e organizzative per proteggere il sistema da manipolazioni, esfiltrazioni e abusi, tenendo conto delle vulnerabilità specifiche dei modelli. Tra le minacce tipiche: data poisoning e model poisoning, attacchi adversarial (evasion), prompt injection, model leakage e inferenze sensibili. La sicurezza deve essere proporzionata ai rischi e integrata nel ciclo di vita (dalla supply chain ai rilasci), con test e controlli documentati. La robustezza di sicurezza è distinta ma correlata alle prestazioni: un modello affidabile deve anche resistere a input malevoli e fallire in modo sicuro. Misure quali difese a livello di dati, hardening dei modelli, sandboxing, monitoraggio runtime e gestione delle vulnerabilità contribuiscono alla resilienza complessiva del sistema.

Ciclo di vita del sistema di IA

È l’evoluzione del sistema dall’ideazione al ritiro. ISO/IEC 22989 mappa le fasi chiave (progettazione/dati/modelli; verifica e validazione; deployment; operazione e monitoraggio) e ne sottolinea la natura iterativa, diversa dal software tradizionale. L’impostazione allinea il ciclo alle raccomandazioni internazionali, includendo requisiti di tracciabilità e gestione del rischio in ogni fase. Il modello guida la definizione di processi, controlli e decisioni di re-training, re-evaluation e retirement, assicurando che prestazioni e rischi restino entro soglie accettabili durante l’esercizio. Vanno previsti momenti di gate decisionali, metriche e responsabilità chiare per passaggi di stato, nonché piani di ritiro e dismissione ordinata.

Classificazione del rischio (proibito, alto rischio, trasparenza; GPAI)

Il quadro europeo distingue pratiche vietate (es. social scoring, manipolazioni subliminali, determinate applicazioni biometriche), sistemi ad alto rischio soggetti a requisiti rigorosi, e categorie soggette a obblighi di trasparenza (ad es. sistemi che interagiscono con persone o generano contenuti sintetici). Per i modelli di IA per finalità generali (GPAI) è introdotta una classe “a rischio sistemico” con criteri tecnici, inclusa una soglia indicativa basata sulla potenza di addestramento cumulata. La classificazione guida documentazione, audit, registrazione e controlli proporzionati. Definire correttamente la categoria applicabile è decisivo per impostare processi, risorse e tempi di conformità, evitando sottostime del rischio ed eccessi di oneri ingiustificati.

Codici di buone pratiche (per i modelli GPAI)

L’Ufficio per l’IA promuove codici di buone pratiche europei che aiutano i fornitori di modelli di IA per finalità generali (GPAI) a rispettare obblighi di trasparenza, gestione dei rischi sistemici, documentazione e reporting. I codici definiscono obiettivi, impegni, KPI e misure proporzionate; possono essere approvati dalla Commissione con validità generale. Finché non esistono norme armonizzate di riferimento, l’adesione può fornire un mezzo pratico per dimostrare conformità, specie per modelli con “rischio sistemico”. I codici coprono, tra l’altro, la sintesi dei contenuti di training, la tassonomia dei rischi e le procedure di valutazione/attenuazione lungo la catena del valore, inclusi test di robustezza e piani di risposta a incidenti.

Conformità presunta, norme armonizzate e specifiche comuni

Il meccanismo di “presunzione di conformità” consente a fornitori e operatori di dimostrare, in via semplificata, il rispetto degli obblighi facendo riferimento a norme europee armonizzate. In loro assenza o insufficienza, la Commissione può adottare “specifiche comuni” tramite atti di esecuzione. Anche per i modelli GPAI l’adesione a norme o a codici approvati facilita la dimostrazione di conformità della documentazione tecnica e dei processi. Questo quadro si integra con requisiti di gestione qualità e tracciabilità, consente adattamenti al progresso tecnico e riduce oneri duplicati, promuovendo al contempo livelli omogenei di tutela dei diritti e di sicurezza in tutto il mercato interno.

Contenuti sintetici e marcatura (provenienza/“watermarking”)

Gli output generativi (testo, immagini, audio, video) possono alterare fiducia e integrità dell’ecosistema informativo. Le migliori pratiche prevedono che i fornitori integrino soluzioni tecniche per marcare in modo leggibile dalle macchine i contenuti generati o manipolati dall’IA, promuovendo metadati, filigrane, metodi crittografici di provenienza e altre tecniche interoperabili. Inoltre, i deployer devono segnalare chiaramente i “deepfake” quando presentano contenuti che appaiono falsamente autentici. La marcatura può essere a livello di modello o di sistema e va calibrata su limiti tecnici e tipologie di media; deve anche essere accompagnata da informative chiare agli utenti e da processi di verifica periodica dell’efficacia contro rimozioni o trasformazioni.

Controllabilità

La controllabilità è la proprietà per cui un agente esterno (tipicamente un umano competente) può intervenire sul funzionamento del sistema di IA. È distinta ma collegata a spiegabilità e trasparenza: sapere “come” e “perché” il sistema agisce facilita l’intervento corretto, inclusa la possibilità di override. È cruciale in contesti ad alto impatto (sanità, giustizia, sicurezza), dove occorrono meccanismi affidabili per fermare, modificare o riportare a condizioni sicure un sistema quando emergono condizioni inattese. La progettazione deve includere scelte architetturali, interfacce e procedure di escalation; test e addestramento del personale completano il quadro, assicurando che l’intervento umano sia efficace e tempestivo, riducendo rischio e impatti indesiderati.

Dati sintetici e data augmentation

Per data augmentation si intendono campioni sintetici creati modificando o usando dati esistenti (p.es. trasformazioni, generazione controllata). L’uso responsabile richiede regole su provenienza, qualità, rappresentatività e privacy: i sintetici possono ridurre squilibri e proteggere informazioni personali, ma anche introdurre bias se generati da modelli imparzialmente addestrati o se non si validano gli effetti sui gruppi minoritari. Gli standard collegano i sintetici ai compiti dell’IA e raccomandano di documentare categorie e fonti dati (incluse fonti “synthetic”), diritti d’uso, metadati e processo di acquisizione. È opportuno misurare l’impatto dei sintetici sulla performance e sulla fairness, prevedendo meccanismi di controllo continuo in esercizio.

Dati: addestramento, convalida, prova e produzione

La gestione dei dati è centrale per qualità e affidabilità. ISO/IEC 22989 definisce i set: validation data (per confrontare modelli candidati), test data (per valutare il modello finale) e production data (input in esercizio). La separazione tra training/validation/test previene stime ottimistiche e leakage; in carenza di dati, si ricorre a strategie come cross-validation o data augmentation. Le pratiche di governance impongono regole per raccolta, annotazione, pulizia, analisi di bias, completezza e adeguatezza rispetto alla finalità e ai rischi del caso d’uso. Documentare qualità e provenienza dei dataset, assieme a versioning e controlli di accesso, abilita tracciabilità, audit e miglioramento continuo delle prestazioni.

Dichiarazione di conformità UE

Documento con cui il fornitore attesta che un sistema di IA ad alto rischio soddisfa i requisiti essenziali applicabili. È unica ove si applichino più normative di armonizzazione, deve identificare il sistema, essere mantenuta aggiornata e resa disponibile alle autorità per 10 anni. La dichiarazione comporta l’assunzione di responsabilità da parte del fornitore; il suo contenuto può essere aggiornato con atti delegati, tenendo conto del progresso tecnico. È strettamente collegata al fascicolo tecnico e alla marcatura CE, e funge da “carta d’identità regolatoria” del sistema, richiamando norme armonizzate, specifiche comuni, procedure seguite e risultati delle valutazioni effettuate lungo il ciclo di vita.

Drift dei dati e del modello (convalida continua)

I sistemi che apprendono nel tempo sono esposti a drift (cambiamenti nei dati o nell’ambiente che degradano le prestazioni). Le buone pratiche raccomandano “convalida continua” in esercizio: si monitora l’operatività con dati di test aggiornati, si rivalutano obiettivi e requisiti e si perfezionano i piani di trattamento del rischio. Un sistema di gestione per l’IA dovrebbe integrare tali controlli nei processi di monitoraggio, misurazione e audit interni, collegando i risultati a riesami e azioni di miglioramento. Tecniche come il rilevamento del data shift, il controllo di concetto (concept drift) e la ricalibrazione periodica aiutano a mantenere performance e fairness entro soglie accettabili, riducendo il rischio di decisioni errate dovute a cambiamenti non intercettati.

Fornitore (Provider) di sistemi o modelli di IA

È l’organizzazione (o persona) che sviluppa o fa sviluppare un sistema di IA o un modello di IA per finalità generali e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio. Oltre alla progettazione conforme ai requisiti essenziali, il fornitore di sistemi ad alto rischio deve predisporre un sistema di gestione della qualità, la documentazione tecnica, la procedura di valutazione di conformità e un piano di monitoraggio successivo all’immissione sul mercato, attivo e proporzionato ai rischi, con raccolta e analisi sistematica di dati sulle prestazioni e sugli incidenti. L’obiettivo è mantenere il controllo del rischio e la tracciabilità anche dopo il rilascio, coordinando gli attori della catena del valore.

FRIA – Valutazione d’impatto sui diritti fondamentali

Obbligo per i deployer pubblici (e privati che forniscono servizi pubblici) e per taluni usi ad alto rischio di svolgere, prima del primo impiego, una valutazione dell’impatto sui diritti fondamentali dell’uso del sistema. La FRIA descrive processi coinvolti, durata/frequenza d’uso, categorie di persone interessate, rischi specifici e misure di sorveglianza umana; prevede piani d’azione, meccanismi di reclamo e mitigazioni concrete. Integra eventuali DPIA privacy già svolte e va aggiornata quando cambiano fattori rilevanti. La notifica dell’esito all’autorità competente e l’aggancio al monitoraggio post-market garantiscono che i rischi siano seguiti e ridotti nel tempo, con un coinvolgimento adeguato degli stakeholder impattati.

Gestione del rischio (Risk Management)

Processo iterativo che copre l’intero ciclo di vita: identificazione e analisi dei rischi prevedibili (per salute, sicurezza e diritti fondamentali), stima e valutazione anche in condizioni di uso improprio ragionevolmente prevedibile, misure di mitigazione mirate, riesame continuo e documentato. Un sistema di gestione dei rischi deve essere calibrato sullo stato dell’arte e aggiornato con l’evidenza del monitoraggio post-market, coinvolgendo stakeholder ed esperti quando opportuno. Gli esiti devono tradursi in rischi residui accettabili e in decisioni verificabili di rilascio o ritiro, con collegamenti stretti alla documentazione tecnica, alle istruzioni per l’uso e ai processi di audit e sorveglianza.

Governance dei dati e qualità dei dataset

La qualità del dato è fondativa: uno schema di governance definisce ruoli e controlli per raccolta, preparazione, aggiornamento e accesso. Gli standard discutono bias e fairness, chiarendo che distorsioni possono emergere da dati, scelte progettuali e bias cognitivi; vanno rilevate e mitigate. Oltre a log e documentazione tecnica, il quadro regolatorio disciplina l’uso di categorie particolari di dati (ad es. per rilevare e correggere distorsioni) con tutele privacy stringenti. Un governo dei dati robusto unisce tracciabilità, controlli su provenienza e versioning, pulizia/filtraggio e gestione dei consensi, a supporto di trasparenza, spiegabilità, sicurezza e verificabilità dell’intero ciclo di vita del sistema di IA.

Identificazione biometrica remota (in tempo reale e a posteriori)

Il quadro normativo distingue i sistemi di identificazione biometrica remota “in tempo reale” (rilevamento, confronto e identificazione senza ritardi significativi, spesso con flussi video live) da quelli “a posteriori” (confronto su materiale già acquisito). La disciplina è particolarmente stringente in spazi pubblici e, per le attività di contrasto, prevede tutele, condizioni e autorizzazioni preventive, oltre a obblighi di registrazione e valutazioni d’impatto. È esclusa la mera verifica/autenticazione per accesso a servizi o dispositivi. La distinzione tra real-time e post-evento è determinante per proporzionalità, basi giuridiche e misure di salvaguardia, e richiede accurati controlli su accuratezza, bias e rischi di errore.

Immissione sul mercato e messa in servizio (definizioni chiave)

“Immissione sul mercato” è la prima messa a disposizione di un sistema o modello nell’UE; “messa in servizio” è la fornitura per il primo uso (anche per uso proprio del fornitore) in linea con la finalità prevista. Queste soglie attivano obblighi: documentazione tecnica pronta e aggiornata, marcatura CE ove applicabile, registrazioni e log per la tracciabilità. La chiarezza terminologica evita equivoci fra “sviluppo”, “rilascio” e “uso”, e coordina le tempistiche di valutazione della conformità e di sorveglianza post-market. La corretta qualificazione influisce su responsabilità, obblighi informativi e possibilità di audit, anche in relazione a modifiche sostanziali o cambi di destinazione d’uso.

Importatore, Distributore e Rappresentante autorizzato (obblighi)

Gli importatori devono garantire che i sistemi soddisfino i requisiti, conservare documenti (istruzioni, certificati) per 10 anni e cooperare con le autorità. I distributori verificano marcatura CE, dichiarazione UE, istruzioni e non mettono a disposizione sistemi non conformi; in caso di rischi, adottano o sollecitano misure correttive e informano fornitore e autorità. Il rappresentante autorizzato (per fornitori extra-UE) detiene documentazione, assiste nelle verifiche e funge da interfaccia formale con le autorità per 10 anni dalla messa a disposizione. La chiarezza dei doveri lungo la catena di fornitura migliora la vigilanza e la risposta strutturata alle non conformità.

Incidente grave (definizione e segnalazione)

È un incidente o malfunzionamento di un sistema di IA che causi decesso o gravi danni alla salute, danni gravi a cose/ambiente, violazioni di obblighi UE sulla tutela dei diritti fondamentali o gravi perturbazioni di infrastrutture critiche. I fornitori (e in taluni casi i deployer) devono segnalare senza indugio all’autorità competente: in generale entro 15 giorni dal nesso causale ragionevolmente probabile; in caso di infrazione diffusa entro 2 giorni; in caso di decesso immediatamente e comunque entro 10 giorni. Seguono indagini, misure correttive e cooperazione con autorità e organismi notificati. Una gestione efficace degli incidenti include registro interno, root cause analysis e azioni preventive.

Istruzioni per l’uso (contenuti e destinatari)

Le istruzioni per l’uso descrivono finalità prevista e uso corretto; devono rendere interpretabile l’output e supportare un impiego adeguato da parte dei deployer. Un buon pacchetto informativo chiarisce limiti, fabbisogni di supervisione umana, accuratezza attesa, condizioni per l’override, contatti e requisiti ambientali/tecnici. L’informazione va accessibile e aggiornata, tenendo conto dell’uso previsto e dell’uso improprio ragionevolmente prevedibile. Le istruzioni si integrano con documentazione tecnica e piani di monitoraggio post-market, favorendo trasparenza, responsabilizzazione dei ruoli e controlli efficaci sull’intero ciclo di vita del sistema.

Logging e conservazione dei log

I log sono fondamentali per tracciabilità, investigazioni, miglioramento continuo e difesa in sicurezza. È buona pratica abilitare la registrazione eventi almeno in esercizio (cosa, quando, chi, input/output, scostamenti dai limiti operativi), mantenendoli secondo policy e vincoli legali. L’obbligo di conservazione dei log nella misura sotto il controllo del fornitore, per un periodo adeguato alla finalità prevista del sistema, rafforza accountability e capacità di gestione incidenti. Vanno definiti ruoli e responsabilità per l’accesso, procedure di anonimizzazione quando necessario e misure di integrità dei log (firme, catene di hash) per prevenire manipolazioni.

Marcatura CE

I sistemi di IA ad alto rischio che superano con esito positivo la valutazione di conformità recano la marcatura CE, fisica o digitale (se forniti digitalmente e facilmente accessibile). Se interviene un organismo notificato nel modulo di conformità, al marchio segue il suo numero identificativo. La marcatura CE indica conformità anche ad altre normative UE applicabili e deve essere apposta in modo visibile, leggibile e indelebile (o su imballaggio/documenti se l’apposizione sul sistema non è possibile). È lo strumento che abilita la libera circolazione nel mercato interno e rende chiara la responsabilità del fornitore in merito alla conformità del sistema.

Misure correttive: ritiro e richiamo

Se un sistema ad alto rischio immesso sul mercato o messo in servizio non è conforme, il fornitore deve intervenire senza indugio: rendere conforme, ritirare dalla catena di fornitura o richiamare (restituzione o disabilitazione presso i deployer). Deve informare distributori, deployer, rappresentante e importatori e, se sussiste rischio, notificare l’autorità di vigilanza e l’organismo notificato. La definizione formale di “ritiro” e “richiamo” assicura reazioni coordinate quando emergono non conformità o rischi, e richiede piani di comunicazione e tracciabilità per individuare rapidamente utenti affetti, aggiornare documentazione e ridurre gli effetti sull’ecosistema.

Modello di IA per finalità generali (GPAI)

Un modello capace di svolgere con competenza un’ampia gamma di compiti diversi, spesso addestrato su grandi moli di dati (autosupervisione, non supervisionato, rinforzo) e distribuito come libreria, API o download; da solo non è un “sistema di IA” finché non è integrato con altri componenti (es. interfaccia utente). Il quadro europeo stabilisce obblighi specifici per GPAI e, in particolare, per quelli “con rischi sistemici”, anche quando i modelli sono integrati in sistemi a valle. Il testo fornisce indicazioni su generalità, parametri e modalità di mercato, chiarendo la diversa natura tra “modello” e “sistema”, e legando gli obblighi a trasparenza, sicurezza, reportistica e contenuti di training.

Monitoraggio successivo all’immissione sul mercato (Post-Market Monitoring)

Dopo il rilascio, i fornitori devono istituire un sistema proporzionato per raccogliere, documentare e analizzare in modo attivo e sistematico dati sulle prestazioni reali, inclusi feedback dei deployer e fonti esterne. L’obiettivo è individuare tempestivamente cali di performance, rischi emergenti, impatti inattesi su diritti fondamentali, quindi aggiornare misure correttive, documentazione e, se del caso, progettazione e dati. Un piano definito (PMS) integra questa funzione con obblighi di segnalazione di incidenti gravi. Coinvolgere le funzioni operative e di sicurezza, oltre a canali di escalation e revisione periodica, è essenziale per l’efficacia del monitoraggio.

Organismo notificato (Notified Body)

Ente con personalità giuridica istituito da uno Stato membro, notificato alla Commissione e agli altri Stati, competente a svolgere attività di valutazione di conformità per specifici tipi di sistemi (moduli, ambiti). La notifica segue una procedura formale e richiede dimostrazione di competenza e disposizioni per il monitoraggio periodico; in assenza di obiezioni entro i termini, l’ente può operare come organismo notificato. I requisiti riguardano indipendenza, imparzialità, risorse e processi, nonché qualità della reportistica e capacità di effettuare prove o richiedere prove supplementari in relazione ai sistemi di IA oggetto di valutazione.

Piano di monitoraggio successivo all’immissione sul mercato (PMS)

Il fornitore di un sistema ad alto rischio deve istituire e mantenere un sistema di monitoraggio post-market, basato su un piano che entra a far parte della documentazione tecnica. Scopo: assicurare che il sistema continui a rispettare i requisiti essenziali, includendo – se del caso – l’analisi di interazioni con altri sistemi di IA. Un modello dettagliato per il piano può essere definito a livello europeo; ove esistano già obblighi settoriali, è possibile integrare i requisiti generali per evitare duplicazioni, a condizione di garantire protezione equivalente. Il PMS va collegato a risk management, sorveglianza umana e processi di change management.

Prevedibilità (Predictability)

Proprietà che consente agli stakeholder di formulare assunzioni affidabili sugli output del sistema. Nella pratica, significa che, date certe condizioni d’uso e dati di input, l’intervallo di comportamenti del modello è noto e stabile. ISO/IEC 22989 definisce la prevedibilità come qualità distinta da affidabilità e robustezza; rispetto al software tradizionale, i sistemi di IA sono spesso meno prevedibili e richiedono iterazioni e esperienza operativa per raggiungere livelli accettabili. Di conseguenza, test statistici, limiti operativi, validazione indipendente e monitoraggio continuo diventano essenziali per mantenere il comportamento entro soglie accettabili e ridurre sorprese negative in esercizio.

Provenienza dei dati (Data Provenance)

Processo e registrazione della “storia” dei dati usati nello sviluppo e nell’operazione di un sistema di IA: creazione, aggiornamenti, trasformazioni, trasferimenti di controllo o condivisioni, etichette/arricchimenti, diritti (PII, copyright), fonti (interne, acquistate, open, sintetiche), caratteristiche (statiche/streaming), demografie e possibili bias. Documentare e verificare la provenienza aiuta trasparenza, spiegabilità, qualità e difesa da minacce (data poisoning, incoerenze). La provenienza è un controllo raccomandato nei sistemi di gestione per l’IA e consente collegamenti robusti tra dati, modelli, risultati di test e decisioni di rilascio, supportando audit e responsabilizzazione lungo la catena del valore.

Registrazione nella banca dati UE

Prima di immettere o mettere in servizio un sistema ad alto rischio, il fornitore si registra e registra il sistema nella banca dati europea; anche i deployer pubblici devono registrare il proprio uso. La registrazione supporta la tracciabilità delle soluzioni sul mercato, l’attività delle autorità e la trasparenza regolatoria. Esistono inoltre obblighi di registrazione per sistemi dichiarati non ad alto rischio secondo criteri specifici. Le informazioni alimentano un database centrale che facilita coordinamento e vigilanza, permette analisi aggregate e migliora la capacità di risposta a incidenti o non conformità diffuse.

Resilienza

Capacità del sistema di recuperare rapidamente uno stato operativo accettabile dopo un incidente (tecnico, di sicurezza, operativo). In ambito IA implica fallback, ridondanze, graceful degradation e procedure di ripristino che minimizzino impatti su utenti e terzi. Gli standard richiedono che i sistemi ad alto rischio siano resilienti a errori interni, incongruenze e interazioni con persone o altri sistemi, adottando misure tecniche/organizzative adeguate, anche rispetto a tentativi di terzi di manipolarne comportamento e output. La resilienza si misura e si prova con scenari avversi, esercitazioni e test periodici, e si sostiene con formazione e chiare responsabilità operative.

Rischio sistemico (nei modelli GPAI)

Un modello GPAI è classificato “con rischio sistemico” se mostra capacità d’impatto elevato secondo metodologie e benchmark adeguati o in base a decisione delle autorità competenti supportata da esperti; è prevista una presunzione quando il calcolo cumulativo di addestramento supera una soglia definita e aggiornabile nel tempo. La qualifica comporta obblighi rafforzati, tra cui gestione dei rischi, cyber-security adeguata all’intero ciclo di vita, test e reportistica di incidenti gravi. La ratio è mitigare effetti negativi che potrebbero propagarsi a settori, comunità o all’intero mercato interno, vista la portata e riusabilità di questi modelli e la loro integrazione pervasiva a valle.

Robustezza

È l’abilità di mantenere il livello di prestazioni “sotto ogni circostanza” entro i limiti dichiarati. Una robustezza adeguata include resistenza a rumore, drift dei dati, condizioni non ideali e attacchi mirati, e si dimostra con metriche, prove e stress-test. Gli obblighi tecnici richiedono che la documentazione includa metriche e risultati di prova sulla robustezza e che i sistemi ad alto rischio adottino soluzioni di ridondanza (backup, fail-safe) quando opportuno. Robustezza e sicurezza sono complementari: un sistema robusto deve anche essere cyber-resiliente e progettato per degradare in modo sicuro, con allarmi tempestivi e meccanismi di blocco controllato.

Sistema di gestione per l’IA (SGIA) – ISO/IEC 42001

ISO/IEC 42001 definisce requisiti per un sistema di gestione organizzativo dedicato all’IA (politiche, obiettivi, ruoli, processi, competenze, controlli) integrato nei processi aziendali. Include pratiche per: definire e documentare un ciclo di vita “responsabile” (requisiti, dati, addestramento, verifica/validazione, rilascio, sorveglianza), gestire rischi e impatti (anche con AI system impact assessment), assicurare uso responsabile (fairness, sorveglianza umana, affidabilità, privacy e sicurezza), coinvolgere le parti interessate e mantenere evidenze (log, valutazioni, decisioni). Il SGIA rende sistemica la conformità, allineandola alle aspettative normative e ai ruoli lungo la catena (fornitori, integratori, utilizzatori).

Sistema di IA

Per il regolatore europeo, è un sistema automatizzato pensato per operare con diversi livelli di autonomia e potenziale adattabilità dopo la diffusione, che, a partire dagli input, genera output (previsioni, contenuti, raccomandazioni o decisioni) capaci di influenzare ambienti fisici o virtuali. La definizione è funzionale e tecnologicamente neutra, centrata sul comportamento e sugli effetti dell’output. Ciò consente di abbracciare sia approcci simbolici sia statistici (machine learning), includendo casi d’uso emergenti (generazione di contenuti, supporto decisionale). È la definizione giuridica cardine da cui discendono classificazioni (rischio, ambiti vietati) e obblighi, con impatti diretti su responsabilità e tracciabilità degli operatori.

Sistema di valutazione della conformità (AI Act) / Valutazione della conformità

Per i sistemi ad alto rischio, il fornitore deve dimostrare la conformità ai requisiti essenziali (governance dei dati, documentazione tecnica, tracciabilità, robustezza, sorveglianza umana, ecc.) seguendo procedure codificate: controllo interno, oppure valutazione del sistema di gestione della qualità e della documentazione tecnica, con eventuale organismo notificato. La dichiarazione di conformità UE richiama norme armonizzate o specifiche comuni utilizzate e collega il sistema a una catena di tracciabilità post-market (monitoraggio, registrazione incidenti, aggiornamenti). Queste procedure sono proporzionate al rischio e favoriscono la fiducia nel mercato unico.

Sorveglianza del mercato e cooperazione con le autorità

Le autorità nazionali possono richiedere documentazione, accedere ai log sotto controllo del fornitore e verificare l’adempimento dei requisiti. Fornitori, importatori e distributori devono cooperare e condividere le informazioni in lingua comprensibile; i distributori, in particolare, segnalano non conformità e rischi e collaborano alla riduzione/mitigazione. Questo quadro abilita controlli ex-ante ed ex-post, incident reporting e, se necessario, azioni correttive e restrizioni d’uso, rafforzando l’affidabilità dell’ecosistema. Il coordinamento europeo e lo scambio di dati tra autorità aumentano l’efficacia delle azioni di vigilanza sul mercato unico digitale.

Sorveglianza umana (Human Oversight)

È l’insieme di misure, interfacce e procedure che permettono a persone competenti di prevenire o attenuare rischi derivanti dall’uso del sistema, interpretarne gli output e intervenire quando necessario. È richiesto che nelle istruzioni e nella documentazione siano specificate le misure di sorveglianza e che le interfacce facilitino l’interpretabilità per i deployer. Gli standard evidenziano che l’oversight è tipicamente presente almeno in addestramento/validazione e che il grado di supervisione dipende dal caso d’uso, da definire esplicitamente nei requisiti e nelle istruzioni. La progettazione deve includere allarmi, limiti operativi, funzioni di stop e escalation a operatori qualificati.

Specifiche comuni (Common Specifications)

Se le norme armonizzate non sono disponibili, tardano o non coprono adeguatamente diritti fondamentali, la Commissione può adottare specifiche comuni tramite atti di esecuzione. La conformità a tali specifiche fa presumere la conformità ai requisiti essenziali, finché non saranno pubblicate norme armonizzate idonee. Il meccanismo serve a garantire certezza giuridica e livello di tutela omogeneo, allineando requisiti tecnici e obblighi operativi in assenza (o in attesa) di standard EN. Le specifiche comuni possono riguardare metodi di prova, metriche, contenuti minimi della documentazione e modelli organizzativi di riferimento per particolari categorie di sistemi.

Spiegabilità (Explainability)

È la capacità di esprimere in modo comprensibile i fattori che influenzano gli output del sistema. Serve a supportare fiducia, validazione e controllabilità, soprattutto quando le decisioni incidono su persone. La spiegabilità è più agevole per modelli simbolici/regole, mentre reti profonde possono richiedere tecniche specifiche (es. spiegazioni locali, saliency). La spiegazione non pretende di dimostrare l’ottimalità assoluta, ma di rispondere al “perché” dell’output, comunicando limiti, assunzioni, dati e processi rilevanti. È componente complementare a trasparenza e documentazione, e va progettata rispetto al pubblico di riferimento, con esempi, avvertenze e metriche di fedeltà.

Stato dell’arte (tecnico e regolatorio)

I requisiti e le soglie operative si aggiornano alla luce dello “stato dell’arte” tecnologico e regolatorio. Questo implica che procedure, misure di sicurezza e valutazioni vengano riviste nel tempo, integrando norme armonizzate, linee guida e metodi via via più maturi. Per i modelli GPAI, ad esempio, soglie e criteri di rischio possono essere aggiornati, riflettendo la rapida evoluzione della potenza di calcolo e delle tecniche. Un approccio basato sullo stato dell’arte richiede meccanismi organizzativi per la sorveglianza normativa, la formazione continua e l’aggiornamento dei processi, così da mantenere la conformità e la protezione effettiva dei diritti.

Tracciabilità e trasparenza del sistema

La tracciabilità richiede di poter ricostruire in modo affidabile come e con quali dati, componenti e procedure un’IA ha prodotto un certo output: si lega quindi a concetti come explainability, transparency e predictability. La trasparenza, intesa come messa a disposizione di informazioni appropriate (finalità, limiti, dati, modelli, algoritmi, QA), sostiene obiettivi human-centered e fiducia, ma va bilanciata per non violare sicurezza e privacy; la predictability aiuta l’accettabilità sociale consentendo assunzioni affidabili sul comportamento del sistema. Insieme, questi principi guidano progettazione, comunicazione e governance e informano le scelte su documentazione tecnica, istruzioni per l’uso e controlli operativi.

Trasparenza

Proprietà dell’organizzazione e del sistema: comunicare informazioni appropriate su obiettivi, limiti, dati, modelli, scelte progettuali, livelli di automazione, processi di qualità e tutela dei dati. Gli standard distinguono trasparenza “di sistema” (dettagli tecnici su performance, limiti, dati, assunzioni) e “di organizzazione” (decisioni e attività rese comprensibili agli stakeholder), notando che l’eccesso di disclosure può confliggere con sicurezza, privacy o segreti. In chiave regolatoria, la trasparenza supporta valutazioni, audit e diritti informativi, e si traduce in documentazione tecnica, registri, istruzioni per l’uso, informative agli utenti e, per alcuni casi, alla banca dati europea. L’obiettivo è una fiducia informata e verificabile.

Uso previsto e uso improprio ragionevolmente prevedibile

La “finalità prevista” descrive contesto e condizioni d’uso dichiarate dal fornitore; l’“uso improprio ragionevolmente prevedibile” copre impieghi non conformi ma prevedibili per comportamento umano o interazione con altri sistemi. Le pratiche di gestione richiedono di calibrare informazioni, controlli e valutazioni proprio su questi concetti, validando che la comunicazione agli utenti sia completa, accessibile e aggiornata. Incorporare finalità e usi prevedibili nel design, nelle istruzioni e nel monitoraggio riduce rischi di sicurezza, unfairness e inefficacia operativa e migliora l’affidabilità delle decisioni lungo l’intero ciclo di vita del sistema.

Valutazione d’impatto del sistema di IA (AI System Impact Assessment)

Processo formale e documentato per identificare, valutare e affrontare impatti su individui, gruppi e società derivanti da prodotti o servizi che impiegano IA. È uno strumento di governance che integra aspetti etico-sociali (equità, diritti fondamentali), tecnici (accuratezza, robustezza), organizzativi (competenze, sorveglianza umana) e giuridici (basi legali, proporzionalità). I risultati alimentano obiettivi, controlli, decisioni di rilascio, monitoraggio e miglioramento continuo, e possono supportare doveri informativi verso autorità e stakeholder. In ambito pubblico, il coinvolgimento dei portatori di interesse rafforza la legittimità delle scelte e la mitigazione dei rischi.

Verifica e Convalida (V&V)

La “verifica” accerta che il sistema sia costruito correttamente rispetto a specifiche e requisiti; la “convalida” che sia il sistema giusto per la finalità prevista e le esigenze degli stakeholder. ISO/IEC 22989 colloca V&V come stadio cardine del ciclo di vita, prima del deployment e insieme al monitoraggio operativo. Le buone pratiche inseriscono test e convalida nel sistema di gestione della qualità, specificando che le procedure siano pianificate, documentate e ripetute prima, durante e dopo lo sviluppo, con frequenza definita e metriche adeguate all’uso previsto. La V&V si estende anche agli aggiornamenti, ai modelli sostitutivi e alle modifiche sostanziali.

Vigilanza del mercato (Market Surveillance)

Le autorità applicano regole orizzontali sui prodotti ai sistemi di IA: controlli su prodotti/servizi immessi sul mercato, poteri di richiesta informazioni e coordinamento a livello europeo, report annuali e scambio di dati. L’obiettivo è verificare la conformità, intervenire su non conformità e rischi, e garantire la tutela degli utenti. Il perimetro applicativo copre tutti i sistemi rientranti nel regolamento, assicurando un’applicazione efficace e uniforme. Per gli operatori, la cooperazione tempestiva, la qualità della documentazione tecnica e la capacità di attuare misure correttive sono elementi decisivi per una relazione efficace con le autorità di vigilanza.

↑

ia2023 è un’idea di Pasquale Popolizio – pasquale@ia2023.it – Privacy policy