dI Paolo Canfora

La Fondazione Olivetti Tecnologia e Ricerca presenta una piattaforma sviluppata, secondo quanto comunicato dall’ente, insieme a istituzioni di Spagna, Romania, Francia e Germania e messa gratuitamente a disposizione della Commissione europea. L’obiettivo è costruire un metodo comune per verificare i sistemi di intelligenza artificiale, controllare le filiere digitali dei Paesi membri e candidati e aprire un nuovo fronte strategico con gli Stati Uniti nel campo della cyber intelligence e delle tecnologie per la difesa.

L’Europa ha scritto la legge più ambiziosa al mondo sull’intelligenza artificiale. Adesso deve dimostrare di saperla applicare.

Dal 2 agosto 2026 l’AI Act è entrato nella sua fase operativa generale e l’AI Office della Commissione europea, insieme alle autorità nazionali competenti, ha iniziato il percorso di applicazione e controllo, pur con scadenze differenziate per alcune categorie di sistemi ad alto rischio. È il momento nel quale la qualità di una normativa non si misura più dalla forza delle sue dichiarazioni, ma dalla capacità di verificare ciò che realmente accade dentro i software, nelle organizzazioni che li utilizzano e lungo le filiere internazionali da cui dipendono. (Strategia Digitale Europea)

È precisamente dentro questa distanza tra la norma scritta e la sua attuazione concreta che si colloca l’iA Act Compliance Controller, il progetto realizzato dalla Fondazione Olivetti Tecnologia e Ricerca. Non un altro documento da archiviare, non una checklist da compilare frettolosamente e nemmeno un bollino da esibire sul sito aziendale. Il Controller nasce per trasformare la conformità in un fascicolo ricostruibile, nel quale restano collegati la descrizione del sistema, il ruolo dell’organizzazione, le risposte fornite, i documenti esaminati, i controlli eseguiti, le criticità individuate, le azioni correttive, le approvazioni e le diverse versioni del software.

La Commissione europea dispone già di un proprio AI Act Compliance Checker, attualmente presentato come uno strumento ufficiale in versione beta, destinato ad aiutare provider, deployer e altri operatori a comprendere quali disposizioni possano applicarsi a un determinato sistema. Il valore aggiunto del progetto della Fondazione si collocherebbe però nel cosiddetto “secondo miglio” della compliance: non soltanto capire quali regole possano essere applicabili, ma dimostrare come siano state rispettate, quali prove siano state raccolte, chi abbia assunto le decisioni, quali lacune restino aperte e con quale piano debbano essere risolte. (AI Act Service Desk)

La presentazione tecnica del Controller descrive un percorso articolato in cinque passaggi pubblici, quattro livelli di rischio, 118 domande guidate e otto famiglie di risultati. Il sistema parte dall’identificazione del caso d’uso, prosegue con la classificazione del rischio e la definizione degli obblighi, raccoglie le evidenze e conclude con findings, azioni correttive, rating, report e piano di miglioramento.

Il questionario non è identico per tutti, perché si adatta al ruolo dell’organizzazione, alla finalità del sistema, al rischio e alle risposte precedenti. Una società che sviluppa un modello non può essere valutata come un’impresa che si limita a utilizzarlo; un programma che seleziona lavoratori non può essere trattato come un filtro antispam; un sistema impiegato in una struttura sanitaria non può essere analizzato con le stesse cautele di un’applicazione ricreativa. Ogni risposta deve essere motivata, collegata a evidenze e comprensibile anche da un revisore che non abbia partecipato allo sviluppo del progetto.

Da queste informazioni viene generata una mappa dei requisiti che distingue ciò che è applicabile, ciò che non lo è, ciò che deve ancora essere verificato e ciò che costituisce una condizione bloccante. Il sistema non si limita quindi a produrre un punteggio, ma tenta di spiegare da dove quel risultato provenga. Le carenze diventano findings classificati per severità, assegnati a un responsabile e collegati a un piano di remediation con scadenze, prove attese e criteri di chiusura.

Secondo quanto comunicato dalla Fondazione, questo lavoro non sarebbe stato sviluppato in una dimensione esclusivamente italiana. Al progetto avrebbero partecipato istituzioni e competenze provenienti da Spagna, Romania, Francia e Germania, con l’intento di superare la frammentazione nazionale e costruire una lingua operativa comune. È questo uno degli aspetti politicamente più rilevanti dell’iniziativa: una legge europea non può essere applicata attraverso ventisette interpretazioni tecnologiche incompatibili, ventisette modelli documentali differenti e ventisette sistemi incapaci di dialogare tra loro.

La Fondazione definisce la messa a disposizione del Controller alla Commissione europea come una vera e propria donazione tecnologica e metodologica. Bruxelles potrebbe valutarne l’utilizzo, integrarlo con gli strumenti già esistenti, sperimentarlo attraverso progetti pilota e, una volta conclusi i necessari controlli giuridici, tecnici e di sicurezza, distribuirlo alle amministrazioni e alle organizzazioni dei Paesi dell’Unione.

L’adozione europea non potrebbe naturalmente essere automatica. Sarebbero necessari la validazione indipendente del ruleset, il controllo della sicurezza del codice, la verifica della protezione dei dati, l’interoperabilità con i sistemi nazionali, la definizione delle responsabilità istituzionali e una chiara separazione tra assistenza, autovalutazione, vigilanza e certificazione. La prospettiva, tuttavia, è significativa: trasformare il Controller in una piattaforma comune attraverso la quale imprese, enti pubblici, università, strutture sanitarie e autorità possano descrivere un sistema, documentarne il funzionamento e mantenere una storia verificabile delle modifiche.

La sua funzione non dovrebbe essere quella di sostituire le autorità, ma di rendere il loro lavoro più rapido e attendibile. Un’autorità di controllo non dovrebbe ricevere soltanto una dichiarazione con la quale un’impresa afferma di essere conforme. Dovrebbe poter esaminare quale versione del modello sia stata valutata, quali dataset siano stati utilizzati, quali test siano stati eseguiti, chi abbia verificato la supervisione umana, quali incidenti siano stati registrati, quali dipendenze esterne esistano e quali interventi siano stati completati.

È altrettanto importante non confondere questa capacità operativa con una certificazione automatica. Lo stesso manuale della piattaforma specifica che il rating interno — articolato nelle classi A, B, C, D, E, X e U — serve a rappresentare maturità, completezza, qualità delle evidenze e severità delle criticità, ma non costituisce un’attestazione legale di conformità.

Questa distinzione rafforza, anziché indebolire, il progetto. Un software responsabile non dovrebbe promettere sentenze automatiche su questioni normative complesse. Dovrebbe organizzare i fatti, rendere visibili le assunzioni e consentire alle persone autorizzate di assumere decisioni informate. Persino l’assistente integrato nel Controller è progettato per spiegare concetti e fonti, non per modificare autonomamente classificazioni, findings o report.

La dimensione europea del progetto non si limita tuttavia ai ventisette Stati membri. Uno dei fronti più delicati riguarda i Paesi candidati all’ingresso nell’Unione, nei quali la trasformazione digitale procede con velocità differenti rispetto alla maturazione delle strutture di controllo, delle competenze amministrative e dei sistemi di sicurezza.

Albania e Macedonia del Nord possiedono entrambe lo status di Paese candidato. Il percorso di adesione richiede non soltanto l’adozione formale dell’acquis europeo, ma anche la capacità amministrativa e tecnica di applicarlo e farlo rispettare. (Enlargement and Eastern Neighbourhood)

Secondo quanto riferito dalla Fondazione, alcune attività di analisi hanno già riguardato software sviluppati in questi due Paesi. Non si tratta — e non dovrebbe mai trattarsi — di formulare un giudizio politico generalizzato sulle nazioni o sulle capacità dei loro programmatori. Il tema è molto più concreto: verificare se i prodotti digitali destinati a entrare nelle amministrazioni, nelle imprese o nelle infrastrutture europee dispongano di documentazione tecnica sufficiente, controllo delle versioni, registrazione degli accessi, governance dei dati, supervisione umana, gestione degli incidenti e procedure di aggiornamento sicure.

Le valutazioni ufficiali della Commissione mostrano del resto un quadro articolato. Per l’Albania vengono riconosciute l’adozione di una strategia nazionale di cibersicurezza e altre iniziative, ma viene anche indicata la necessità di rafforzare ulteriormente le capacità operative e completare l’attuazione della legislazione. Per la Macedonia del Nord la preparazione nell’area della trasformazione digitale e dei media viene considerata moderata, con ulteriori allineamenti richiesti rispetto alla direttiva NIS2, al quadro europeo delle comunicazioni e agli strumenti di sicurezza delle reti 5G. (Enlargement and Eastern Neighbourhood)

Sono proprio queste differenze a rendere utile un Controller comune. Il rischio non deriva dal passaporto del software, ma dall’opacità della sua filiera. Un programma sviluppato fuori dall’Unione può essere perfettamente documentato, sicuro e verificabile; un sistema realizzato dentro l’Unione può invece essere fragile, privo di log, alimentato da dati di provenienza incerta o dipendente da componenti non controllate. L’origine geografica non deve diventare né una presunzione di colpevolezza né un lasciapassare.

Gli alert che la Fondazione intende trasmettere a Bruxelles e alle autorità italiane dovrebbero quindi essere costruiti su indicatori tecnici misurabili. Tra questi rientrano l’impossibilità di identificare la versione effettivamente in uso, l’assenza di documentazione sulle modifiche, l’utilizzo di dataset non tracciabili, la mancanza di test sui bias, la presenza di aggiornamenti remoti non governati, l’assenza di procedure di risposta agli incidenti, l’insufficiente separazione degli accessi amministrativi, l’utilizzo di fornitori non dichiarati e la mancanza di prove sulla supervisione umana.

Un alert serio non dovrebbe dire semplicemente che un Paese “non è pronto”. Dovrebbe indicare quale sistema è stato analizzato, in quale versione, con quali fonti, quali controlli sono mancanti, quale rischio può prodursi e quale azione potrebbe ridurlo. È la differenza tra intelligence e pregiudizio, tra vigilanza e propaganda, tra sicurezza reale e costruzione di un nemico immaginario.

Il Controller potrebbe così assumere una funzione ulteriore: diventare un radar sulle filiere digitali che si avvicinano al mercato europeo. Non per bloccare l’innovazione dei Paesi candidati, ma per accompagnarla verso gli standard necessari all’integrazione. In questo modo, gli alert non sarebbero semplici segnalazioni punitive, bensì strumenti per individuare carenze, definire remediation e misurare l’effettivo miglioramento nel tempo.

Il secondo percorso strategico annunciato dalla Fondazione riguarda il settore militare, la cyber intelligence e la protezione delle infrastrutture critiche, in collaborazione con competenze e interlocutori statunitensi. In questo campo la Fondazione rivendica un posizionamento avanzato, fondato sulla capacità di correlare dati, individuare anomalie, analizzare dipendenze tecnologiche e trasformare segnali frammentari in scenari operativi.

Occorre però mantenere una distinzione giuridica essenziale. I sistemi impiegati esclusivamente per finalità militari, di difesa o di sicurezza nazionale sono generalmente esclusi dal perimetro dell’AI Act; i sistemi dual use, civili, umanitari, di pubblica sicurezza o impiegati anche fuori dall’ambito esclusivamente militare possono invece rientrare nel regolamento. Il percorso militare e di cyber intelligence non può quindi essere presentato come una semplice estensione della compliance civile, ma richiede una governance separata, capace di integrare diritto nazionale, sicurezza, protezione delle informazioni, responsabilità democratica e norme internazionali. (AI Act Service Desk)

La direzione europea, peraltro, si sta già muovendo verso una maggiore integrazione tra intelligenza artificiale e cibersicurezza. Nel luglio 2026 la Commissione ha presentato un piano d’azione europeo dedicato ai rischi e alle opportunità dei modelli avanzati nell’ambito cyber. Una piattaforma capace di organizzare evidenze, controlli, vulnerabilità, responsabilità e remediation potrebbe quindi trovare spazio anche all’interno di questa strategia, purché sottoposta a verifiche indipendenti e inserita in una cornice istituzionale trasparente. (Strategia Digitale Europea)

La cooperazione con gli Stati Uniti, se formalizzata e documentata, potrebbe offrire alla Fondazione un accesso privilegiato alle competenze maturate negli ambiti della threat intelligence, della protezione delle infrastrutture, dell’analisi delle catene di fornitura e della sicurezza dei sistemi dual use. Ma proprio perché si parla di settori sensibili, il valore di questa collaborazione dovrà essere dimostrato attraverso partner identificabili, incarichi verificabili, protocolli di sicurezza e risultati misurabili.

La vera forza dell’iA Act Compliance Controller non consiste quindi nell’attribuire un voto a un algoritmo. Consiste nella possibilità di ricostruire la storia di quel voto. Sapere quale sistema è stato esaminato, quali regole sono state applicate, quali documenti sono stati considerati, quali persone hanno deciso, quali criticità sono rimaste aperte e come il prodotto è cambiato nel tempo.

È questo il punto sul quale Bruxelles dovrebbe concentrare la propria attenzione. Il problema europeo non è più soltanto scrivere regole sull’intelligenza artificiale. È impedire che quelle regole diventino una montagna di dichiarazioni non verificabili. Un’Europa incapace di controllare le prove, le versioni, gli aggiornamenti e le dipendenze dei sistemi digitali rischierebbe di possedere la legislazione più avanzata del mondo e, contemporaneamente, la più difficile da applicare.

La Fondazione offre alla Commissione una possibile risposta: un metodo che unisce valutazione, documentazione, controllo, remediation e audit trail. Perché una valutazione affidabile non è quella che afferma semplicemente “conforme” o “non conforme”. È quella che può essere ricostruita integralmente, collegando oggetto, fatti, regole, evidenze, decisioni, responsabilità, azioni e versioni.

Se Bruxelles saprà verificare, sperimentare e valorizzare questo contributo, il Compliance Controller potrà diventare qualcosa di più di un’applicazione italiana: una possibile infrastruttura europea di fiducia, un presidio sulle filiere digitali e un ponte tra regolazione civile, sicurezza tecnologica e protezione strategica.

Perché l’intelligenza artificiale non si governa con una firma in fondo a un documento. Si governa rendendo impossibile nascondere ciò che il sistema fa, chi lo ha deciso e quali rischi lascia dietro di sé.