Jak mohou marketingové týmy nasazovat aplikace vytvořené AI bez odhalení údajů odběratelů

„Někdo z marketingového týmu chce vytvořit web. Není to technik a pravděpodobně má jen malé nebo žádné zkušenosti či znalosti z oblasti bezpečnosti,“ řekl bezpečnostní výzkumník Joel Margolis časopisu Wired. Stejná reportáž Wired popisuje, jak bezpečnostní firma RedAccess našla přes 5 000 aplikací vytvořených pomocí vibe codingu prakticky bez zabezpečení nebo autentizace; přibližně 40 procent těchto aplikací odhalovalo citlivá data. Wired se nepodařilo potvrdit pravost zkoumaných osobních nebo firemních údajů.

Aplikace vytvořené AI pro marketingové týmy přinášejí specifickou podobu tohoto problému. Nástroje, které má smysl stavět (tvorba segmentů, panel kampaní, analyzátor A/B testů či synchronizace publik), jsou napojené na seznam odběratelů a často také na reklamní účet.

Stručně

• Každému API klíči e-mailové platformy a tokenu reklamního účtu přidělte nejužší přístup, který nástroj potřebuje, a uchovávejte je v serverovém kódu. Marketing API služby Mailchimp nemá omezenější typ klíče, takže úloha pouze pro čtení dostane místo klíče omezený export obsahující jen potřebné údaje.
• E-mailová platforma zůstává směrodatným zdrojem stavu odběru. Nástroj nikdy znovu nepřihlásí lidi, kteří odběr odmítli, předává platformě žádosti o odhlášení a do každého marketingového e-mailu, který sám odešle, vloží funkční odhlašovací odkaz.
• Hashované údaje nahrané do vlastního publika jsou stále osobními údaji: předem určete, co odchází reklamním platformám a službám AI, a zajistěte, aby se každé odhlášení promítlo i do reklamního publika.
• GDPR upravuje uchovávání a používání seznamu: oznamování porušení zabezpečení a bezpodmínečné právo vznést námitku proti marketingu. ePrivacy/PECR, CAN-SPAM nebo CASL upravují odesílání e-mailů, i když je odesílá interní nástroj.

Chyby nasazení, které odhalují údaje odběratelů nebo porušují podmínky souhlasu

Marketingový nástroj vytvořený AI obvykle při práci se seznamem selže jedním ze dvou způsobů: seznam unikne přes klíč, veřejný odkaz či nahrání dat, nebo se použije vůči lidem, kteří odmítli. Reklamní token s oprávněním ke správě přidává samostatné riziko: útratu na reklamním účtu firmy.

Nástroj AI, který aplikaci vytvořil, dokáže na požádání provést většinu těchto oprav. Každý následující pokyn berte jako výchozí bod k úpravě a používané pokyny uchovávejte v souboru pravidel, který nástroj AI čte při každé relaci. Hlášení AI, že změnu provedla, není důkaz; tím je krok Ověřte: pod každým pokynem. Žádejte označení nejistot místo hádání a nikdy nevkládejte do chatu platný klíč ani export odběratelů.

Nahraďte klíč e-mailové platformy s plným přístupem klíčem s nejužšími právy

Nástroj na tvorbu segmentů, který jen ukazuje počty, nepotřebuje klíč umožňující export seznamu nebo odeslání kampaně, přesto nejširší klíč každé níže uvedené platformy umí obojí. Záleží i na umístění: kód v prohlížeči potřebuje pro volání samotnou hodnotu klíče, takže ji přečte každý, kdo načte stránku. Mailchimp použití svého API na straně klienta vůbec nepodporuje.

Každý řádek vychází z dokumentace platformy: nápovědy Mailchimp k API klíčům, oprávnění API klíčů SendGrid, průvodce autentizací Klaviyo a dokumentace API klíčů Mailgun. Oprávnění Listmonk jsou uvedena dále v části o Listmonk.

Nástroj dostane klíč s nejužšími právy, která jeho úloha umožňuje, nebo žádný. V Mailchimp je pro úlohu pouze ke čtení (přehled či počet v segmentu) lepší použít vlastní reporty platformy nebo omezený export provedený vlastníkem účtu, obsahující jen potřebná pole. Cenou je čas člověka a aktuálnost dat pouze k okamžiku exportu; změny a odesílání předejte IT nebo ponechte v Mailchimp. Na jiných platformách, například ActiveCampaign či Brevo, nejprve hledejte možnost omezeného klíče.

Klíč pak existuje pouze v serverovém kódu (vlastním backendu nástroje, který prohlížeč nikdy nestahuje) jako proměnná prostředí: hodnota, kterou server předá aplikaci při spuštění a která zůstává mimo kód i repozitář.

Najdi v tomto projektu všechny API klíče, přístupové tokeny, hesla a tajné údaje pro naši e-mailovou platformu (Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk či jinou) i jakoukoli reklamní platformu: Meta, Google Ads, LinkedIn či jinou. Zkontroluj kód, soubory prostředí a historii repozitáře místním skenerem tajných údajů nebo metodou schválenou IT. Nikdy neodesílej externí službě AI nezakryté tajné hodnoty, obsah souborů prostředí ani historii obsahující přihlašovací údaje. AI předej pouze nálezy se zakrytými citlivými údaji, včetně umístění souborů a typu nalezených přihlašovacích údajů. U každého uveď:

- soubor a řádek

- zda je hodnota zapsána v kódu, nebo čtena z proměnné prostředí

- zda kód, který ji používá, běží na serveru, nebo v prohlížeči

Zobrazuj pouze první čtyři znaky každé hodnoty. Nikdy nevypisuj celý klíč ani token.

Jako nejvyšší prioritu označ všechny přihlašovací údaje umožňující odesílat e-maily, měnit odběratele nebo spravovat reklamní účet.

Poté přesuň každé volání vyžadující soukromý API klíč či přístupový token do serverového kódu, který čte přihlašovací údaje z proměnné prostředí dostupné jen serveru. V prohlížeči ponech pouze zdokumentovaná veřejná klientská volání API, odstraň odhalené soukromé klíče z kódu a vyluč z repozitáře soubory se skutečnými tajnými údaji. Přesně popiš změny a místo hádání uveď, kde sis nebyl jistý.

Poznámka: smazání vloženého klíče z chatu nebo kódu nevrátí jeho odhalení zpět. Odvolejte jej (vypněte v nastavení platformy, aby přestal fungovat) a vytvořte nový.

Ověřte: otevřete nástroj, stiskněte F12, vyberte kartu Network a používejte nástroj jako tým, přičemž sledujte doménu každého požadavku. Požadavek prohlížeče přímo volající soukromé API e-mailové platformy je varovný signál, ale samotný cíl nedokazuje odhalení tajného údaje. Prohlédněte hlavičky požadavků a kód kvůli soukromým přihlašovacím údajům, aniž byste jejich hodnoty kopírovali do chatu AI. Veřejné požadavky klientského SDK jsou jiné: mohou oprávněně používat veřejné identifikátory místo tajných API klíčů. V Klaviyo požadavky na a.klaviyo.com/client/ používají veřejný klíč a patří do prohlížeče, zatímco požadavek prohlížeče na a.klaviyo.com/api/ vyžaduje prošetření, protože tento koncový bod obvykle vyžaduje autentizaci soukromým klíčem. Potvrďte, zda byl soukromý přihlašovací údaj skutečně přenesen.

Zbytek řeší člověk: vytvořte omezený klíč z účtu, který nepatří jedné osobě (Mailchimp odstraní API klíče uživatele při odebrání jeho přístupu); pojmenujte jej podle nástroje, protože Mailchimp doporučuje jeden klíč na integraci, a s pomocí IT jej uložte tam, kde jsou klíče nástroje uchovávány. Při plánované rotaci přepněte nástroj na nový klíč před odvoláním starého, protože odvolaný klíč Mailchimp nelze znovu aktivovat. Již kompromitovaný klíč odvolejte okamžitě a nahraďte jej. Počítejte i s vypršením: API klíče Mailchimp vytvořené 22. června 2026 nebo později vyprší rok po vytvoření.

Dejte tokenu reklamního účtu pouze oprávnění, která nástroj používá

Token reklamního účtu považuji za přihlašovací údaj s největším dopadem, který může marketingový nástroj mít, protože je spojen s útratou. Token Meta s právem správy může vytvářet, měnit či pozastavovat kampaně účtované reklamnímu účtu firmy a číst útratu i výsledky.

Takový token ale nevrací seznam odběratelů nahraný do vlastního publika. Průvodce Meta pro Custom Audiences pracuje při přidávání i odstraňování lidí s hodnotami hashovanými SHA-256: jednosměrnou úpravou každé adresy, kterou platforma porovnává se svými záznamy. Žádný zdokumentovaný koncový bod nevrací čitelný seznam z existujícího publika.

Přehled oprávnění Meta popisuje každé oprávnění a říká vývojářům, aby vybírali pouze ta, která aplikace potřebuje. Každý nástroj dostane vlastní token systémového uživatele (označení Meta pro účet v Business Manageru používaný softwarem) přiřazeného jen k reklamnímu účtu, se kterým nástroj pracuje. Nepoužívejte v nástroji osobní přihlašovací token tvůrce a token systémového uživatele držte na serveru stejně jako e-mailový klíč; stejná inventura platí pro jakýkoli přístup ke Google Ads nebo LinkedIn.

Vypiš všechna volání tohoto nástroje na Marketing API Meta, Google Ads nebo jinou reklamní platformu, včetně volání přes pomocné knihovny a SDK. Pro každé uveď:

- soubor a řádek

- koncový bod nebo metodu SDK

- štítek: REPORT: čte metriky nebo útratu; MANAGE: vytváří či mění kampaně, reklamy, rozpočty nebo publika; LEADS: čte odpovědi z formulářů pro zájemce

- oprávnění platformy, které tento štítek potřebuje

Označ každý token používaný více nástroji a každý kód, který posílá token do prohlížeče. Nevypisuj hodnoty tokenů. Pokud neumíš určit potřebný štítek volání, řekni to.

Ověřte: zkontrolujte token panelu v nástroji Meta pro ladění tokenů, který uvádí jeho oprávnění, a porovnejte je se štítky z pokynu. Token reportovacího panelu má mít ads_read a žádná oprávnění ke správě účtu; štítek MANAGE nebo LEADS u reportovacího nástroje je zjištěný problém. Pak v nastavení Business ověřte, že nástroj používá token svého systémového uživatele, nikoli osobní token tvůrce.

Uzavřete veřejnou adresu a zobrazujte řádky odběratelů jen správcům seznamu

Aplikaci na hostingu nástroje AI může otevřít každý, kdo najde její adresu. Některé aplikace zkoumané RedAccess měly podle Wired pouze triviální překážky, například požadavek přihlásit se jakoukoli e-mailovou adresou. Takový hosting se hodí pro ukázku s vymyšlenými adresami; jde o úlohu, pro kterou jsou určeny bezplatný hosting a tunely.

Druhou částí je, co každý po vstupu uvidí. Úkolem panelu kampaní jsou souhrnné ukazatele kampaní: míra otevření, míra prokliků, výsledky A/B testů a velikosti segmentů. Řádky odběratelů v pozadí (každá adresa s podrobnostmi souhlasu a historií interakcí) jsou osobními údaji.

Řádně anonymizované souhrnné ukazatele zpravidla nejsou osobními údaji, ale malé segmenty nebo podrobné rozklady stále mohou umožnit identifikaci lidí. I anonymní čísla mohou odhalit konkurenční informace firmy a analyzátor A/B testů uchovávající otevření a kliknutí jednotlivých osob také obsahuje osobní údaje. Tým vidí souhrny; řádky vidí pouze správci seznamu a server to vynucuje při každém požadavku.

Vypiš všechna pole v databázi, obrazovkách, exportech a odpovědích API této aplikace obsahující osobní údaje odběratelů: e-mailovou adresu, jméno, telefon, poštovní adresu, IP adresu, polohu, stav odběru, zdroj a čas souhlasu, datum přihlášení, stav odhlášení a otevření i kliknutí jednotlivých osob. U každého pole uveď obrazovky a exporty, které je zobrazují. Označ nejisté věci místo hádání.

Potom přidej dvě role převzaté z přihlášeného účtu a ověřované serverem pro každou stránku, export a trasu API:

- správce seznamu: vidí řádky odběratelů a provádí exporty

- marketér: vidí pouze ukazatele kampaní, počty segmentů a výsledky A/B testů, bez řádků jednotlivců a bez exportů

Vše ostatní odmítni odpovědí „přístup odepřen“ (403). Uveď, která kontrola chrání každou stránku a trasu.

Zda jsou uložená data na disku šifrovaná, je otázka pro IT; nástroj AI to nemůže potvrdit čtením kódu.

Ověřte: vytvořte testovací účet s rolí marketéra. Po přihlášení tímto účtem otevřete panel kampaní (načte se) a pak stránku seznamu odběratelů a export: oba se zastaví na „přístup odepřen“. Potom otevřete adresu nástroje na telefonu přes mobilní data bez přihlášení: nic se nenačte, nebo se zobrazí stránka firemního přihlášení.

Ponechte odhlášení a záznamy o souhlasu e-mailové platformě

Nástroj uchovávající vlastní kopii seznamu a zapisující ji zpět obousměrnou synchronizací nebo opětovným importem exportu z minulého měsíce může odhlášeného člověka znovu označit jako přihlášeného a zahodit záznam, kde, kdy a jak se každý přihlásil. Nástroj obvykle nic nenaznačí, dokud dotyčný nedostane další kampaň, kdy se uplatní níže uvedená pravidla odesílání. Brání tomu čtyři pravidla:

1. E-mailová platforma je směrodatným zdrojem stavu odběru. Nástroj tento stav čte a nikdy znovu nepřihlašuje ani nepřepisuje existujícího odběratele. Může předat výslovnou žádost o odhlášení prostřednictvím určeného odhlašovacího procesu platformy.
2. Žádný hromadný import ani synchronizace nenahrazuje existující záznamy odběratelů a nepřepisuje jejich informace o odběru a souhlasu. Prověřený nástroj může aktualizovat výslovně schválená pole, například štítky, bez změny stavu odběru. Nová přihlášení přicházejí přes vlastní přihlašovací formulář či import platformy, aby se uplatnilo její zpracování souhlasu; vlastní formulář nástroje může po prověření přidávat nové odběratele se zdrojem, časem a formulářem, ale nikdy znovu nepřihlásí existující kontakt ani nepřepíše jeho informace o odběru či souhlasu.
3. Při každém odeslání nebo exportu nástroj čte stav z platformy v daný okamžik, nikoli z vlastní kopie. Exporty vynechávají odhlášené a vyloučené kontakty nebo je označují jako seznam „neodesílat“, který se nikdy nepoužívá k odesílání.
4. Pole souhlasu (zdroj, čas, formulář nebo metoda) zůstávají nedotčená v každém kopírovaném záznamu, nebo je nástroj nekopíruje a netvrdí, že je má.

Vypiš všechna místa, kde nástroj zapisuje do e-mailové platformy nebo jakékoli kopie seznamu odběratelů: API volání vytvářející či aktualizující odběratele, importy, synchronizace a exporty souborů. U každého řekni, zda může:

- změnit stav odběru existujícího odběratele

- přepsat existující záznamy odběratelů

- zahrnout odhlášené nebo vyloučené kontakty

U každé cesty odesílající e-mail nebo exportující seznam pro odesílání uveď zdroj stavu odběru: e-mailová platforma v daný okamžik, nebo vlastní kopie nástroje.

Pak uprav nástroj tak, aby nikdy znovu nepřihlásil existující kontakt ani nepřepsal jeho stav odběru, kromě předání výslovné žádosti o odhlášení určeným procesem e-mailové platformy; nikdy nenahrazoval existující záznamy odběratelů celé; četl stav z platformy bezprostředně před každým odesláním či exportem a zachoval zdroj, čas i formulář souhlasu v každém kopírovaném záznamu. Popiš změny a označ vše, čím si nejsi jistý.

Poznámka: starý export opětovně importovaný přes seznam přináší staré stavy, takže lidé odhlášení po exportu se mohou vrátit jako přihlášení, podle toho, jak platforma a nástroj import zpracovávají.

Ověřte: přidejte v e-mailové platformě testovacího odběratele a poté jej tam odhlaste. Spusťte synchronizaci, tvorbu segmentů a export nástroje. V platformě zůstává testovací odběratel odhlášený; v exportu nástroje chybí nebo je označen „neodesílat“; neobjeví se v žádném seznamu pro odesílání vytvořeném nástrojem.

Odesílejte přes e-mailovou platformu, nebo nejprve vybudujte odhlašovací cestu

Nástroj pro opětovné zapojení, který odesílá seznamu přímo přes účet SMTP nebo API transakčních e-mailů, nezíská to, co platforma přidává do marketingové pošty (odhlašovací odkaz, poštovní adresu a kontrolu vyloučení), pokud jeho kód každý prvek nepřidá. Řešením je nechat odesílat platformu či Listmonk a v nástroji tvořit segment nebo spouštět kampaň platformy. Nástroj, který musí odesílat sám, je odesílací nástroj, který další část směruje k IT.

Takový nástroj potřebuje v každé marketingové zprávě odhlašovací odkaz fungující i po odeslání a totožnost i poštovní adresu odesílatele v patičce, podle lhůt v tabulce zákonů níže. Potřebuje také vlastní seznam vyloučených kontaktů, kontrolovaný před každým odesláním a uchovávaný jako trvalý záznam zákazu, se zálohami a postupy obnovy zabraňujícími tomu, aby starší databáze odběratelů přepsala novější odhlášení. CAN-SPAM zachází s transakčními zprávami jinak.

U velkých odesílatelů nemusí odkaz v patičce stačit. Gmail vyžaduje od odesílatelů posílajících denně alespoň 5 000 zpráv na osobní účty Gmail podporu odhlášení jedním kliknutím podle RFC 8058 pro marketingové a odebírané zprávy. To znamená přidat hlavičky List-Unsubscribe a List-Unsubscribe-Post vedle viditelného odhlašovacího odkazu. Koncový bod odhlášení jedním kliknutím musí zpracovat požadavek POST; samotné otevření URL požadavkem GET nesmí nikoho odhlásit. Před odesíláním v tomto rozsahu požádejte IT o ověření těchto požadavků.

Přidej do každé marketingové zprávy odesílané tímto nástrojem odhlašovací odkaz a za něj koncový bod pro odhlášení.
Pokud nástroj podléhá požadavkům Gmailu pro hromadné odesílatele, implementuj i hlavičky odhlášení jedním kliknutím podle RFC 8058 pokryté platným podpisem DKIM a koncový bod založený na POST. Nikdy nespouštěj odhlášení jen kvůli otevření URL. Nejistoty označ k prověření IT.
Když odhlašovací koncový bod přijme platný požadavek (kliknutí na odkaz, odeslání formuláře nebo volání API):

- okamžitě přidej adresu do seznamu vyloučených kontaktů uloženého odděleně od tabulek odběratelů

- zaznamenej čas a kanál, kterým požadavek přišel

- pokud seznam uchovává naše e-mailová platforma, požádej ji také o odhlášení adresy

Před každým odesláním kontroluj seznam vyloučených kontaktů a přeskoč každou shodu. Nikdy automaticky neodstraňuj adresu z tohoto seznamu při importu, synchronizaci nebo obnově databáze. Uchovávej pouze minimální informace nutné k dodržení odmítnutí podle schválené firemní retenční politiky a nikdy nedovol importu či synchronizaci znovu přidat vyloučenou adresu. Zajisti, aby zálohy obsahovaly seznam vyloučených kontaktů a obnova tabulek odběratelů jej ponechala nedotčený. Do patičky každé marketingové zprávy přidej naše jméno odesílatele a poštovní adresu pomocí zástupných hodnot, které doplním. Popiš změny a odesílání, kterých se týkají.

Ověřte: přidejte do testovacího seznamu kontrolní adresu, kterou ovládáte, odešlete přes nástroj testovací kampaň a klikněte na odhlašovací odkaz ve zprávě přijaté na tuto adresu. Adresa je nyní v seznamu vyloučených kontaktů a v e-mailové platformě odhlášená, pokud platforma seznam uchovává. Odešlete znovu stejnému testovacímu seznamu: kontrolní adresa nic nedostane.

Osoba odpovědná za dodržování pravidel firemní e-mailové komunikace dodá jméno a poštovní adresu odesílatele do těchto zástupných hodnot.

Předem určete, co odchází reklamním platformám a nástrojům AI

Dvě cesty kódu ve výchozím nastavení odesílají údaje odběratelů ven: synchronizace nahrávající segment do vlastního publika Meta nebo Google a volání předávající pole odběratelů API AI pro psaní předmětů či hodnocení zájemců nebo analytickým skriptům a webhookům.

Meta a Google mohou párovat zákaznická publika pomocí kontaktních identifikátorů hashovaných SHA-256. Data Manager API od Google vyžaduje normalizaci a hashování e-mailových adres i telefonů před odesláním, zatímco některá nahrávání přes rozhraní Google Ads mohou hashování provést při nahrávání. Hashování umožňuje platformě spárovat adresu s profilem; nedělá člověka anonymním; viz FAQ.

U nových integrací Google Customer Match ověřte podporované API pro nahrávání ještě před stavbou synchronizace. Od 1. dubna 2026 Google omezuje starší metody nahrávání Customer Match pro nové uživatele a směruje takové integrace na Data Manager API.

Podmínky Meta pro publika ze seznamů zákazníků požadují, aby inzerent zaručil potřebná práva, oprávnění a právní základ pro sdílení údajů. Zásady Google Customer Match vyžadují sdílení uvést v zásadách ochrany soukromí a získat souhlas tam, kde jej zákon vyžaduje.

Pro jednoduchost považuje tento nástroj každé odhlášení také za žádost o zastavení reklamního párování. Jde o obezřetnou firemní politiku, nikoli tvrzení, že každé odhlášení e-mailu v jednom kanálu právně vyžaduje odstranění ze všech reklamních publik.

Cesta nahrávání proto má přijímat jen segment schválený firmou pro reklamní párování; firma musí určit odpovídající právní základ s pomocí odpovědné osoby pro soukromí nebo jmenovaného pověřence pro ochranu osobních údajů (DPO), pokud byl ustanoven. Odhlášené a vyloučené kontakty zůstávají mimo každé nahrávání a odhlášení spustí odstranění podle hashované hodnoty z každého publika; část o GDPR níže vysvětluje proč.

Každá služba AI či analytiky přijímající údaje odběratelů musí být schválená firmou. Před sdílením osobních údajů ověřte, zda poskytovatel působí jako zpracovatel nebo samostatný správce, a zajistěte odpovídající smluvní záruky včetně smlouvy o zpracování údajů, je-li vyžadována.

Proveď audit všech odchozích volání nástroje: e-mailových platforem, reklamních platforem včetně nahrávání publik, API AI (OpenAI, Anthropic či jiných), analytických nástrojů a webhooků. U každého přesně vypiš pole odběratelů v těle požadavku nebo URL. Uveď, která volání zvládnou úlohu s méně poli nebo bez údajů odběratelů. Na závěr uveď názvy všech externích služeb pro porovnání se schválenými dodavateli.

Ověřte: každé pole odběratele uvedené ve zprávě pro službu AI či analytiky má být potřebné pro danou úlohu a každá služba má být na firemním seznamu schválených služeb; ostatní předejte osobě, která podepisuje smlouvy s dodavateli.

U každé cesty nástroje nahrávající kontakty do Meta, Google Ads nebo jiné reklamní platformy:

- před nahráním hashuj e-mailové adresy a telefony pomocí SHA-256 na serveru podle normalizačních pravidel každé platformy

- nahrávej jen kontakty ze [segmentu schváleného vaší firmou pro reklamní párování]

- v okamžiku nahrávání vyluč odhlášené a zakázané kontakty

- při odhlášení kontaktu odešli požadavek na odstranění jeho hashované hodnoty každému publiku, kam byl nahrán

- zaznamenej každé nahrání a odstranění s časem, publikem, počtem kontaktů a uživatelem nebo úlohou, která je spustila

Popiš změny a označ vše, čím si nejsi jistý.

Ověřte: odhlaste testovací kontakt patřící do nahraného segmentu. Po příští synchronizaci nástroje zkontrolujte odeslání žádosti o odstranění do každého příslušného publika. Ověřte, že každá reklamní platforma odstranění úspěšně zpracovala, nikoli jen že je nástroj zaznamenal nebo odeslal. Neúspěšná či částečně provedená odstranění označte k opakování a kontrole IT.

Co nástroj dělá se seznamem, určuje místo jeho provozu

Nástroj zobrazující pouze ukazatele kampaní běží na serveru řízeném týmem, dostupném jen v soukromé síti; nástroj zobrazující řádky odběratelů přidává firemní přihlášení, protože na něm závisejí role. Nástroj odesílající marketingové e-maily nebo synchronizující reklamní publika zůstává ve vlastních funkcích platforem, nebo jde před prvním použitím k IT.

Schvalování odpovídá řádkům: dva řádky pouze pro čtení vyžadují vydání klíče správcem e-mailové platformy, změny seznamu vyžadují druhého kontrolora a odesílání IT plus kontrolu soukromí při nahrávání publik.

Soukromá síť znamená, že nástroj zvenčí vůbec neodpovídá. Přihlašovací stránka napsaná AI je dostupná komukoli a silná jen jako kód za ní; tak RedAccess našla aplikace, jejichž přihlášení přijímalo jakoukoli e-mailovou adresu.

Moje pravidlo: začněte soukromou sítí a doplňte nad ni firemní přihlášení všude, kde ho role potřebují. Funguje i spravovaná platforma nasazení s vestavěným přihlášením a úložištěm tajných údajů, pokud za ni tým už platí a kontroluje dodavatele.

Serverovou část předejte IT s jedním určeným vlastníkem serveru a klíčů. Nástroj běží na VPS (pronajatém serveru plně řízeném týmem) pod nástrojem nasazení, jako je Coolify nebo Dokploy, který spouští aplikaci z jejího kódu a uchovává proměnné prostředí včetně klíčů platforem.

Soukromou síť poskytne Tailscale, který se rychleji nastavuje, ale závisí na vlastní koordinační službě, již může nahradit Headscale, nebo plně samostatně hostovaný WireGuard. Firemní přihlášení (jednotné přihlášení firemním účtem) zajišťuje Authentik nebo Keycloak a reverzní proxy Caddy či Nginx Proxy Manager přidá HTTPS všude, kde je nástroj dostupný z webu.

Přesun e-mailového jádra do Listmonk

Druhá cesta místo omezených klíčů současné platformy odstraní klíč komerční platformy přesunem seznamu a odesílání do samostatně hostovaného správce seznamů. Listmonk ve verzi v4.0.0 a novější umožňuje každému nástroji vlastního API uživatele s rolí omezenou na seznamy, kterých se nástroj dotýká.

Nástroj pouze pro čtení dostane zobrazení svých seznamů bez odesílání; campaigns:send a tx:send pro transakční zprávy dostane jen odesílací nástroj. Tři zvlášť riziková oprávnění nemají být v rolích omezených nástrojů: lists:get_all a lists:manage_all, která obcházejí role jednotlivých seznamů, a subscribers:sql_query, které podle varování v dokumentaci rolí a oprávnění Listmonk umožňuje „dotazování všech seznamů a odběratelů přímo z databáze s obejitím jednotlivých oprávnění seznamů a odběratelů“. Prověřte i široká oprávnění subscribers:get_all, campaigns:get_all a campaigns:manage_all, než nástroj označíte za omezený na seznamy. Každému API uživateli dejte jen práva potřebná pro jeho úlohu. Listmonk je určen pro kampaně, nikoli vícekrokovou automatizaci (kdy Listmonk není vhodný nástroj); tu na stejném typu serveru zajišťuje Mautic.

Cenou je průběžná práce: tým pak odpovídá za autentizaci odesílací domény (SPF, DKIM a DMARC), SMTP relay pro doručování pošty, záplatování, zálohy a doručitelnost. Pokud je seznam malý, nikdo nemůže spravovat server nebo reputace odesílání a automatizace současné platformy zajišťují práci, na kterou tým spoléhá, je lepší zůstat na platformě s omezenými klíči.

Obě cesty potřebují server s odpovědným vlastníkem, na kterém běží nástroj nasazení a soukromá síť a při samostatném hostování také Listmonk se SMTP relay. Náš Linux VPS dává root přístup a Listmonk, Mautic, Tailscale, WireGuard i Authentik se nasazují jako aplikace jedním kliknutím. IT pak věnuje čas konfiguraci a kontrole místo instalace; udržování aktualizací všeho zůstává týmu.

Lokality zahrnují Frankfurt a Amsterdam v EU, Londýn ve Spojeném království a několik měst USA; vybrané místo určuje, kde sídlí nástroj a jakákoli kopie seznamu, v Listmonk i samotný seznam. Lokalita je podkladem k rozhovoru s DPO, nikoli jeho náhradou, a sama nezajišťuje soulad nástroje s předpisy.

Souhlas a protispamová pravidla pro marketingové e-maily

GDPR pro seznam odběratelů

GDPR nevyžaduje souhlas jako základ zpracování pro přímý marketing: bod 47 odůvodnění říká, že takové zpracování „lze považovat za zpracování prováděné z důvodu oprávněného zájmu“. Pokud marketing vychází ze souhlasu, článek 7 požaduje, aby firma „byla schopna doložit“ souhlas každé osoby, a aby jeho odvolání bylo stejně snadné jako udělení. K tomu slouží zdroj a čas souhlasu v e-mailové platformě.

Přísnější pravidlo obsahuje článek 21 GDPR. Bez ohledu na základ může člověk kdykoli vznést námitku proti přímému marketingu včetně souvisejícího profilování; pak „již osobní údaje nesmějí být pro tyto účely zpracovávány“. U marketingu se neprovádí balanční test, na rozdíl od jiných námitek podle téhož článku. Pro tento nástroj je nejbezpečnějším výchozím postupem vztahovat obecnou námitku proti přímému marketingu na všechna marketingová použití údajů člověka: odesílací seznam, segmenty nástroje a reklamní publika. Odhlášení pro konkrétní kanál může mít užší rozsah, takže firma má s odpovědnou osobou pro soukromí určit pravidla preferencí a zajistit vhodné splnění každé žádosti.

Uniklý nebo nesprávně změněný seznam může představovat porušení zabezpečení osobních údajů. Článek 33 vyžaduje oznámit jej dozorovému úřadu (národnímu regulátorovi ochrany údajů) bez zbytečného odkladu a pokud možno do 72 hodin od zjištění, ledaže je nepravděpodobné, že by porušení vedlo k riziku pro lidi. Ve Spojeném království je obdobou UK GDPR, jehož dodržování vymáhá ICO.

Zákony o odesílání: ePrivacy a PECR, CAN-SPAM a CASL

Pravidla ePrivacy EU a britská PECR vyžadují předchozí souhlas s marketingovými e-maily fyzickým osobám, s úzkou výjimkou soft opt-in pro stávající zákazníky. Spojené království má také samostatný soft opt-in pro charitativní účely za určitých podmínek; článek se věnuje komerčnímu marketingu. Kanadský CASL vyžaduje výslovný nebo předpokládaný souhlas. Americký CAN-SPAM nevyžaduje souhlas s odesíláním; vyžaduje funkční odmítnutí splněné do 10 pracovních dnů a přesné údaje o odesílateli i poštovní adresu v každé zprávě.

Výjimka soft opt-in v článku 13 směrnice ePrivacy zahrnuje kontaktní údaje získané při prodeji a používané pro vlastní podobné produkty, s bezplatnou možností odmítnout při získání i v každé zprávě. Britskou verzí je pravidlo 22 PECR, vysvětlené v pokynech ICO pro e-mailový marketing. Článek 13 také zakazuje marketingové e-maily skrývající odesílatele nebo bez platné adresy pro žádosti o odmítnutí; pravidlo 23 PECR dělá totéž ve Spojeném království.

Částky CAN-SPAM pocházejí z průvodce FTC zákonem CAN-SPAM, který dodává, že adresy odhlášených osob se nesmějí prodávat ani předávat, s výjimkou firmy najaté k pomoci s dodržováním CAN-SPAM. Pravidla CASL jsou v oddílu 6 CASL a oddílu 11 a sankce v přehledu CASL od ISED.

Časté dotazy

Platí GDPR i pro nástroj newsletteru, který jsem si vytvořil sám?

Rozhoduje, kde firma působí a čí data nástroj uchovává, nikoli způsob jeho vytvoření. Podle článku 3 GDPR platí pro firmu usazenou v EU i pro firmu mimo EU, která nabízí zboží či služby lidem v EU nebo tam sleduje jejich chování. Zda do působnosti spadá konkrétní firma, je otázka pro jejího DPO.

Co se stane, když unikne náš API klíč Klaviyo?

Držitel klíče Full Access může měnit seznam; klíč Read-Only umožňuje pouze prohlížení. Vytvořte náhradu jen s rozsahy používanými nástrojem: Klaviyo neumožňuje později přidat rozsah k existujícímu klíči, takže je vyberte nyní. Uniklý klíč okamžitě odvolejte, přepněte nástroj na náhradu a prověřte neoprávněné exporty nebo změny seznamu. Pokud mohl být seznam přečten, berte to jako možné porušení GDPR.

Je hashovaný seznam e-mailů stále osobními údaji?

Podle GDPR ano, pokud jej lze spojit s člověkem. Bod 26 odůvodnění považuje pseudonymizované údaje, které „lze přiřadit fyzické osobě s použitím dodatečných informací“, za informace o identifikovatelné osobě. Podle mého výkladu funguje reklamní párování právě proto: platforma může vypočítat stejný hash z adresy, kterou už má.

Platí stejná pravidla pro marketingové e-maily B2B?

Ne všude. Podle FTC CAN-SPAM neobsahuje výjimku pro e-maily mezi firmami. E-mailové pravidlo PECR se vztahuje na fyzické osoby a ICO potvrzuje možnost posílat marketingové e-maily firmám. Pro země EU a Kanadu se obraťte na právníka.