Con l’introduzione della legge sull’AI n. 132/2025, diventa indispensabile per le organizzazioni che operano in settori ad alto rischio, adottare approcci strutturati per dimostrare l’affidabilità dei sistemi di intelligenza artificiale, garantendo al contempo la tutela dei diritti fondamentali e la sicurezza degli utenti.
Indice degli argomenti
L’Italia apre la strada alla normativa europea sull’intelligenza artificiale
L’Italia è infatti il primo Paese dell’Unione Europea a dotarsi di un quadro normativo nazionale pienamente allineato all’AI Act europeo. Dal 10 ottobre 2025, la nuova legge italiana sull’Intelligenza Artificiale impone obblighi stringenti in termini di tracciabilità, supervisione umana e sicurezza per tutti i sistemi di IA impiegati in settori ad alto rischio quali sanità, lavoro, istruzione, giustizia, pubblica amministrazione e attività sportive. Per “alto rischio” si intendono quei contesti in cui l’IA può impattare significativamente su diritti fondamentali, sicurezza o accesso a servizi essenziali, come definito dagli Allegati II e III dell’AI Act.
Evidence-based compliance: una risposta strutturata ai requisiti normativi
In questo scenario, dimostrare che un sistema sia affidabile, controllabile e verificabile, diventa un requisito essenziale per la conformità agli articoli 9-15 dell’AI Act (gestione del rischio, qualità dei dati, trasparenza). Una possibile risposta consiste nell’adottare un approccio di evidence-based compliance, supportato da una gerarchia dei livelli di evidenza in grado di guidare la valutazione e la verifica dei sistemi lungo tutto il loro ciclo di vita di un sistema di IA.
I livelli proposti sono cumulativi e progressivi: ogni livello superiore presuppone il completamento di quelli precedenti e aggiunge complessità e robustezza all’evidenza raccolta. La scelta di quale livello raggiungere dipende dal profilo di rischio del sistema e dalle risorse disponibili, ma sistemi ad alto rischio dovrebbero mirare almeno al livello E4.
Livello E1 e E2: test sintetici e validazione tramite benchmark
Il primo livello di evidenza deriva da quanto si può verificare in ambienti controllati: simulazioni, dati sintetici e stress test. È utile nelle prime fasi del ciclo di sviluppo per verificare funzionalità di base e identificare vulnerabilità evidenti, ma offre una generalizzabilità limitata, non garantendo che il sistema reagisca correttamente in condizioni d’uso reali o se sottoposto e evoluzioni.
Strumenti consigliati: sandbox, protocolli di sicurezza pre-rilascio, synthetic data.
Esempio: un sistema di triage sanitario può essere testato con scenari clinici simulati prima dell’implementazione, verificando che non presenti errori logici gravi.
Trade-off: Basso costo e rapida implementazione, ma limitata validità predittiva per contesti reali complessi.
Al secondo livello, l’evidenza proviene da dataset pubblici o benchmark standardizzati, conformi ai requisiti di qualità dei dati dell’articolo 10 dell’AI Act. Questa fase consente di effettuare un confronto tra sistemi e fornisce metriche utili per la documentazione tecnica richiesta dalla normativa, ma presenta una scarsa rappresentatività rispetto ai contesti reali, aspetto cruciale per i settori ad alto impatto.
Esempi: MMLU, GLUE/SuperGLUE, HumanEval, test di robustezza e bias come BOLD o WinoBias.
Caso d’uso: un sistema di valutazione automatica per concorsi pubblici può essere validato su benchmark di equità algoritmica per dimostrare l’assenza di discriminazioni sistematiche.
Trade-off: moderato impegno con buona comparabilità, ma rischio di overfitting sui benchmark e scarsa validità ecologica.
Livello E3: validazione contestuale per garantire rappresentatività e sicurezza
Il terzo livello introduce la valutazione in contesti d’uso realistici, in linea con l’articolo 9 dell’AI Act (gestione del rischio basata sul contesto). L’attenzione si sposta sul rapporto tra dati, utenti e ambiente operativo, un requisito essenziale per garantire sicurezza, equità e tracciabilità nei settori sensibili.
Un elemento chiave è l’analisi della completezza del dataset, ossia la capacità dei dati di rappresentare gruppi, situazioni e variabili presenti nel mondo reale. Criteri operativi includono:
- Diversità demografica: copertura minima di gruppi protetti (sesso, età, etnia) secondo distribuzioni rappresentative.
- Copertura situazionale: presenza di casi limite, situazioni rare e scenari edge.
- Metriche di bilanciamento: rapporti di rappresentazione, entropy score, coverage metrics.
Metodi: test di dominio, trial controllati con utenti reali, analisi della diversità e della copertura dei dati.
Esempio: un algoritmo per la selezione del personale dovrebbe essere testato su campioni rappresentativi di candidati reali, verificando che non penalizzi sistematicamente categorie protette.
Trade-off: richiede accesso a dati reali e collaborazione con stakeholder, ma fornisce evidenza molto più rilevante per la conformità.
Livello E4: trasparenza e audit attraverso test ibridi gray e white box
Il quarto livello combina test esterni (black box) e analisi interne del modello, rispondendo ai requisiti di trasparenza dell’articolo 13 dell’AI Act. Collegare i meccanismi interni del sistema ai suoi comportamenti osservabili consente di individuare vulnerabilità e bias con maggiore precisione, facilitando il rispetto delle normative che richiedono responsabilizzazione e supervisione umana.
Differenza tra approcci:
- Gray box: accesso parziale (es. feature importance, attention weights) – preferibile quando il modello è proprietario.
- White box: accesso completo all’architettura e ai pesi – ideale per audit approfonditi e sistemi critici.
Strumenti: audit basati su explainability (SHAP, LIME), analisi della robustezza (adversarial testing), trasparenza dei componenti, interpretability dashboards.
Esempio: un sistema di scoring creditizio può essere auditato analizzando quali feature influenzano maggiormente le decisioni, verificando che non emergano proxy discriminatori (es. codice postale come proxy di etnia).
Trade-off: richiede competenze specialistiche e può essere oneroso, ma è spesso indispensabile per sistemi ad alto rischio dove è richiesta piena accountability.
Livello E5: monitoraggio continuo per una compliance dinamica nel tempo
Il livello più alto riguarda l’accumulo di evidenze nel tempo durante l’uso effettivo del sistema, in conformità con l’articolo 72 dell’AI Act (obblighi post-market). È qui che si creano le condizioni per una compliance dinamica, capace di adattarsi a derive prestazionali (model drift), incidenti, feedback degli utenti e mutamenti del contesto operativo. Questo livello è cruciale perché molti bias e problemi emergono solo dopo il deployment, quando il sistema interagisce con la variabilità del mondo reale.
Attività tipiche:
- Tracciamento continuo delle prestazioni disaggregate per sottogruppi.
- Registri degli incidenti e near-miss (quasi-incidenti).
- Audit ciclici programmati (es. trimestrali).
- Indicatori di affidabilità: MTBF (Mean Time Between Failures), concept drift, performance decay.
- Meccanismi di feedback degli utenti e canali di segnalazione.
Esempio: un sistema di diagnosi medica assistita deve monitorare continuamente l’accuratezza per diverse popolazioni di pazienti, rilevando tempestivamente se l’efficacia diminuisce per specifici gruppi demografici o patologie emergenti.
Trade-off: richiede infrastruttura di monitoraggio e governance continua, ma è l’unico modo per garantire compliance nel lungo periodo e prevenire incidenti gravi.
I vantaggi della gerarchia dell’evidenza per organizzazioni e stakeholder
La nuova normativa non si limita a introdurre obblighi, ma invita le organizzazioni a ripensare la governance dell’IA in modo continuo e verificabile. Una gerarchia come quella proposta consente di:
- definire i livelli minimi di evidenza per ciascun settore o profilo di rischio,
- giustificare gli interventi di controllo in modo proporzionato e non arbitrario,
- migliorare la trasparenza, la supervisione umana e l’accountability,
- integrare verifiche tecniche e processuali all’interno di un unico framework,
- bilanciare costi implementativi e benefici in termini di riduzione del rischio.
Limiti e integrazioni necessarie per applicare il framework
Questa gerarchia fornisce una guida strutturata ma non sostituisce la valutazione legale specifica, l’analisi etica contestuale o la consultazione con stakeholder. In casi particolarmente complessi o innovativi, potrebbe essere necessario integrare metodi aggiuntivi o sviluppare protocolli ad hoc.
