Linee guida AGID e accessibilità

 ACCESSIBILITA’

La legge 4 del 2004, nota anche come Legge Stanca, è intitolata "Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici". Il suo obiettivo principale è garantire l'accessibilità digitale per tutti, inclusi coloro che hanno disabilità, assicurando che possano accedere alle informazioni e ai servizi erogati tramite strumenti informatici e telematici. 

Ecco alcuni punti chiave della legge:

• Accessibilità:

La legge stabilisce il diritto di ogni persona ad accedere a tutte le fonti di informazione e ai relativi servizi, compresi quelli erogati tramite strumenti informatici. 

• Soggetti coinvolti:

La legge si applica alle pubbliche amministrazioni e ai soggetti che forniscono servizi informatici e telematici. 

• Obblighi:

I soggetti interessati sono tenuti ad adottare misure per garantire l'accessibilità, inclusi requisiti tecnici e linee guida specifiche. 

• Tecnologie assistive:

La legge promuove l'uso di tecnologie assistive per superare le barriere all'accesso per le persone con disabilità. 

• Formazione:

Sono previste attività formative per promuovere la conoscenza e l'applicazione dei principi di accessibilità. 

• Responsabilità:

La legge definisce le responsabilità dei diversi soggetti coinvolti nell'attuazione delle disposizioni sull'accessibilità. 

• Valutazione e verifica:

Sono previste procedure per la valutazione e la verifica dell'accessibilità dei siti web e delle applicazioni. 

In sintesi, la Legge 4 del 2004 è un importante strumento per promuovere l'inclusione digitale e garantire che tutti, indipendentemente dalle proprie capacità, possano partecipare pienamente alla società dell'informazione. 

Art. 9 (Responsabilita)
1. L'inosservanza delle disposizioni della presente legge 

((da parte dei soggetti di cui all'articolo 3, comma 1))

 è rilevante ai fini della misurazione e della valutazione della performance individuale dei dirigenti responsabili e comporta responsabilità dirigenziale e responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n. 165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti.

((1-bis. L'inosservanza delle disposizioni della presente legge da parte dei soggetti di cui all'articolo 3, comma 1-bis, è accertata e sanzionata dall'AgID, fermo restando il diritto del soggetto discriminato di agire ai sensi della legge 1° marzo 2006, n. 67. Si osservano, in quanto applicabili, le disposizioni contenute nel capo I, sezioni I e II, della legge 24 novembre 1981, n. 689. Se a seguito dell'istruttoria l'AgID ravvisa violazioni della presente legge, fissa il termine per l'eliminazione delle infrazioni stesse da parte del trasgressore. In caso di inottemperanza alla diffida di cui al periodo precedente, l'AgID applica la sanzione amministrativa pecuniaria fino al 5 per cento del fatturato.))

L'AGID (Agenzia per l'Italia Digitale) svolge un ruolo centrale nella definizione e promozione dell'accessibilità degli strumenti informatici in Italia, con particolare attenzione alla Pubblica Amministrazione e, con l'avvento dell'European Accessibility Act (EAA), anche al settore privato.

Le Linee Guida sull'accessibilità degli strumenti informatici di AGID, emanate ai sensi dell'art. 11 della Legge 4/2004 (Legge Stanca), sono il riferimento principale per la Pubblica Amministrazione. Queste linee guida definiscono:

• Requisiti tecnici per l'accessibilità: riguardano siti web, applicazioni mobili, software, documenti elettronici, hardware e postazioni di lavoro. Fanno riferimento a standard internazionali come le WCAG (Web Content Accessibility Guidelines) 2.1 – livello AA e la norma europea EN 301 549.
• Metodologie di verifica dell'accessibilità: indicano come testare la conformità degli strumenti informatici ai requisiti.
• Modello della dichiarazione di accessibilità: un documento che le amministrazioni (e alcuni privati) devono compilare e pubblicare annualmente (entro il 23 settembre) per rendere pubblico lo stato di accessibilità dei propri siti web e applicazioni mobili.
• Meccanismo di feedback: la possibilità per i cittadini di segnalare problemi di accessibilità riscontrati sui siti o app.
• Metodologia di monitoraggio e valutazione: AGID effettua il monitoraggio sui siti web e le app su un campione rappresentativo, relazionando ogni tre anni alla Commissione Europea.
• Circostanze che determinano un onere sproporzionato: casi in cui il rispetto di un requisito di accessibilità comporterebbe un onere eccessivo o un'alterazione sostanziale della natura del servizio.

Novità con l'European Accessibility Act (EAA) - D. Lgs. 82/2022:

Dal 28 giugno 2025, l'European Accessibility Act (Direttiva UE 2019/882, recepita in Italia con il D. Lgs. 82/2022) estende gli obblighi di accessibilità anche a un'ampia gamma di prodotti e servizi offerti dal settore privato. AGID è stata designata come Autorità di vigilanza anche per questa normativa.

Le nuove Linee Guida in consultazione (e che si prevede entrino pienamente in vigore) relative all'EAA si applicano a:

• Siti web e applicazioni mobili (anche per i privati).
• Servizi bancari per consumatori (es. online banking, app di pagamento).
• Commercio elettronico (e-commerce).
• Servizi di trasporto passeggeri (aerei, autobus, ferroviari, per vie navigabili, inclusi urbani, extraurbani e regionali).
• Servizi di comunicazione elettronica.
• Servizi che forniscono accesso a servizi di media audiovisivi.
• Lettori di libri elettronici (e-reader) e software dedicati.
• Terminali self-service (bancomat, biglietterie automatiche, ecc.).
• Dispositivi hardware e software con interfaccia utente (smartphone, tablet, PC).
• Documenti elettronici.

Punti chiave e adempimenti per le aziende (dal 28 giugno 2025):

• Obbligo generalizzato: Le microimprese sono escluse, ma tutte le altre aziende che offrono i prodotti e servizi rientranti nell'EAA dovranno adeguarsi.
• Dichiarazione di Accessibilità: Anche per il settore privato diventa obbligatoria la predisposizione e pubblicazione della dichiarazione di conformità.
• Progettazione inclusiva: Non si tratta solo di adeguamenti tecnici puntuali, ma di progettare l'intero servizio o l'interfaccia che lo eroga pensando fin dall'inizio a tutte le potenziali esigenze dell'utenza.
• Sanctions: Le aziende non conformi rischiano sanzioni economiche (fino al 5% del fatturato annuo), danni reputazionali e la possibile rimozione dei prodotti/servizi dai marketplace.

 

Accessibilità dei moduli e form

In sintesi, le linee guida AGID mirano a garantire che tutti i cittadini, comprese le persone con disabilità, possano fruire dei servizi digitali in modo autonomo, senza discriminazioni e con facilità. È fondamentale che sia il settore pubblico che quello privato si adeguino a queste normative per promuovere un web e servizi digitali sempre più inclusivi.

Per informazioni dettagliate e per consultare i documenti ufficiali, si consiglia di visitare il portale tematico di AGID sull'accessibilità digitale: https://www.agid.gov.it/it/design-servizi/accessibilita.

Le Linee Guida sull'accessibilità degli strumenti informatici di AGID per la Pubblica Amministrazione, basate sull'articolo 11 della Legge 4/2004 e con riferimento alla norma tecnica europea EN 301 549, includono requisiti che si applicano all'accessibilità dei moduli e dei campi di input.

Sebbene il documento non abbia una sezione specifica intitolata "moduli e form", i requisiti per questi elementi rientrano nelle categorie più ampie di:

• Requisiti tecnici per il Web (Capitolo 2.2): Le linee guida fanno riferimento agli standard internazionali come le WCAG (Web Content Accessibility Guidelines) 2.1 – livello AA, che contengono indicazioni precise su come rendere i form accessibili. Questo include, ad esempio, l'etichettatura corretta dei campi di input (<label>) e la gestione del focus da tastiera.
• Documenti non Web (Capitolo 2.3): Per i documenti scaricabili che possono contenere moduli (ad esempio, PDF interattivi), si applicano requisiti specifici per i documenti non web.

In generale, le linee guida di AGID promuovono una progettazione inclusiva che assicuri che le informazioni e i comandi, compresi quelli all'interno dei moduli, siano:

• Percettibili: le informazioni e i comandi necessari per l'esecuzione dell'attività devono essere sempre disponibili e percettibili.
• Comprensibili: facili da capire e da usare.
• Operabili: consentire una scelta immediata dell'azione adeguata per raggiungere l'obiettivo voluto.
• Tolleranti agli errori: l'ambiente deve prevenire gli errori e, in caso si manifestino, fornire messaggi appropriati che individuano chiaramente l'errore e le azioni necessarie per superarlo.

Per approfondire i requisiti specifici relativi ai moduli e ai campi di input, è necessario consultare direttamente il Capitolo 2 delle "Linee Guida sull'accessibilità degli strumenti informatici" di AGID, che dettaglia i riferimenti tecnici alla norma UNI CEI EN 301549.

È possibile consultare il documento completo delle Linee Guida sull'accessibilità degli strumenti informatici per la Pubblica Amministrazione sul sito di AGID.

Accessibilità dei contenuti mobili

Le Linee Guida sull'accessibilità degli strumenti informatici di AGID, emanate ai sensi della Legge 4/2004 (Legge Stanca) e costantemente aggiornate, dedicano ampio spazio all'accessibilità dei contenuti mobili e, più in generale, delle applicazioni mobili.

I principi e i requisiti per l'accessibilità dei contenuti mobili si basano sugli stessi standard internazionali e norme europee di riferimento per l'accessibilità web, adattati alle specificità del contesto mobile. I riferimenti chiave sono le WCAG (Web Content Accessibility Guidelines) 2.1 – livello AA e la norma EN 301 549.

Ecco i punti chiave e le indicazioni generali fornite dalle linee guida AGID per l'accessibilità dei contenuti e delle applicazioni mobili:

1. Applicazioni mobili come strumenti informatici: Le linee guida classificano esplicitamente le applicazioni mobili come "strumenti informatici" soggetti agli obblighi di accessibilità, sia per la Pubblica Amministrazione che, con l'entrata in vigore dell'European Accessibility Act (EAA), anche per il settore privato che rientra nell'ambito di applicazione dell'EAA.
2. Riferimento alle WCAG 2.1 e EN 301 549:
• WCAG 2.1: Vengono recepite le WCAG 2.1, che includono specifici criteri di successo per il mobile. Questi riguardano aspetti come:
• Orientamento dello schermo: Il contenuto non deve limitare l'orientamento (verticale/orizzontale) a meno che non sia essenziale.
• Puntatori (target size): Le aree cliccabili (pulsanti, link) devono avere dimensioni sufficienti per essere attivate facilmente con il tocco, evitando errori.
• Gestures (movimenti): I comandi basati su gesti complessi (es. "pinch-to-zoom" o swipe specifici) devono avere alternative più semplici o essere configurabili.
• Contenuti sensibili al movimento: Eventuali funzioni attivate dal movimento del dispositivo devono avere alternative accessibili.
• Contenuti visibili e operabili: Assicurare che tutti i contenuti e i controlli siano facilmente visibili e utilizzabili, anche con ingrandimento, e non siano nascosti da tastiere virtuali o altre interfacce.
• EN 301 549: Questa norma europea integra i requisiti delle WCAG e aggiunge specifiche tecniche per i prodotti e i servizi ICT, comprese le applicazioni mobili. Ad esempio, dettaglia requisiti per:
• Accessibilità dei controlli nativi: I componenti dell'interfaccia utente nativi (es. pulsanti, slider, caselle di testo) devono essere accessibili tramite le API di accessibilità del sistema operativo (es. VoiceOver su iOS, TalkBack su Android).
• Supporto delle impostazioni di accessibilità del sistema: L'app deve rispettare le preferenze dell'utente impostate a livello di sistema operativo (es. dimensione del testo, modalità scura, riduzione animazioni).
• Interazione con le tecnologie assistive: L'app deve essere compatibile con screen reader, tastiere esterne, switch e altri strumenti compensativi.
3. Principi di progettazione generale applicati al mobile:
• Percepibilità: Testo leggibile con contrasto sufficiente, immagini con alternative testuali, video con sottotitoli e audiodescrizioni.
• Operabilità: Navigazione intuitiva, possibilità di utilizzare l'app tramite tastiera o switch (anche se su mobile l'interazione touch è predominante, l'accessibilità da tastiera è cruciale per alcune disabilità), gestione del focus.
• Comprensibilità: Linguaggio semplice e chiaro, istruzioni comprensibili, messaggi di errore chiari e suggerimenti per la correzione.
• Robustezza: Compatibilità con diverse tecnologie assistive e browser/sistemi operativi mobili.
4. Dichiarazione di Accessibilità: Anche per le applicazioni mobili, i soggetti obbligati (PA e in futuro privati) devono compilare e pubblicare una "Dichiarazione di Accessibilità" annuale, specificando lo stato di conformità dell'applicazione ai requisiti e un meccanismo di feedback per segnalare eventuali problemi.

In sintesi, le linee guida AGID richiedono che le applicazioni e i contenuti mobili siano progettati e sviluppati in modo tale da essere pienamente fruibili da parte di tutte le persone, indipendentemente dalle loro abilità, garantendo un'esperienza utente inclusiva e paritaria.

Strumenti per la valutazione dell'accessibilità dei siti web

Ci sono diversi strumenti che possono essere usati per valutare l'accessibilità dei siti web e che si dividono in due categorie principali: automatici e manuali.

Strumenti automatici

Gli strumenti automatici sono utili per identificare rapidamente problemi comuni e ovvi, come attributi alt mancanti, contrasto insufficiente e struttura di intestazione scorretta. Non possono, però, rilevare tutti i problemi di accessibilità e sono più efficaci se usati come un primo controllo.

• Estensioni per browser: Sono tra gli strumenti più semplici e veloci da usare. Si integrano direttamente nel browser e permettono di analizzare la pagina web che stai visualizzando. Esempi popolari sono WAVE Evaluation Tool, Lighthouse (integrato in Chrome DevTools) e axe DevTools.

• Servizi online: Questi strumenti scansionano un sito web a partire da un URL. Un esempio molto usato è il già citato WAVE, che offre un servizio online oltre all'estensione. Un altro è AChecker. WAVE è una suite di strumenti di valutazione che aiuta gli autori a rendere i loro contenuti web più accessibili alle persone con disabilità. WAVE può identificare molti errori di accessibilità e delle Linee Guida per l'Accessibilità dei Contenuti Web (WCAG), ma facilita anche la valutazione umana dei contenuti web.

• Scanner desktop/server: Software più potenti che possono analizzare un intero sito web o un set di pagine, utili per progetti più grandi. Tra questi, troviamo SortSite e Accessibility Checker di Monsido. MAUVE++ (Multiguideline Accessibility and Usability Validation Environment) è un sistema per valutare l'accessibilità dei siti web controllandone il codice HTML e CSS tramite linee guida, fornisce risultati di convalida per diversi tipi di stakeholder e supporta la convalida delle linee guida W3C WCAG 2.1.

Strumenti manuali

La valutazione manuale è fondamentale perché gli strumenti automatici non sono in grado di comprendere il contesto e la complessità di un sito web. Questi controlli richiedono una comprensione delle linee guida sull'accessibilità (WCAG). 🧐

• Lettori di schermo: Essenziali per capire come gli utenti non vedenti o ipovedenti navigano sul sito. I più comuni sono NVDA (gratuito per Windows), JAWS (a pagamento) e VoiceOver (integrato in macOS e iOS). Usare un lettore di schermo ti permette di verificare se le etichette sono corrette, se il flusso di navigazione è logico e se tutti i contenuti sono accessibili.

• Tastiera: Navigare un sito solo con la tastiera (senza mouse) è un test cruciale. Permette di verificare che tutti gli elementi interattivi (link, pulsanti, form) siano raggiungibili e attivabili, e che l'ordine di tabulazione sia logico.

• Zoom del browser e opzioni ad alto contrasto: Testare il sito ingrandendo il testo o usando le impostazioni di alto contrasto del sistema operativo serve a verificare la leggibilità per gli utenti con problemi di vista.

• Valutazione del codice: Esaminare manualmente il codice HTML, CSS e JavaScript per assicurarsi che siano usate le corrette pratiche di accessibilità (es. uso di elementi semantici, attributi ARIA, ecc.). A supporto di questa attività può essere utile il supporto del tool MUAVE++

Gaia–X, il cloud dei cloud o meglio il cloud federato europeo

 Scopo del progetto e principi fondanti

Il progetto GAIA-X si propone lo sviluppo di una federazione di infrastrutture di dati e fornitori di servizi per l’Europa con gli obiettivi dichiarati di essere efficiente, competitivo, sicuro e affidabile.

Il principio fondante è quello di realizzare una infrastruttura a livello europeo il cui fine è quello di raggiungere la sovranità digitale europea nel campo del cloud.

Lo scopo è quello di collegare differenti sistemi cloud già esistenti per far interagire e far dialogare banche dati tra di loro e renderne disponibile i dati ai cittadini UE, consentendo la creazione di nuove piattaforme diversificate. Gaia X fornirà un uno standard condiviso dai paesi partner che garantirà la sicurezza dei dati.

Quindi la finalità è lo sviluppo di una “data economy” continentale fondata sui valori europei e coerente con le finalità della strategia europea per i dati. Creare una data strategy europea nella quale l’Europa possa esercitare la propria data sovereignty senza dipendere da altri soggetti.

Il fondamento strategico si allinea all’aggiornamento che la Commissione europea ha fatto a maggio 2021 della sua Strategia industriale, annunciando il lancio dell’Alleanza per i dati industriali, l’edge e il cloud, in quanto parte della Strategia europea sui dati, con cui Bruxelles mira a stimolare la fornitura europea di cloud affidabili. Tale strategia prevede, tra gli ambiziosi obiettivi fissati per il Decennio digitale europeo, da raggiungere entro il 2030, un tasso di adozione del 75% di servizi cloud avanzati per le aziende europee.

Organizzazione e persone

L'entità giuridica della Fondazione GAIA-X è stata p

resentata al pubblico il 4 giugno 2020. Si tratta di un'associazione internazionale senza scopo di lucro (AISBL, association internationale sans but lucratif), con sede in Belgio (Gaia-X European Association for Data and Cloud AISBL - Avenue des Arts 6-9, 1210 Bruxelles. Belgium - info@gaia-x.eu).

Le figure principali sono:

• Hubert Tardieu, Direttore Generale di Gaia X e consigliere indipendente e a lungo stretto collaboratore di Thierry Breton, oggi commissario europeo al Mercato interno.
• Maximilian Ahrens, responsabile tecnologico di T-Systems (della compagnia telefonica Deutsche Telekom) e presidente del consiglio d'amministrazione di Gaia-X.
• Francesco Bonfiglio, CEO di Gaia X.

Il progetto ha avuto origine da una proposta del ministro tedesco dell'economia e dell'Energia Peter Altmaier, subito sostenuto dal ministro dell'economia francese Bruno Le Maire durante l'estate 2019. un primo Position Paper franco-tedesco è stato pubblicato il 18 febbraio 2020.

L'annuncio sulla Fondazione GAIA-X AISBL da parte di 22 membri fondatori è stato dato in una specifica conferenza stampa congiunta nel giugno 2020.

I 22 membri fondatori provengono sia dalla Germania che dalla Francia e rappresentano i fornitori di servizi cloud, gli utenti del cloud, le associazioni di ricerca e di categoria e sono: Amadeus CRS, Atos, Beckhoff Automation, Bosch, BMW, CISPE, DE-CIX, Deutsche Telekom, Docaposte, EDF, Fraunhofer, German Edge Cloud, Institut Mines Telecom, International Data Spaces Association, Orange, 3DS Outscale, OVHcloud, PlusServer, Safran, SAP, Scaleway e Siemens.

Ad oggi sono 300 i membri che da tutte le parti del mondo si sono uniti al progetto. In merito a questo, infatti, sono stati ultimamente sollevati dei dubbi in merito alla presenza di partner come Microsoft, Oracle, Huawei e Alibaba, in contrapposizione alla mission del progetto, anche se questi non hanno diritto di voto, ma fanno parte dei gruppi di lavoro e anche se l'azienda di Redmond, una delle più attive in queste attività, ha dichiarato che le scelte finali saranno sempre dell'Europa.

Gaia-X European Association for Data and Cloud AISBL rappresenta il “core” della struttura dell’organizzazione della Gaia-X vision.

La struttura dell’organizzazione (vedi figura riportata di seguito) è composta dai seguenti elementi:

• L'Assemblea Generale (General Assembly) è composta da tutti i membri dell'Associazione Gaia-X. L'Assemblea Generale ha pieni poteri per raggiungere gli obiettivi della Gaia-X European Association for Data and Cloud AISBL.

• Il Consiglio Direttivo (Board of Directors) delibera su questioni importanti riguardanti l'Associazione Gaia-X. È presieduto da un presidente e da un vicepresidente.

• Il Consiglio di Gestione (Management Board) gestisce le attività quotidiane dell'Associazione Gaia-X. Il Consiglio di Gestione è composto da un Chief Executive Officer (CEO), un Chief Operating Officer (COO), un Chief Technical Officer (CTO) e un Chief Financial Officer (CFO) e altro personale della segreteria.

• Il Comitato per la regolamentazione (Policy Rules Committee) è responsabile dell'approvazione delle politiche e delle regole relative al Gaia-X Data Ecosystem e al suo funzionamento (insieme alle "Data Ecosystem Policy Rules"). Il Comitato è presieduto da un Presidente e da un Vicepresidente.

• Il Comitato Tecnico (Technical Committee) è competente per tutte le questioni tecniche attinenti allo scopo dell'Associazione. Decide in merito all'Architettura Tecnica, all'Architettura degli Standard e al Portafoglio del Software Open Source, inclusi i Servizi della Federazione. Gestisce gli input dai pacchetti di lavoro, coordina i dimostratori e i casi d'uso.

• Il Data Space Business Committee sostiene la creazione di spazi dati. La sua missione è stimolare e supportare attivamente la creazione di Data Spaces in tutta Europa e dare raccomandazioni sulle migliori pratiche per le materie prime dello spazio dati e i relativi principi di progettazione generici.

• Working Groups: I Gruppi di Lavoro all'interno dell'Associazione si occupano di compiti definiti. Sono gestiti dal Comitato Tecnico. Gli attuali gruppi lavoro sono:

o   Working Group: User

o   Working Group: Provider

o   Working Group: X-Association

o   Working Group: Federation Services/Open-Source-Software

o   Working Group: Architecture

o   Working Group: Portfolio

• Gaia-X Hub nazionali: gli Hub nazionali sono invitati a partecipare alla progettazione dell’infrastruttura dati sovrana. Contribuiscono ai casi d'uso di settori specifici e beneficiano dello scambio di idee e delle migliori pratiche.

Gaia-X European Association for Data and Cloud AISBL

Stato di avanzamento

Il lavoro pluriennale già esistente sia dell'International Data Spaces Association (IDSA) che dei Cloud Infrastructure Services Providers in Europe (CISPE) sono stati presentati come principali acceleratori per sviluppare le regole GAIA-X in meno di 6 mesi.

Sono stati presentati diversi use case nei vari ambiti dell’energia, industria, salute e agricoltura. A titolo esemplificativo, si rilevano due casi d’uso, di possibile attinenza con le attività del settore agricolo, presentati dalla Germania che sono rispettivamente:

Use case AgriML

https://www.bmwi.de/Redaktion/EN/Artikel/Digital-World/GAIA-X-Use-Cases/agriML-automatic-crop-type-recognition-with-intelligent-satellite-imagery.html

Uno degli obiettivi del progetto AgriML - Machine-Learning for Agriculture in Alto Adige è estendere il riconoscimento automatico delle forme colturali al 100% dichiarato sul territorio della Provincia Autonoma di Bolzano. Altro obiettivo è automatizzare il controllo delle forme colturali per verificarne sia la correttezza che eventuali successive modifiche alle stesse.

Use case Agri-GAIA

https://www.bmwi.de/Redaktion/EN/Artikel/Digital-World/GAIA-X-Use-Cases/agri-gaia.html

Agri-Gaia è concepito come un'infrastruttura decentralizzata per lo scambio di dati e algoritmi in agricoltura. GAIA-X viene utilizzato come infrastruttura di base per implementare, ad esempio, la gestione dell'identità e la descrizione semantica di servizi e dati. Una piattaforma centrale nell'architettura Agri-Gaia fornisce questi servizi e offre dati e algoritmi di base che sono rilevanti in agricoltura e su cui si può basare un'ampia gamma di prodotti.

Nella figura seguente è mostrata la roadmap con le milestones del progetto Gaia-X:

Architettura

Gaia-X, basata su standard esistenti e tecnologia open source, si pone infatti come un’infrastruttura di dati ed ecosistemi che punta ad assumere la forma di una infrastruttura “hyperscaling”, ovvero un’architettura di server massivamente scalabili e reti virtuali.

Tutti i sistemi devono essere interoperabili e i fornitori di servizi di cloud computing che parteciperanno al progetto saranno autonomi, ma dovranno rispettare determinate regole comuni e certificare i propri servizi, dal punto di vista tecnico, così come dal punto di vista legale, mentre la tutela della privacy e della sicurezza informatica deve essere sempre posta al centro.

Il modello concettuale si basa sulle seguenti entità:

Federator: sono responsabili dei Servizi della Federazione e della Federazione stessa e sono indipendenti l'uno dall'altro. I federatori sono i partecipanti a Gaia-X. Possono esistere uno o più federatori per tipo di servizio federativo. Una Federazione si riferisce a un insieme sciolto di attori interagenti che, direttamente o indirettamente, consumano, producono o forniscono risorse correlate.

Provider: è un partecipante che fornisce risorse nell'Ecosistema Gaia-X. Il Fornitore definisce l'offerta del servizio includendo termini e condizioni e politiche tecniche. Inoltre, fornisce l'istanza del servizio che include un'auto-descrizione e relative politiche. Pertanto, il Provider gestisce risorse diverse.

Consumer: è un partecipante che cerca offerte di servizi e utilizza istanze di servizio nell'Ecosistema Gaia-X per abilitare offerte digitali per gli Utenti finali.

Resources e Resource Template: le risorse descrivono in generale i beni e gli oggetti di un ecosistema Gaia-X. Una risorsa può essere una risorsa Dati, una risorsa Software, un Nodo o un'Interconnessione. Ogni risorsa è caratterizzata da endpoint e diritti di accesso e appartiene ad un proprietario della risorsa.

Data spaces: In generale, il termine "data spaces" si riferisce a un tipo di relazione di dati tra partner di fiducia, ciascuno dei quali applica gli stessi standard e regole elevati per l'archiviazione e la condivisione dei propri dati. Tuttavia, di fondamentale importanza per il concetto di spazio dati è che i dati non sono archiviati centralmente ma alla fonte e sono quindi condivisi (tramite l'interoperabilità semantica) solo quando necessario. Nell'ambito di Gaia-X, i dati negli spazi dati sono detenuti esclusivamente dai membri dell'Associazione.

Ruolo che gioca l’ITALIA

Tantissime sono le compagnie private italiane, molte di grande rilievo, come Tim, Intesa Sanpaolo, Engineering, Dedagroup, Reply, Retelit, le partecipate pubbliche come Eni, Enel, Leonardo, Poste Italiane e Sogei e le associazioni industriali come Confindustria Digitale e Servizi Innovativi che sono approdate alla membership di GAIA-X.

Confindustria, d’intesa con le Istituzioni italiane, ha il compito di promuovere la costituzione e di coordinare un Hub italiano, che agirà da aggregatore e punto di riferimento per lo sviluppo dell'economia dei dati a livello Paese.

L’evento di Confindustria del 28 maggio scorso ha rappresentato il momento di avvio di un percorso condiviso, volto ad aggregare e coordinare tutti i soggetti interessati allo sviluppo di progetti che mirano alla valorizzazione dei dati, ed è stata l’occasione per conoscere il progetto europeo e le modalità di realizzazione in Italia.

Sono stati presentati alcuni "use case" nell’ambito cloud/dati/HPC per promuovere le attività del Regional Hub, stimolare l’interesse e il coinvolgimento delle aziende italiane nello sviluppo di idee progettuali e favorire così la crescita dell’economia dei dati nel nostro Paese.

Per realizzarlo il patrimonio ICT del nostro Paese sarà razionalizzato, saranno verificati e controllati i data center attuali per verificare quelli che hanno le condizioni per essere ritenuti partner affidabili.

Il Piano sarebbe quello di lasciare i dati in Italia affinché la giurisdizione di riferimento sia quella italiana, anche se, con il “Cloud Act” approvato nel 2018 negli Stati Uniti, gli Stati Uniti hanno diritto di acquisire dati informatici dagli operatori di cloud computing a prescindere da dove questi dati si trovino a condizione che questi operatori siano sottoposti alla giurisdizione degli Stati Uniti, che si tratti di società europee con una filiale negli USA o che operino nel loro Paese.

Da qui ne discende che i dati ospitati sui server di Google, Amazon, Microsoft o altri ancora, che hanno sede negli Stati Uniti, anche quando questi dovessero appartenere a utenti europei saranno gli Stati Uniti ad averne il controllo, qualora la P.A. dovesse appoggiarsi a queste aziende.

Ipotesi di Sistema Europeo di Condivisione OPEN DATA

ODSE (Open Data Sharing Environment)

Il panorama degli open data messi a disposizione dagli enti pubblici attualmente propone una serie di accessi ai dati tramite link predisposti su apposite pagine web raggiungibili dai siti istituzionali degli stessi enti fornitori o tramite cataloghi di link, suddivisi per aree tematiche, collezionati sui portali istituzionali nazionali degli open data quali www.data.gov.it per l’Italia e www.europeandataportal.eu che reindirizza a tutti i portali open data istituzionali di tutti gli stati membri della Comunità Europea.

Tale struttura basata sui link alle risorse dati, benché consenta di accedere ai dati direttamente da applicazioni costruite ad hoc, non consente un uso ed una gestione integrata degli open data. Di fatti nel caso in cui si voglia sviluppare applicazioni che fanno uso degli open data è necessario ricercare prima i corrispondenti link sugli appositi portali per poi implementarli nelle proprie applicazioni.

Per poter mettere a sistema tutti gli open data, sia nazionali che europei, in maniera integrata e automatica potrebbe essere utile declinare, in termini di gestione, integrazione e uso degli open data, l’attuale progetto europeo EUCISE2020. Il progetto EUCISE2020 è coordinato dall’Agenzia Spaziale Italiana (ASI) e si propone di creare un sistema decentrato e distribuito per lo scambio di informazioni che colleghi fra loro tutte le comunità di utilizzatori, sia civili che militari, a livello europeo intersettoriale e internazionale, comprese le agenzie UE ed ha l’obiettivo di sviluppare una rete interoperabile di scambio e condivisione d'informazioni a partire da sistemi e piattaforme operative nazionali ed europee vigenti, in un intento di maggiore efficienza, qualità, reattività e supporto al coordinamento delle operazioni di sorveglianza nel settore marittimo europeo, nonché di promozione dell'innovazione ai fini della prosperità e sicurezza dei cittadini dell'UE.

EUCISE2020, già concluso con successo, ha dato vita ad una ambiente di condivisione di informazioni indipendente e non vincolante per i sistemi di informazione appartenenti agli enti pubblici partecipanti o per i sistemi settoriali europei già esistenti. Tale filosofia ben si presta a quelli che sono i principi cardini della condivisione degli open data.

L'ambiente EUCISE2020 è pensato per consentire l'interoperabilità dei sistemi legacy nazionali o europei appartenenti agli enti pubblici degli Stati membri mediante tre componenti:

• uno o più Adaptor che consentono ad un sistema legacy (LS) di un ente di connettersi a un nodo nazionale. Trasforma i dati LS nel modello di dati EUCISE comune. Consente sia di fornire e sia di ricevere dati; 
•  i Gateway (GW) – nodo nazionale semplice - che implementa le specifiche EUCISE comuni e implementa il protocollo di messaggistica per lo scambio di informazioni con gli adaptor o con gli altri gateway;
• i Node (NODE) - gateway avanzato – che è in grado di eseguire attività e servizi avanzati come fusione e archiviazione di informazioni.

Lo scambio di informazioni tra i partecipanti in EUCISE2020 viene effettuato sulla base di un modello che prevede le seguenti funzioni:

Pull: il consumatore conosce l'elenco esatto dei fornitori e chiede informazioni; 

Pull Unknown Recipients: il consumatore non conosce l'elenco esatto dei provider e chiede le informazioni di interesse a tutti i possibili fornitori partecipanti alla rete EUCISE2020. In questo caso, potrebbero verificarsi diverse risposte alla richiesta.

Push: il provider conosce l'elenco esatto dei consumatori ed invia loro le informazioni indipendentemente dal fatto che questi abbiano precedentemente richiesto tali informazioni.

Push Unknown Recipients: il provider non conosce l’elenco dei consumatori, e quindi invia le informazioni al nodo che si preoccupa di inviarle ad un elenco di consumatori scelti secondo le regole EUCISE2020 definite in base alla comunità di appartenenza, alle aree di interesse, allo scopo, al tipo di entità ed alla sottoscrizione dei servizi disponibili.

Pubblica: il provider condivide un elenco di informazioni fornite al sistema in modalità periodica ad un elenco di consumatori che hanno sottoscritto il servizio.

Sottoscrizione: il consumatore può sottoscriversi a un servizio per ricevere automaticamente informazioni su un'entità, un’area o una comunità

Mutuando il sistema EUCISE2020 sulle esigenze di condivisione degli open data potremmo pensare ad un sistema analogo, denominato ODSE (Open Data Sharing Environment), che consenta di veicolare gli open data di tutti gli enti pubblici di tutti gli Stati membri attraverso una infrastruttura distribuita a cui tutti i sistemi open data siano collegati in modo paritario.

Ogni Stato membro predispone uno o più nodi (semplice o avanzato) a cui ogni ente pubblico può collegare un adaptor per la condivisione degli open data (sia come provider che come consumer).

Gli open data sono classificati per aree di interesse, per scopo e per tipo di entità e sono disponibili in cataloghi.