„Ktoś z zespołu marketingowego chce stworzyć stronę. Nie jest inżynierem i prawdopodobnie ma niewielkie doświadczenie lub wiedzę o bezpieczeństwie albo nie ma ich wcale”, powiedział badacz bezpieczeństwa Joel Margolis magazynowi Wired. W tym samym materiale Wired opisuje, jak firma RedAccess znalazła ponad 5000 aplikacji stworzonych metodą vibe coding, praktycznie pozbawionych zabezpieczeń lub uwierzytelniania; około 40 procent z nich ujawniało wrażliwe dane. Wired nie potwierdził autentyczności analizowanych danych osobowych ani firmowych.
Aplikacje stworzone przez AI dla marketingu niosą szczególny wariant tego problemu. Narzędzia warte zbudowania (kreator segmentów, panel kampanii, analizator A/B, synchronizacja odbiorców) są połączone z listą subskrybentów, a często również z kontem reklamowym.
TL;DR
- Każdemu kluczowi API platformy e-mailowej i tokenowi konta reklamowego nadaj najwęższy dostęp potrzebny narzędziu i przechowuj je w kodzie serwerowym. Marketing API Mailchimp nie ma bardziej ograniczonego typu klucza, więc zadanie tylko do odczytu otrzymuje zamiast klucza ograniczony eksport zawierający wyłącznie niezbędne dane.
- Platforma e-mailowa pozostaje wiarygodnym źródłem statusu subskrypcji. Narzędzie nigdy ponownie nie zapisuje osób, które zrezygnowały, przekazuje platformie żądania wypisania i dodaje działający link rezygnacji do każdego samodzielnie wysłanego e-maila marketingowego.
- Przesłana zahaszowana lista niestandardowych odbiorców nadal jest danymi osobowymi: ustal wcześniej, co trafia do platform reklamowych i usług AI, i zadbaj, aby każda rezygnacja została uwzględniona w grupie odbiorców reklam.
- GDPR reguluje przechowywanie i wykorzystywanie listy: zgłaszanie naruszeń oraz bezwarunkowe prawo sprzeciwu wobec marketingu. ePrivacy/PECR, CAN-SPAM lub CASL regulują wysyłanie e-maili, także przez narzędzie wewnętrzne.
Błędy wdrożenia, które ujawniają dane subskrybentów lub naruszają warunki zgody
Narzędzie marketingowe stworzone przez AI zwykle popełnia jeden z dwóch błędów dotyczących listy: lista wydostaje się na zewnątrz przez klucz, publiczny link albo przesłanie danych lub jest wykorzystywana wobec osób, które odmówiły. Token reklamowy z uprawnieniami zarządzania dodaje odrębne ryzyko: wydatki na koncie reklamowym firmy.
| Błąd | Co ujawnia lub narusza | Jakie wymagania obejmuje |
|---|---|---|
| Klucz platformy e-mailowej z pełnym dostępem w kodzie, przeglądarce lub czacie narzędzia AI | Całą listę można odczytać i wyeksportować; można zmieniać subskrybentów; kampanie są wysyłane w imieniu firmy | Naruszenie ochrony danych osobowych tam, gdzie obowiązuje GDPR: zgłoszenie z art. 33; przepisy o wysyłce, jeśli wiadomości zostaną wysłane |
| Token konta reklamowego z prawem zarządzania lub osobisty token twórcy | Tworzenie lub zmienianie kampanii na rachunek reklamowy firmy; dane o wydatkach; przynależność do odbiorców według skrótu; dane formularzy kontaktowych z leads_retrieval. Nie przesłana lista | Warunki platformy reklamowej i rachunek reklamowy firmy; naruszenie, jeśli odczytano dane formularzy kontaktowych |
| Narzędzie dostępne pod publicznym linkiem, w którym każdy widzi wszystko | Wiersze subskrybentów, szczegóły zgód i historia zaangażowania dostępne każdemu, kto zna adres; wyniki kampanii i testów A/B widoczne dla osób z zewnątrz i niepotrzebujących ich pracowników | Naruszenie ochrony danych wierszy; utrata poufności wskaźników kampanii |
| Synchronizacja lub ponowny import zapisujący dane z powrotem na listę | Wypisane kontakty ponownie zapisane; utracone informacje, gdzie, kiedy i jak ludzie się zapisali | Prawo sprzeciwu GDPR i zasady rezygnacji CAN-SPAM oraz CASL przy następnej wysyłce; brak możliwości udowodnienia zgody, jeśli jest ona podstawą |
| Narzędzie samodzielnie wysyła e-maile marketingowe | Brak linku rezygnacji, adresu pocztowego nadawcy i sprawdzenia listy wykluczeń | Wymagania CAN-SPAM i CASL wobec wiadomości; zgoda na wysyłkę według ePrivacy/PECR |
| Przesyłanie odbiorców i wywołania AI domyślnie wysyłają listę na zewnątrz | Zahaszowane listy w Meta lub Google; pola subskrybentów w niezatwierdzonych usługach AI i analitycznych | GDPR: zahaszowane dane nadal są osobowe, a sprzeciw obejmuje grupę odbiorców; warunki Meta i Google dotyczące list klientów |
Narzędzie AI, które napisało aplikację, może na żądanie wprowadzić większość tych poprawek. Każde poniższe polecenie traktuj jako punkt wyjścia do dostosowania, a używane polecenia przechowuj w pliku reguł odczytywanym przez narzędzie AI podczas każdej sesji. Zgłoszenie przez AI, że wprowadzono zmianę, nie jest dowodem; dowodem jest krok Sprawdź: pod każdym poleceniem. Poproś o zaznaczanie niepewności zamiast zgadywania i nigdy nie wklejaj aktywnego klucza ani eksportu subskrybentów do czatu.
Zastąp klucz platformy e-mailowej z pełnym dostępem najbardziej ograniczonym
Kreator segmentów wyświetlający tylko liczebność nie potrzebuje klucza, który może eksportować listę lub wysyłać kampanię, choć na każdej platformie poniżej klucz o najszerszych prawach potrafi jedno i drugie. Liczy się też lokalizacja: kod przeglądarki potrzebuje samej wartości klucza do wywołania, więc może ją odczytać każdy, kto otworzy stronę. Mailchimp w ogóle nie obsługuje korzystania ze swojego API po stronie klienta.
| Platforma | Co może standardowy klucz | Najwęższa udokumentowana opcja |
|---|---|---|
| Mailchimp (Marketing API) | „Klucze API dają pełny dostęp do konta Mailchimp” | Brak na stronie pomocy |
| SendGrid | Full Access: większość punktów końcowych API konta, z wyjątkiem rozliczeń i Email Address Validation | Custom Access: wybrane punkty końcowe na wybranych poziomach, nigdy powyżej własnych uprawnień twórcy |
| Klaviyo | Klucz prywatny Full Access: tworzenie, usuwanie lub zmienianie wszystkiego w jego punktach końcowych | Klucz Read-Only lub klucz Custom z wybranymi zakresami |
| Mailgun | Klucze API konta: pełny dostęp do konta | Domain Sending Key: jedna domena, tylko wysyłka; rola Analyst tylko do odczytu w niektórych planach |
| Listmonk (v4.0.0 i nowsze) | To, na co pozwalają rola użytkownika i role list | Role odczytu lub zarządzania dla poszczególnych list, z osobno przyznawaną wysyłką |
Każdy wiersz opiera się na dokumentacji platformy: stronie pomocy Mailchimp o kluczach API, uprawnieniach kluczy API SendGrid, przewodniku uwierzytelniania Klaviyo i dokumentacji kluczy API Mailgun. Uprawnienia Listmonk opisano dalej w części o Listmonk.
Narzędzie otrzymuje klucz o najwęższych prawach dopuszczalnych dla zadania lub nie otrzymuje go wcale. W Mailchimp zadanie tylko do odczytu (raport lub liczebność segmentu) lepiej obsłużyć własnymi raportami platformy albo ograniczonym eksportem uruchamianym przez właściciela konta, zawierającym tylko niezbędne pola. Kosztem jest czas człowieka i aktualność danych tylko na moment eksportu; zadania zmian i wysyłki trafiają do IT lub pozostają w Mailchimp. Na innych platformach, np. ActiveCampaign lub Brevo, najpierw poszukaj ograniczonego klucza.
Klucz istnieje następnie wyłącznie w kodzie serwerowym (zapleczu narzędzia, którego przeglądarka nigdy nie pobiera) jako zmienna środowiskowa: wartość przekazywana aplikacji przez serwer przy uruchomieniu, poza kodem i repozytorium.
Znajdź w tym projekcie wszystkie klucze API, tokeny dostępu, hasła i sekrety dla naszej platformy e-mailowej (Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk lub innej) oraz każdej platformy reklamowej: Meta, Google Ads, LinkedIn lub innej. Sprawdź kod, pliki środowiska i historię repozytorium lokalnym skanerem sekretów lub metodą zatwierdzoną przez IT. Nigdy nie wysyłaj zewnętrznej usłudze AI niezamaskowanych sekretów, zawartości plików środowiska ani historii zawierającej dane uwierzytelniające. Przekaż AI tylko wyniki z zamaskowanymi sekretami, wraz z lokalizacją plików i typem znalezionych danych uwierzytelniających. Dla każdego podaj:
- plik i wiersz
- czy wartość jest zapisana w kodzie, czy odczytywana ze zmiennej środowiskowej
- czy korzystający z niej kod działa na serwerze, czy w przeglądarce
Pokazuj tylko pierwsze cztery znaki każdej wartości. Nigdy nie wyświetlaj pełnego klucza ani tokena.
Oznacz jako najwyższy priorytet każde dane uwierzytelniające pozwalające wysyłać e-maile, zmieniać subskrybentów lub zarządzać kontem reklamowym.
Następnie przenieś każde wywołanie wymagające prywatnego klucza API lub tokena dostępu do kodu serwerowego, który odczytuje dane uwierzytelniające ze zmiennej środowiskowej dostępnej wyłącznie na serwerze. W przeglądarce zachowaj tylko udokumentowane publiczne wywołania API po stronie klienta, usuń ujawnione klucze prywatne z kodu i wyklucz z repozytorium pliki z prawdziwymi sekretami. Dokładnie opisz zmiany i wskaż niepewne kwestie zamiast zgadywać.
Uwaga: usunięcie wklejonego klucza z czatu lub kodu nie cofa jego ujawnienia. Unieważnij go (wyłącz w ustawieniach platformy, aby przestał działać) i utwórz nowy.
Sprawdź: otwórz narzędzie, naciśnij F12, wybierz kartę Network i korzystaj z narzędzia tak jak zespół, sprawdzając domenę każdego żądania. Żądanie przeglądarki bezpośrednio wywołujące prywatne API platformy e-mailowej jest sygnałem ostrzegawczym, ale sam adres docelowy nie dowodzi ujawnienia sekretu. Sprawdź nagłówki żądań i kod pod kątem prywatnych danych uwierzytelniających, nie kopiując ich wartości do czatu AI. Publiczne żądania klienckiego SDK są inne: mogą prawidłowo używać publicznych identyfikatorów zamiast tajnych kluczy API. W Klaviyo żądania do a.klaviyo.com/client/ używają klucza publicznego i należą do przeglądarki, natomiast żądanie przeglądarki do a.klaviyo.com/api/ wymaga zbadania, bo ten punkt końcowy zwykle wymaga uwierzytelniania kluczem prywatnym. Potwierdź, czy faktycznie przesłano prywatne dane uwierzytelniające.
Resztą zajmuje się człowiek: utwórz ograniczony klucz z konta, które nie należy do jednej osoby (Mailchimp usuwa klucze API użytkownika po odebraniu mu dostępu); nazwij go według narzędzia, bo Mailchimp zaleca jeden klucz na integrację, i poproś IT o przechowanie go tam, gdzie przechowywane są klucze narzędzia. Przy planowej rotacji przełącz narzędzie na nowy klucz przed unieważnieniem starego, bo unieważnionego klucza Mailchimp nie można ponownie aktywować. Już skompromitowany klucz natychmiast unieważnij i zastąp. Zaplanuj też wygaśnięcie: klucze API Mailchimp utworzone 22 czerwca 2026 r. lub później wygasają po roku od utworzenia.
Nadaj tokenowi konta reklamowego tylko uprawnienia używane przez narzędzie
Token konta reklamowego traktuję jako dane uwierzytelniające o najpoważniejszych skutkach, jakie może mieć narzędzie marketingowe, bo jest powiązany z wydatkami. Token Meta z prawem zarządzania może tworzyć, zmieniać lub wstrzymywać kampanie obciążające konto reklamowe firmy oraz odczytywać wydatki i wyniki.
Taki token nie zwraca jednak listy subskrybentów przesłanej do niestandardowych odbiorców. Przewodnik Meta po Custom Audiences przy dodawaniu i usuwaniu osób korzysta z wartości zahaszowanych SHA-256: jednokierunkowego przekształcenia każdego adresu, porównywanego przez platformę z własnymi zapisami. Żaden udokumentowany punkt końcowy nie zwraca czytelnej listy z istniejącej grupy odbiorców.
| Co robi narzędzie | Potrzebne uprawnienie Meta | Do czego daje dostęp ujawniony token |
|---|---|---|
| Raportuje kampanie | ads_read | Dane raportowe Ads Insights dla widocznych mu kont reklamowych |
| Tworzy lub zmienia kampanie | ads_management | Kampanie i reklamy na tym koncie, obciążające jego rachunek; wydatki i wskaźniki |
| Synchronizuje segment z niestandardowymi odbiorcami | Dostęp do konta reklamowego na poziomie zarządzania | Dodawanie i usuwanie osób według skrótu; bez czytelnej listy |
| Pobiera zgłoszenia z reklam kontaktowych do listy | leads_retrieval: Meta wymienia ads_management wśród jego zależności | Wszystkie pola wypełnione w firmowych formularzach kontaktowych, w czytelnej postaci, dodatkowo do dostępu na poziomie zarządzania |
Dokumentacja uprawnień Meta opisuje każde uprawnienie i zaleca programistom wybieranie tylko tych, których potrzebuje aplikacja. Każde narzędzie otrzymuje własny token użytkownika systemowego (tak Meta określa konto w Business Manager używane przez oprogramowanie) przypisanego wyłącznie do konta reklamowego obsługiwanego przez narzędzie. Nie używaj w narzędziu osobistego tokena logowania twórcy, a token użytkownika systemowego przechowuj na serwerze, jak klucz e-mailowy; ten sam przegląd dotyczy dostępu do Google Ads lub LinkedIn.
Wymień wszystkie wywołania narzędzia do Marketing API Meta, Google Ads i innych platform reklamowych, także przez biblioteki pomocnicze lub SDK. Dla każdego podaj:
- plik i wiersz
- punkt końcowy lub metodę SDK
- etykietę: REPORT: odczytuje wskaźniki lub wydatki; MANAGE: tworzy lub zmienia kampanie, reklamy, budżety lub odbiorców; LEADS: odczytuje zgłoszenia z formularzy kontaktowych
- uprawnienie platformy wymagane przez tę etykietę
Zaznacz każdy token używany przez więcej niż jedno narzędzie i każdy kod wysyłający token do przeglądarki. Nie wyświetlaj wartości tokenów. Jeśli nie potrafisz określić etykiety wywołania, powiedz o tym.
Sprawdź: sprawdź token panelu w narzędziu debugowania tokenów Meta, które pokazuje jego uprawnienia, i porównaj je z etykietami polecenia. Token panelu raportowego powinien mieć ads_read i żadnych praw zarządzania kontem; etykieta MANAGE lub LEADS w narzędziu raportowym oznacza problem. Następnie w ustawieniach Business potwierdź, że narzędzie korzysta z tokena swojego użytkownika systemowego, a nie osobistego tokena twórcy.
Zamknij publiczny adres i pokazuj wiersze subskrybentów wyłącznie administratorom listy
Aplikację na hostingu narzędzia AI może otworzyć każdy, kto znajdzie jej adres. Jak podaje Wired, część aplikacji badanych przez RedAccess miała tylko banalne bariery, np. wymóg zalogowania się dowolnym adresem e-mail. Taki hosting nadaje się do demonstracji na fikcyjnych adresach; to zadanie, do którego służą darmowy hosting i tunele.
Druga część to zakres widoczny każdej osobie po wejściu. Panel kampanii ma pokazywać wskaźniki na poziomie kampanii: współczynnik otwarć, współczynnik kliknięć, wyniki A/B i wielkości segmentów. Stojące za nimi wiersze subskrybentów (każdy adres ze szczegółami zgody i historią zaangażowania) są danymi osobowymi.
Prawidłowo zanonimizowane dane zbiorcze zwykle nie są danymi osobowymi, ale małe segmenty lub szczegółowe podziały nadal mogą umożliwić identyfikację osób. Nawet anonimowe wskaźniki mogą ujawnić informacje konkurencyjne firmy, a analizator A/B przechowujący otwarcia i kliknięcia poszczególnych osób także zawiera dane osobowe. Zespół widzi agregaty; wiersze widzą tylko osoby zarządzające listą, a serwer wymusza to przy każdym żądaniu.
Wymień każde pole bazy danych, ekranów, eksportów i odpowiedzi API tej aplikacji zawierające dane osobowe subskrybentów: adres e-mail, imię i nazwisko, telefon, adres pocztowy, adres IP, lokalizację, status subskrypcji, źródło i czas zgody, datę zapisu, status wypisania oraz otwarcia i kliknięcia każdej osoby. Dla każdego pola wskaż ekrany i eksporty, które je pokazują. Zaznacz niepewne kwestie zamiast zgadywać.
Następnie dodaj dwie role pobierane z zalogowanego konta i sprawdzane na serwerze dla każdej strony, eksportu i trasy API:
- administrator listy: widzi wiersze subskrybentów i wykonuje eksporty
- marketer: widzi wyłącznie wskaźniki kampanii, liczebności segmentów i wyniki A/B, bez wierszy poszczególnych osób i bez eksportów
Każdy inny dostęp odrzucaj odpowiedzią „odmowa dostępu” (403). Wskaż, jaka kontrola chroni każdą stronę i trasę.
To, czy zapisane dane są szyfrowane na dysku, jest pytaniem do IT; narzędzie AI nie potwierdzi tego na podstawie kodu.
Sprawdź: utwórz konto testowe z rolą marketera. Po zalogowaniu otwórz panel kampanii (powinien się załadować), a następnie stronę listy subskrybentów i eksport: oba powinny zatrzymać się na „odmowie dostępu”. Potem, bez logowania, otwórz adres narzędzia na telefonie przez sieć komórkową: nic się nie ładuje lub pojawia się strona logowania firmowego.
Pozostaw wypisania i zapisy zgód platformie e-mailowej

Narzędzie przechowujące własną kopię listy i zapisujące ją z powrotem przez dwukierunkową synchronizację lub ponowny import eksportu z ubiegłego miesiąca może oznaczyć wypisaną osobę jako ponownie zapisaną i usunąć zapis tego, gdzie, kiedy i jak każda osoba się zapisała. Zwykle nie widać tego w narzędziu, dopóki osoba nie otrzyma kolejnej kampanii, kiedy zastosowanie mają poniższe przepisy o wysyłce. Zapobiegają temu cztery zasady:
- Platforma e-mailowa jest wiarygodnym źródłem statusu subskrypcji. Narzędzie odczytuje ten status i nigdy ponownie nie zapisuje ani nie nadpisuje istniejącego subskrybenta. Może przekazać wyraźne żądanie wypisania przez przeznaczony do tego proces platformy.
- Żaden import masowy ani synchronizacja nie zastępuje istniejących rekordów subskrybentów ani nie nadpisuje ich informacji o subskrypcji i zgodzie. Sprawdzone narzędzie może aktualizować wyraźnie zatwierdzone pola, np. tagi, bez zmiany statusu subskrypcji. Nowe zapisy trafiają przez formularz zapisu lub ścieżkę importu platformy, więc działa jej obsługa zgód; własny formularz narzędzia po przeglądzie może dodawać nowych subskrybentów ze źródłem, czasem i formularzem, ale nigdy ponownie nie zapisuje istniejącego kontaktu ani nie nadpisuje jego informacji o subskrypcji lub zgodzie.
- Przy każdej wysyłce lub eksporcie narzędzie odczytuje status z platformy w danej chwili, a nie z własnej kopii. Eksporty pomijają wypisane i wykluczone kontakty albo oznaczają je jako listę „nie wysyłać”, której nigdy nie używa się do wysyłki.
- Pola zgody (źródło, czas, formularz lub metoda) pozostają nienaruszone w każdym kopiowanym rekordzie albo narzędzie ich nie kopiuje i nie twierdzi, że je posiada.
Wymień wszystkie miejsca, w których narzędzie zapisuje do platformy e-mailowej lub dowolnej kopii listy subskrybentów: wywołania API tworzące lub aktualizujące subskrybentów, importy, synchronizacje i eksporty plików. Dla każdego określ, czy może:
- zmienić status subskrypcji istniejącego subskrybenta
- nadpisać istniejące rekordy subskrybentów
- uwzględnić wypisane lub wykluczone kontakty
Dla każdej ścieżki wysyłającej e-maile lub eksportującej listę do wysyłki określ źródło statusu subskrypcji: platforma e-mailowa w tej chwili czy własna kopia narzędzia.
Następnie zmień narzędzie tak, aby nigdy ponownie nie zapisywało istniejącego kontaktu ani nie nadpisywało jego statusu subskrypcji, z wyjątkiem przekazania wyraźnego żądania wypisania przez przeznaczony proces platformy; nigdy nie zastępowało istniejących rekordów subskrybentów w całości; odczytywało status z platformy bezpośrednio przed każdą wysyłką lub eksportem i zachowywało źródło, czas i formularz zgody w każdym kopiowanym rekordzie. Opisz zmiany i zaznacz niepewne kwestie.
Uwaga: stary eksport ponownie zaimportowany na listę wnosi dawne statusy, więc osoby wypisane po jego wykonaniu mogą wrócić jako zapisane, zależnie od obsługi importu przez platformę i narzędzie.
Sprawdź: dodaj testowego subskrybenta na platformie e-mailowej, a potem go tam wypisz. Uruchom synchronizację, kreator segmentów i eksport narzędzia. Na platformie testowy subskrybent nadal jest wypisany; w eksporcie narzędzia nie występuje lub ma oznaczenie „nie wysyłać”; nie pojawia się na żadnej liście wysyłkowej utworzonej przez narzędzie.
Wysyłaj przez platformę e-mailową lub najpierw zbuduj mechanizm wypisania
Narzędzie ponownego angażowania, które wysyła bezpośrednio do listy przez konto SMTP lub API poczty transakcyjnej, nie otrzymuje dodatków platformy do e-maili marketingowych (linku rezygnacji, adresu pocztowego i sprawdzenia wykluczeń), chyba że kod doda każdy z nich. Rozwiązaniem jest wysyłka przez platformę lub Listmonk, a w narzędziu tworzenie segmentu lub uruchamianie kampanii platformy. Narzędzie wymagające samodzielnej wysyłki jest narzędziem wysyłkowym, które kolejna część kieruje do IT.
Takie narzędzie potrzebuje w każdej wiadomości marketingowej linku rezygnacji działającego także po wysłaniu oraz tożsamości i adresu pocztowego nadawcy w stopce, zgodnie z terminami w poniższej tabeli przepisów. Potrzebuje też własnej listy wykluczeń sprawdzanej przed każdą wysyłką i utrzymywanej jako trwały zapis zakazów, z kopiami zapasowymi i procedurami odtwarzania zapobiegającymi nadpisaniu nowszych rezygnacji przez starszą bazę subskrybentów. CAN-SPAM inaczej traktuje wiadomości transakcyjne.
Przy dużej liczbie wysyłek link w stopce może nie wystarczyć. Gmail wymaga od nadawców wysyłających co najmniej 5000 wiadomości dziennie na osobiste konta Gmail obsługi rezygnacji jednym kliknięciem zgodnie z RFC 8058 dla wiadomości marketingowych i subskrybowanych. Oznacza to dodanie nagłówków List-Unsubscribe i List-Unsubscribe-Post obok widocznego linku rezygnacji. Punkt końcowy rezygnacji jednym kliknięciem musi przetwarzać żądanie POST; samo otwarcie URL żądaniem GET nie powinno nikogo wypisywać. Przed wysyłką na taką skalę poproś IT o sprawdzenie tych wymagań.
Dodaj link rezygnacji do każdej wiadomości marketingowej wysyłanej przez narzędzie oraz obsługujący go punkt końcowy wypisania.
Jeśli narzędzie podlega wymaganiom Gmail dla masowych nadawców, wdroż również nagłówki rezygnacji jednym kliknięciem RFC 8058 objęte prawidłowym podpisem DKIM i punkt końcowy oparty na POST. Nigdy nie uruchamiaj wypisania tylko dlatego, że otwarto URL. Zaznacz niepewne kwestie do przeglądu IT.
Kiedy punkt końcowy wypisania otrzyma prawidłowe żądanie (kliknięcie linku, przesłanie formularza lub wywołanie API):
- natychmiast dodaj adres do listy wykluczeń przechowywanej osobno od tabel subskrybentów
- zapisz czas i kanał nadejścia żądania
- jeśli lista jest przechowywana na naszej platformie e-mailowej, poleć jej również wypisanie adresu
Sprawdzaj listę wykluczeń przed każdą wysyłką i pomijaj każdy pasujący adres. Nigdy automatycznie nie usuwaj adresu z listy wykluczeń podczas importu, synchronizacji lub odtwarzania bazy. Zachowuj tylko minimalne informacje potrzebne do respektowania rezygnacji, zgodnie z zatwierdzoną polityką retencji firmy, i nigdy nie pozwalaj importowi lub synchronizacji ponownie dodać wykluczonego adresu. Dopilnuj, aby kopie zapasowe zawierały listę wykluczeń, a odtwarzanie tabel subskrybentów jej nie zmieniało. Dodaj nazwę i adres pocztowy naszego nadawcy do stopki każdej wiadomości marketingowej, używając pól zastępczych, które wypełnię. Opisz zmiany i objęte nimi wysyłki.
Sprawdź: dodaj kontrolowany przez siebie adres testowy do listy testowej, wyślij kampanię testową przez narzędzie i kliknij link rezygnacji w otrzymanej na ten adres wiadomości. Adres znajduje się teraz na liście wykluczeń i jest wypisany na platformie e-mailowej, jeśli to ona przechowuje listę. Wyślij ponownie do tej samej listy: adres testowy nic nie otrzymuje.
Osoba odpowiedzialna za zgodność firmowej poczty z przepisami dostarcza nazwę i adres pocztowy nadawcy do tych pól zastępczych.
Ustal wcześniej, co trafia do platform reklamowych i narzędzi AI
Dwie ścieżki kodu domyślnie wysyłają dane subskrybentów na zewnątrz: synchronizacja przesyłająca segment do niestandardowych odbiorców Meta lub Google oraz wywołania przekazujące pola subskrybentów API AI do pisania tematów lub oceny leadów bądź skryptom analitycznym i webhookom.
Meta i Google mogą dopasowywać odbiorców klientów przy użyciu identyfikatorów kontaktowych zahaszowanych SHA-256. Data Manager API Google wymaga normalizacji i haszowania adresów e-mail oraz telefonów przed przesłaniem, podczas gdy niektóre operacje w interfejsie Google Ads mogą wykonać haszowanie w trakcie przesyłania. Haszowanie pozwala platformie dopasować adres do profilu; nie czyni osoby anonimową; zobacz FAQ.
W nowych integracjach Google Customer Match sprawdź obsługiwany interfejs przesyłania API przed budowaniem synchronizacji. Od 1 kwietnia 2026 r. Google ogranicza starsze metody przesyłania Customer Match dla nowych użytkowników i kieruje te integracje do Data Manager API.
Warunki Meta dotyczące odbiorców z list klientów wymagają od reklamodawcy zapewnienia niezbędnych praw, pozwoleń i podstawy prawnej udostępniania danych. Zasady Google Customer Match wymagają ujawnienia udostępniania w polityce prywatności i uzyskania zgody tam, gdzie wymaga jej prawo.
Dla uproszczenia narzędzie traktuje każde wypisanie również jako żądanie zaprzestania dopasowania reklamowego. Jest to ostrożna polityka firmy, a nie twierdzenie, że każda rezygnacja z e-maili w konkretnym kanale prawnie wymaga usunięcia ze wszystkich grup odbiorców reklam.
Ścieżka przesyłania powinna więc pobierać wyłącznie segment zatwierdzony przez firmę do dopasowania reklamowego; firma musi ustalić odpowiednią podstawę prawną pod kierunkiem osoby odpowiedzialnej za prywatność lub wyznaczonego inspektora ochrony danych (DPO), jeśli został powołany. Wypisane i wykluczone kontakty nie trafiają do żadnej operacji przesyłania, a wypisanie uruchamia usunięcie według skrótu z każdej grupy odbiorców; część o GDPR poniżej wyjaśnia dlaczego.
Każda usługa AI lub analityczna otrzymująca dane subskrybentów musi być zatwierdzona przez firmę. Przed udostępnieniem danych osobowych potwierdź, czy dostawca działa jako podmiot przetwarzający czy niezależny administrator, i zapewnij odpowiednie zabezpieczenia umowne, w tym umowę powierzenia przetwarzania danych, gdy jest wymagana.
Przeprowadź audyt wszystkich wywołań wychodzących narzędzia: platform e-mailowych, reklamowych (w tym przesyłania odbiorców), API AI, np. OpenAI, Anthropic lub innych, narzędzi analitycznych i webhooków. Dla każdego dokładnie wymień pola subskrybentów w treści żądania lub URL. Wskaż wywołania, które mogą wykonać zadanie z mniejszą liczbą pól lub bez danych subskrybentów. Na koniec wymień nazwy wszystkich zewnętrznych usług do porównania z zatwierdzonymi dostawcami.
Sprawdź: każde pole subskrybenta wymienione w raporcie dla usługi AI lub analitycznej powinno być niezbędne do zadania, a każda usługa powinna figurować na zatwierdzonej liście firmy; pozostałe trafiają do osoby podpisującej umowy z dostawcami.
Dla każdej ścieżki narzędzia przesyłającej kontakty do Meta, Google Ads lub innej platformy reklamowej:
- przed przesłaniem haszuj adresy e-mail i telefony algorytmem SHA-256 na serwerze, zgodnie z regułami normalizacji każdej platformy
- przesyłaj tylko kontakty z [segmentu zatwierdzonego przez firmę do dopasowania reklamowego]
- wykluczaj wypisane i wykluczone kontakty w chwili przesyłania
- po wypisaniu kontaktu wysyłaj żądanie usunięcia jego skrótu do każdej grupy odbiorców, do której go przesłano
- rejestruj każde przesłanie i usunięcie z czasem, grupą odbiorców, liczbą kontaktów oraz użytkownikiem lub zadaniem, które je wywołało
Opisz zmiany i zaznacz niepewne kwestie.
Sprawdź: wypisz kontakt testowy należący do przesłanego segmentu. Po następnej synchronizacji narzędzia sprawdź, czy wysłano żądanie usunięcia do każdej właściwej grupy odbiorców. Potwierdź, że każda platforma reklamowa pomyślnie przetworzyła usunięcie, a nie tylko że narzędzie je zapisało lub przesłało. Oznacz nieudane lub częściowo wykonane usunięcia do ponowienia i przeglądu IT.
To, co narzędzie robi z listą, określa miejsce jego działania

Narzędzie pokazujące wyłącznie wskaźniki kampanii działa na serwerze kontrolowanym przez zespół, dostępnym tylko w sieci prywatnej; narzędzie z wierszami subskrybentów dodaje firmowe logowanie, bo od niego zależą role. Narzędzie wysyłające e-maile marketingowe lub synchronizujące odbiorców reklam pozostaje w funkcjach platform albo trafia do IT, zanim ktokolwiek go użyje.
| Co narzędzie robi z listą | Jaki klucz lub dostęp otrzymuje | Miejsce działania |
|---|---|---|
| Pracuje wyłącznie na subskrybentach testowych | Bez klucza produkcyjnego; lista testowa lub konto sandbox | Hosting narzędzia AI, tylko do tworzenia i demonstracji |
| Pokazuje wyłącznie wskaźniki kampanii | Klucz tylko do odczytu lub raportowania: ads_read w Meta, Read-Only Klaviyo, ograniczony Custom Access SendGrid; w Mailchimp eksport | Serwer zespołu tylko w prywatnej sieci Tailscale lub WireGuard |
| Odczytuje wiersze subskrybentów lub tworzy z nich segmenty | Klucz z prawem odczytu ograniczony do niezbędnych danych i punktów końcowych, z ograniczeniami dla poszczególnych list tam, gdzie platforma je obsługuje | Ten sam serwer z firmowym logowaniem i rolami administratora listy oraz marketera |
| Zmienia listę: tagi, pola niestandardowe, formularz dodający subskrybentów | Klucz z prawem zapisu ograniczony do niezbędnych czynności i odpowiednich list, gdzie jest to obsługiwane | Ten sam serwer po przeglądzie audytów danych uwierzytelniających, statusów i wypisań przez drugą osobę; publiczny formularz zapisu jest otwarty na internet, więc chronią go ten przegląd i klucz przechowywany na serwerze |
| Wysyła e-maile marketingowe lub synchronizuje odbiorców reklam | Klucz wysyłkowy lub token na poziomie zarządzania | Własne kampanie i automatyzacje platformy e-mailowej, Listmonk lub IT przed uruchomieniem; synchronizacje odbiorców wymagają też przeglądu zatwierdzonego segmentu pod kątem prywatności |
Zatwierdzenie zależy od wiersza: dwie pozycje tylko do odczytu wymagają wydania klucza przez administratora platformy e-mailowej, zmiana listy wymaga drugiej osoby sprawdzającej, a wysyłka wymaga IT oraz przeglądu prywatności dla przesyłania odbiorców.
Sieć prywatna oznacza, że narzędzie w ogóle nie odpowiada z zewnątrz. Strona logowania napisana przez AI jest osiągalna dla każdego i bezpieczna tylko na tyle, na ile bezpieczny jest jej kod; dlatego RedAccess mogła znaleźć aplikacje akceptujące dowolny adres e-mail przy logowaniu.
Moja zasada: zacznij od sieci prywatnej i dodawaj do niej firmowe logowanie wszędzie, gdzie wymagają go role. Sprawdzi się też zarządzana platforma wdrożeniowa z wbudowanym logowaniem i magazynem sekretów, jeśli zespół już za nią płaci i sprawdza dostawców.
Część serwerową należy przekazać IT, z jedną wyznaczoną osobą odpowiedzialną za serwer i klucze. Narzędzie działa na VPS (wynajętym serwerze w pełni kontrolowanym przez zespół) pod narzędziem wdrożeniowym takim jak Coolify lub Dokploy, które uruchamia aplikację z jej kodu i przechowuje zmienne środowiskowe, w tym klucze platform.
Sieć prywatną zapewnia Tailscale, szybszy w konfiguracji, lecz zależny od własnej usługi koordynacyjnej, którą może zastąpić Headscale, albo w pełni samodzielnie hostowany WireGuard. Firmowe logowanie (jednokrotne logowanie kontem firmy) zapewniają Authentik lub Keycloak, a odwrotny serwer proxy Caddy lub Nginx Proxy Manager dodaje HTTPS tam, gdzie narzędzie jest dostępne z internetu.
Przeniesienie silnika e-mail do Listmonk
Druga ścieżka zamiast ograniczonych kluczy na obecnej platformie usuwa klucz platformy komercyjnej, przenosząc listę i wysyłkę do samodzielnie hostowanego menedżera list. Listmonk w wersji v4.0.0 i nowszych pozwala każdemu narzędziu mieć własnego użytkownika API z rolą ograniczoną do list, na których pracuje.
Narzędzie tylko do odczytu otrzymuje podgląd swoich list bez wysyłki; campaigns:send i tx:send dla wiadomości transakcyjnych trafiają tylko do narzędzia wysyłkowego. Trzy szczególnie ryzykowne uprawnienia nie powinny występować w rolach narzędzi ograniczonych: lists:get_all i lists:manage_all, które omijają role poszczególnych list, oraz subscribers:sql_query, które według dokumentacji ról i uprawnień Listmonk pozwala „odpytywać wszystkie listy i subskrybentów bezpośrednio z bazy danych, z pominięciem indywidualnych uprawnień list i subskrybentów”. Sprawdź też szerokie uprawnienia subscribers:get_all, campaigns:get_all i campaigns:manage_all, zanim uznasz narzędzie za ograniczone do list. Każdemu użytkownikowi API nadaj tylko prawa niezbędne do zadania. Listmonk służy kampaniom, a nie wieloetapowej automatyzacji (kiedy Listmonk nie jest właściwym narzędziem); taką automatyzację na tym samym rodzaju serwera zapewnia Mautic.
Kosztem jest stała praca: zespół odpowiada za uwierzytelnianie domeny nadawczej (SPF, DKIM i DMARC), przekaźnik SMTP dostarczający pocztę, aktualizacje, kopie zapasowe i dostarczalność. Gdy lista jest mała, nikt nie może odpowiadać za serwer albo reputacja wysyłkowa i automatyzacje obecnej platformy wykonują pracę, na której polega zespół, lepiej pozostać na platformie z ograniczonymi kluczami.
Obie ścieżki wymagają serwera, za który ktoś odpowiada, z narzędziem wdrożeniowym i siecią prywatną, a przy samodzielnym hostingu również z Listmonk i przekaźnikiem SMTP. Nasz Linux VPS daje dostęp root, a Listmonk, Mautic, Tailscale, WireGuard i Authentik wdrażają się jako aplikacje jednym kliknięciem. IT poświęca więc czas konfiguracji i przeglądowi zamiast instalacji; dbanie o aktualizacje nadal należy do zespołu.
Lokalizacje obejmują Frankfurt i Amsterdam w UE, Londyn w Wielkiej Brytanii oraz kilka miast USA; wybór określa, gdzie znajdują się narzędzie i każda kopia listy, a w Listmonk sama lista. Lokalizacja jest informacją do rozmowy z DPO, nie jej zamiennikiem, i sama nie zapewnia zgodności narzędzia z przepisami.
Zgoda i przepisy antyspamowe dla marketingu e-mailowego
GDPR a lista subskrybentów
GDPR nie wymaga zgody jako podstawy przetwarzania w marketingu bezpośrednim: motyw 47 mówi, że takie przetwarzanie „można uznać za działanie wykonywane w prawnie uzasadnionym interesie”. Gdy marketing opiera się na zgodzie, art. 7 wymaga, aby firma „była w stanie wykazać”, że każda osoba wyraziła zgodę, a jej wycofanie było równie łatwe jak udzielenie. Temu służą źródło i czas zgody na platformie e-mailowej.
Surowsza zasada znajduje się w art. 21 GDPR. Niezależnie od podstawy osoba może w każdej chwili sprzeciwić się marketingowi bezpośredniemu, w tym związanemu z nim profilowaniu, a wtedy „danych osobowych nie wolno już przetwarzać do takich celów”. Dla marketingu nie przeprowadza się testu równowagi, inaczej niż przy innych sprzeciwach z tego artykułu. Dla tego narzędzia najbezpieczniej domyślnie objąć ogólnym sprzeciwem wobec marketingu bezpośredniego wszystkie marketingowe zastosowania danych osoby: listę wysyłkową, segmenty narzędzia i odbiorców reklam. Rezygnacja dotycząca jednego kanału może mieć węższy zakres, więc firma powinna ustalić reguły preferencji z osobą odpowiedzialną za prywatność i dopilnować właściwej realizacji każdego żądania.
Wyciek lub błędna zmiana listy może być naruszeniem ochrony danych osobowych. Art. 33 wymaga powiadomienia organu nadzorczego (krajowego regulatora ochrony danych) bez zbędnej zwłoki i, w miarę możliwości, w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, aby skutkowało ryzykiem dla osób. W Wielkiej Brytanii odpowiednikiem jest UK GDPR egzekwowany przez ICO.
Przepisy o wysyłce: ePrivacy i PECR, CAN-SPAM i CASL
Unijne przepisy ePrivacy i brytyjskie PECR wymagają uprzedniej zgody na e-maile marketingowe do osób fizycznych, z wąskim wyjątkiem soft opt-in dla obecnych klientów. Wielka Brytania ma też osobny wyjątek soft opt-in dla celów charytatywnych pod określonymi warunkami; artykuł skupia się na marketingu komercyjnym. Kanadyjski CASL wymaga zgody wyraźnej lub dorozumianej. Amerykański CAN-SPAM nie wymaga zgody na wysyłkę; wymaga działającej rezygnacji realizowanej w ciągu 10 dni roboczych oraz dokładnych danych nadawcy i adresu pocztowego w każdej wiadomości.
| Prawo | Zgoda na wysyłkę | Każda wiadomość marketingowa musi | Termin realizacji rezygnacji | Maksymalna kara |
|---|---|---|---|---|
| ePrivacy (UE) i PECR (Wielka Brytania) | Uprzednia zgoda na e-maile do osób fizycznych; soft opt-in klientów; osobny brytyjski wyjątek charytatywny podlega określonym warunkom | Nie ukrywać nadawcy; podawać ważny adres do żądań rezygnacji; przy soft opt-in zapewniać bezpłatną, łatwą odmowę w każdej wiadomości | Brak stałego terminu w tekście | Nie podano tutaj kwoty |
| CAN-SPAM (USA) | Niewymagana; obejmuje wszystkie komercyjne e-maile, w tym B2B | Dokładne nagłówki i dane „Od”, niewprowadzający w błąd temat, oznaczenie reklamy, chyba że odbiorca wcześniej wyraźnie się zgodził, ważny fizyczny adres pocztowy i działająca rezygnacja | 10 dni roboczych; mechanizm rezygnacji musi działać co najmniej 30 dni po wysłaniu | Do 53 088 USD za e-mail; sankcje karne tylko za określone praktyki z okolicznościami obciążającymi |
| CASL (Kanada) | Zgoda wyraźna lub dorozumiana | Identyfikować nadawcę i każdego, w czyim imieniu wysłano wiadomość; dane kontaktowe i mechanizm rezygnacji muszą działać co najmniej 60 dni | Bez zwłoki, nie później niż w ciągu 10 dni roboczych | Do 1 mln CAD dla osób fizycznych i 10 mln CAD dla firm za najpoważniejsze naruszenia |
Wyjątek soft opt-in w art. 13 dyrektywy ePrivacy obejmuje dane kontaktowe uzyskane przy sprzedaży, używane do własnych podobnych produktów, z bezpłatną możliwością odmowy przy zbieraniu i w każdej wiadomości. Wersją brytyjską jest przepis 22 PECR, opisany w wytycznych ICO dotyczących marketingu e-mailowego. Art. 13 zakazuje też e-maili marketingowych ukrywających nadawcę lub bez ważnego adresu do żądań rezygnacji; przepis 23 PECR robi to samo w Wielkiej Brytanii.
Kwoty CAN-SPAM pochodzą z przewodnika FTC po CAN-SPAM, który dodaje, że adresów osób rezygnujących nie wolno sprzedawać ani przekazywać, z wyjątkiem firmy zatrudnionej do pomocy w przestrzeganiu CAN-SPAM. Zasady CASL zawierają sekcja 6 CASL i sekcja 11, a kary podaje przegląd CASL opracowany przez ISED.
Często zadawane pytania
Czy GDPR dotyczy narzędzia newsletterowego, które zbudowałem samodzielnie?
Odpowiedź zależy od miejsca działalności firmy i tego, czyje dane przechowuje narzędzie, nie od sposobu jego zbudowania. Zgodnie z art. 3 GDPR dotyczy firmy ustanowionej w UE oraz firmy spoza UE, która oferuje towary lub usługi osobom w UE albo monitoruje ich zachowanie na tym obszarze. Zakres zastosowania do konkretnej firmy powinien ustalić jej DPO.
Co się stanie, jeśli wycieknie nasz klucz API Klaviyo?
Posiadacz klucza Full Access może zmieniać listę; Read-Only pozwala tylko ją przeglądać. Utwórz zamiennik wyłącznie z zakresami używanymi przez narzędzie: Klaviyo nie pozwala później dodać zakresu do istniejącego klucza, więc wybierz je teraz. Natychmiast unieważnij ujawniony klucz, przełącz narzędzie na zamiennik i sprawdź nieautoryzowane eksporty lub zmiany listy. Jeśli lista mogła zostać odczytana, traktuj to jako możliwe naruszenie GDPR.
Czy zahaszowana lista e-mailowa nadal jest danymi osobowymi?
Według GDPR tak, jeśli można ją powiązać z osobą. Motyw 26 uznaje spseudonimizowane dane, które „można przypisać osobie fizycznej przy użyciu dodatkowych informacji”, za informacje o możliwej do zidentyfikowania osobie. Według mojego odczytania dopasowanie reklamowe działa właśnie z tego powodu: platforma może obliczyć ten sam skrót z adresu, który już posiada.
Czy e-maile marketingowe B2B podlegają tym samym zasadom?
Nie wszędzie. Jak podaje FTC, CAN-SPAM nie przewiduje wyjątku dla e-maili między firmami. Zasada e-mailowa PECR obejmuje osoby fizyczne, a ICO potwierdza możliwość wysyłania e-maili marketingowych do firm. W przypadku państw UE i Kanady zapytaj prawnika.
Dyskusja
Komentarze
Zaloguj się, aby dołączyć do dyskusji.