Local-first come posizione legale, non scelta tecnica
Costruire un'applicazione che non ha server cambia il proprio profilo ai sensi del GDPR in modo che pochi fornitori italiani comprendono. Si esce dalla qualifica di "responsabile del trattamento" e si entra in quella, più scarica, di "fornitore di software".
La differenza che cambia tutto
L'art. 28 del GDPR definisce il "responsabile del trattamento" (in inglese: processor) come il soggetto che tratta dati personali per conto del titolare. Da questa qualifica discende una cascata di obblighi contrattuali, organizzativi e assicurativi non triviali: nomina formale, contratto art. 28 articolato, registro delle attività, audit periodici, notifica del data breach, responsabilità solidale con il titolare verso gli interessati, e così via.
Le Linee Guida 07/2020 dell'EDPB ("Guidelines on the concepts of controller and processor in the GDPR") chiariscono al § 30 un punto che la pratica italiana ha sistematicamente sottovalutato: il mero fornitore di software che non accede ai dati e non processa i dati per conto del cliente non è un responsabile del trattamento. È un fornitore. Punto.
Perché la distinzione conta
Per un fornitore di software italiano la differenza fra "responsabile del trattamento" e "fornitore di software che non processa" si traduce in:
— Diminuzione drammatica del rischio assicurativo (la responsabilità solidale verso gli interessati scompare)
— Sparizione dell'obbligo di nomina art. 28 da parte del cliente (semplificazione contrattuale)
— Eliminazione della necessità di un DPO dedicato lato fornitore in quasi tutti i casi
— Riduzione drastica del perimetro di un eventuale data breach (il fornitore non detiene i dati, dunque non può notificare un breach che non ha)
Come si costruisce una posizione local-first credibile
Dichiarare "local-first" in marketing non basta. La posizione si difende solo se l'architettura è tecnicamente verificabile da un consulente del cliente in pochi minuti.
Primo requisito: nessun endpoint server gestito dal fornitore deve ricevere dati personali. Tutti i flussi di rete partono dal dispositivo del cliente e arrivano direttamente al destinatario istituzionale (es. Sistema TS, Alloggiati Web). Verificabile via DevTools del browser — pannello Network.
Secondo requisito: lo storage è esclusivamente client-side, in IndexedDB del browser, con cifratura at-rest derivata da PIN utente. Le credenziali sensibili (es. password Sistema TS) sono cifrate prima di essere persistite. Verificabile via DevTools — pannello Application/Storage.
Terzo requisito: nessun analytics o telemetria che inviti dati identificabili. Plausible o analytics aggregati cookie-less sì; Google Analytics o Mixpanel no.
Quarto requisito: il codice eseguito sul dispositivo è leggibile (non offuscato in modo aggressivo, source map disponibili in caso di richiesta). Questo permette un audit indipendente da parte di un consulente del cliente.
La trappola del cloud sync
La tentazione più grande, dopo aver costruito local-first, è introdurre "cloud sync" per il backup multi-device. È una tentazione razionale dal punto di vista del prodotto e una catastrofe dal punto di vista legale, perché ricolloca il fornitore in qualità di responsabile del trattamento per i dati che transitano nel sync.
La soluzione, se il sync è davvero necessario, è il pattern E2E encrypted blob: il dispositivo del cliente cifra l'intero database con una chiave derivata dalla passphrase del cliente, e carica il blob cifrato su uno storage object (Cloudflare R2, Backblaze B2, S3) operato dal fornitore. Il fornitore detiene il blob ma non può leggerlo. La chiave è solo sul dispositivo.
Questa configurazione mantiene la posizione di "fornitore di software": il blob cifrato non è "dato personale identificabile" ai sensi del GDPR per il fornitore, perché il fornitore non possiede la chiave. Per il cliente lo è — ma il cliente è il titolare comunque. Tutto in ordine.
Implicazioni contrattuali
Vedi il DPA pubblicato sul nostro sito: dichiara esplicitamente l'assenza del ruolo di responsabile del trattamento, fonda la posizione sull'architettura local-first, lascia tutti gli obblighi GDPR al cliente in qualità di titolare. Un cliente diligente lo accetta volentieri, perché il vantaggio in termini di velocità contrattuale e riduzione dei costi assicurativi è significativo.
Un cliente non sofisticato a volte chiede di nominare comunque il fornitore come responsabile "per sicurezza". Vanno educati: la nomina superflua introduce obblighi sproporzionati per entrambe le parti. È sciatteria contrattuale, non prudenza.