Perché il CLOUD Act cambia la tua scelta di BaaS

I confronti BaaS sono generalmente organizzati attorno a quattro assi: prezzo per utilizzo, ricchezza funzionale, facilità di migrazione ed esperienza dello sviluppatore. La ricchezza funzionale copre funzioni di autenticazione, database, tempo reale, archiviazione ed edge. Questi sono criteri legittimi. Nessuno dei quattro risponde a una semplice domanda: chi può accedere legalmente ai tuoi dati e sotto quale autorità?

Il CLOUD Act — Clarifying Lawful Overseas Use of Data Act — è stato promulgato nel marzo 2018 negli Stati Uniti. Autorizza le autorità federali a obbligare qualsiasi fornitore legalmente presente sul suolo americano a produrre i dati in suo possesso, anche quelli archiviati all'estero (18 U.S.C. § 2713). Il testo risponde direttamente ad una controversia in cui Microsoft si rifiutò di trasmettere all'FBI i dati archiviati su un server a Dublino. Il Congresso ha deciso per legge anziché attendere la decisione della Corte Suprema, che poi ha investito del caso.

Questa domanda non appare in quasi nessuna griglia di confronto pubblica, compresi i siti di terze parti dedicati al BaaS. Il motivo è strutturale: un sito di confronto elenca le funzionalità che possono essere verificate: presenza di un SDK, quota gratuita, supporto GraphQL. La giurisdizione di un'azienda non è una funzionalità che può essere attivata in un pannello di amministrazione, quindi non rientra nel consueto formato della tabella. Ciò non lo rende meno decisivo.

I dettagli del testo, la sua articolazione con il GDPR e una lista di controllo completa per la verifica dei fornitori sono trattati nella nostra guida Conforme al GDPR e backend sovrano dell'UE. Questa sezione è limitata a ciò che effettivamente cambia in un confronto BaaS.

Controllare una regione ospitante europea in un pannello di amministrazione non è sufficiente per andare oltre l’ambito del CLOUD Act. La legge si applica alla società che gestisce il servizio, non all'ubicazione fisica del server, due informazioni che la pagina dei prezzi di un fornitore non distingue quasi mai.

Supabase, Inc. è l'entità identificata come titolare del trattamento dei dati nella propria politica sulla privacy, con siti ospitati principalmente dagli Stati Uniti. Firebase è un prodotto di Google LLC, una filiale di Alphabet Inc., una società costituita secondo la legge americana. AWS Amplify è contrattualmente collegato per impostazione predefinita a Amazon Web Services, Inc., con sede nello stato di Washington. Tutti e tre offrono una regione ospitante nell’UE. Le tre restano, in quanto ente aggiudicatore, società di diritto americano.

Questo non è un giudizio sulla loro qualità tecnica, ma un'osservazione sulla struttura giuridica dell'entità che firma il contratto con te. Un ottimo prodotto può rimanere legalmente esposto; le due valutazioni sono indipendenti l'una dall'altra.

Il CLOUD Act non merita lo stesso peso in tutti i progetti. Un MVP solitario, senza un utente europeo identificato e senza dati sanitari o sulle risorse umane, può ragionevolmente considerare questo criterio come secondario rispetto al prezzo e alla velocità di sviluppo.

Il passaggio avviene non appena appare un segnale: un DPO o un avvocato coinvolto nella decisione, dati sensibili ai sensi dell’articolo 9 del GDPR – salute, dati biometrici, opinioni. Si conferma con un cliente del settore pubblico, o con un appalto pubblico dell’UE che richiede un’esplicita garanzia di sovranità. A questo punto, il test legale dovrebbe essere controllato prima di confrontare i prezzi, non dopo aver già scelto un favorito tecnico.

Questo è il tipico punto di svolta per un CTO PMI-ETI che arbitra tra la creazione interna, Supabase Cloud, AWS Amplify e una soluzione sovrana. Il fattore scatenante non è la dimensione dell’azienda, ma la natura dei dati trattati e l’esistenza di un contatto che dovrà rispondere a un cliente o a un regolatore.

Concretamente, il criterio viene verificato in tre momenti distinti di un ciclo di acquisto BaaS. Prima della shortlist, funge da filtro binario per i progetti già identificati come sensibili. Durante la due diligence tecnica, viene verificata documento per documento, insieme al DPA e alla policy di sicurezza. Prima di firmare, diventa una clausola contrattuale, non solo una risposta orale da parte di un venditore dimostrativo.

Una clausola utile da negoziare in questa fase: il diritto di recedere senza penalità se cambia l'azionariato del fornitore. L'acquisizione da parte di un'azienda americana cambia la risposta alla questione giuridica, anche se il giorno successivo l'infrastruttura resta tecnicamente identica.

Ecco la griglia da aggiungere a un confronto BaaS esistente, ordinato per intensità di esposizione anziché in ordine alfabetico per fornitore.

Aggiungi questa griglia come un'altra colonna nel foglio di calcolo di confronto esistente, non come un documento separato. Deve rimanere visibile quando si decide tra due favoriti tecnicamente vicini.

Una prima verifica non richiede consulenza legale. Per individuare qualsiasi candidato fornitore sono sufficienti due documenti pubblici: la sua politica di riservatezza e le condizioni generali allegate al contratto.

1. Cerca "responsabile del trattamento dei dati" o "responsabile del trattamento dei dati" nell'informativa sulla privacy: si tratta dell'entità legale effettiva, non del nome del marchio visualizzato sul sito.
2. Individua la clausola sulla legge applicabile nelle condizioni generali: indica la giurisdizione in cui opera il contratto, e spesso l'entità.
3. Controlla se esiste un'entità UE separata per la tua regione (filiale irlandese, ad esempio) e se cambia la risposta alla domanda precedente o solo l'indirizzo di fatturazione.

Questo è il metodo utilizzato per verificare i fatti citati in questo articolo: Informativa sulla privacy di Supabase, Inc., Termini e condizioni AWS, Informativa sulla privacy di Google. Tre documenti pubblici, nessuno dei quali richiede un account commerciale per essere visualizzato.

Il criterio CLOUD Act non esonera dal valutare il resto del confronto. Il costo della migrazione, la maturità dell'ecosistema, la qualità reale dell'RLS e l'esperienza dello sviluppatore rimangono fattori determinanti per la velocità di un team. Un fornitore sovrano dell’UE con un SDK immaturo rimane una scelta sbagliata per molti progetti.

C’è anche un argomento temporale specifico nella scelta di un BaaS: quanto più profondamente un team integra un provider – schema, policy, Edge Functions, webhook –, tanto più costosa sarà una successiva migrazione. Un criterio giuridico scoperto dopo sei mesi di produzione viene gestito con urgenza e con rapporti di forza sfavorevoli. Lo stesso criterio valutato prima della firma costa solo il tempo necessario per leggere due documenti pubblici.