Come i team di marketing possono distribuire app create con l’IA senza esporre i dati degli iscritti

«Una persona di un team di marketing vuole creare un sito web. Non è un ingegnere e probabilmente ha poche competenze o conoscenze in materia di sicurezza, o non ne ha affatto», ha dichiarato il ricercatore di sicurezza Joel Margolis a Wired. Lo stesso articolo di Wired descrive come l’azienda di sicurezza RedAccess abbia trovato oltre 5.000 app realizzate con vibe coding praticamente prive di sicurezza o autenticazione; circa il 40% esponeva dati sensibili. Wired non ha potuto confermare che i dati personali o aziendali esaminati fossero autentici.

Le app create con l’IA per i team di marketing presentano una versione specifica di questo problema. Gli strumenti utili da creare (un generatore di segmenti, una dashboard campagne, un analizzatore A/B, una sincronizzazione dei pubblici) sono proprio quelli collegati alla lista degli iscritti e spesso anche all’account pubblicitario.

TL;DR

• Assegna a ogni chiave API della piattaforma email e token dell’account pubblicitario l’accesso minimo usato dallo strumento, conservandoli nel codice lato server. La Marketing API di Mailchimp non offre un tipo di chiave più limitato: un’attività Mailchimp di sola lettura riceve quindi un’esportazione limitata ai dati necessari anziché una chiave.
• La piattaforma email resta la fonte autorevole per lo stato d’iscrizione. Lo strumento non reiscrive mai chi si è disiscritto, inoltra le richieste di disiscrizione alla piattaforma e include un link di disiscrizione funzionante in ogni email di marketing che invia direttamente.
• Un caricamento con hash per un pubblico personalizzato contiene comunque dati personali: decidi cosa inviare alle piattaforme pubblicitarie e ai servizi IA prima di farlo, e fai arrivare ogni disiscrizione anche al pubblico pubblicitario.
• Il GDPR regola la conservazione e l’uso della lista (notifica delle violazioni, diritto incondizionato di opposizione al marketing); ePrivacy/PECR, CAN-SPAM o CASL regolano l’invio delle email, anche da uno strumento interno.

Gli errori di distribuzione che divulgano i dati degli iscritti o violano il consenso

Uno strumento di marketing creato con l’IA che gestisce male la lista lo fa solitamente in due modi: la lista esce all’esterno (tramite una chiave, un link pubblico o un caricamento), oppure viene usata per persone che hanno detto no. Un token pubblicitario con accesso di gestione aggiunge un rischio distinto: spese sull’account pubblicitario aziendale.

Lo strumento IA di programmazione che ha creato l’app può effettuare gran parte di queste correzioni su richiesta. Considera ogni prompt seguente un punto di partenza da adattare e conserva quelli utilizzati in un file di regole che lo strumento IA legge a ogni sessione. Il resoconto dell’IA che afferma di aver fatto una modifica non è una prova: lo è il passaggio Verifica: sotto ogni prompt. Chiedi di segnalare le incertezze anziché indovinare e non incollare mai una chiave attiva o un’esportazione degli iscritti nella chat.

Sostituisci la chiave della piattaforma email con accesso completo con quella più limitata

Un generatore di segmenti che mostra solo conteggi non richiede una chiave capace di esportare la lista o inviare una campagna, eppure la chiave più ampia di ogni piattaforma seguente può fare entrambe le cose. Conta anche la collocazione: il codice del browser richiede il valore della chiave per la chiamata, quindi chiunque carichi la pagina può leggerlo (Mailchimp non supporta affatto l’uso della sua API lato client).

Ogni riga segue la documentazione della piattaforma: la pagina di assistenza di Mailchimp sulle chiavi API, i permessi delle chiavi API di SendGrid, la guida all’autenticazione di Klaviyo e la documentazione delle chiavi API di Mailgun. I permessi di Listmonk sono trattati più avanti nella sezione dedicata.

Lo strumento riceve la chiave più limitata compatibile con la sua attività, oppure nessuna. Su Mailchimp, per un’attività di sola lettura (report o conteggio di segmenti) sono preferibili gli strumenti di report della piattaforma o un’esportazione limitata eseguita dal titolare dell’account con i soli campi necessari. Questo costa tempo a una persona e offre dati aggiornati solo al momento dell’esportazione; modifiche e invii passano all’IT o restano in Mailchimp. Su altre piattaforme, come ActiveCampaign o Brevo, cerca prima un’opzione di chiave limitata.

La chiave risiede quindi solo nel codice lato server (il backend dello strumento, che il browser non scarica mai), conservata come variabile d’ambiente: un valore fornito dal server all’app all’avvio, tenuto fuori dal codice e dal repository.

Trova tutte le chiavi API, i token d’accesso, le password e i segreti in questo progetto per la nostra piattaforma email (Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk o altre) e qualsiasi piattaforma pubblicitaria (Meta, Google Ads, LinkedIn o altre). Usa uno scanner locale di segreti o un metodo approvato dall’IT per controllare codice, file d’ambiente e cronologia del repository. Non inviare mai valori segreti non oscurati, contenuti dei file d’ambiente o cronologia con credenziali a un servizio IA esterno. Fornisci all’IA soltanto risultati oscurati con posizioni dei file e tipo di credenziale trovata. Per ciascuna, indicami:

- il file e la riga

- se il valore è scritto nel codice o letto da una variabile d’ambiente

- se il codice che lo usa gira sul server o nel browser

Mostra soltanto i primi quattro caratteri di qualsiasi valore. Non stampare mai una chiave o un token completi.

Segnala come massima priorità ogni credenziale capace di inviare email, modificare iscritti o gestire un account pubblicitario.

Sposta poi ogni chiamata che richiede una chiave API privata o un token d’accesso nel codice lato server, che legga le credenziali da una variabile d’ambiente riservata al server. Mantieni nel browser soltanto le chiamate API pubbliche lato client documentate, rimuovi dal codice le chiavi private esposte ed escludi dal repository i file con segreti reali. Riporta esattamente cosa hai modificato e indica dove avevi dubbi anziché indovinare.

Nota: Eliminare una chiave incollata dalla chat o dal codice non annulla la condivisione. Revocala (disattivala nelle impostazioni della piattaforma affinché smetta di funzionare) e creane una nuova.

Verifica: apri lo strumento, premi F12, seleziona la scheda Network e usalo come farà il team, leggendo il dominio di ogni richiesta. Una richiesta del browser diretta all’API privata di una piattaforma email è un segnale di allarme, ma la sola destinazione non prova l’esposizione di un segreto. Esamina header delle richieste e codice per individuare credenziali private, senza copiarne i valori in una chat IA. Le richieste degli SDK pubblici lato client sono diverse: possono legittimamente usare identificatori pubblici anziché chiavi API segrete. In Klaviyo, le richieste a a.klaviyo.com/client/ usano una chiave pubblica e appartengono al browser, mentre una richiesta del browser a a.klaviyo.com/api/ richiede indagini perché quell’endpoint normalmente richiede autenticazione con chiave privata. Conferma se sia stata effettivamente trasmessa una credenziale privata.

Il resto spetta a una persona: crea la chiave limitata da un account che non appartenga a un singolo individuo (Mailchimp rimuove le chiavi API di un utente quando ne viene revocato l’accesso), assegnale il nome dello strumento (Mailchimp consiglia una chiave per integrazione) e chiedi all’IT di aiutarti a conservarla dove vengono custodite le chiavi dello strumento. Per una rotazione pianificata, passa alla nuova chiave prima di revocare la vecchia, perché una chiave Mailchimp revocata non può essere riattivata. Se una chiave è già compromessa, revocala immediatamente e sostituiscila. Considera anche la scadenza: le chiavi API Mailchimp generate dal 22 giugno 2026 in poi scadono un anno dopo la creazione.

Concedi al token pubblicitario solo i permessi utilizzati dallo strumento

Considero il token dell’account pubblicitario la credenziale di maggiore impatto che uno strumento di marketing possa possedere, perché è legata alla spesa. Un token Meta con accesso di gestione può creare, modificare o sospendere campagne addebitate all’account pubblicitario aziendale, e leggere spese e prestazioni.

Ciò che un token del genere non restituisce è la lista degli iscritti caricata in un pubblico personalizzato. La guida di Meta ai Custom Audiences usa valori con hash SHA-256 (una trasformazione a senso unico di ogni indirizzo che la piattaforma confronta con i propri dati) per aggiungere e rimuovere persone, e nessun endpoint documentato restituisce una lista leggibile da un pubblico esistente.

La guida ai permessi di Meta descrive ciascun permesso e invita gli sviluppatori a selezionare solo quelli necessari all’app. Ogni strumento riceve un proprio token da un utente di sistema, il termine Meta per un account interno a Business Manager usato dal software, assegnato soltanto all’account pubblicitario su cui lavora lo strumento. Tieni il token d’accesso personale del creatore fuori dallo strumento e il token dell’utente di sistema sul server, come la chiave email; lo stesso inventario vale per gli accessi a Google Ads o LinkedIn.

Elenca tutte le chiamate dello strumento alla Marketing API di Meta, a Google Ads o ad altre piattaforme pubblicitarie, comprese quelle tramite librerie ausiliarie o SDK. Per ogni chiamata indica:

- il file e la riga

- l’endpoint o il metodo SDK

- un’etichetta: REPORT (legge metriche o spese), MANAGE (crea o modifica campagne, annunci, budget o pubblici) oppure LEADS (legge le risposte ai moduli per lead)

- il permesso richiesto da quell’etichetta sulla piattaforma

Segnala ogni token usato da più strumenti e il codice che invia un token al browser. Non stampare i valori dei token. Se non riesci a stabilire l’etichetta necessaria per una chiamata, dichiaralo.

Verifica: controlla il token della dashboard nello strumento di debug dei token di Meta, che ne riporta i permessi, e confrontali con le etichette del prompt. Il token di una dashboard di report dovrebbe mostrare ads_read e niente che gestisca l’account; un’etichetta MANAGE o LEADS su uno strumento di report è una criticità. Conferma poi nelle impostazioni aziendali che lo strumento usi il proprio token utente di sistema, non quello personale del creatore.

Chiudi l’indirizzo pubblico e mostra le righe degli iscritti solo agli amministratori della lista

Un’app sull’hosting dello strumento IA può essere aperta da chiunque ne trovi l’indirizzo. Alcune app esaminate da RedAccess avevano soltanto barriere banali, come richiedere ai visitatori di accedere con qualsiasi indirizzo email, riferisce Wired. Questo hosting è adatto a demo con indirizzi inventati, il compito per cui sono pensati hosting gratuiti e tunnel.

L’altra metà riguarda cosa vede ogni persona dopo l’accesso. Una dashboard campagne serve a mostrare numeri a livello di campagna: tassi di apertura e clic, risultati A/B e dimensioni dei segmenti. Le righe sottostanti degli iscritti, ogni indirizzo con dettagli del consenso e cronologia delle interazioni, sono dati personali.

I numeri aggregati correttamente anonimizzati in genere non sono dati personali, ma segmenti piccoli o suddivisioni dettagliate possono rendere ancora identificabili le persone. Anche numeri anonimi possono rivelare informazioni competitive aziendali, e un analizzatore A/B che conserva aperture e clic per persona detiene anch’esso dati personali. Il team vede aggregati; soltanto chi gestisce la lista vede le righe, e il server impone questo limite a ogni richiesta.

Elenca ogni campo in database, schermate, esportazioni e risposte API di questa app che contenga dati personali degli iscritti: indirizzo email, nome, telefono, indirizzo postale, indirizzo IP, posizione, stato d’iscrizione, fonte e momento del consenso, data d’iscrizione, stato di disiscrizione, aperture e clic per persona. Per ogni campo indica quali schermate ed esportazioni lo mostrano. Segnala ciò di cui non sei certo anziché indovinare.

Aggiungi poi due ruoli, ricavati dall’account autenticato e controllati sul server per ogni pagina, esportazione e percorso API:

- amministratore della lista: può vedere le righe degli iscritti ed eseguire esportazioni

- addetto marketing: vede soltanto numeri delle campagne, conteggi dei segmenti e risultati A/B, senza righe per persona né esportazioni

Rifiuta tutto il resto con una risposta «accesso negato» (403). Riporta quale controllo protegge ogni pagina e percorso.

Sapere se i dati memorizzati sono cifrati su disco spetta all’IT; lo strumento IA non può confermarlo leggendo il codice.

Verifica: crea un account di prova con il ruolo marketing. Accedi con quell’account e apri la dashboard campagne (si carica), poi la pagina degli iscritti e l’esportazione (entrambe si fermano con «accesso negato»). Quindi apri l’indirizzo dello strumento da un telefono su rete mobile senza autenticarti: non si carica nulla oppure compare la pagina d’accesso aziendale.

Lascia disiscrizioni e registrazioni del consenso alla piattaforma email

Uno strumento che conserva una propria copia della lista e la riscrive tramite sincronizzazione bidirezionale o reimportazione dell’esportazione del mese scorso può reiscrivere una persona disiscritta e perdere la registrazione di dove, quando e come ciascuno si è iscritto. Di solito non mostra segnali finché quella persona riceve la campagna successiva, quando si applicano le regole sull’invio riportate sotto. Quattro regole lo impediscono:

1. La piattaforma email è la fonte autorevole per lo stato d’iscrizione. Lo strumento legge quello stato e non reiscrive né sovrascrive mai un iscritto esistente. Può inoltrare una richiesta esplicita di disiscrizione attraverso l’apposito processo della piattaforma.
2. Nessuna importazione in blocco o sincronizzazione sostituisce i record esistenti degli iscritti o ne sovrascrive iscrizione e consenso. Uno strumento revisionato può aggiornare campi esplicitamente approvati, come i tag, senza modificare lo stato d’iscrizione. Le nuove iscrizioni passano dal modulo o dal percorso d’importazione della piattaforma, così si applica la sua gestione dell’opt-in; il modulo dello strumento, dopo revisione, può aggiungere nuovi iscritti con fonte, momento e modulo, ma non reiscrive mai un contatto esistente né ne sovrascrive le informazioni d’iscrizione o consenso.
3. Ogni invio o esportazione dello strumento legge lo stato dalla piattaforma in quel momento, non dalla propria copia. Le esportazioni escludono contatti disiscritti o bloccati, oppure li contrassegnano come lista da non utilizzare mai per l’invio.
4. I campi del consenso (fonte, momento, modulo o metodo) accompagnano intatti ogni record copiato, oppure lo strumento non li copia e non afferma di possederli.

Elenca ogni punto in cui questo strumento scrive nella piattaforma email o in una copia della lista: chiamate API che creano o aggiornano iscritti, importazioni, sincronizzazioni ed esportazioni di file. Per ciascuno indica se può:

- cambiare lo stato d’iscrizione di un iscritto esistente

- sovrascrivere record esistenti degli iscritti

- includere contatti disiscritti o bloccati

Per ogni percorso che invia email o esporta una lista per l’invio, indica da dove legge lo stato d’iscrizione: dalla piattaforma email in quel momento o dalla copia dello strumento.

Modifica poi lo strumento affinché non reiscriva mai un contatto esistente né ne sovrascriva lo stato, salvo inoltrare una richiesta esplicita di disiscrizione tramite il processo designato della piattaforma email; non sostituisca mai integralmente i record esistenti; legga lo stato dalla piattaforma immediatamente prima di ogni invio o esportazione; e conservi fonte, momento e modulo del consenso associati a ogni record copiato. Riporta le modifiche e segnala le incertezze.

Nota: Una vecchia esportazione reimportata sopra la lista porta con sé i vecchi stati: chi si è disiscritto dopo l’esportazione può tornare iscritto, a seconda di come piattaforma e strumento gestiscono l’importazione.

Verifica: aggiungi un iscritto di prova sulla piattaforma email, poi disiscrivilo lì. Esegui sincronizzazione, generatore di segmenti ed esportazione dello strumento. Sulla piattaforma resta disiscritto; nell’esportazione è assente o contrassegnato come da non contattare; non compare in alcuna lista d’invio creata dallo strumento.

Invia tramite la piattaforma email o crea prima il percorso di disiscrizione

Uno strumento di riattivazione che invia direttamente alla lista tramite account SMTP o API per email transazionali non ottiene ciò che la piattaforma aggiunge alle email di marketing (link di disiscrizione, indirizzo postale, controllo delle esclusioni), a meno che il suo codice aggiunga ogni elemento. La soluzione è lasciare l’invio alla piattaforma (o a Listmonk), mentre lo strumento costruisce il segmento o attiva la campagna della piattaforma. Uno strumento che deve inviare autonomamente è uno strumento d’invio, che la sezione successiva indirizza all’IT.

Uno strumento simile richiede in ogni messaggio di marketing un link di disiscrizione che continui a funzionare dopo l’invio, e identità e indirizzo postale del mittente nel piè di pagina, entro i termini della tabella sulle leggi d’invio seguente. Richiede anche una propria lista di esclusione, verificata prima di ogni invio e conservata come registrazione durevole, con backup e procedure di ripristino che impediscano a un vecchio database degli iscritti di sovrascrivere disiscrizioni più recenti. CAN-SPAM tratta diversamente i messaggi transazionali.

Per chi invia grandi volumi, un link nel piè di pagina potrebbe non bastare. Gmail richiede ai mittenti di almeno 5.000 messaggi al giorno verso account Gmail personali il supporto alla disiscrizione con un clic secondo RFC 8058 per messaggi di marketing e in abbonamento. Occorre aggiungere gli header List-Unsubscribe e List-Unsubscribe-Post, oltre al link visibile. L’endpoint con un clic deve elaborare una richiesta POST; aprire semplicemente l’URL con GET non deve disiscrivere nessuno. Chiedi all’IT di verificare questi requisiti prima di inviare a tale scala.

Aggiungi un link di disiscrizione a ogni messaggio di marketing inviato da questo strumento, con un endpoint di disiscrizione sottostante.
Se lo strumento è soggetto ai requisiti Gmail per i mittenti massivi, implementa anche gli header RFC 8058 per la disiscrizione con un clic, coperti da una firma DKIM valida, e un endpoint basato su POST. Non attivare mai una disiscrizione solo perché è stato aperto un URL. Segnala ogni incertezza per la revisione IT.
Quando l’endpoint riceve una richiesta valida di disiscrizione (clic su link, invio di un modulo o chiamata API):

- aggiungi subito l’indirizzo a una lista di esclusione conservata separatamente dalle tabelle degli iscritti

- registra il momento e il canale d’arrivo della richiesta

- se la piattaforma email contiene la lista, chiedile di disiscrivere anch’essa l’indirizzo

Controlla la lista di esclusione prima di ogni invio e salta ogni corrispondenza. Non rimuovere mai automaticamente un indirizzo da tale lista durante importazioni, sincronizzazioni o ripristini del database. Conserva solo le informazioni minime necessarie per rispettare la disiscrizione, secondo la politica di conservazione approvata dall’azienda, e non permettere mai a importazioni o sincronizzazioni di reinserire un indirizzo bloccato. Assicurati che i backup includano la lista di esclusione e che ripristinare le tabelle degli iscritti la lasci intatta. Aggiungi nome e indirizzo postale del nostro mittente al piè di pagina di ogni messaggio di marketing, con segnaposto che compilerò. Riporta le modifiche e quali invii coprono.

Verifica: aggiungi un indirizzo di prova sotto il tuo controllo a una lista di test, invia una campagna di prova tramite lo strumento e fai clic sul link di disiscrizione ricevuto. L’indirizzo ora compare nella lista di esclusione (e come disiscritto nella piattaforma email, se contiene la lista). Invia nuovamente alla stessa lista di test: l’indirizzo non riceve nulla.

Chi è responsabile della conformità email aziendale fornisce nome del mittente e indirizzo postale per quei segnaposto.

Decidi cosa esce verso piattaforme pubblicitarie e strumenti IA prima che esca

Due percorsi del codice inviano per impostazione predefinita i dati degli iscritti all’esterno: una sincronizzazione che carica un segmento in un pubblico personalizzato Meta o Google e chiamate che passano campi degli iscritti a un’API IA (per scrivere oggetti o valutare lead), a script di analisi o webhook.

Meta e Google possono abbinare pubblici di clienti usando identificatori di contatto con hash SHA-256. La Data Manager API di Google richiede normalizzazione e hashing di indirizzi email e numeri di telefono prima dell’invio, mentre alcuni caricamenti tramite interfaccia Google Ads possono eseguire l’hashing durante il caricamento. L’hashing permette alla piattaforma di abbinare un indirizzo a un profilo; non rende anonima la persona (vedi FAQ).

Per nuove integrazioni Google Customer Match, controlla quale API di caricamento è supportata prima di creare la sincronizzazione. Dal 1° aprile 2026, Google limita i vecchi metodi di caricamento Customer Match per i nuovi utilizzatori e indirizza queste integrazioni alla Data Manager API.

Le condizioni di Meta sui pubblici da liste clienti impongono all’inserzionista di garantire diritti, autorizzazioni e una base giuridica necessari per condividere i dati. Le norme Customer Match di Google richiedono che la condivisione sia dichiarata nell’informativa privacy, ottenendo il consenso quando la legge lo richiede.

Per semplicità, questo strumento considera ogni disiscrizione anche come richiesta di interrompere l’abbinamento pubblicitario. È una politica aziendale prudente, non l’affermazione che ogni disiscrizione email specifica di un canale richieda legalmente la rimozione da tutti i pubblici pubblicitari.

Il percorso di caricamento dovrebbe quindi prendere soltanto il segmento approvato dall’azienda per l’abbinamento pubblicitario; l’azienda deve stabilire una base giuridica appropriata con la guida del responsabile privacy o del responsabile della protezione dei dati (DPO), se nominato. Contatti disiscritti e bloccati restano fuori da ogni caricamento e una disiscrizione attiva la rimozione tramite hash da ciascun pubblico (la sezione GDPR seguente spiega perché).

Ogni servizio IA o di analisi che riceve dati degli iscritti deve essere approvato dall’azienda. Prima di condividere dati personali, conferma se il fornitore agisce come responsabile del trattamento o titolare autonomo e predisponi le appropriate garanzie contrattuali, compreso un accordo sul trattamento quando richiesto.

Controlla ogni chiamata in uscita di questo strumento: piattaforme email, piattaforme pubblicitarie (inclusi caricamenti dei pubblici), API IA (OpenAI, Anthropic o altre), strumenti di analisi e webhook. Per ciascuna elenca esattamente quali campi degli iscritti compaiono nel corpo della richiesta o nell’URL. Indica quali chiamate potrebbero funzionare con meno campi o senza dati degli iscritti. Concludi con l’elenco per nome di ogni servizio esterno, da confrontare con i fornitori approvati.

Verifica: ogni campo degli iscritti riportato per un servizio IA o di analisi dovrebbe essere necessario alla funzione e ogni servizio dovrebbe figurare nell’elenco aziendale approvato; quelli assenti passano a chi firma i contratti con i fornitori.

Per ogni percorso di questo strumento che carica contatti su Meta, Google Ads o altre piattaforme pubblicitarie:

- applica hash SHA-256 a indirizzi email e numeri di telefono sul server prima del caricamento, secondo le regole di normalizzazione di ciascuna piattaforma

- carica solo i contatti in [il segmento approvato dall’azienda per l’abbinamento pubblicitario]

- escludi i contatti disiscritti e bloccati al momento del caricamento

- quando un contatto si disiscrive, invia la rimozione del suo valore hash a ogni pubblico in cui era stato caricato

- registra ogni caricamento e rimozione con momento, pubblico, numero di contatti e utente o processo che li ha attivati

Riporta le modifiche e segnala le incertezze.

Verifica: disiscrivi un contatto di prova appartenente a un segmento caricato. Dopo la sincronizzazione successiva, controlla che sia stata inviata una richiesta di rimozione a ogni pubblico interessato. Verifica che ogni piattaforma pubblicitaria abbia elaborato correttamente la rimozione, non soltanto che lo strumento l’abbia registrata o inviata. Segnala rimozioni fallite o parziali per un nuovo tentativo e una revisione IT.

Ciò che lo strumento fa alla lista determina dove viene eseguito

Uno strumento che mostra solo numeri delle campagne gira su un server controllato dal team e accessibile solo da una rete privata; uno che mostra righe degli iscritti aggiunge l’accesso aziendale, perché i ruoli ne dipendono. Uno strumento che invia marketing email o sincronizza pubblici pubblicitari resta nelle funzionalità delle piattaforme oppure passa all’IT prima che qualcuno lo utilizzi.

L’approvazione segue le righe: le due righe di sola lettura richiedono che l’amministratore della piattaforma email emetta la chiave; quella che modifica la lista richiede un secondo revisore; quella d’invio richiede l’IT, oltre alla revisione privacy per i caricamenti dei pubblici.

Una rete privata significa che lo strumento non risponde affatto dall’esterno. Una pagina d’accesso scritta dall’IA è raggiungibile da chiunque ed è sicura solo quanto il codice sottostante: così RedAccess ha trovato app che accettavano qualsiasi indirizzo email all’accesso.

La mia regola: parti dalla rete privata e aggiungi l’accesso aziendale dove i ruoli lo richiedono. Funziona anche una piattaforma di distribuzione gestita con accesso e archiviazione dei segreti integrati, per un team che già la paga e controlla i propri fornitori.

Il lato server è da affidare all’assistenza IT, con un responsabile nominato per server e chiavi. Lo strumento gira su un VPS (un server a noleggio completamente controllato dal team) sotto uno strumento di distribuzione come Coolify o Dokploy, che esegue l’app dal codice e conserva le variabili d’ambiente, incluse le chiavi delle piattaforme.

La rete privata viene da Tailscale, più rapido da configurare ma dipendente dal proprio servizio di coordinamento (Headscale può sostituirlo), oppure da WireGuard, completamente autogestito. L’accesso aziendale (single sign-on con l’account aziendale) viene da Authentik o Keycloak, e un reverse proxy (Caddy o Nginx Proxy Manager) aggiunge HTTPS dove lo strumento si affaccia sul web.

Trasferire il motore email a Listmonk

Invece di limitare le chiavi della piattaforma attuale, l’altra strada elimina la chiave della piattaforma commerciale trasferendo lista e invio a un gestore di liste autogestito. Listmonk (v4.0.0 e successive) consente a ogni strumento un proprio utente API, con un ruolo limitato alle liste utilizzate.

Uno strumento di sola lettura ottiene accesso di visualizzazione alle proprie liste e nessun invio; campaigns:send e tx:send (messaggi transazionali) vanno solo a uno strumento d’invio. Tre permessi particolarmente rischiosi devono restare fuori dai ruoli degli strumenti limitati: lists:get_all e lists:manage_all, che scavalcano i ruoli per lista, e subscribers:sql_query, che secondo la documentazione su ruoli e permessi di Listmonk consente di «interrogare tutte le liste e tutti gli iscritti direttamente dal database, scavalcando i singoli permessi di lista e iscritto». Esamina anche permessi ampi come subscribers:get_all, campaigns:get_all e campaigns:manage_all prima di definire uno strumento limitato per lista. Assegna a ogni utente API solo i permessi necessari. Listmonk è progettato per campagne anziché automazioni a più fasi (quando Listmonk è lo strumento sbagliato); Mautic copre quell’automazione sullo stesso tipo di server.

Il compromesso è il lavoro continuativo: il team diventa responsabile dell’autenticazione del dominio d’invio (SPF, DKIM e DMARC), del relay SMTP per la consegna, degli aggiornamenti, dei backup e della recapitabilità. Se la lista è piccola, nessuno può gestire un server o la reputazione d’invio e le automazioni della piattaforma attuale svolgono lavoro essenziale per il team, restare sulla piattaforma con chiavi limitate è la scelta migliore.

Entrambe le strade richiedono un server con un responsabile, che esegua lo strumento di distribuzione e la rete privata e, per l’opzione autogestita, Listmonk con un relay SMTP. Il nostro Linux VPS offre accesso root, e Listmonk, Mautic, Tailscale, WireGuard e Authentik si distribuiscono come app con un clic. L’assistenza IT dedica così tempo a configurazione e revisione anziché all’installazione; mantenere tutto aggiornato resta al team.

Le sedi includono Francoforte e Amsterdam nell’UE, Londra nel Regno Unito e varie città statunitensi; la scelta determina dove risiedono lo strumento e ogni copia della lista (e con Listmonk la lista stessa). La sede è un elemento della conversazione con il DPO, non un sostituto, e da sola non rende conforme lo strumento.

Consenso e regole antispam per le email di marketing

GDPR per la lista degli iscritti

Il GDPR non richiede il consenso come base del trattamento per marketing diretto: il considerando 47 afferma che tale trattamento «può essere considerato effettuato per un legittimo interesse». Quando il marketing si basa invece sul consenso, l’articolo 7 richiede all’azienda di poter dimostrare che ogni persona abbia acconsentito e rende la revoca semplice quanto la concessione. È questo il compito di fonte, data e ora del consenso nella piattaforma email.

La regola più severa è nell’articolo 21 del GDPR. Qualunque sia la base, una persona può opporsi in ogni momento al marketing diretto, compresa la profilazione connessa; da quel momento «i dati personali non sono più oggetto di trattamento per tali finalità». Per il marketing non c’è un bilanciamento di interessi, diversamente da altre opposizioni nello stesso articolo. Per questo strumento, l’impostazione più sicura è applicare un’opposizione generale al marketing diretto a tutti gli usi di marketing dei dati della persona: lista d’invio, segmenti dello strumento e pubblici pubblicitari. Una disiscrizione specifica per canale può avere un ambito più ristretto: l’azienda dovrebbe definire le regole delle preferenze con il responsabile privacy e rispettare adeguatamente ogni richiesta.

Una lista divulgata o modificata erroneamente può costituire una violazione dei dati personali. L’articolo 33 richiede la notifica all’autorità di controllo (l’autorità nazionale per la protezione dei dati) senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla scoperta, salvo che sia improbabile che la violazione comporti un rischio per le persone. Nel Regno Unito l’equivalente è l’UK GDPR, applicato dall’ICO.

Le leggi sull’invio: ePrivacy e PECR, CAN-SPAM e CASL

Le regole ePrivacy dell’UE e le PECR britanniche richiedono consenso preventivo per marketing email a persone fisiche, con un limitato «soft opt-in» per clienti esistenti. Il Regno Unito ha anche un soft opt-in separato per finalità benefiche con condizioni specifiche; l’articolo si concentra sul marketing commerciale. La CASL canadese richiede consenso esplicito o implicito. La CAN-SPAM statunitense non richiede consenso all’invio, ma una disiscrizione funzionante rispettata entro 10 giorni lavorativi, oltre a dati del mittente corretti e un indirizzo postale in ogni messaggio.

Il soft opt-in nell’articolo 13 della direttiva ePrivacy riguarda recapiti ottenuti durante una vendita, usati per propri prodotti simili, con possibilità gratuita di rifiutare alla raccolta e in ogni messaggio. La versione britannica è la PECR Regulation 22, illustrata nelle linee guida ICO sul marketing email. L’articolo 13 vieta anche email di marketing che nascondano il mittente o siano prive di un indirizzo valido per le richieste di disiscrizione; la PECR Regulation 23 fa lo stesso nel Regno Unito.

Le cifre CAN-SPAM provengono dalla guida CAN-SPAM della FTC, che aggiunge che gli indirizzi disiscritti non possono essere venduti o trasferiti, salvo a un’azienda incaricata di aiutare a rispettare CAN-SPAM. Le regole CASL si trovano nella sezione 6 di CASL e nella sezione 11, le sanzioni nella panoramica CASL di ISED.

Domande frequenti

Il GDPR si applica a uno strumento newsletter che ho creato da solo?

La risposta dipende da dove opera l’azienda e dalle persone i cui dati sono contenuti nello strumento, non da come è stato creato. Secondo l’articolo 3, il GDPR si applica a un’azienda stabilita nell’UE e a una esterna che offre beni o servizi a persone nell’UE o ne monitora il comportamento in quel territorio. Stabilire se una specifica azienda rientri nell’ambito spetta al suo DPO.

Cosa succede se la nostra chiave API Klaviyo viene divulgata?

Chi possiede una chiave Full Access può modificare la lista; una Read-Only consente solo di visualizzarla. Crea una sostituzione con i soli ambiti usati dallo strumento (Klaviyo non può aggiungere un ambito a una chiave esistente in seguito, quindi sceglili ora), revoca immediatamente la chiave divulgata, passa alla nuova e controlla esportazioni o modifiche non autorizzate della lista. Se la lista potrebbe essere stata letta, trattala come una possibile violazione GDPR.

Una lista email con hash è ancora un insieme di dati personali?

Secondo il GDPR sì, quando è riconducibile a una persona. Il considerando 26 tratta i dati pseudonimizzati che «potrebbero essere attribuiti a una persona fisica mediante l’utilizzo di ulteriori informazioni» come informazioni su una persona identificabile. La mia interpretazione è che l’abbinamento pubblicitario funzioni proprio per questo: la piattaforma può calcolare lo stesso hash da un indirizzo che già possiede.

Le email di marketing B2B seguono le stesse regole?

Non ovunque. Secondo la FTC, CAN-SPAM non prevede eccezioni per le email tra aziende. La regola email delle PECR riguarda le persone fisiche, e l’ICO conferma che si possono inviare email di marketing alle aziende. Per i paesi UE e il Canada, consulta un legale.