Se costruisci un portale clienti, un'app di prenotazione o un piccolo CRM per i tuoi clienti, la conformità al GDPR diventa presto una domanda concreta — anche senza un team legale o un avvocato interno. Questa guida spiega, in linguaggio semplice, cosa richiede realmente il GDPR a un'app di piccola impresa, cosa cambia quando costruisci con una piattaforma no-code o IA, e una checklist pratica che puoi seguire da solo. È una panoramica educativa, non una consulenza legale: per settori regolamentati (salute, finanza, dati di minori) o trattamenti su larga scala, parlane con un avvocato o con un responsabile della protezione dei dati prima di pubblicare.
Titolare vs responsabile del trattamento: la distinzione che chiarisce tutto
Il GDPR si basa su una distinzione semplice ma spesso fonte di confusione. Il titolare del trattamento decide perché e come vengono trattati i dati personali — di solito sei tu, come titolare dell'attività, quando raccogli nomi, email o prenotazioni dei tuoi clienti nella tua app. Un responsabile del trattamento tratta questi dati per conto del titolare e secondo le sue istruzioni — è il caso di ogni strumento che collegi: la tua piattaforma no-code/IA, il tuo hosting, il tuo database, il tuo strumento di email, il tuo fornitore di pagamenti. Questa distinzione conta per un motivo molto pratico: dice chi è responsabile di cosa, ed è per questo che dovresti aspettarti un accordo sul trattamento dei dati (DPA) da ogni responsabile che tocca i dati dei tuoi utenti. Se un fornitore non riesce a produrre un DPA su richiesta, trattalo come un segnale d'allarme.
- Titolare: tu, per i dati dei tuoi clienti finali raccolti tramite la tua app.
- Responsabile: la tua piattaforma, il tuo hosting, il tuo strumento di email, il tuo fornitore di pagamenti — chiunque tratti i dati solo su tue istruzioni.
- Sub-responsabile: i fornitori del tuo responsabile, ad esempio il cloud dietro il tuo fornitore di database.
Cosa richiede tipicamente il GDPR a una piccola app
Tolto il linguaggio giuridico, gli obblighi GDPR per una piccola app si riducono a una lista breve e pratica.
- Un'informativa sulla privacy in linguaggio semplice: cosa raccogli, perché, per quanto tempo, chi ha accesso, e come esercitare i propri diritti.
- Una base giuridica per ogni tipo di trattamento: esecuzione del contratto per onorare una prenotazione, consenso per email di marketing o cookie non essenziali, legittimo interesse per la sicurezza di base e la prevenzione delle frodi.
- Consenso dove è davvero richiesto: un'adesione esplicita per le comunicazioni di marketing e per ogni cookie o tracciatore non essenziale.
- Minimizzazione dei dati: raccogliere solo i campi realmente necessari per fornire il servizio — resistere al riflesso di aggiungere campi "per ogni evenienza".
- Sicurezza di base: connessioni cifrate (HTTPS), controllo di accesso ragionevole, password sottoposte a hashing, backup regolari.
- Diritti degli utenti: un modo per richiedere l'accesso, la rettifica o la cancellazione dei propri dati, e riceverli in un formato portabile.
- Consapevolezza sulle violazioni: in caso di incidente, potresti dover notificare la tua autorità di controllo e, in certi casi, gli utenti coinvolti.
Le domande extra che una piattaforma no-code o IA aggiunge
Costruire su una piattaforma no-code o IA non ti esonera dai tuoi obblighi come titolare — aggiunge un livello di domande sul tuo fornitore. Prima di affidare dati reali dei clienti a una piattaforma, chiediti quanto segue.
- Dove vivono fisicamente i dati — su quale infrastruttura, in quale regione?
- Chi è il responsabile per quei dati, e pubblica un elenco dei propri sub-responsabili?
- È disponibile un accordo sul trattamento dei dati (DPA), e copre realmente i dati che memorizzerai?
- Puoi esportare schema e dati, e cancellare tutto su richiesta, senza dipendere dal supporto del fornitore?
- L'IA serve solo a scrivere il codice della tua app, o vede e conserva anche i dati di produzione dei tuoi utenti finali?
- La piattaforma si pone come intermediario opaco per i dati personali dei tuoi clienti, o tu detieni le chiavi del database vero e proprio?
Scegliere una regione e ottenere un DPA
Due domande determinano gran parte della tua esposizione al rischio: dove sono archiviati i dati, e puoi ottenere un DPA firmato per essi. La maggior parte dei fornitori seri di backend-as-a-service — Supabase tra questi — pubblica un DPA standard che puoi accettare direttamente, e ti lascia scegliere la regione di hosting per il tuo progetto di database, incluse regioni nell'UE. Questo conta perché metti la scelta della giurisdizione nelle tue mani invece di lasciarla al default di una piattaforma. Vale la pena verificarlo per ogni responsabile del tuo stack — database, strumento di email, fornitore di pagamenti, strumento di analytics — non solo per il tuo builder di app.
Cookie e tracciatori sull'app o sul sito che generi
Le regole sui cookie sono più semplici di quanto si pensi, una volta separate le due categorie. I cookie strettamente necessari — quelli che mantengono un utente collegato o ricordano un carrello — non richiedono consenso. Tutto il resto, come analytics, pubblicità o pixel dei social, generalmente lo richiede, tramite un'adesione chiara prima che il cookie venga impostato. L'approccio più semplice per una piccola app: partire solo con cookie strettamente necessari, e aggiungere un banner di consenso solo quando aggiungi realmente uno strumento di analytics o pubblicità che ne ha bisogno.
Una checklist senza avvocato per i tipi di app più comuni
Sito vetrina o portfolio: una pagina di informativa sulla privacy nel footer, un modulo di contatto che indichi cosa succede ai dati inviati e per quanto tempo, e un banner cookie solo se aggiungi analytics o pubblicità.
App di prenotazione o appuntamenti: una base giuridica che combina l'esecuzione del contratto per la prenotazione stessa e il consenso per i promemoria di marketing, raccogliendo solo ciò che serve per completare la prenotazione (nome, contatto, data), e elencando i tuoi responsabili — sincronizzazione calendario, pagamento, fornitore SMS o email — nella tua informativa sulla privacy.
Portale clienti o piccolo CRM: un DPA in vigore con ogni responsabile che tocca i dati dei clienti, un accesso basato sui ruoli affinché ciascun membro del team veda solo ciò di cui ha bisogno, un modo documentato per esportare o cancellare definitivamente il record di un cliente, e un periodo di conservazione che applichi davvero invece di conservare tutto per sempre.
Dove si posiziona Cadrant: mantieni tu le chiavi
Cadrant è costruito attorno a un'architettura "porta il tuo Supabase": quando costruisci un'app, collegate la tua organizzazione Supabase invece di un database che Cadrant ospiterebbe e controllerebbe per te. Questo ha conseguenze GDPR dirette. Scegli tu il tuo progetto Supabase e la sua regione di hosting. Supabase, come responsabile del trattamento del tuo database, pubblica il proprio DPA che accetti direttamente con loro. Rimani il titolare dei dati dei tuoi utenti finali — le persone che prenotano, si registrano o inviano moduli tramite la tua app — e mantieni sempre la piena capacità di consultare, esportare o cancellare quei dati dalla tua dashboard Supabase, indipendentemente da Cadrant. Questo è deliberatamente diverso dalle piattaforme in cui i dati dei tuoi clienti risiedono in un database opaco, condiviso e di proprietà del fornitore, che non puoi interrogare né esportare.
Per essere trasparenti sulla nostra configurazione: Cadrant è pubblicato da Convergence Lab, un'azienda francese, e la piattaforma stessa — non i database che collegate — è ospitata su infrastruttura AWS che non è esclusivamente nell'UE; ci basiamo su garanzie adeguate per qualsiasi trasferimento fuori dall'UE, e il nostro responsabile della protezione dei dati è raggiungibile a dpo@cadrant.ai per domande sulla piattaforma stessa. Oggi non rivendichiamo certificazioni SOC 2 o ISO 27001, e dovresti guardare con sano scetticismo a una simile affermazione da parte di qualsiasi fornitore finché non hai visto il certificato.
Come Cadrant ti aiuta a restare conforme, concretamente
Puoi chiedere in linguaggio naturale gli elementi che supportano la conformità: una pagina di informativa sulla privacy, un banner di consenso ai cookie, un modulo di contatto che spiega cosa viene fatto con i dati inviati, o una pagina di impostazioni account dove i tuoi utenti finali possono richiedere i propri dati o la cancellazione. Poiché il tuo database vive nel tuo progetto Supabase, onorare una richiesta di cancellazione o esportazione è un'azione reale e verificabile — non un ticket inviato a terzi. La conformità non è mai del tutto automatica, ma partire da un'architettura in cui detieni i dati rende ogni passo successivo molto più semplice.