La Fondazione Olitec ottiene dalla Library of Congress degli Stati Uniti e dal Copyright Office Department il riconoscimento e la protezione internazionale sul protocollo di controllo e validazione dei dati a funzione pubblica.
Di Nicolini Massimiliano
La trasformazione digitale della Pubblica Amministrazione non può più essere considerata una semplice evoluzione tecnica, né può essere ridotta alla sostituzione della carta con piattaforme informatiche, portali online, banche dati interoperabili o sistemi automatizzati di gestione dei procedimenti. Ciò che oggi abbiamo davanti è una mutazione molto più profonda: lo Stato sta trasferendo una parte crescente della propria capacità decisionale dentro infrastrutture digitali, algoritmi, software, architetture di dati e processi automatizzati che incidono direttamente sulla vita dei cittadini, sull’organizzazione dei servizi pubblici, sulla sicurezza nazionale, sulla spesa pubblica, sulla salute, sull’istruzione, sulla giustizia, sul welfare, sulla fiscalità e sull’intero equilibrio democratico del Paese.
In questo scenario, il regolatorio OPM AG1, nato come sistema di analisi e valutazione dei software sanitari, assume un significato che supera il solo perimetro della sanità digitale. La sua architettura metodologica, fondata sulla verifica del modello concettuale, sull’audit del codice sorgente, sulla sicurezza informatica, sull’interoperabilità, sulla sostenibilità computazionale, sul monitoraggio post-certificazione, sul registro nazionale dei software verificati, sul certificato digitale di conformità e sulla misurazione dell’impatto energetico attraverso la scala NIC, rappresenta una possibile matrice regolatoria per l’intera Pubblica Amministrazione. Non si tratta più soltanto di certificare un software clinico, ma di introdurre un principio generale: ogni sistema digitale che tratta dati di interesse collettivo e nazionale deve essere verificabile, tracciabile, auditabile e sottoposto a responsabilità pubblica.
La vera questione, oggi, è comprendere che il software pubblico non è più uno strumento neutro. Quando un programma informatico entra in un ospedale, in un tribunale, in una scuola, in un comune, in una regione, in un ministero, in una centrale di acquisto, in un sistema fiscale, in una piattaforma previdenziale o in un’infrastruttura di protezione civile, quel software diventa parte dell’esercizio della funzione pubblica. Non è più soltanto codice scritto da un fornitore. È una porzione operativa dello Stato. È amministrazione che agisce attraverso una macchina. È norma che viene trasformata in processo. È decisione pubblica che passa attraverso una logica algoritmica.
Per questa ragione, la regolamentazione della verifica digitale non può più essere trattata come un tema accessorio, riservato agli specialisti informatici o ai responsabili dei sistemi informativi. Essa deve diventare una procedura di indirizzo generale per tutta la Pubblica Amministrazione, perché ogni volta che il dato assume rilevanza collettiva, il sistema che lo raccoglie, lo elabora, lo conserva, lo trasmette o lo interpreta diventa esso stesso una infrastruttura critica della democrazia amministrativa.
Il dato pubblico non è materia inerte. Dentro i dati pubblici ci sono persone, famiglie, imprese, pazienti, studenti, lavoratori, contribuenti, soggetti fragili, territori, risorse economiche, diritti, doveri, autorizzazioni, controlli, graduatorie, sanzioni e opportunità. Un errore in un sistema sanitario può incidere su una diagnosi. Un errore in un sistema scolastico può incidere su una graduatoria. Un errore in un sistema previdenziale può ritardare un sostegno economico. Un errore in un sistema fiscale può generare un accertamento ingiusto. Un errore in un software giudiziario può produrre disordine procedurale. Un errore in una piattaforma di welfare può escludere proprio chi avrebbe più bisogno dell’intervento pubblico.
Di conseguenza, la Pubblica Amministrazione non può più limitarsi ad acquistare software sulla base di capitolati, dichiarazioni di conformità, esperienze pregresse del fornitore o promesse commerciali. Deve poter verificare, prima e dopo l’adozione, che quel software sia coerente con la funzione pubblica che deve servire. Deve poter sapere se il modello concettuale è corretto, se l’algoritmo è spiegabile, se il codice è sicuro, se le librerie sono controllate, se i dati sono trattati secondo finalità legittime, se il sistema è interoperabile, se può essere migrato, se crea dipendenza tecnologica, se consuma risorse inutili, se introduce bias, se genera automatismi impropri, se può essere sospeso in caso di rischio.
Questo è il salto che oggi deve essere imposto con forza: non basta più certificare il risultato amministrativo finale, occorre certificare anche la catena digitale che lo produce. La legittimità dell’atto pubblico, nell’epoca della Pubblica Amministrazione algoritmica, dipende anche dalla legittimità del processo informatico sottostante. Se il procedimento nasce, passa o viene condizionato da un software, quel software deve essere parte del perimetro di controllo pubblico.
Il regolatorio OPM AG1 indica proprio questa direzione. Nato nel campo sanitario, dove la sensibilità del dato e il rischio diretto sulla persona sono immediatamente evidenti, esso afferma un principio che può essere esteso a tutte le amministrazioni: il software deve essere valutato come una componente sostanziale del servizio pubblico, non come una semplice fornitura tecnica. Nel settore sanitario si è detto che il software deve essere trattato con lo stesso rigore con cui si valuta un presidio clinico, perché una riga di codice può incidere sulla salute di un paziente. Nella Pubblica Amministrazione generale bisogna compiere lo stesso passaggio culturale: una riga di codice può incidere su un diritto, su una libertà, su un beneficio economico, su una procedura, su una responsabilità, su un servizio essenziale.
Da qui nasce la necessità di una procedura nazionale di verifica dei software pubblici. Una procedura che non abbia natura meramente burocratica, ma che diventi un sistema di garanzia. Ogni software destinato a gestire dati di rilievo collettivo dovrebbe essere sottoposto a una valutazione preliminare del modello concettuale, perché prima ancora di analizzare il codice occorre comprendere quale idea di amministrazione quel software traduce. Un sistema pubblico non può incorporare scorciatoie non dichiarate, criteri opachi, automatismi non controllabili o semplificazioni che alterino la sostanza del procedimento. Il modello concettuale deve dimostrare coerenza con la legge, con la finalità pubblica, con il principio di proporzionalità, con la tutela del cittadino e con la possibilità di intervento umano nei passaggi critici.
Successivamente, deve intervenire la verifica del codice sorgente o, nei casi di software proprietario, un audit obbligatorio svolto da soggetti terzi qualificati e indipendenti. Il segreto industriale non può diventare uno schermo assoluto dietro il quale si nasconde il funzionamento di strumenti che agiscono su dati pubblici e processi nazionali. È possibile tutelare la proprietà intellettuale senza rinunciare al controllo. È possibile proteggere il valore economico del codice senza sottrarlo alla verifica. Ma non è più accettabile che una pubblica amministrazione utilizzi sistemi che nessuno, al di fuori del fornitore, può comprendere davvero.
La sicurezza informatica deve diventare parte costitutiva della certificazione. Non come allegato tecnico, ma come condizione di legittimità operativa. Ogni software pubblico deve essere progettato per resistere ad attacchi esterni, accessi impropri, manipolazioni interne, perdita di dati, alterazioni dei log, vulnerabilità delle dipendenze, backdoor, aggiornamenti non controllati e interruzioni operative. La sicurezza non riguarda soltanto la protezione del sistema, ma la protezione della fiducia dei cittadini nello Stato. Un’amministrazione che perde dati, che non sa ricostruire un evento, che non controlla i propri applicativi o che dipende da infrastrutture opache perde una parte della propria autorevolezza.
L’interoperabilità deve essere verificata in modo reale, non dichiarata in modo formale. La frammentazione digitale della Pubblica Amministrazione è una delle cause principali di inefficienza, duplicazione di costi e perdita di controllo. Sistemi non comunicanti producono dati duplicati, errori, rallentamenti, procedure parallele, dipendenza dai fornitori e impossibilità di costruire una visione unitaria del servizio pubblico. Un software pubblico deve poter dialogare con gli altri sistemi, rispettare standard condivisi, consentire migrazioni, evitare chiusure proprietarie e non trasformarsi in una prigione tecnologica. Ogni piattaforma chiusa, non sostituibile e non integrabile rappresenta una limitazione della libertà amministrativa dello Stato.
Accanto alla verifica iniziale serve un monitoraggio permanente. Nessun software pubblico dovrebbe ottenere una certificazione eterna. Gli aggiornamenti cambiano le funzioni, le vulnerabilità emergono nel tempo, le normative mutano, gli usi reali mostrano problemi non previsti, i carichi aumentano, le integrazioni si moltiplicano. La conformità deve essere dinamica. Serve un registro nazionale dei software pubblici verificati, nel quale ogni applicativo rilevante sia identificato con versione, produttore, ambito d’uso, livello di rischio, stato di conformità, storico degli audit, eventuali prescrizioni, sospensioni o revoche. Un registro di questo tipo non sarebbe solo uno strumento tecnico, ma una vera infrastruttura di trasparenza democratica.
La valutazione etica e sociale deve entrare nella procedura con la stessa forza della verifica tecnica. Un sistema può essere sicuro e funzionante, ma comunque ingiusto. Può essere efficiente e tuttavia escludere gli anziani, le persone con bassa alfabetizzazione digitale, i cittadini delle aree interne, i soggetti con disabilità, chi non dispone di strumenti adeguati o chi non riesce a interpretare interfacce complesse. Una Pubblica Amministrazione digitale non può misurare il proprio successo soltanto sul numero di servizi online, ma deve misurarlo sulla capacità di non lasciare indietro nessuno. La tecnologia pubblica deve semplificare l’accesso ai diritti, non trasformarsi in un nuovo filtro sociale.
In questo quadro, la protezione dell’opera dell’ingegno alla base del modello assume un valore strategico. Il riferimento al riconoscimento presso il sistema statunitense della Library of Congress e del Copyright Office degli Stati Uniti, con numero TX9608139, data 02/01/2026 e decisione del 22/06/2026, consente di collocare l’impianto regolatorio in una dimensione internazionale di tutela autorale. Non siamo davanti a una semplice proposta occasionale, ma a un’opera strutturata, rivendicata e protetta in uno dei sistemi più rilevanti al mondo per la registrazione e la difesa delle opere dell’ingegno.
Questo aspetto deve essere enfatizzato con chiarezza. La tutela americana rafforza la paternità intellettuale del modello, ne protegge la struttura concettuale e ne riconosce la natura di opera originale. In un tempo in cui i modelli regolatori, le architetture di audit, le scale di misurazione e le metodologie di verifica possono essere rapidamente imitate, copiate o assorbite da grandi apparati tecnologici e istituzionali, la protezione dell’opera rappresenta un presidio fondamentale. Essa non sostituisce la normativa nazionale o europea, ma conferisce al modello una forza ulteriore sul piano globale: ne cristallizza l’origine, ne tutela l’identità e ne rende difendibile l’impianto metodologico.
La protezione dell’opera dell’ingegno non è un dettaglio formale. È parte della strategia. Se il futuro della Pubblica Amministrazione passerà dalla standardizzazione dei processi digitali, allora chi ha concepito per primo una procedura organica di verifica, valutazione, tracciamento e certificazione dei software pubblici ha prodotto non soltanto un documento tecnico, ma una vera infrastruttura concettuale. Proteggere questa infrastruttura significa proteggere un pezzo di visione strategica. Significa affermare che il metodo con cui si controlla il software pubblico è esso stesso un bene intellettuale, regolatorio e nazionale.
L’estensione del modello a tutta la Pubblica Amministrazione consente inoltre di affrontare il tema della sovranità digitale in modo più concreto. Troppo spesso la sovranità digitale viene ridotta alla localizzazione dei server, alla proprietà dei data center o alla scelta del cloud. Sono aspetti importanti, ma non sufficienti. La vera sovranità digitale nasce dalla capacità di comprendere, controllare e verificare ciò che il software fa. Uno Stato può avere infrastrutture sul proprio territorio e tuttavia dipendere da sistemi opachi. Può possedere banche dati enormi e tuttavia non sapere con precisione come vengono interrogate, incrociate, elaborate o trasferite. Può digitalizzare migliaia di servizi e tuttavia perdere il controllo delle logiche che li governano.
La sovranità digitale, quindi, non è soltanto possesso dell’infrastruttura. È verificabilità dell’infrastruttura. È capacità di audit. È tracciabilità del codice. È conoscenza delle dipendenze. È controllo degli aggiornamenti. È libertà di migrazione. È indipendenza dai fornitori dominanti. È possibilità di sospendere un sistema non conforme. È diritto dello Stato di sapere come funziona la macchina che esercita potere pubblico.
In questa prospettiva, la scala NIC introduce un ulteriore elemento di innovazione. Il digitale pubblico non deve essere valutato soltanto per le sue funzioni, ma anche per il suo peso computazionale, energetico e ambientale. Ogni bit elaborato consuma energia, occupa risorse, genera calcolo, produce necessità di archiviazione, backup, raffreddamento, trasmissione e manutenzione. Quando milioni di cittadini interagiscono ogni giorno con piattaforme pubbliche, anche l’inefficienza del codice diventa una voce nascosta di spesa nazionale.
Un software pubblico inefficiente non è solo lento o costoso. È energivoro. È ambientalmente irresponsabile. È economicamente dannoso. È tecnicamente fragile. Per questo l’idea di classificare i software attraverso un indice di consumo informativo normalizzato può diventare uno strumento di politica pubblica. Le amministrazioni dovrebbero poter premiare software leggeri, efficienti, scalabili e sostenibili, e penalizzare quelli ridondanti, pesanti, non ottimizzati e inutilmente dispendiosi. La sostenibilità digitale non deve essere uno slogan, ma un criterio di gara, un parametro di conformità e un indicatore di responsabilità.
La procedura di verifica avrebbe anche un effetto positivo sul mercato. Oggi molte amministrazioni sono vincolate a ecosistemi software chiusi, contratti pluriennali, fornitori storici e piattaforme difficili da sostituire. Questo genera rendite di posizione, riduce la concorrenza e ostacola l’innovazione reale. Un sistema nazionale di certificazione, fondato su criteri pubblici, renderebbe il mercato più aperto e più meritocratico. Non vincerebbe chi possiede la relazione più forte, ma chi dimostra maggiore qualità, sicurezza, interoperabilità, trasparenza e sostenibilità.
Le imprese serie verrebbero valorizzate. Le start-up realmente innovative potrebbero competere su basi oggettive. I centri di ricerca potrebbero contribuire alla costruzione di standard. I fornitori dominanti sarebbero costretti ad aprire, documentare e migliorare le proprie soluzioni. Le pubbliche amministrazioni avrebbero strumenti più solidi per scegliere. I cittadini avrebbero maggiori garanzie. La spesa pubblica sarebbe più difendibile. La legalità amministrativa ne uscirebbe rafforzata.
La resistenza a un simile cambiamento sarà inevitabile. Ogni sistema di verifica reale mette in discussione rendite, abitudini, opacità e poteri consolidati. Ci sarà chi dirà che certificare rallenta l’innovazione, che controllare il codice è troppo complesso, che le amministrazioni non hanno competenze, che i fornitori devono essere liberi, che il mercato si autoregola, che bastano le norme esistenti. Ma questa opposizione va letta per ciò che è: la difesa di un modello nel quale la digitalizzazione pubblica cresce senza un controllo proporzionato al suo potere.
In realtà, la verifica non rallenta l’innovazione. La rende credibile. Non blocca il mercato. Lo qualifica. Non appesantisce la Pubblica Amministrazione. La protegge. Non limita la tecnologia. La orienta verso il bene comune. Il vero freno all’innovazione non è il controllo pubblico, ma l’adozione disordinata di soluzioni opache, non interoperabili, insicure e prive di responsabilità verificabile.
La Pubblica Amministrazione del futuro dovrà essere digitale, ma soprattutto dovrà essere dimostrabile. Dovrà poter dimostrare che i propri sistemi funzionano, che i propri dati sono protetti, che i propri algoritmi sono controllabili, che i propri fornitori sono responsabili, che le proprie piattaforme sono sostenibili, che le proprie decisioni automatizzate sono ricostruibili, che i cittadini possono fidarsi non per fede, ma per evidenza.
Il regolatorio OPM AG1, nella sua estensione ideale a tutte le funzioni pubbliche, indica una via precisa: trasformare il software da oggetto contrattuale a oggetto di garanzia pubblica. Questo passaggio è destinato a diventare uno standard. Dove il dato è nazionale, la verifica deve essere nazionale. Dove il dato è collettivo, il controllo deve essere pubblico. Dove il software incide sui diritti, la sua logica deve essere conoscibile. Dove l’algoritmo sostiene una decisione amministrativa, la responsabilità deve restare umana, giuridica e istituzionale.
La protezione americana dell’opera dell’ingegno che ne sta alla base rafforza questo percorso e ne amplia la portata. Essa conferisce al modello una dimensione di tutela globale, difendendo non soltanto il testo, ma l’architettura concettuale di una nuova procedura di verifica pubblica. È un riconoscimento che consente di affermare con maggiore forza che l’Italia può produrre non solo software, ma standard; non solo applicazioni, ma metodi; non solo piattaforme, ma visioni regolatorie capaci di parlare al mondo.
La sfida dei prossimi anni non sarà semplicemente digitalizzare lo Stato. Sarà impedire che lo Stato venga digitalizzato senza sapere davvero da chi, come, con quali regole, con quali rischi e con quali conseguenze. Il punto non è portare la Pubblica Amministrazione dentro il software. Il punto è portare il software dentro il perimetro della responsabilità pubblica.
Perché quando il codice gestisce la salute, l’identità, il lavoro, la scuola, la giustizia, la sicurezza, il welfare e le risorse pubbliche, quel codice non appartiene più soltanto alla tecnica. Appartiene alla sovranità. E una sovranità che non può verificare il proprio codice non è più pienamente sovrana.
Scopri di più da
Abbonati per ricevere gli ultimi articoli inviati alla tua e-mail.

