Sovranità digitale nell'infrastruttura documentale: cosa significa e perché è importante

“Ospitato nell’UE” non è lo stesso di “sovrano nell’UE.” Questa distinzione è la fonte della maggior parte dei problemi di conformità che le organizzazioni scoprono quando è troppo tardi: dopo una valutazione dell’impatto del trasferimento dei dati, dopo un’indagine regolatoria, o dopo che un fornitore cambia i propri termini.

Per i documenti che hanno valore legale, la questione della sovranità non è accademica. Determina se la propria organizzazione controlla le proprie prove o se tale controllo è delegato a un fornitore in base a termini che possono cambiare.

Cosa significa sovranità per l’infrastruttura documentale

La sovranità sull’infrastruttura documentale significa:

Residenza dei dati: i documenti sono memorizzati su infrastrutture fisicamente situate in una giurisdizione in cui si applica la legge sulla protezione dei dati applicabile, e nessuna copia viene conservata o elaborata al di fuori di quella giurisdizione senza consenso esplicito.

Controllo degli accessi senza eccezioni per il fornitore: il fornitore non può accedere ai propri documenti se non nei termini espressamente concordati. Ciò esclude l’accesso di manutenzione del fornitore, le richieste delle forze dell’ordine ai sensi della legge straniera e l’accesso da parte di società madri in altre giurisdizioni.

Portabilità delle prove: è possibile esportare tutti i propri documenti, le tracce di audit, i timestamp e i pacchetti di prove in un formato verificabile senza la partecipazione del fornitore. Se il fornitore chiude domani, le prove rimangono valide.

Nessuna esposizione a giurisdizioni straniere: il fornitore non è soggetto a leggi che obbligano alla divulgazione a governi o agenzie stranieri, come il CLOUD Act statunitense o la legislazione equivalente in altre giurisdizioni.

Perché “ospitato nell’UE” non è sufficiente

Un servizio cloud può ospitare dati in datacenter dell’UE pur rimanendo soggetto a giurisdizione non UE. Se la società operativa è costituita negli Stati Uniti, la sua società madre è con sede negli USA, o è soggetta alla legge statunitense attraverso altri mezzi, potrebbe essere costretta ai sensi del CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) a produrre dati memorizzati in strutture dell’UE alle forze dell’ordine statunitensi, senza la conoscenza o il consenso dell’interessato.

La Corte di giustizia dell’UE (CGUE) ha invalidato lo EU-US Privacy Shield nel 2020 (Schrems II) precisamente perché la legge sulla sorveglianza statunitense rende impossibile una protezione adeguata per i dati personali trasferiti a o accessibili da entità controllate dagli USA. Il successivo EU-US Data Privacy Framework è stato in incertezza legale sin dalla sua adozione.

Per i documenti contenenti dati personali (che includono fatture, documenti HR, contratti e documenti medici), un fornitore soggetto alla giurisdizione statunitense che memorizza i dati in datacenter dell’UE non è una soluzione sovrana. La residenza dei dati è nell’UE; l’esposizione legale non lo è.

Il problema del vendor lock-in specifico per le prove documentali

La maggior parte delle piattaforme documentali crea un lock-in invisibile fino a quando non si cerca di andarsene. Per i documenti senza valore legale, questo è un inconveniente. Per i documenti che servono come prove legali, è un rischio strutturale.

I meccanismi specifici di lock-in da tenere d’occhio:

Formati proprietari della traccia di audit: se la traccia di audit del fornitore non è esportabile in un formato verificabile, la catena di custodia dipende dall’operatività del sistema del fornitore e dall’accessibilità della sua API. Se il fornitore viene acquisito, chiude o modifica la sua API, la catena di custodia potrebbe diventare non verificabile.

Timestamp da autorità controllate dal fornitore: se i timestamp RFC 3161 sui propri documenti sono emessi da una TSA gestita dal fornitore, la verifica di quei timestamp dopo la fine del rapporto con il fornitore richiede la continua cooperazione del fornitore. Questa è una contraddizione: il timestamp dovrebbe essere verificabile in modo indipendente.

Registri di validazione opachi: se i rapporti di validazione nel pacchetto di prove sono HTML leggibile dall’uomo piuttosto che dati strutturati analizzabili da una macchina, un futuro revisore potrebbe non essere in grado di riprodurre la validazione senza rieseguirla, il che non dice nulla sull’eventuale conformità del documento al momento dell’archiviazione.

Il test per la vera sovranità: è possibile portare i propri documenti e pacchetti di prove a una terza parte tecnicamente competente che non ha mai interagito con il proprio fornitore, e farle verificare l’integrità e la provenienza di ogni documento, utilizzando solo standard aperti e infrastruttura a chiave pubblica?

Se la risposta è no, l’infrastruttura di prove non è sovrana.

GDPR e obblighi di conservazione dei documenti

Il GDPR crea tensioni specifiche con la conservazione dei documenti a lungo termine. L’articolo 5(1)(e) richiede la minimizzazione dei dati: i dati personali non devono essere conservati più a lungo del necessario. L’articolo 17 stabilisce il diritto alla cancellazione. Ma le leggi fiscali nazionali richiedono la conservazione delle fatture (che contengono dati personali) per sette-dieci anni.

La soluzione è l’eccezione di conservazione nell’articolo 17(3)(b) del GDPR: gli obblighi di cancellazione non si applicano quando il trattamento è necessario per il rispetto di un obbligo legale. La conservazione delle fatture ai sensi della GoBD, del codice fiscale francese o della legge IVA belga è qualificata.

L’implicazione pratica per la sovranità: è necessario essere in grado di dimostrare, per ogni documento conservato, che la conservazione è coperta da un obbligo legale specifico e che il periodo e l’ambito di conservazione non sono più ampi di quanto richiesto da quell’obbligo. Questo è un requisito di documentazione e traccia di audit, non solo di storage.

Come appare un’infrastruttura documentale sovrana

Un’infrastruttura documentale sovrana soddisfa questi criteri:

1. Gestita da un’entità costituita e operante esclusivamente in una giurisdizione con adeguata protezione dei dati (gli Stati membri dell’UE soddisfano questo requisito per i dati dell’UE)
2. Nessuna società madre, struttura di investimento o accordo contrattuale che crea esposizione a giurisdizioni non UE
3. Pacchetti di prove esportabili in formati aperti e verificabili (PDF/A-3, token di timestamp CMS, tracce di audit JSON)
4. Timestamp RFC 3161 da TSA elencate nell’EU Trusted List, non TSA gestite dal fornitore
5. Catene di hash verificabili con strumenti open source senza partecipazione del fornitore
6. Opzione self-hosted per le organizzazioni che richiedono il controllo completo dell’infrastruttura

Il punto 6 è particolarmente rilevante per gli enti governativi, le istituzioni finanziarie regolamentate e gli operatori di infrastrutture critiche, che possono avere requisiti che precludono l’uso di qualsiasi servizio hosted di terze parti indipendentemente dalla giurisdizione.

SealDoc e la sovranità dell’UE

SealDoc opera esclusivamente su infrastrutture basate nell’UE sotto la giurisdizione dell’UE. Non esiste un rapporto di società madre che crei esposizione a giurisdizioni straniere.

I pacchetti di prove prodotti da SealDoc sono verificabili indipendentemente: timestamp RFC 3161 da TSA dell’EU Trusted List, catene di hash verificabili con SHA-256 e tracce di audit esportate come JSON strutturato. La verifica non richiede chiamate API a SealDoc e non richiede un rapporto continuativo con SealDoc.

Per le organizzazioni che richiedono un deployment on-premises o su cloud privato, SealDoc supporta il deployment self-hosted sulla propria infrastruttura. Il formato delle prove è identico alla versione hosted, quindi migrare da hosted a self-hosted o viceversa non influisce sulla verificabilità dei pacchetti di prove emessi in precedenza.

Il principio di base è che la prova dovrebbe sopravvivere a qualsiasi particolare rapporto con un fornitore. Se SealDoc non esiste più nel 2038, ogni pacchetto di prove emesso oggi dovrebbe essere ancora verificabile da un revisore con un’implementazione SHA-256 e il certificato pubblico della TSA.