“Iemand uit een marketingteam wil een website maken. Die persoon is geen engineer en heeft waarschijnlijk weinig tot geen achtergrond of kennis op beveiligingsgebied”, vertelde beveiligingsonderzoeker Joel Margolis aan Wired. Datzelfde Wired-bericht beschrijft hoe beveiligingsbedrijf RedAccess meer dan 5.000 met vibe coding gemaakte apps vond met vrijwel geen beveiliging of authenticatie; ongeveer 40 procent daarvan stelde gevoelige gegevens bloot. Wired kon niet bevestigen dat de onderzochte persoonlijke of bedrijfsgegevens echt waren.
AI-apps voor marketingteams kennen een specifieke variant van dat probleem. Juist de nuttige tools (een segmentbouwer, campagnedashboard, A/B-analysetool of doelgroepsynchronisatie) zijn verbonden met de abonneelijst en vaak ook met het advertentieaccount.
TL;DR
- Geef elke API-sleutel van het e-mailplatform en elk advertentieaccounttoken uitsluitend de kleinste toegang die de tool gebruikt en bewaar ze in servercode. Mailchimps Marketing API heeft geen beperkter sleuteltype; een alleen-lezen-taak voor Mailchimp krijgt daarom een beperkte export met alleen noodzakelijke gegevens in plaats van een sleutel.
- Het e-mailplatform blijft de gezaghebbende bron voor de abonnementsstatus. De tool meldt afgemelde mensen nooit opnieuw aan, stuurt afmeldverzoeken door naar het platform en neemt een werkende afmeldlink op in iedere marketingmail die hij zelf verzendt.
- Een gehashte upload voor een aangepaste doelgroep bevat nog steeds persoonsgegevens: bepaal vooraf wat naar advertentieplatforms en AI-diensten gaat en zorg dat iedere afmelding ook de advertentiedoelgroep bereikt.
- De AVG regelt het bewaren en gebruiken van de lijst (datalekmeldingen, een onvoorwaardelijk recht van bezwaar tegen marketing); ePrivacy/PECR, CAN-SPAM of CASL regelen de verzending van de e-mail, ook vanuit een interne tool.
Uitrolfouten die abonneegegevens lekken of toestemming schenden
Een AI-marketingtool die verkeerd omgaat met de lijst doet dat doorgaans op twee manieren: de lijst komt naar buiten (via een sleutel, openbare link of upload), of wordt gebruikt voor mensen die nee zeiden. Een advertentietoken met beheerrechten voegt een apart risico toe: uitgaven op het advertentieaccount van het bedrijf.
| Fout | Wat wordt blootgesteld of geschonden | Welke regels of gevolgen spelen |
|---|---|---|
| Een e-mailplatformsleutel met volledige toegang in de code, browser of chat van de AI-tool | De hele lijst leesbaar en exporteerbaar; abonnees wijzigbaar; campagnes verzendbaar namens het bedrijf | Een inbreuk op persoonsgegevens waar de AVG geldt (melding volgens artikel 33); verzendwetten als er e-mail uitgaat |
| Een advertentieaccounttoken met beheerrechten of het eigen token van de bouwer | Campagnes gemaakt of gewijzigd op de advertentierekening van het bedrijf; uitgavengegevens; doelgroepdeelname via hash; leadformuliergegevens met leads_retrieval. Niet de geüploade lijst | De voorwaarden van het advertentieplatform en de advertentierekening van het bedrijf; een datalek als leadformuliergegevens worden gelezen |
| De tool op een openbare link, waarbij iedereen alles ziet | Abonneerijen, toestemmingsdetails en interactiegeschiedenis toegankelijk voor iedereen met het adres; campagne- en A/B-testresultaten zichtbaar voor buitenstaanders en medewerkers zonder noodzaak | Een datalek voor de rijen; verlies van vertrouwelijkheid voor de campagnecijfers |
| Een synchronisatie of herimport die terugschrijft naar de lijst | Afgemelde contacten opnieuw aangemeld; waar, wanneer en hoe mensen zich aanmeldden verloren | Het AVG-recht van bezwaar en de afmeldregels van CAN-SPAM en CASL bij de volgende verzending; onbewijsbare toestemming als toestemming de grondslag is |
| De tool verzendt zelf marketingmail | Geen afmeldlink, geen postadres van de afzender, geen controle van de uitsluitingslijst | Berichtregels van CAN-SPAM en CASL; toestemming voor verzending volgens ePrivacy/PECR |
| Doelgroepuploads en AI-aanroepen sturen de lijst standaard naar buiten | Gehashte lijsten bij Meta of Google; abonneevelden bij AI- en analysediensten die niemand heeft goedgekeurd | AVG (gehashte gegevens blijven persoonsgegevens; bezwaar bereikt ook de doelgroep); klantenlijstvoorwaarden van Meta en Google |
De AI-codeertool waarmee de app is gebouwd kan de meeste correcties uitvoeren als je daarom vraagt. Gebruik elke onderstaande prompt als aanpasbaar uitgangspunt en bewaar gebruikte prompts in een regelbestand dat de AI-tool iedere sessie leest. De mededeling van de AI-tool dat iets is gewijzigd is geen bewijs; de stap Controleer: onder iedere prompt is dat wel. Vraag onzekerheden te markeren in plaats van te gokken en plak nooit een actieve sleutel of abonnee-export in de chat.
Vervang de e-mailplatformsleutel met volledige toegang door de beperktste
Een segmentbouwer die alleen aantallen toont heeft geen sleutel nodig die de lijst kan exporteren of een campagne kan versturen, terwijl de breedste sleutel van elk onderstaande platform beide kan. Ook de plaats is belangrijk: browsercode heeft de sleutelwaarde zelf nodig voor de aanroep, zodat iedereen die de pagina laadt deze kan lezen (Mailchimp ondersteunt gebruik van zijn API aan de clientzijde helemaal niet).
| Platform | Wat de standaardsleutel kan | Beperktste gedocumenteerde optie |
|---|---|---|
| Mailchimp (Marketing API) | “API-sleutels geven volledige toegang tot je Mailchimp-account” | Geen op de hulppagina |
| SendGrid | Full Access: de meeste account-API-eindpunten, behalve facturering en Email Address Validation | Custom Access: gekozen eindpunten op gekozen niveaus, nooit boven de eigen rechten van de maker |
| Klaviyo | Privésleutel met Full Access: alles op zijn eindpunten maken, verwijderen of wijzigen | Read-Only-sleutel of Custom-sleutel met gekozen scopes |
| Mailgun | Account-API-sleutels: volledige accounttoegang | Domain Sending Key (één domein, alleen verzenden); een alleen-lezen-Analyst-rol bij sommige abonnementen |
| Listmonk (v4.0.0 en nieuwer) | Wat de gebruikersrol en lijstrollen toestaan | Bekijk- of beheerrollen per lijst, met apart verleende verzendrechten |
Elke rij volgt de documentatie van het platform zelf: Mailchimps hulppagina over API-sleutels, SendGrids API-sleutelrechten, Klaviyo’s authenticatiehandleiding en Mailguns documentatie over API-sleutels. Listmonks rechten staan verderop in het Listmonk-gedeelte.
De tool krijgt de beperktste sleutel die zijn taak toelaat, of geen sleutel. Voor een alleen-lezen-taak in Mailchimp (een rapport of segmenttelling) zijn de eigen rapportagetools van het platform of een beperkte export door de accounteigenaar geschikter, met uitsluitend de benodigde velden. Dat kost iemand tijd en de gegevens zijn slechts zo actueel als die export; wijzigings- en verzendtaken gaan naar IT of blijven in Mailchimp. Zoek bij andere platforms, zoals ActiveCampaign of Brevo, eerst naar een beperkte sleuteloptie.
De sleutel staat vervolgens uitsluitend in servercode (de eigen backend van de tool, die de browser nooit downloadt), opgeslagen als omgevingsvariabele: een waarde die de server bij het starten aan de app geeft en die buiten de code en repository blijft.
Zoek elke API-sleutel, toegangstoken, elk wachtwoord of geheim in dit project voor ons e-mailplatform (Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk of een ander) en elk advertentieplatform (Meta, Google Ads, LinkedIn of een ander). Controleer code, omgevingsbestanden en repositorygeschiedenis met een lokale geheimenscanner of een door IT goedgekeurde methode. Stuur nooit ruwe geheime waarden, inhoud van omgevingsbestanden of geschiedenis met inloggegevens naar een externe AI-dienst. Geef de AI alleen bevindingen met afgeschermde waarden, inclusief bestandslocaties en het type gevonden inloggegevens. Vertel per vondst:
- het bestand en de regel
- of de waarde in de code staat of uit een omgevingsvariabele wordt gelezen
- of de code die de waarde gebruikt op de server of in de browser draait
Toon van iedere waarde alleen de eerste vier tekens. Geef nooit een volledige sleutel of token weer.
Markeer inloggegevens die e-mail kunnen verzenden, abonnees kunnen wijzigen of een advertentieaccount kunnen beheren als hoogste prioriteit.
Verplaats daarna iedere aanroep die een private API-sleutel of toegangstoken vereist naar servercode die zijn inloggegevens uit een uitsluitend serverzijdige omgevingsvariabele leest. Laat alleen gedocumenteerde openbare client-API-aanroepen in de browser staan, verwijder blootgestelde privésleutels uit de code en sluit bestanden met echte geheimen uit van de repository. Rapporteer precies wat je hebt gewijzigd en benoem onzekerheden in plaats van te gokken.
Opmerking: Een geplakte sleutel uit chat of code verwijderen maakt het delen niet ongedaan. Trek hem in (schakel hem uit in de platforminstellingen zodat hij niet meer werkt) en maak een nieuwe.
Controleer: open de tool, druk op F12, selecteer het tabblad Network en gebruik de tool zoals het team dat gaat doen; lees het domein van iedere aanvraag. Een browseraanvraag rechtstreeks naar de private API van een e-mailplatform is een waarschuwingssignaal, maar de bestemming alleen bewijst niet dat een geheim is blootgesteld. Controleer aanvraagheaders en code op private inloggegevens zonder de waarden naar een AI-chat te kopiëren. Openbare client-SDK-aanvragen zijn anders: ze kunnen terecht openbare identificatoren gebruiken in plaats van geheime API-sleutels. Bij Klaviyo gebruiken aanvragen naar a.klaviyo.com/client/ een openbare sleutel en horen ze in de browser; een browseraanvraag naar a.klaviyo.com/api/ vereist onderzoek, omdat dat eindpunt normaal authenticatie met een privésleutel vereist. Bevestig of daadwerkelijk private inloggegevens zijn verzonden.
De rest doet een mens: maak de beperkte sleutel vanuit een account dat niet van één persoon is (Mailchimp verwijdert de API-sleutels van een gebruiker als diens toegang wordt ingetrokken), vernoem hem naar de tool (Mailchimp adviseert één sleutel per integratie) en laat IT helpen hem op de bestemde plaats te bewaren. Schakel bij geplande rotatie de tool op de nieuwe sleutel over voordat je de oude intrekt, want een ingetrokken Mailchimp-sleutel kan niet worden heractiveerd. Is een sleutel al gecompromitteerd, trek hem dan onmiddellijk in en vervang hem. Houd ook rekening met verval: Mailchimp-API-sleutels die op of na 22 juni 2026 zijn gegenereerd verlopen één jaar na aanmaak.
Geef het advertentieaccounttoken alleen de rechten die de tool gebruikt
Ik beschouw het advertentieaccounttoken als het toegangsmiddel met de grootste impact dat een marketingtool kan bezitten, omdat het gekoppeld is aan uitgaven. Een Meta-token met beheerrechten kan campagnes maken, wijzigen of pauzeren die op het advertentieaccount van het bedrijf worden gefactureerd, en uitgaven en prestaties lezen.
Wat zo’n token niet teruggeeft is de abonneelijst die naar een aangepaste doelgroep is geüpload. Meta’s handleiding voor Custom Audiences gebruikt SHA-256-gehashte waarden (een eenrichtingsbewerking van elk adres die het platform vergelijkt met zijn eigen gegevens) om mensen toe te voegen en te verwijderen, en geen gedocumenteerd eindpunt retourneert een leesbare lijst uit een bestaande doelgroep.
| Wat de tool doet | Benodigd Meta-recht | Wat een gelekt token kan bereiken |
|---|---|---|
| Rapporteert over campagnes | ads_read | Ads Insights-rapportagegegevens voor de advertentieaccounts die het kan zien |
| Maakt of wijzigt campagnes | ads_management | Campagnes en advertenties op dat account, op diens rekening; uitgaven en meetgegevens |
| Synchroniseert een segment met een aangepaste doelgroep | Beheertoegang tot het advertentieaccount | Mensen toevoegen en verwijderen via hash; geen leesbare lijst |
| Haalt inzendingen van leadadvertenties op naar de lijst | leads_retrieval (Meta noemt ads_management als een afhankelijkheid) | Elk veld dat mensen op de leadformulieren van het bedrijf invulden, leesbaar, boven op de beheertoegang |
Meta’s rechtenreferentie beschrijft ieder recht en vraagt ontwikkelaars alleen te kiezen wat een app nodig heeft. Iedere tool krijgt zijn eigen token van een systeemgebruiker, Meta’s term voor een account binnen Business Manager dat door software wordt gebruikt, uitsluitend toegewezen aan het advertentieaccount waarop de tool werkt. Houd het persoonlijke inlogtoken van de bouwer buiten de tool en het systeemgebruikerstoken op de server, net als de e-mailsleutel; dezelfde inventarisatie geldt voor toegang tot Google Ads of LinkedIn.
Noem iedere aanroep die deze tool doet naar Meta’s Marketing API, Google Ads of een ander advertentieplatform, ook via hulplibraries of SDK’s. Geef per aanroep:
- het bestand en de regel
- het eindpunt of de SDK-methode
- een label: REPORT (leest meetgegevens of uitgaven), MANAGE (maakt of wijzigt campagnes, advertenties, budgetten of doelgroepen) of LEADS (leest leadformulierinzendingen)
- het platformrecht dat dit label nodig heeft
Markeer ieder token dat meerdere tools gebruiken en alle code die een token naar de browser stuurt. Geef geen tokenwaarden weer. Als je niet kunt bepalen welk label een aanroep nodig heeft, zeg dat dan.
Controleer: controleer het dashboardtoken in Meta’s tokendebugger, die de rechten van het token toont, en vergelijk die met de labels van de prompt. Het token van een rapportagedashboard hoort ads_read te tonen en niets waarmee het account wordt beheerd; een MANAGE- of LEADS-label op een rapportagetool is een bevinding. Bevestig daarna in de bedrijfsinstellingen dat de tool zijn systeemgebruikerstoken gebruikt en niet het persoonlijke token van de bouwer.
Sluit het openbare adres af en toon abonneerijen alleen aan lijstbeheerders
Iedereen die het adres vindt kan een app openen op de hosting van de AI-tool zelf. Sommige door RedAccess onderzochte apps hadden slechts triviale drempels, zoals dat een bezoeker zich met een willekeurig e-mailadres moest aanmelden, meldt Wired. Dat soort hosting past bij een demo met verzonnen adressen, het doel waarvoor gratis hosting en tunnels zijn gemaakt.
De andere helft is wat iedereen na binnenkomst ziet. Een campagnedashboard dient voor cijfers op campagneniveau: openingspercentages, klikpercentages, A/B-resultaten en segmentgroottes. De achterliggende abonneerijen, ieder adres met toestemmingsdetails en interactiegeschiedenis, zijn persoonsgegevens.
Goed geanonimiseerde totalen zijn doorgaans geen persoonsgegevens, maar kleine segmenten of gedetailleerde uitsplitsingen kunnen mensen nog steeds identificeerbaar maken. Zelfs anonieme cijfers kunnen concurrentiegevoelige bedrijfsinformatie onthullen, en een A/B-analysetool die openingen en klikken per persoon bewaart bevat ook persoonsgegevens. Het team ziet totalen; alleen lijstbeheerders zien rijen en de server handhaaft dit bij iedere aanvraag.
Noem ieder veld in de database, schermen, exports en API-antwoorden van deze app dat persoonsgegevens van abonnees bevat: e-mailadres, naam, telefoon, postadres, IP-adres, locatie, abonnementsstatus, toestemmingsbron en -tijdstip, aanmelddatum, afmeldstatus en openingen en klikken per persoon. Geef per veld aan welke schermen en exports het tonen. Markeer onzekerheden in plaats van te gokken.
Voeg daarna twee rollen toe, afkomstig van het aangemelde account en op de server gecontroleerd voor iedere pagina, export en API-route:
- lijstbeheerder: kan abonneerijen zien en exports uitvoeren
- marketeer: ziet alleen campagnecijfers, segmentaantallen en A/B-resultaten, zonder rijen per persoon en zonder exports
Weiger al het andere met een antwoord “toegang geweigerd” (403). Rapporteer welke controle iedere pagina en route beschermt.
Of opgeslagen gegevens op schijf versleuteld zijn is een vraag voor IT; de AI-tool kan dat niet bevestigen door de code te lezen.
Controleer: maak een testaccount met de marketeerrol. Open aangemeld als dat account het campagnedashboard (het laadt), daarna de abonneelijstpagina en de export (beide stoppen bij “toegang geweigerd”). Open vervolgens afgemeld het tooladres vanaf een telefoon met mobiele data: niets laadt of het stopt op de aanmeldpagina van het bedrijf.
Laat afmeldingen en toestemmingsregistraties aan het e-mailplatform over

Een tool die een eigen kopie van de lijst bijhoudt en terugstuurt via tweerichtingssynchronisatie of herimport van de export van vorige maand kan iemand die is afgemeld opnieuw als aangemeld markeren en de registratie verliezen van waar, wanneer en hoe iedereen zich aanmeldde. Meestal laat de tool niets merken tot die persoon de volgende campagne krijgt, wanneer onderstaande verzendregels gelden. Vier regels voorkomen dit:
- Het e-mailplatform is de gezaghebbende bron voor de abonnementsstatus. De tool leest die status en meldt een bestaande abonnee nooit opnieuw aan of overschrijft die niet. Hij mag een uitdrukkelijk afmeldverzoek via het daarvoor bestemde afmeldproces van het platform doorgeven.
- Geen bulkimport of synchronisatie vervangt bestaande abonneeregistraties of overschrijft hun abonnements- en toestemmingsgegevens. Een beoordeelde tool mag uitdrukkelijk goedgekeurde velden zoals tags bijwerken zonder de abonnementsstatus te wijzigen. Nieuwe aanmeldingen komen via het eigen aanmeldformulier of importpad van het platform binnen zodat diens opt-in-afhandeling geldt; het eigen aanmeldformulier van de tool mag na beoordeling nieuwe abonnees met bron, tijdstip en formulier toevoegen, maar meldt nooit een bestaand contact opnieuw aan en overschrijft nooit diens abonnements- of toestemmingsgegevens.
- Alles wat de tool verzendt of exporteert leest op dat moment de status van het platform, niet uit zijn eigen kopie. Exports laten afgemelde en uitgesloten contacten weg of markeren ze als een niet-verzenden-lijst die nooit voor verzending wordt gebruikt.
- Toestemmingsvelden (bron, tijdstip, formulier of methode) blijven intact bij iedere gekopieerde registratie, of de tool kopieert ze niet en beweert ook niet ze te hebben.
Noem iedere plek waar deze tool schrijft naar het e-mailplatform of een kopie van de abonneelijst: API-aanroepen die abonnees maken of bijwerken, imports, synchronisaties en bestandsexports. Geef per plek aan of die:
- de abonnementsstatus van een bestaande abonnee kan wijzigen
- bestaande abonneeregistraties kan overschrijven
- afgemelde of uitgesloten contacten kan bevatten
Geef voor ieder pad dat e-mail verzendt of een verzendlijst exporteert aan waar het de abonnementsstatus leest: op dat moment van het e-mailplatform of uit de eigen kopie van de tool.
Wijzig de tool vervolgens zodat hij een bestaand contact nooit opnieuw aanmeldt of diens abonnementsstatus overschrijft, behalve om een uitdrukkelijk afmeldverzoek via het daarvoor bestemde platformproces door te geven; bestaande abonneeregistraties nooit integraal vervangt; vlak vóór iedere verzending of export de status van het e-mailplatform leest; en toestemmingsbron, tijdstip en formulier bij iedere gekopieerde registratie houdt. Rapporteer wijzigingen en markeer onzekerheden.
Opmerking: Een oude export die opnieuw over de lijst wordt geïmporteerd brengt zijn oude statussen mee. Daardoor kan iemand die zich na die export afmeldde weer als aangemeld terugkomen, afhankelijk van hoe het platform en de tool de import behandelen.
Controleer: voeg een testabonnee toe op het e-mailplatform en meld die daar af. Voer de synchronisatie, segmentbouwer en export van de tool uit. Op het platform is de testabonnee nog afgemeld; in de export ontbreekt die of is die gemarkeerd als niet-verzenden; in iedere verzendlijst van de tool ontbreekt die.
Verzend via het e-mailplatform of bouw eerst het afmeldpad
Een heractiveringstool die de lijst rechtstreeks mailt via een SMTP-account of transactionele e-mail-API krijgt de toevoegingen van het e-mailplatform voor marketingmail (afmeldlink, postadres, uitsluitingscontrole) alleen als de toolcode ze allemaal zelf toevoegt. De oplossing is het platform (of Listmonk) te laten verzenden, terwijl de tool het segment bouwt of de platformcampagne activeert. Een tool die zelf moet verzenden is een verzendtool, die het volgende gedeelte naar IT verwijst.
Zo’n tool heeft in iedere marketingmail een afmeldlink nodig die na verzending blijft werken, en de identiteit en het postadres van de afzender in de footer, volgens de termijnen in de onderstaande tabel met verzendwetten. Ook heeft hij een eigen uitsluitingslijst nodig, gecontroleerd vóór iedere verzending en bewaard als duurzaam uitsluitingsregister, met back-ups en herstelprocedures die voorkomen dat een oudere abonneedatabase nieuwere afmeldingen overschrijft. CAN-SPAM behandelt transactionele berichten anders.
Voor verzenders met grote volumes is een link in de e-mailfooter mogelijk onvoldoende. Gmail vereist voor verzenders van dagelijks 5.000 of meer berichten aan persoonlijke Gmail-accounts ondersteuning voor afmelden met één klik volgens RFC 8058 voor marketing- en abonnementsberichten. Dit betekent de e-mailheaders List-Unsubscribe en List-Unsubscribe-Post toevoegen naast de zichtbare afmeldlink. Het éénklik-eindpunt moet een POST-aanvraag verwerken; alleen de URL openen met een GET-aanvraag mag niemand afmelden. Laat IT dit controleren voordat je op die schaal verzendt.
Voeg een afmeldlink toe aan ieder marketingbericht van deze tool, met een achterliggend afmeldeindpunt.
Valt de tool onder Gmails eisen voor bulkverzenders, implementeer dan ook RFC 8058-headers voor afmelden met één klik, gedekt door een geldige DKIM-handtekening, en een POST-gebaseerd eindpunt. Meld nooit iemand af alleen doordat een URL is geopend. Markeer onzekerheden voor IT-beoordeling.
Wanneer het afmeldeindpunt een geldig verzoek ontvangt (linkklik, formulierinzending of API-aanroep):
- voeg het adres onmiddellijk toe aan een uitsluitingslijst die apart van de abonneetabellen wordt opgeslagen
- registreer het tijdstip en het kanaal waarlangs het verzoek binnenkwam
- als ons e-mailplatform de lijst bijhoudt, geef dat platform dan ook opdracht het adres af te melden
Controleer de uitsluitingslijst vóór iedere verzending en sla iedere overeenkomst over. Verwijder nooit automatisch een adres uit de uitsluitingslijst tijdens een import, synchronisatie of databaseherstel. Bewaar volgens het goedgekeurde bewaarbeleid van het bedrijf uitsluitend de minimale uitsluitingsinformatie die nodig is om de afmelding te respecteren en laat import of synchronisatie nooit een uitgesloten adres opnieuw toevoegen. Zorg dat back-ups de uitsluitingslijst bevatten en dat herstel van de abonneetabellen die lijst onaangeroerd laat. Voeg onze afzendernaam en ons postadres aan de footer van ieder marketingbericht toe met placeholders die ik zal invullen. Rapporteer wijzigingen en welke verzendingen ze dekken.
Controleer: voeg een testadres waarover je controle hebt toe aan een testlijst, verstuur via de tool een testcampagne en klik op de afmeldlink in het ontvangen bericht. Het adres staat nu op de uitsluitingslijst (en als afgemeld in het e-mailplatform als dat de lijst bijhoudt). Verzend opnieuw naar dezelfde testlijst: het testadres ontvangt niets.
De verantwoordelijke voor e-mailcompliance bij het bedrijf levert de afzendernaam en het postadres voor die placeholders.
Bepaal vooraf wat naar advertentieplatforms en AI-tools gaat
Twee codepaden sturen standaard abonneegegevens naar buiten: een synchronisatie die een segment naar een aangepaste doelgroep bij Meta of Google uploadt en aanroepen die abonneevelden doorgeven aan een AI-API (voor onderwerpregels of leadbeoordeling), analysescripts of webhooks.
Meta en Google kunnen klantdoelgroepen matchen met SHA-256-gehashte contactidentificatoren. Googles Data Manager API vereist dat e-mailadressen en telefoonnummers vóór indiening worden genormaliseerd en gehasht, terwijl sommige uploads via de Google Ads-interface het hashen tijdens de upload kunnen uitvoeren. Hashing is hoe het platform een adres met een profiel matcht; het maakt de persoon niet anoniem (zie de FAQ).
Controleer bij nieuwe Google Customer Match-integraties welke upload-API wordt ondersteund voordat je de synchronisatie bouwt. Sinds 1 april 2026 beperkt Google oudere Customer Match-uploadmethoden voor nieuwe gebruikers en verwijst het deze integraties naar zijn Data Manager API.
Meta’s voorwaarden voor klantenlijstdoelgroepen laten de adverteerder garanderen dat die de benodigde rechten, toestemmingen en een rechtsgrond voor de gegevensdeling heeft. Googles Customer Match-beleid vereist dat de deling in het privacybeleid wordt vermeld en toestemming wordt verkregen waar de wet dat verlangt.
Voor de eenvoud behandelt deze tool iedere afmelding ook als een verzoek om advertentiematching te stoppen. Dat is een voorzichtig bedrijfsbeleid, geen bewering dat iedere kanaalspecifieke e-mailafmelding wettelijk verwijdering uit alle advertentiedoelgroepen vereist.
Het uploadpad moet daarom alleen het segment gebruiken dat het bedrijf voor advertentiematching heeft goedgekeurd; het bedrijf moet een passende rechtsgrond vaststellen, begeleid door de privacyverantwoordelijke of aangewezen functionaris voor gegevensbescherming (DPO), als die is benoemd. Afgemelde en uitgesloten contacten blijven buiten iedere upload en een afmelding activeert verwijdering via hashwaarde uit iedere doelgroep (het AVG-gedeelte hieronder legt uit waarom).
Iedere AI- of analysedienst die abonneegegevens ontvangt moet door het bedrijf zijn goedgekeurd. Bevestig vóór het delen van persoonsgegevens of de aanbieder als verwerker of zelfstandig verwerkingsverantwoordelijke handelt en regel passende contractuele waarborgen, waaronder een verwerkersovereenkomst waar nodig.
Controleer iedere uitgaande aanroep van deze tool: e-mailplatforms, advertentieplatforms (inclusief doelgroepuploads), AI-API’s (OpenAI, Anthropic of andere), analysetools en webhooks. Noem per aanroep precies welke abonneevelden in de aanvraagbody of URL staan. Geef aan welke aanroepen met minder velden of helemaal zonder abonneegegevens kunnen werken. Sluit af met een namenlijst van alle externe diensten om te vergelijken met onze goedgekeurde leveranciers.
Controleer: ieder abonneeveld dat het rapport bij een AI- of analysedienst noemt moet nodig zijn voor de taak, en iedere genoemde dienst moet op de goedgekeurde bedrijfslijst staan; andere gaan naar degene die leverancierscontracten ondertekent.
Voor ieder pad in deze tool dat contacten uploadt naar Meta, Google Ads of een ander advertentieplatform:
- hash e-mailadressen en telefoonnummers vóór upload op de server met SHA-256 volgens de normalisatieregels van ieder platform
- upload alleen contacten in [het segment dat je bedrijf voor advertentiematching heeft goedgekeurd]
- sluit afgemelde en uitgesloten contacten op het uploadmoment uit
- stuur bij afmelding van een contact een verwijderverzoek voor diens hashwaarde naar iedere doelgroep waarnaar het contact was geüpload
- log iedere upload en verwijdering met tijdstip, doelgroep, aantal contacten en de gebruiker of taak die ze activeerde
Rapporteer wat je hebt gewijzigd en markeer onzekerheden.
Controleer: meld een testcontact af dat in een geüpload segment zit. Controleer na de volgende synchronisatie of naar iedere relevante doelgroep een verwijderverzoek is gestuurd. Verifieer dat ieder advertentieplatform de verwijdering met succes heeft verwerkt, en niet alleen dat de tool haar heeft gelogd of ingediend. Markeer mislukte of gedeeltelijke verwijderingen voor een nieuwe poging en IT-beoordeling.
Wat de tool met de lijst doet bepaalt waar hij draait

Een tool die alleen campagnecijfers toont draait op een server die het team beheert en die uitsluitend via een privénetwerk bereikbaar is; een tool die abonneerijen toont voegt bedrijfsaanmelding toe omdat de rollen daarvan afhangen. Een tool die marketingmail verzendt of advertentiedoelgroepen synchroniseert blijft binnen de eigen platformfuncties of gaat naar IT voordat iemand hem gebruikt.
| Wat de tool met de lijst doet | De sleutel of toegang die hij krijgt | Waar de tool draait |
|---|---|---|
| Werkt alleen met testabonnees | Geen productiesleutel; een testlijst of sandboxaccount | De hosting van de AI-tool zelf, alleen voor bouwen en demo’s |
| Toont alleen cijfers op campagneniveau | Een alleen-lezen- of rapportagesleutel: ads_read bij Meta, een Klaviyo Read-Only-sleutel, beperkt SendGrid Custom Access; bij Mailchimp een export | Een teamserver die alleen via een privénetwerk zoals Tailscale of WireGuard bereikbaar is |
| Leest of segmenteert abonneerijen | Een leessleutel beperkt tot noodzakelijke gegevens en eindpunten, met beperkingen per lijst waar het platform die ondersteunt | Dezelfde server, met bedrijfsaanmelding en de rollen lijstbeheerder en marketeer |
| Wijzigt de lijst (tags, aangepaste velden, een aanmeldformulier dat abonnees toevoegt) | Een schrijfsleutel beperkt tot noodzakelijke handelingen en, waar ondersteund, de relevante lijsten | Dezelfde server nadat een tweede persoon de controles van inloggegevens, status en afmelding heeft gelezen; een openbaar aanmeldformulier staat op internet, dus die beoordeling en een op de server bewaarde sleutel beschermen het |
| Verzendt marketingmail of synchroniseert advertentiedoelgroepen | Een verzendsleutel of token met beheerrechten | De eigen campagnes en automatiseringen van het e-mailplatform, Listmonk of IT vóór lancering; doelgroepsynchronisaties vereisen ook een privacybeoordeling van het goedgekeurde segment |
Goedkeuring volgt de rijen: voor de twee alleen-lezen-rijen moet de e-mailplatformbeheerder de sleutel uitgeven, de lijstwijzigende rij vereist een tweede lezer en de verzendrij vereist IT, plus privacybeoordeling voor doelgroepuploads.
Een privénetwerk betekent dat de tool van buitenaf helemaal niet antwoordt. Een door de AI-tool geschreven inlogpagina is voor iedereen bereikbaar en slechts zo sterk als de achterliggende code. Zo kon RedAccess apps vinden waarvan de aanmelding ieder e-mailadres accepteerde.
Mijn regel hier: begin met het privénetwerk en voeg daar bedrijfsaanmelding aan toe waar de rollen dat vereisen. Een beheerd uitrolplatform met ingebouwde aanmelding en geheimenopslag werkt ook voor een team dat daar al voor betaalt en zijn leveranciers beoordeelt.
De serverkant is het deel om aan IT-ondersteuning over te dragen, met één aangewezen eigenaar voor server en sleutels. De tool draait op een VPS (een gehuurde server die het team volledig beheert) onder een uitroltool zoals Coolify of Dokploy, die de app vanuit de code draait en de omgevingsvariabelen, inclusief platformsleutels, bewaart.
Het privénetwerk komt van Tailscale, sneller op te zetten maar afhankelijk van zijn eigen coördinatiedienst (Headscale kan die vervangen), of van het volledig zelf gehoste WireGuard. Bedrijfsaanmelding (single sign-on met het bedrijfsaccount) komt van Authentik of Keycloak en een reverse proxy (Caddy of Nginx Proxy Manager) voegt HTTPS toe waar de tool het web raakt.
De e-mailengine naar Listmonk verplaatsen
In plaats van beperkte sleutels op het huidige platform verwijdert de andere route de sleutel van het commerciële platform door de lijst en verzending naar een zelf gehoste lijstbeheerder te verplaatsen. Listmonk (v4.0.0 en nieuwer) geeft iedere tool een eigen API-gebruiker met een lijstrol beperkt tot de lijsten die de tool gebruikt.
Een alleen-lezen-tool krijgt kijktoegang tot zijn lijsten en geen verzending; campaigns:send en tx:send (transactionele berichten) gaan uitsluitend naar een verzendtool. Drie bijzonder riskante rechten horen niet bij beperkte toolrollen: lists:get_all en lists:manage_all, die lijstrollen overrulen, en subscribers:sql_query, waarmee volgens Listmonks documentatie over rollen en rechten “alle lijsten en abonnees rechtstreeks uit de database kunnen worden opgevraagd, boven individuele lijst- en abonneerechten”. Beoordeel ook brede rechten zoals subscribers:get_all, campaigns:get_all en campaigns:manage_all voordat je een tool lijstbeperkt noemt. Geef iedere API-gebruiker alleen de rechten voor diens taak. Listmonk is voor campagnes gebouwd, niet voor meerstapsautomatisering (wanneer Listmonk de verkeerde tool is); Mautic verzorgt die automatisering op hetzelfde type server.
Daar staat doorlopend werk tegenover: het team wordt verantwoordelijk voor verzenddomeinauthenticatie (SPF, DKIM en DMARC), een SMTP-relay voor bezorging, updates, back-ups en bezorgbaarheid. Bij een kleine lijst, als niemand een server kan beheren, of als de verzendreputatie en automatiseringen van het huidige platform belangrijk werk dragen, is op het platform blijven met beperkte sleutels de betere keuze.
Beide routes vereisen een server waarvoor iemand verantwoordelijk is, met de uitroltool en het privénetwerk, en bij zelfhosting Listmonk met een SMTP-relay. Onze Linux VPS biedt roottoegang en Listmonk, Mautic, Tailscale, WireGuard en Authentik worden als éénklik-apps uitgerold. IT-ondersteuning besteedt dan tijd aan configuratie en beoordeling in plaats van installatie; alles bijgewerkt houden blijft bij het team.
Locaties zijn onder meer Frankfurt en Amsterdam in de EU, Londen in het VK en meerdere Amerikaanse steden; de keuze bepaalt waar de tool en iedere lijstkopie staan (en bij Listmonk de lijst zelf). Een locatie is input voor het gesprek met de DPO, geen vervanging daarvan, en maakt de tool op zichzelf niet compliant.
Toestemmings- en antispamregels voor marketingmail
AVG voor de abonneelijst
De AVG vereist geen toestemming als grondslag voor verwerking voor direct marketing: overweging 47 zegt dat die verwerking “kan worden beschouwd als uitgevoerd met het oog op een gerechtvaardigd belang”. Als marketing wel op toestemming steunt, vereist artikel 7 dat het bedrijf kan aantonen dat iedere persoon toestemming gaf, en moet intrekken even eenvoudig zijn als geven. Daarvoor dienen de toestemmingsbron en het tijdstip in het e-mailplatform.
De strengere regel staat in artikel 21 van de AVG. Ongeacht de grondslag kan iemand op ieder moment bezwaar maken tegen direct marketing, inclusief bijbehorende profilering; daarna “worden de persoonsgegevens niet meer voor deze doeleinden verwerkt”. Bij marketing is er geen belangenafweging, anders dan bij andere bezwaren onder hetzelfde artikel. Voor deze tool is het veiligste uitgangspunt een algemeen bezwaar tegen direct marketing toe te passen op alle marketinggebruik van iemands gegevens: verzendlijst, toolsegmenten en advertentiedoelgroepen. Een kanaalspecifieke afmelding kan beperkter zijn; het bedrijf moet daarom met zijn privacyverantwoordelijke voorkeursregels vastleggen en ieder verzoek passend respecteren.
Een gelekte of onjuist gewijzigde lijst kan een inbreuk op persoonsgegevens zijn. Artikel 33 vereist melding aan de toezichthouder (de nationale privacyautoriteit) zonder onnodige vertraging en waar mogelijk binnen 72 uur na ontdekking, tenzij het onwaarschijnlijk is dat de inbreuk risico voor mensen oplevert. In het VK geldt de overeenkomstige UK GDPR, gehandhaafd door de ICO.
De verzendwetten: ePrivacy en PECR, CAN-SPAM en CASL
De ePrivacy-regels van de EU en de Britse PECR vereisen voorafgaande toestemming voor marketingmail aan natuurlijke personen, met een beperkte “soft opt-in” voor bestaande klanten. Het VK heeft ook een aparte soft opt-in voor liefdadigheidsdoelen met specifieke voorwaarden; dit artikel gaat over commerciële marketing. Het Canadese CASL vereist uitdrukkelijke of impliciete toestemming. Het Amerikaanse CAN-SPAM vereist geen toestemming voor verzending, maar wel een werkende afmelding die binnen 10 werkdagen wordt gerespecteerd, plus juiste afzendergegevens en een postadres in ieder bericht.
| Wet | Toestemming om te verzenden | Ieder marketingbericht moet | Afmeldtermijn | Maximumstraf |
|---|---|---|---|---|
| ePrivacy (EU) en PECR (VK) | Voorafgaande toestemming voor e-mail aan natuurlijke personen; soft opt-in voor klanten; een aparte Britse uitzondering voor liefdadigheidsdoelen kent specifieke voorwaarden | De afzender niet verhullen; een geldig adres voor afmeldverzoeken geven; bij soft opt-in in ieder bericht een gratis, eenvoudige mogelijkheid bieden om te weigeren | Geen vaste termijn in de tekst | Hier geen bedrag vermeld |
| CAN-SPAM (VS) | Niet vereist; geldt voor alle commerciële e-mail, inclusief B2B | Juiste header- en “Van”-gegevens, een niet-misleidende onderwerpregel, vermelding dat het reclame is tenzij de ontvanger vooraf uitdrukkelijk instemde, een geldig fysiek postadres en een werkende afmelding bevatten | 10 werkdagen; de afmelding moet minstens 30 dagen na verzending blijven werken | Tot US$53.088 per e-mail; strafrechtelijke sancties alleen bij specifieke verzwarende praktijken |
| CASL (Canada) | Uitdrukkelijke of impliciete toestemming | De afzender en iedereen namens wie wordt verzonden identificeren; contactgegevens en een afmeldmechanisme bevatten, beide minstens 60 dagen geldig | Zonder vertraging, uiterlijk binnen 10 werkdagen | Bij de ernstigste overtredingen tot C$1 miljoen voor personen en C$10 miljoen voor bedrijven |
De soft opt-in in artikel 13 van de ePrivacy-richtlijn betreft contactgegevens verkregen bij een verkoop, gebruikt voor eigen soortgelijke producten, met een gratis weigeringsmogelijkheid bij verzameling en in ieder bericht. De Britse versie is PECR Regulation 22, uitgelegd in de e-mailmarketingrichtlijnen van de ICO. Artikel 13 verbiedt ook marketingmail die de afzender verhult of geen geldig adres voor afmeldverzoeken bevat; PECR Regulation 23 doet hetzelfde in het VK.
De CAN-SPAM-bedragen komen uit de CAN-SPAM-gids van de FTC, die toevoegt dat afgemelde adressen niet mogen worden verkocht of overgedragen, behalve aan een bedrijf dat is ingehuurd om te helpen aan CAN-SPAM te voldoen. De CASL-regels staan in sectie 6 van CASL en sectie 11, de sancties in het CASL-overzicht van ISED.
Veelgestelde vragen
Geldt de AVG voor een nieuwsbrief-tool die ik zelf heb gebouwd?
Waar het bedrijf actief is en van wie de gegevens in de tool zijn bepaalt dat, niet hoe de tool is gebouwd. Volgens artikel 3 geldt de AVG voor een bedrijf dat in de EU is gevestigd en voor een bedrijf daarbuiten dat goederen of diensten aan mensen in de EU aanbiedt of hun gedrag daar volgt. Of een bepaald bedrijf eronder valt is een vraag voor zijn DPO.
Wat gebeurt er als onze Klaviyo-API-sleutel lekt?
Wie een Full Access-sleutel bezit kan de lijst wijzigen; een Read-Only-sleutel laat alleen bekijken toe. Maak een vervanging met uitsluitend de scopes die de tool gebruikt (Klaviyo kan later geen scope toevoegen aan een bestaande sleutel, dus kies nu), trek de gelekte sleutel onmiddellijk in, schakel de tool over op de vervanging en controleer op ongeautoriseerde exports of lijstwijzigingen. Als de lijst mogelijk is gelezen, behandel dit dan als een mogelijk AVG-datalek.
Bevat een gehashte e-maillijst nog steeds persoonsgegevens?
Onder de AVG wel als die aan een persoon kan worden gekoppeld. Overweging 26 behandelt gepseudonimiseerde gegevens die “door het gebruik van aanvullende gegevens aan een natuurlijke persoon kunnen worden gekoppeld” als informatie over een identificeerbaar persoon. Mijn interpretatie is dat advertentiematching precies daarom werkt: het platform kan dezelfde hash berekenen uit een adres dat het al bezit.
Gelden voor B2B-marketingmails dezelfde regels?
Niet overal. CAN-SPAM maakt volgens de FTC geen uitzondering voor e-mail tussen bedrijven. De e-mailregel van PECR geldt voor natuurlijke personen en de ICO bevestigt dat je marketingmails aan bedrijven mag sturen. Vraag voor EU-landen en Canada juridisch advies.
Discussie
Reacties
Log in om mee te praten.