SugarAI a RODO: retencja danych, prawo do bycia zapomnianym i zgody marketingowe w praktyce

SugarAI (dawniej SugarCRM) ma natywne narzędzia do trzech obowiązków RODO: moduł Data Privacy do rejestrowania żądań i zgód, trwałe usuwanie pól z danymi osobowymi oraz Data Archiver do egzekwowania okresów retencji. System nie ustala jednak, jak długo przechowywać dane ani na jakiej podstawie wysyłać marketing. Te decyzje podejmuje administrator danych, a SugarAI i Mautic pozwalają je konsekwentnie wykonać.

W skrócie: włączcie moduł Data Privacy, oznaczcie pola z danymi osobowymi w Studio i przypiszcie rolę Data Privacy Manager. Okresy retencji wynikają z przepisów szczególnych i celu przetwarzania, a nie z samego RODO. Zgody marketingowe od listopada 2024 r. zbiera się osobno dla każdego kanału, a ich wycofanie musi trafiać z SugarAI do Mautic i z powrotem.

Czy SugarAI spełnia wymogi RODO?

SugarAI dostarcza funkcje, które pozwalają spełnić wymogi RODO, ale sam system nie „jest zgodny” z rozporządzeniem. Zgodność zapewnia administrator danych przez procesy i konfigurację. Funkcje ochrony danych pojawiły się w wersji 8.0 (wiosna 2018 r.) i są dostępne we wszystkich edycjach SugarAI, zarówno on-premise, jak i w chmurze (SugarCRM, 2018). Obejmują rejestr żądań osób, których dane dotyczą, rejestr zgód, trwałe usuwanie danych osobowych i audyt zmian.

Granica odpowiedzialności SugarAI przebiega tam, gdzie kończy się baza CRM. Moduł Data Privacy usuwa dane z rekordów SugarAI, ale nie z kopii zapasowych, eksportów do Excela, skrzynek pocztowych handlowców ani z Mautic. Każdy z tych obszarów wymaga osobnej procedury w polityce ochrony danych. Dlatego wdrożenie RODO w SugarAI zaczynamy od mapy przepływu danych, a nie od konfiguracji modułu.

Jak skonfigurować moduł Data Privacy w SugarAI?

Moduł Data Privacy w SugarAI jest domyślnie ukryty, więc konfigurację zaczyna administrator systemu. Pełne przygotowanie obejmuje pięć kroków, a ich kolejność ma znaczenie: pola z danymi osobowymi można oznaczyć dopiero w module, który ma włączony audyt.

1. Włączenie modułu. Administrator udostępnia moduł Data Privacy w ustawieniach Admin > Navigation Bar and Subpanels.
2. Włączenie audytu. W Studio włączamy audyt w każdym module, który przechowuje dane osobowe, także w modułach niestandardowych.
3. Oznaczenie pól jako dane osobowe. SugarAI ma domyślnie oznaczone wybrane pola w Leads, Targets, Accounts i Contacts. Pola dodane przy wdrożeniu, np. prywatny numer telefonu lub data urodzenia, trzeba oznaczyć ręcznie.
4. Przypisanie roli Data Privacy Manager. Rola jest dostępna od razu po instalacji. Jej członkowie domyślnie mają uprawnienia administratora modułów Leads, Contacts i Targets.
5. Dodanie pól zgód i powiązań. Pola zgód dodajemy do layoutów rekordów Leads, Contacts i Targets. Jeśli dane osobowe są w modułach niestandardowych, wiążemy z nimi moduł Data Privacy i rozszerzamy uprawnienia roli DPM.

Krok 3 jest najczęściej pomijany, a ma bezpośredni wpływ na skuteczność usuwania. Erasure w SugarAI usuwa wyłącznie wartości pól oznaczonych jako dane osobowe. Jeśli handlowcy zapisują prywatne numery telefonów w polu „Uwagi”, które nie zostało oznaczone, żądanie usunięcia zostanie formalnie zrealizowane, a dane zostaną w bazie. Przed uruchomieniem modułu warto przejrzeć wszystkie pola tekstowe pod kątem tego, co faktycznie się w nich znajduje.

Jak ustalić okresy retencji danych w CRM?

Okres retencji danych w CRM wyznaczają cel przetwarzania i przepisy szczególne, a nie samo RODO. Rozporządzenie formułuje zasadę ograniczenia przechowywania (art. 5 ust. 1 lit. e): dane przechowujemy nie dłużej, niż jest to niezbędne do celu, w którym je zebrano. Konkretne okresy wynikają z innych ustaw, np. Kodeksu cywilnego i ustawy o rachunkowości, albo z decyzji administratora udokumentowanej w polityce retencji.

W SugarAI okresy retencji egzekwuje Data Archiver, dostępny w Admin > Archive Records. Administrator tworzy zadanie dla wybranego modułu z filtrem, np. leady o statusie „Nie zainteresowany” bez aktywności od 24 miesięcy, i wybiera typ procesu: Archive (przeniesienie do ukrytej tabeli) albo Hard Delete (trwałe usunięcie). Zadania uruchamia scheduler Run Active Data Archives/Deletions. Jeden przebieg obejmuje maksymalnie 10 000 rekordów (SugarAI, dokumentacja wersji 25.1).

Archiwizacja w Data Archiver nie jest usunięciem w rozumieniu RODO. Rekord przeniesiony do ukrytej tabeli nadal jest daną osobową przetwarzaną przez administratora, więc archiwum potrzebuje własnego terminu usunięcia. Po Hard Delete SugarAI zachowuje w tabeli archive_runs wyłącznie identyfikatory usuniętych rekordów. Pozwala to wykazać, że zadanie retencyjne zostało wykonane, bez przechowywania samych danych osobowych.

Zwykłe usunięcie rekordu w interfejsie SugarAI to soft delete. Rekord dostaje flagę „deleted”, znika z widoków, ale zostaje w bazie do czasu uruchomienia schedulera czyszczącego bazę (Prune Database). Dla polityki retencji ma to praktyczną konsekwencję: data usunięcia w interfejsie nie jest datą fizycznego usunięcia danych. Harmonogram tego schedulera warto wpisać do dokumentacji retencji jako element procesu.

Jak obsłużyć żądanie usunięcia danych (art. 17) w SugarAI?

Żądanie usunięcia danych obsługujemy w SugarAI przez rekord Data Privacy typu „Request to Erase Information”, a nie przez usunięcie kontaktu. Administrator ma miesiąc na odpowiedź, z możliwością przedłużenia o kolejne dwa miesiące w złożonych przypadkach (art. 12 ust. 3 RODO). Procedura obejmuje sześć kroków:

1. Rejestracja żądania. Tworzymy rekord Data Privacy typu „Request to Erase Information” i wiążemy go z kontaktem, leadem lub targetem. Data utworzenia rekordu wyznacza początek terminu.
2. Weryfikacja tożsamości. Potwierdzamy, że wniosek złożyła osoba, której dane dotyczą, np. przez odpowiedź z adresu e-mail zapisanego w SugarAI.
3. Ocena wyjątków z art. 17 ust. 3 RODO. Dane potrzebne do ustalenia, dochodzenia lub obrony roszczeń albo wymagane przepisami, np. na fakturach, zostają. Usuwamy pozostałe.
4. Wykonanie erasure. Osoba z rolą Data Privacy Manager wskazuje pola do usunięcia i zamyka rekord. SugarAI trwale usuwa wartości pól, także z historii audytu i z activity streamów.
5. Propagacja do systemów zewnętrznych. Usuwamy lub blokujemy dane w Mautic, ERP, narzędziach poczty i znanych eksportach.
6. Odpowiedź i zamknięcie sprawy. Informujemy osobę o wykonaniu żądania albo o podstawie prawnej, z której część danych zostaje.

Kopie zapasowe wymagają osobnej reguły, bo erasure działa wyłącznie na bazie produkcyjnej SugarAI. Typowe podejście polega na tym, że backupów nie edytuje się ręcznie, ale po każdym odtworzeniu kopii ponownie wykonuje się usunięcia z listy zrealizowanych żądań. Moduł Data Privacy pełni tu funkcję rejestru: zamknięte rekordy typu „Request to Erase Information” pokazują, których osób dane nie mogą wrócić do systemu.

Jak prowadzić zgody marketingowe w SugarAI i Mautic?

Zgody marketingowe w SugarAI zapisujemy w polach zgód na rekordach Leads, Contacts i Targets oraz w rekordach Data Privacy typu „Consent to Process” i „Withdraw Consent”. Rekord zgody ma pole wielokrotnego wyboru celów przetwarzania (Business Purposes Consented for). Dzięki temu SugarAI przechowuje nie tylko aktualny stan zgody, ale też historię jej udzielenia i wycofania, czyli dowód, którego wymaga art. 7 ust. 1 RODO.

Od 10 listopada 2024 r. zasady marketingu elektronicznego w Polsce określa art. 398 ustawy Prawo komunikacji elektronicznej (PKE). Przepis wymaga uprzedniej zgody na przesyłanie informacji handlowej, w tym marketingu bezpośredniego, m.in. przez e-mail i telefon. Ministerstwo Cyfryzacji wskazuje, że zgoda musi dotyczyć konkretnego kanału komunikacji (2025). PKE nie różnicuje odbiorców na osoby prywatne i firmy, więc obowiązek obejmuje także marketing B2B.

W praktyce w SugarAI trzeba rozróżnić dwie warstwy zgód. Zgoda z art. 398 PKE dotyczy kanału, czyli tego, czy wolno wysłać e-mail albo zadzwonić. Podstawa prawna z RODO dotyczy przetwarzania danych osobowych i dla marketingu bezpośredniego może nią być prawnie uzasadniony interes (motyw 47 RODO). Dlatego w SugarAI odwzorowujemy je jako osobne pola: zgoda na e-mail, zgoda na kontakt telefoniczny oraz cel przetwarzania.

Jak synchronizować zgody między SugarAI a Mautic?

Mautic zarządza zgodami na poziomie kanału przez status Do Not Contact (DNC) i centrum preferencji. W centrum preferencji kontakt może wyłączyć wybrany kanał i ustawić częstotliwość komunikacji. Domyślnie wypisanie się z wiadomości nadaje status DNC dla kanału e-mail: kontakt zostaje w segmentach i kampaniach Mautic, ale nie dostaje wiadomości. Integracja SugarAI z Mautic musi przenosić ten status w obu kierunkach.

Reguły synchronizacji zgód, które stosujemy przy integracji SugarAI z Mautic:

• Jedno źródło prawdy dla każdego zdarzenia. SugarAI rejestruje zgody zebrane w procesie sprzedaży, Mautic rejestruje wypisy z wysyłek, a każda zmiana trafia do drugiego systemu.
• Mapowanie pól na kanały. Zgoda na e-mail w SugarAI odpowiada statusowi DNC kanału e-mail w Mautic. Zgoda telefoniczna zostaje w SugarAI, jeśli Mautic nie obsługuje tego kanału.
• Segmenty tylko z aktywną zgodą. Segmenty kampanii w Mautic budujemy wyłącznie z kontaktów, które mają aktywną zgodę na dany kanał.
• Wycofanie zgody bez opóźnień. Rekord „Withdraw Consent” w SugarAI powinien nadawać DNC w Mautic przez integrację lub API, a nie przy nocnej synchronizacji.
• Erasure obejmuje Mautic. Realizacja żądania usunięcia w SugarAI wymaga usunięcia kontaktu w Mautic lub pozostawienia wyłącznie wpisu na liście blokad.
• Dowód zgody z formularza. Formularze Mautic zapisują datę, źródło i wersję treści klauzuli, a te dane trafiają do rekordu w SugarAI.

Scenariusz hipotetyczny: firma dystrybucyjna z 25-osobowym działem handlowym ma w SugarAI 40 000 kontaktów, a synchronizacja z Mautic działa raz na dobę. Kontakt wypisuje się z newslettera w poniedziałek rano. Tego samego dnia handlowiec eksportuje z SugarAI listę do wysyłki ofertowej, na której ten kontakt nadal ma aktywną zgodę. Wiadomość wychodzi po wycofaniu zgody, a firma nie ma w CRM śladu, że wypis nastąpił wcześniej.

Jakie błędy popełnia się najczęściej przy RODO w SugarAI?

Najczęstsze błędy przy obsłudze RODO w SugarAI wynikają z konfiguracji pozostawionej w ustawieniach domyślnych i z braku właściciela procesu, a nie z ograniczeń systemu:

1. Usuwanie rekordu zamiast erasure. Soft delete zostawia dane w bazie, a organizacja nie ma śladu realizacji żądania.
2. Nieoznaczone pola niestandardowe. Erasure pomija pola, których nikt nie oznaczył jako dane osobowe, w tym pola tekstowe z notatkami.
3. Brak audytu w modułach niestandardowych. Bez audytu nie da się oznaczyć pól jako dane osobowe, więc moduł wypada z procesu usuwania.
4. Jedna zbiorcza zgoda „na marketing”. PKE wymaga zgody na konkretny kanał, a RODO na konkretny cel.
5. Archiwizacja traktowana jako usunięcie. Dane w ukrytej tabeli Data Archiver nadal podlegają RODO i potrzebują terminu usunięcia.
6. Import list bez podstawy przetwarzania. Rekord w SugarAI bez źródła i daty pozyskania nie pozwala wykazać legalności kontaktu.
7. Rola DPM bez właściciela merytorycznego. Administrator IT z rolą Data Privacy Manager nie oceni wyjątków z art. 17 ust. 3 bez znajomości polityki retencji.

Od czego zacząć porządkowanie RODO w SugarAI?

Porządkowanie RODO w SugarAI warto zacząć od trzech działań, w tej kolejności. Pierwsze to inwentaryzacja pól we wszystkich modułach i oznaczenie danych osobowych. Drugie to polityka retencji w formie tabeli kategorii danych, przełożona na zadania Data Archiver. Trzecie to mapa zgód między SugarAI a Mautic z jasno wskazanym źródłem prawdy dla każdego zdarzenia. Konfiguracja modułu Data Privacy jest ostatnim, najprostszym etapem.

Test na koniec: wybierzcie losowy kontakt, który wycofał zgodę w ostatnim kwartale. Ile czasu zajmie wam wskazanie wszystkich miejsc, w których nadal jest jego adres e-mail: SugarAI, Mautic, eksporty i skrzynki handlowców?

Artykuł opisuje funkcje systemu i praktykę wdrożeniową. Nie stanowi porady prawnej. Okresy retencji i podstawy przetwarzania warto zatwierdzić z inspektorem ochrony danych lub prawnikiem.

Zobacz też: „SugarAI w sektorze publicznym: jak spełnić wymogi KRI, NIS2 i RODO przy wdrożeniu CRM” oraz „Bezpieczeństwo danych w SugarAI on-premise vs Cloud: szyfrowanie, kopie zapasowe, plan disaster recovery”.

FAQ – RODO w SugarAI

Czy moduł Data Privacy w SugarAI jest płatny?

Nie. Funkcje ochrony danych, w tym moduł Data Privacy, są dostępne od wersji 8.0 we wszystkich edycjach SugarAI, on-premise i w chmurze. Moduł jest domyślnie ukryty i administrator musi go włączyć w ustawieniach Admin > Navigation Bar and Subpanels.

Czy erasure w SugarAI usuwa dane z kopii zapasowych?

Nie. Erasure działa na bazie produkcyjnej SugarAI: usuwa wartości pól i ich historię w audycie. Kopie zapasowe wymagają osobnej procedury, najczęściej ponownego wykonania usunięć po każdym odtworzeniu backupu, na podstawie rejestru żądań z modułu Data Privacy.

Jak długo można przechowywać leady w CRM?

RODO nie podaje konkretnego okresu. Administrator ustala go na podstawie celu przetwarzania i dokumentuje w polityce retencji, zwykle licząc od ostatniej aktywności. W SugarAI taki okres egzekwuje zadanie Data Archiver z filtrem na status i datę ostatniego kontaktu.

Czy do wysyłki ofert B2B na służbowy e-mail potrzebna jest zgoda?

Tak. Art. 398 ustawy Prawo komunikacji elektronicznej wymaga uprzedniej zgody na przesyłanie informacji handlowej przez e-mail i telefon, a przepis nie wyłącza odbiorców biznesowych. Zgoda musi wskazywać konkretny kanał komunikacji.

Kto w firmie powinien mieć rolę Data Privacy Manager w SugarAI?

Osoba, która zna politykę ochrony danych i potrafi ocenić wyjątki od prawa do usunięcia, np. koordynator RODO lub inspektor ochrony danych z dostępem do CRM. Rola pozwala trwale usuwać dane, więc nie powinna trafiać automatycznie do wszystkich administratorów.

Czy usunięcie kontaktu w SugarAI usuwa go z Mautic?

Nie automatycznie. Zależy to od konfiguracji integracji SugarAI z Mautic. Erasure w SugarAI i usunięcie lub zablokowanie kontaktu w Mautic trzeba powiązać regułą synchronizacji i sprawdzać przy realizacji każdego żądania.

Czym różni się archiwizacja od usunięcia w Data Archiver?

Archive przenosi rekordy do ukrytej tabeli, więc dane osobowe nadal są przetwarzane. Hard Delete usuwa rekordy trwale, a SugarAI zachowuje tylko ich identyfikatory w tabeli archive_runs. Do realizacji retencji właściwy jest Hard Delete albo archiwum z własnym terminem usunięcia.

Źródła

• Rozporządzenie (UE) 2016/679 (RODO) – art. 5, 7, 12, 15, 17 i motyw 47
• SugarAI: Data Privacy Guide
• SugarAI: Data Archiver, Administration Guide 25.1
• Ustawa z 12 lipca 2024 r. – Prawo komunikacji elektronicznej, art. 398 (ISAP)
• Ustawa z 23 kwietnia 1964 r. – Kodeks cywilny, art. 118 (ISAP)
• Ministerstwo Cyfryzacji, odpowiedź na interpelację nr 12337 (13.10.2025)