Attributi qualificati per Spid, la svolta con le linee guida Agid

AgID (agenzia Italia digitale) ha adottato le “Linee guida recanti le regole tecniche dei gestori di attributi qualificati” per identità digitali, spid. Ecco a cosa serviranno

Avanti tutta per gli attributi qualificati da agganciare alle identità digitali.

Con la Determinazione n. 215/2022 AgID ha adottato le “Linee guida recanti le regole tecniche dei gestori di attributi qualificati”, a conclusione dell’iter previsto dall’art. 71 del CAD.
Le Linee guida hanno lo scopo di definire i requisiti per la realizzazione dell’architettura dei gestori di attributi qualificati ai sensi dell’art. 1, comma 1, lett. m) del DPCM 24 ottobre 2014.

Attributi qualificati per SPID, identità digitale: a che servono

Gli attributi qualificati arricchiranno le identità digitali SPID con informazioni certificate, permettendo così all’utente un accesso ancora più semplice ai sempre più numerosi servizi online.

Lo scopo è di definire i requisiti per la realizzazione dell’architettura dei gestori di attributi qualificati ex art.1, comma 1, lettera m) del DPCM 24 ottobre 2014 (GU n.285 del 9122014), nel seguito Attribute Authority.

Le linee guida Agid per attributi qualificati

Le Linee Guida contengono anche degli allegati tecnici:

• Allegato tecnico OAS3
• Allegato tecnico SAML (riservato alla AA Gestore delle deleghe, amministrazioni di sostegno e tutele)

L’obbligo di applicazione delle Linee guida è a decorrere dal 31 ottobre 2022.

Proviamo a fare una prima analisi del contenuto e un’ipotesi di scenario di utilizzo.

Soggetti destinatari

I soggetti destinatari delle Linee Guida sono tutti i soggetti coinvolti nella federazione SPID, con primario e principale focus sui gestori di attributi qualificati.

La fruizione del servizio reso dai gestori di attributi qualificati è permesso anche ai soggetti presenti nella federazione CIE.

Gestori di attributi qualificati

Ai sensi dell’art. 1, comma 1, lett. m) del DPCM SPID, si intendono “i soggetti accreditati ai sensi dell’art. 16 che hanno il potere di attestare il possesso e la validità di attributi qualificati, su richiesta dei fornitori di servizi (SP)”;

Attributi qualificati

ai sensi dell’art. 1, comma 1, lett. e) del DPCM SPID, sono “le qualifiche, le abilitazioni professionali e i poteri di rappresentanza e qualsiasi altro tipo di attributo attestato da un gestore di attributi qualificati”.

L’art. 64, comma 2-duodecies, ultimo periodo del CAD – come da ultimo modificato dal D.L. 30 aprile 2022, n. 36, convertito, con modificazioni, dalla L. 29 giugno 2022, n. 79 – concorre a chiarire tale definizione, specificando che:

“L’identità digitale, verificata ai sensi del presente articolo e con livello di sicurezza almeno significativo, attesta gli attributi qualificati dell’utente, ivi compresi i dati relativi al possesso di abilitazioni o autorizzazioni richieste dalla legge ovvero stati, qualità personali e fatti contenuti in albi, elenchi o registri pubblici o comunque accertati da soggetti titolari di funzioni pubbliche, ovvero gli altri dati, fatti e informazioni funzionali alla fruizione di un servizio attestati da un gestore di attributi qualificati, secondo le modalità stabilite da AgID con Linee guida.”

Come diventare attribute autority

Può accreditarsi quale AA – Attribute Authority – qualunque soggetto che gestisca le informazioni e i dati appena descritti

Al momento dell’accreditamento, le AA indicano i dati che intendono rendere disponibili nello SPID, secondo le modalità indicate nei regolamenti attuativi adottati.

Registro delle AA

Già il DPCM SPID del 24 ottobre 2014 aveva già individuato i soggetti che, a fronte di relativa richiesta, sono accreditati di diritto quali AA:

• il Ministero dello sviluppo economico in relazione ai dati contenuti nell’indice nazionale degli indirizzi PEC delle imprese e dei professionisti di cui all’articolo 6-bis del CAD;
• i consigli, gli ordini e i collegi delle professioni regolamentate relativamente all’attestazione dell’iscrizione agli albi professionali;
• le camere di commercio, industria, artigianato e agricoltura per l’attestazione delle cariche e degli incarichi societari iscritti nel registro delle imprese;
• l’AgID in relazione ai dati contenuti nell’IPA di cui all’articolo 6-ter del CAD.

Spunto: tenendo presente che nell’Indice PA sono contenuti non solo i nomi delle Amministrazioni e gestori di Pubblico Servizio, ma anche i nominativi dei Responsabili dei Servizi, sarebbe estremamente utile fare in modo che questi dati possano essere utilizzati per facilitare l’accesso ai vari Portali tematici delle PA (ES: MEPA/CONSIP, ANAC, ecc.), che in questo momento prevedono invece appositi moduli di iscrizione, che allungano i tempi.

Per fare questo, occorrerebbe mappare nell’IPA anche il codice fiscale delle persone censite, eventualmente in un’area non visibile al pubblico.

In modo più generale, l’AgID inserisce nel Registro SPID – accessibile da parte dei fornitori di servizi – le tipologie di dati resi disponibili da ciascuna AA.

Presso il registro SPID, pertanto, è pubblicato un registro delle AA e degli attributi da loro trattati, e ad esse è associato il relativo documento OpenAPI.

Sarà quindi fondamentale un’attività di mappatura – a carico di AGID? – dei dati disponibili presso le principali basi dati di interesse nazionale (e tutte le AA), per la costituzione e attivazione del registro dedicato.

Accesso agli Attributi e rispetto della Privacy

L’attributo qualificato è richiesto dal SP – Service Provider – ai soli fini della fruizione di uno specifico servizio a cui l’interessato intende accedere.

Le AA devono assicurare, per impostazione predefinita, il trattamento dei soli dati personali necessari per ogni specifica finalità del trattamento, tenendo conto dell’effettivo contenuto informativo da fornire ai SP e ciò, ad esempio, privilegiando attributi di tipo booleano o comunque fornendo le informazioni minime necessarie per attestare il possesso dell’attributo richiesto, nel rispetto del principio di minimizzazione dei dati di cui all’art. 5, par. 1, lett. C) del GDPR.

Tali cautele vanno apprestate, a maggior ragione e con particolare rigore, nei casi in cui il trattamento riguardi attributi qualificati appartenenti alle categorie particolari di cui all’art. 9 del GDPR o concernenti dati relativi a condanne penali e reati di cui all’art. 10 del GDPR, i quali:

• possono essere richiesti esclusivamente per la fruizione di servizi non possono essere erogati senza la conoscenza di tali attributi dell’utente (ad esempio: assenza di condanne penali per la partecipazione a un concorso pubblico o l’iscrizione in un albo professionale);
• possono essere resi conoscibili unicamente dalle AA che sono espressamente e specificamente individuate dall’ordinamento come i soggetti abilitati all’attestazione di tali categorie di attributi (ad esempio: con riferimento all’esempio di cui al punto precedente, l’attributo qualificato dell’assenza o presenza di condanne penali a carico del candidato a un concorso pubblico potrà essere attestato unicamente dal Ministero della Giustizia mediante il Casellario giudiziale), quindi il soggetto giuridico che crea e detiene il dato;
• comportano il dovere, in capo al SP che riceve tali attributi qualificati per consentire la fruizione di un servizio, della necessaria messa in atto di misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, ai sensi dell’art. 32 del GDPR.

Qualora sia necessario conoscere un attributo qualificato del soggetto interessato ai fini dell’erogazione di un determinato servizio online, il SP informa di tale necessità l’utente che intende accedere al servizio, indicando, per ogni attributo qualificato, anche l’AA presso cui sarà richiesto.

Per l’ottenimento di uno o più attributi qualificati, il SP (anche per il tramite di Soggetti Aggregatori) invia una richiesta di attributi a una o più AA.

Qualora gli attributi qualificati siano attestabili dalla medesima AA, il SP invia a tale AA un’unica richiesta di attributi, a meno che alcuni di questi siano soggetti a dipendenze verificabili solo previa attestazione di altri attributi qualificati.

Ogni richiesta di attributi qualificati, indirizzata a un’AA da parte di un SP, si caratterizza per:

1. l’identificazione del soggetto a cui si riferiscono gli attributi;
2. la caratteristica temporale della richiesta: puntuale o continuativa.

In questo ultimo caso, si intende all’interno di una finestra temporale – non superiore a un periodo ininterrotto di 12 mesi – reciprocamente concordata tra SP, AA e utente.

L’accesso agli attributi e, di conseguenza, la loro attestazione possono essere classificati sulla base delle seguenti casistiche:

1. a) “public”: il dato è open, di pubblico dominio o liberamente accessibile. In tal caso l’accesso al dato non richiede l’acquisizione dell’assenso dell’utente da parte dell’AA;
2. b) “protected”: l’accesso al dato è riservato ai SP che hanno una specifica convenzione con l’AA. In tal caso, per l’accesso non è richiesta l’acquisizione dell’assenso dell’utente da parte dell’AA;
3. c) “private”: l’accesso al dato è consentito solo previa acquisizione dell’assenso dell’utente da parte dell’AA.

Tale casistica si applica sempre nei casi di richiesta continuativa di attributi qualificati.

Con riferimento alla richiesta di attributi qualificati, il SP è tenuto a valutare – sin dalla progettazione e per impostazione predefinita – l’effettiva necessità di acquisire tali attributi afferenti l’interessato per le finalità del servizio erogato e ad approntare il relativo trattamento nel rispetto scrupoloso dei principi di cui all’art. 5 del GDPR, con particolare riferimento ai principi di liceità, correttezza e trasparenza, limitazione delle finalità, minimizzazione dei dati rispetto alle finalità individuate e limitazione della conservazione, essendo in grado di comprovare il rispetto di tali principi ai sensi dell’art. 5, par. 2 del GDPR

IdP, SP e AA sono tenuti ad adottare le misure tecniche e organizzative necessarie a garantire un livello di sicurezza adeguato al rischio, a sorvegliare e tracciare l’accesso e le attività dei propri utenti per il tempo strettamente necessario e al solo fine di tutelare la protezione dei dati personali secondo quanto definito dagli artt. 25, 29 e 32 del GDPR, informandosi reciprocamente e tempestivamente in caso di violazioni di sicurezza o di qualsiasi minaccia, intervenute nei processi di cui alle presenti LG, che comportino un rischio per la sicurezza e per i diritti e le libertà degli interessati, anche al fine di agevolare l’adempimento degli obblighi di cui agli artt. 33 e 34 del GDPR.

Effetti concreti e prossimi scenari

Se le Linee Guida verranno applicate al massimo delle potenzialità, si potrà arrivare ad un completo superamento delle autocertificazioni e dichiarazioni sostitutive dell’atto di notorietà previste dal DPR 445/2000 – tutte le volte in cui tali qualità, stati o altro è contenuto in un pubblico registro o il dato è detenuto da un’Autorità Pubblica, visto che il dato (ovvero Attributo) sarà verificato in tempo reale e darà la possibilità di procedere nella richiesta del servizio o meno.

Le Linee Guida rappresentano, da questo punto di vista, la completa attuazione del principio di interoperabilità e once only, in cui tutte le PA hanno accesso diretto e immediato ai dati di cui necessitano, evitando il meccanismo attuale di domanda/risposta o verifica manuale da parte degli operatori o inserimenti multipli di dati (con relativi errori, duplicazioni …).

Solo per fare qualche esempio:

• la qualità di proprietario di un immobile – certificato dall’Agenzia delle Entrate – in particolare nei registri catastali, è elemento qualificante per la presentazione della Dichiarazione IMU, e quindi viene verificato attraverso la richiesta dell’attributo al momento dell’accesso e/o compilazione della dichiarazione.
• altro caso interessante è l’attributo che attesta la qualifica di legale rappresentante, il cui gestore è il Registro delle Imprese: finalmente potrà essere possibile richiedere un servizio online anche per le persone giuridiche, evitando compilazione di moduli cartacei e/o scansionati, dal momento che l’identità SPID/CIE dell’interessato sarà “collegata” anche al ruolo che riveste nell’impresa.
• anche il dato della dichiarazione ISEE – in questo modo – viene verificata in tempo reale (con accesso al dato nella banca dati INPS), evitando anche in questo caso le verifiche successive dei dati e/o errori di compilazione da parte degli interessati.

Di conseguenza, ci sarà il completo superamento dei controlli successivi alla presentazione della richiesta, eliminando una cospicua parte di lavoro che viene svolto dagli operatori nel back office, e quindi recuperando “forza lavoro” per attività più qualificanti.

Sarà così necessaria una progettazione più accurata dei servizi online e dei requisiti necessari per presentare domanda, passando dal “modulo online” con la logica cartacea delle “crocette” al vero e proprio servizio online, in cui la richiesta è auto consistente, perché contiene fin dall’origine tutti i dati necessari per poter usufruire del servizio richiesto.

Ovviamente questo sarà possibile nella misura in cui le AA abbiano censito presso il Registro AGID i dati che hanno a disposizione e quindi siano state realizzate le integrazioni necessarie.

Altro tema che rimane un po’ in sospeso è quello della modalità di accesso all’attributo, da cui dipende la modalità di consultazione: infatti, nel caso di Attributo “protected”, le Linee Guida prevedono che  l’accesso al dato è riservato ai SP che hanno una specifica convenzione con l’AA.

Nell’attesa di chiarire meglio l’effettivo contenuto della definizione, sembra che si ritorni al tema delle convenzioni tra enti, che possono in effetti rappresentare un ostacolo burocratico in grado di rallentare notevolmente l’attuazione delle Linee Guida.

Non ci resta che aspettare di capire come verrà attuato il provvedimento per valutarne appieno gli effetti e le potenzialità.

Articolo pubblicato originariamente su: www.agendadigitale.eu/cittadinanza-digitale/pa-come-realizzare-servizi-digitali-innovativi-limportanza-dellinteroperabilita/

PA, come realizzare servizi digitali innovativi: l’importanza dell’interoperabilità

Cos’è un servizio digitale utile e come realizzarlo? La nostra PA non ci è ancora arrivata? Ecco perché non siamo così lontani dal realizzarli, ma bisogna superare importanti ostacoli culturali

Sara La Bombarda - Responsabile per la Transizione Digitale presso Regional Agency for Technology and Innovation - Puglia
Andrea Tironi - Project Manager - Digital Transformation

Una Pubblica amministrazione che semplifica davvero la vita ai cittadini non può non essere interoperabile, in tutte le sue diverse declinazioni.
Solo così potrà fornire servizi utili e veramente innovativi.  A questo proposito, il cuore degli avvisi di padigitale2026.gov.it è l’“Avviso Misura 1.4.1 “Esperienza del Cittadino nei servizi pubblici” Comuni Aprile 2022”.

Tale avviso ci porta infatti a riflettere su come realizzare servizi innovativi e digitali che siano:

• utili: non fini a sé stessi
• veloci: copiare se necessario da best practices già esistenti
• facili: di semplice accesso, mediante mobile
• interoperabili: ne parleremo parecchio dopo

Le domanda da porsi, a questo punto, sono: come raggiungere questo obiettivo? Che ostacoli ci sono o potrebbero esserci? Su quale/i punto/i in particolare focalizzarsi?

Definizione di servizio digitale utile

Cosa è un servizio utile per il cittadino/impresa?

Non si può sbagliare: lo dice il Piano Triennale già nella sua edizione 2020-2022 che definisce i principi guida ed inserisce tra questi la definizione di servizio digitale: “Le pubbliche amministrazioni devono progettare servizi pubblici digitali che siano inclusivi e che vengano incontro alle diverse esigenze delle persone e dei singoli territori”.

Un servizio pubblico digitale sottende al principio #digital first che significa chiedersi cosa il digitale può fare per potenziare, trasformare, stravolgere o a volte distruggere il business o servizio come era concepito fino a ieri. Principio che si rafforza e si arricchisce nella versione aggiornata 21-23 “servizi inclusivi e accessibili che vengano incontro alle diverse esigenze delle persone e dei singoli territori e siano interoperabili by design in modo da poter funzionare in modalità integrata e senza interruzioni in tutto il mercato unico esponendo le opportune API”.

Le parole scelte per definire il servizio pubblico sono estremamente efficaci: si parla di persone, e non solo di cittadino o impresa, e si parla di singoli territori. È come se si volesse sottolineare la grande eterogeneità degli interlocutori della pubblica amministrazione, degli utenti e dei fruitori dei suoi servizi. Quindi un servizio utile (che rappresenta un dovere della PA) è un servizio progettato per dare delle risposte, per riconoscere un diritto, erogare un contributo, creare delle opportunità, generare impatto.

Cosa c’è alla base di un servizio digitale utile?

Sempre nel Piano Triennale e nell’ultima definizione presentata sopra in corsivo, troviamo alcune fondamentali risposte. Sono introdotti dei concetti fondamentali (interoperabili by design, modalità integrata, API) già presenti in realtà nelle precedenti versioni del Piano ma che questa volta vengono indissolubilmente legati alla definizione di servizio digitale pubblico.

Si tratta di alcune parole scelte con precisione, che mirano ad evidenziare come sia fondamentale progettare non solo il contenitore (designers.italia.. accessibilità..eccetera) ma anche il contenuto dei servizi che, in un’ottica di trasformazione digitale, non può limitarsi alla digitalizzazione dei procedimenti amministrativi. Non basta consentire al cittadino di scaricare online un certificato, se poi la stessa informazione gli viene chiesta per accedere ad un altro servizio pubblico. Non basta consentire di accedere tramite SPID se poi non lo “riconosco” davvero: se non riesco a passare da un servizio pubblico ad un altro tutte le informazioni che possano realmente rispondere alle “diverse esigenze delle persone e dei singoli territori”, sto facendo un servizio parzialmente digitale, non interoperabile.

Ed immediatamente, a quest’ultimo principio guida dedicato ai servizi digitali ovvero l’interoperabilità, non possiamo che associare il principio del once only: tanto potente quanto semplice.

Principio associato all’interoperabilità

Once only: se ho già il tuo dato non te lo devo richiedere sotto forma di reinserimento, autocertificazione o altro. Avere il tuo dato vuol dire che “la grande macchina PA ce l’ha in uno dei suoi meandri”. Se ce l’ha INPS o AdE, la PA ce l’ha: perché il comune deve richiedermelo?

Il meccanismo funziona anche internamente alla PA: si chiama onceonlypa, ovvero è inutile chiedere al comune di caricare le informazioni contabili in diverse basi dati. Facciamo in modo che una volta inserite nell’applicativo vengano condivise con i livelli necessari e rese disponibili con API. Oppure è inutile chiedere al comune se permette accesso con SPID: meglio chiedere ad Agid.

Se si guardano gli esempi presenti sul sito si vede chiaramente come le interfacce siano già precompilate con i dati del cittadino, e questo è possibile solo con interoperabilità, altrimenti un cittadino dovrà (da smartphone spesso) inserire molti dati (perdendo la pazienza e commettendo un sacco di errori).

Finti ostacoli all’interoperabilità

L’interoperabilità tecnologia non è un problema, se non nella misura in cui non c’è cultura tecnologica. Di tecnologia per quanto ha bisogno di fare la PA per creare servizi digitali utili, ne abbiamo anche troppa (ad esempio, non ci serve il metaverso). L’aspetto tecnologico può essere compreso con completezza e da valutare solo in merito ai carichi di richieste. Del resto, ci sono siti di eCommerce che ricevono milioni di richieste al secondo.

Interoperabilità Umana

Questa potrebbe aumentare, anche se avendo partecipato a tavoli di Forum PA, Assinter e altri, risulta chiaro a tutti nella PA che “abbiamo bisogno dei dati di qualcun altro e che questo non ce li dà o se ce li dà ci fa penare”. Quindi abbiamo bisogno di interloquire con gli altri enti/silos (sia interni alla nostra amministrazione che esterni) per avere dei dati che ci semplificano il lavoro. Il salto umano da fare è solo quello di capire che se vogliamo ricevere dati, dobbiamo anche dare dati e che l’interoperabilità (come la comunicazione umana) è bidirezionale: io chiedo a te dati e tu li chiedi a me, ce li scambiamo e siamo tutti felici.

Interoperabilità di profilazione

Al momento, l’interoperabilità che tecnologicamente è fattibile e umanamente è percepita come necessaria, si sta scontrando con le contrattualistiche e i profili di accesso ai dati, ovvero con la fase “pilota” in cui si cerca di capire chi accede a cosa e come. Alcuni sventolano la privacy come riferimento per far capire che “non è così facile” rendere disponibili dati il cui accesso va dato secondo l’interlocutore che li richiede. Qui ci sentiamo di sottolineare alcuni aspetti:

• gelosia del dato: voglio il tuo dato ma non ti do il mio, per privacy. Il GDPR nell’articolo 1 smonta questa credenza: “Il presente regolamento stabilisce norme relative alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché norme relative alla libera circolazione di tali dati”. Ovvero i dati sono fatti per circolare, non per rimanere chiusi nel server del mio ufficio, o nel data center in cloud.

• Reverse privacy vs once only: ci sono enti che non forniscono il dato per privacy, senza capire che così la danneggiano. Ad esempio, se l’ente A che ha il compito di trattare dati sensibili D non mi espone un API che mi permette di dire se la persona è positiva o negativa, io dovrò richiedere alla persona il dato D, gestirlo, trattarlo, salvarlo, con conseguente rischio maggiore per i dati forniti alla PA. Se il principio fosse once only invece basterebbe chiamare l’API, e tutto si risolverebbe senza trattare il dato. Si tratta della privacy usata per non tutelare la privacy convinti di tutelarla (appunto reverse privacy). Tra l’altro il non richiedere il dato D mi permette di seguire anche il principio della minimizzazione dei dati, ovvero richiedere i soli dati necessari e non dati ridondanti.

Interoperabilità contrattuale

Non di rado nelle periodiche ricognizioni di piattaforme e servizi della PA, viene indicato il fornitore come responsabile della mancata realizzazione di interoperabilità fra sistemi. Non sempre questo è vero, anzi lo è raramente. Innanzitutto, perché esiste una modalità “contrattuale” per garantire la collaborazione del fornitore: è sufficiente inserire tra le attività oggetto della fornitura anche questo aspetto. Il vero problema è che anche il più valido dei fornitori non riuscirà a completare l’attività se dall’altra parte (ovvero la PA A che deve dare il dato alla PA B che sta facendo il contratto con il fornitore) non c’è l’intenzione/capacità/risorse per fare interoperabilità.

La conseguenza è che sempre più spesso ci sono fornitori che promettono “soluzioni accessibili e interoperabili” e vorrebbero anche realizzarle rispettando i contratti. Possono certamente garantire le competenze tecnologiche e la loro professionalità, ma non possono garantire la realizzazione della cooperazione applicativa tra sistemi, il perché è già stato detto: non è un problema di tecnologia.

Risorse economiche

Ad oggi abbiamo un insieme di elementi favorevoli per il cambiamento digitale: la PA vuole fare servizi digitali utili, una parte della cittadinanza usa servizi digitali efficaci (es. eCommerce) e li vorrebbe uguali quando si affaccia alla PA, i fornitori sono (non tutti ma una parte si) pronti a fare interoperabilità, la normativa chiede interoperabilità (Il piano triennale ne parla, il CAD, la Guida dei Diritti di Cittadinanza Digitale), quindi cosa manca davvero per poter fare reale interoperabilità?

Un esempio per capire perché abbiamo bisogno dell’interoperabilità

Proviamo a descrivere, semplificando, un caso d’uso dove il servizio al cittadino viene limitato nella sua efficacia dalla mancanza di cooperazione applicativa (detta anche interoperabilità) tra sistemi della pubblica amministrazione.

Si tratta dell’assegnazione del beneficio relativo alla fornitura gratuita o semi gratuita di libri di testo per gli studenti frequentanti le scuole secondarie di primo e secondo grado con un reddito familiare basso e residenti nel territorio regionale. Il beneficio viene erogato dai Comuni, sulla base delle risorse assegnate dalla Regione. Dunque, per accedere a questo beneficio gli aventi diritto devono: presentare l’istanza online e compilare tutti i dati relativi ai “requisiti”, quindi: ISEE, frequenza scolastica e residenza. Parliamo di circa 60 mila istanze per quanto riguarda la regione che prendiamo come riferimento, ovvero la Puglia.

Il servizio digitalizzato attualmente prevede l’utilizzo di una piattaforma “interoperabile by design” che acquisisce le candidature e provvede alla creazione di un elenco provvisorio delle istanze ammissibili, previa acquisizione dei dati ISEE tramite cooperazione applicativa con la Banca dati dell’INPS e previo controllo preliminare di verifica dell’effettiva frequenza scolastica, tramite cooperazione applicativa con il Ministero per l’Istruzione.

A questo punto però è necessario verificare la correttezza della residenza anagrafica del beneficiario: il singolo Comune dovrà accreditare un proprio funzionario responsabile che dovrà accedere in piattaforma e procedere con la verifica richiesta. Eppure, l’interoperabilità con l’Anagrafe Nazionale della Popolazione Residente avrebbe potuto evitare un importante passaggio nella procedura.

Se volessimo immaginare diversamente l’intero processo, se volessimo immaginare un servizio pubblico che riconosce “le persone” e sa di cosa hanno bisogno e a cosa hanno diritto, potremmo pensare ad una notifica push su AppIO del genitore dello studente frequentante, che ha un ISEE sotto la soglia e che risiede nel Comune X, senza fare niente. Nella notifica il genitore trova perfino le istruzioni per l’utilizzo del contributo “buono libro digitale”, spiegato per bene.

Si passa quindi da una cittadinanza che passa il tempo a scoprire di aver diritto ad un buono, a capire come richiederlo, a inserire tutti i dati per averlo, ad una cittadinanza che riceve una notifica che dice “hai diritto a questo buono, fai così per spenderlo”! Un po’ come accaduto col bonus vacanze ma con l’evoluzione che i controlli per verificare la legittimità della richiesta sono fatti a monte, e quindi solo chi ha diritto riceve la notifica.

Non siamo ancora lì, ma non siamo nemmeno troppo lontani e molte base dati si stanno aprendo o sono in fase pilota per poi aprirsi.

Questo perché consideriamo l’interoperabilità un processo, inarrestabile, che si alimenta di apripista, di best practice e di circoli virtuosi, e per questo progressivamente sempre più i cittadini come professionisti, le persone, chiederanno che i sistemi della PA debbano scambiare dati e informazioni per valorizzare il dialogo che si attua attraverso i servizi digitali, per avere servizi utili, per poter “usare” la PA come usano i servizi di e-commerce.

Nel caso specifico presentato sopra l’interoperabilità:

• permette di fare domanda solo a chi ne ha i requisiti: questo evita malcontento in chi fa domanda e se la vede respinta, solo perché il sistema permetteva di farla, o evita i furbi “che ci provano” facendo sprecare tempo ai controllori
• permette di ridurre al minimo le fasi di controllo: se il controllo è fatto a monte permettendo solo a chi può di fare domanda, le domande si riducono drasticamente
• se i dati sono “interoperabilmente” precompilati, si riducono gli errori di inserimento
• permette di avere nella PA più tempo “di qualità e ragionamento” e meno tempo “burocratico di controllo”
• permette di far evolvere i servizi da #dovereonly (messaggio su IO di paga la Tari) a #dirittoedovere (arriva un messaggio che dice che in base alle tue caratteristiche hai diritto al Bonus vacanze)
• permette di far sentire lo Stato collaboratore del cittadino e dell’impresa e non solo vessatore (se mi scrivono ci sarà qualcosa da pagare)
• permette di semplificare la partecipazione del cittadino alla cosa pubblica: compro su e-commerce, faccio subito ci metto 2 minuti; mi arriva un messaggio dalla PA: sarà sicuramente un pagamento e ci metterò 2 ore a farlo, lo faccio dopo
• permette di fare servizi di qualità, interoperabili, accessibili, sicuri by design, privati (ma il giusto non il troppo) by design
• permette di avere dati di migliore qualità a supporto delle decisioni, con base dati uniche, aggiornate in tempo reale, e consultabili quando serve

Conclusioni

Tutto questo è fantascienza? Tecnologicamente no, è una possibilità che esiste da anni. Umanamente è una necessità sia internamente alla PA che dei cittadini e delle imprese. Come PA, dobbiamo farlo adesso, perché se riusciremo a fare interoperabilità sia tra PAC che tra PAC e PAL in entrambe le direzioni, sia tra PAL, probabilmente avremo fatto un grosso passo per poter dire: noi c’eravamo all’epoca del PNRR e abbiamo fatto un grosso cambiamento nel modo di gestire, lavorare, vivere, interagire con la PA. E la PA potrebbe davvero diventare un alleato nel rilancio del Paese con servizi davvero digitali, smart e utili, e non un mero “controllore analogico burocratico”.