By · Last updated 2026-06-02

Powrót do blogaBezpieczeństwo AI

RODO a AI w obsłudze klienta: niestandardowe identyfikatory

Wiadomości klientów do działu obsługi zawierają imiona i nazwiska, adresy e-mail ORAZ numery zamówień. Standardowe narzędzia PII usuwają adresy e-mail, ale pozostawiają numery zamówień niezmienione.

June 2, 20267 min czytania
customer support AIGDPR AI complianceorder ID detectionIntercom GDPRZendesk privacyAI vendor data

RODO a AI w obsłudze klienta: niestandardowe identyfikatory też się liczą

Twój zespół obsługi klienta używa AI do redagowania odpowiedzi i przeglądania zgłoszeń. Wydajność wzrosła. Potem Twój IOD sprawdza konfigurację.

Typowa wiadomość klienta zawiera imię i nazwisko, adres e-mail oraz numer zamówienia. Imię, nazwisko i adres e-mail to dane osobowe. Numer zamówienia również. Łączy się on z Moniką Kowalską w Twojej bazie zamówień. Dostawca AI może zestawić go z innymi danymi. Jeśli dojdzie do wycieku danych treningowych, identyfikator umożliwi ponowną identyfikację tej osoby.

Wysłanie któregokolwiek z tych elementów do zewnętrznego dostawcy AI bez podstawy prawnej stanowi naruszenie RODO.

Dlaczego numery zamówień są danymi osobowymi

Art. 4 RODO definiuje dane osobowe szeroko. Pojęcie to obejmuje wszelkie informacje odnoszące się do zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. Możliwość identyfikacji obejmuje pośrednią identyfikację za pomocą identyfikatora.

Numer zamówienia taki jak ORD-4521893 to identyfikator pośredni. Sam w sobie nie wskazuje Moniki Kowalskiej z imienia i nazwiska. W połączeniu z Twoją bazą zamówień — już tak.

Art. 4 ust. 5 RODO obejmuje pseudonimizację. Numery zamówień są pseudonimami. Do ujawnienia osoby stojącej za nimi potrzebne jest dodatkowe źródło. Kiedy wysyłasz taki numer do zewnętrznego dostawcy AI, udostępniasz dane osobowe. Wymagana jest podstawa prawna i umowa powierzenia przetwarzania.

Dostawca może nie dysponować Twoją bazą. Nie zwalnia Cię to z obowiązków. Udostępniłeś dane osobowe. RODO nadal ma zastosowanie.

Luka w standardowej anonimizacji

Zespoły obsługi często wdrażają wykrywanie PII w celu zapewnienia zgodności z RODO. Standardowe narzędzia usuwają typowe typy encji.

Standardowe wykrywanie wychwytuje: imiona i nazwiska klientów, adresy e-mail, numery telefonów oraz numery kart kredytowych. Te przechodzą pomyślnie.

Standardowe wykrywanie nie wychwytuje: numerów zamówień w formacie ORD-XXXXXXX. Pomija numery kont, numery zgłoszeń, wewnętrzne identyfikatory użytkowników i identyfikatory subskrypcji. Te zawodzą.

Efekt wygląda tak: Dzień dobry, jestem [PERSON_1] i moje zamówienie ORD-4521893 jeszcze nie dotarło. Proszę o kontakt na adres [EMAIL_1].

Numer zamówienia nadal jest widoczny. Każdy z dostępem do CRM może natychmiast znaleźć Monikę Kowalską. Anonimizacja jest niepełna. To właśnie jest luka w zgodności.

Rozszerzenie Chrome: wykrywanie już w przeglądarce

Pracownicy obsługi korzystający z Claude'a, ChatGPT lub Gemini pracują w przeglądarce. Rozszerzenie Chrome blokuje niestandardowe identyfikatory, zanim opuszczą środowisko pracy.

Oto jak to działa. Pracownik wkleja wiadomość klienta do narzędzia AI. Rozszerzenie rozpoznaje, że docelowa platforma to narzędzie AI. Usuwa standardowe PII, a następnie stosuje niestandardowe wzorce. Wzorce te odpowiadają formatowi numerów zamówień, numerów kont i innym niestandardowym identyfikatorom używanym przez Twój zespół. Pracownik widzi tylko oczyszczoną wiadomość. Surowe dane nigdy nie docierają do AI.

Zespół ds. zgodności konfiguruje niestandardowe wzorce raz. Udostępnia preset wszystkim pracownikom. Pracownicy nie muszą samodzielnie tym zarządzać. Wklejają wiadomość. Rozszerzenie robi resztę.

Serwer MCP: wykrywanie na poziomie API

Niektóre platformy wywołują AI przez API. Intercom używa AI do redagowania odpowiedzi. Zendesk stosuje AI do sugestii odpowiedzi. Serwer MCP dodaje anonimizację na poziomie API dla takich konfiguracji.

Oto przepływ danych. Wiadomość klienta trafia na platformę obsługi. Przechodzi przez punkt końcowy MCP, zanim dotrze do AI. Punkt końcowy usuwa standardowe i niestandardowe encje. Oczyszczona wiadomość trafia do AI. AI zwraca odpowiedź. Żadne dane osobowe nie zostały udostępnione. Następnie pracownik czyta i edytuje odpowiedź w platformie obsługi.

Pracownicy nie zauważają żadnej zmiany w sposobie pracy. Proces wygląda tak samo. Niestandardowe encje są konfigurowane raz w ustawieniach MCP. Od tej chwili wszystkie wywołania API korzystają z pełnego wykrywania encji.

Lista kontrolna IOD do wdrożenia

1. Zmapuj wszystkie przepływy danych do AI.

Wypisz miejsca, gdzie pracownicy korzystają z AI. Uwzględnij narzędzia przeglądarkowe, narzędzia oparte na API oraz przesyłanie plików.

2. Wypisz wszystkie typy identyfikatorów w wiadomościach klientów.

Standardowe PII — imiona, adresy e-mail, telefony — są domyślnie objęte ochroną. Niestandardowe identyfikatory — numery zamówień, numery zgłoszeń, numery kont — wymagają niestandardowych wzorców.

3. Dodaj niestandardowe wzorce encji.

Zdefiniuj każdy format. Przetestuj go na przykładowych wiadomościach. Zapisz do presetu zespołu.

4. Wdróż na właściwej warstwie.

AI w przeglądarce: użyj rozszerzenia Chrome ze współdzielonym presetem. AI zintegrowane przez API: użyj serwera MCP lub preprocesowania na poziomie API.

5. Zaktualizuj Rejestr Czynności Przetwarzania (RoPA).

Odnotuj, że AI w obsłudze klienta stosuje automatyczną anonimizację. Wymień objęte nią typy niestandardowych identyfikatorów. To jest dokumentacja Twojego środka technicznego.

6. Przetestuj konfigurację.

Uruchom przykładowe wiadomości ze wszystkimi typami identyfikatorów. Sprawdź, czy nic nie dociera do AI. Wzory dokumentów znajdziesz w przewodniku po zgodności prawnej.

Zespół obsługi SaaS: praktyczny przykład

Zespół obsługi klienta SaaS korzysta z Claude'a przez wewnętrzną platformę AI. Wiadomości klientów zawierają imiona i nazwiska, adresy e-mail, numery zamówień oraz identyfikatory subskrypcji. Niektóre nazwy flag funkcji zawierają też wewnętrzne identyfikatory.

Przed przeglądem RODO: Cała treść trafiała do AI. Numery zamówień i subskrypcji były widoczne.

Po wdrożeniu wykrywania niestandardowych encji:

ORD-XXXXXXX i SUB-XXXXXXXX zostały dodane jako niestandardowe encje. Rozszerzenie Chrome wdrożono ze współdzielonym presetem. IOD przeprowadził testy i potwierdził, że wszystkie identyfikatory są usuwane przed przetwarzaniem przez AI.

Zmiana w pracy pracowników: Żadna. Pracownicy pracują tak samo jak wcześniej. Anonimizacja działa w tle. IOD ma udokumentowany środek ochrony w aktach.

Podsumowanie

AI w obsłudze klienta zgodna z RODO to coś więcej niż usuwanie imion i adresów e-mail. Numery zamówień, numery kont i numery zgłoszeń są danymi osobowymi. Standardowe narzędzia je pomijają. Konfiguracja niestandardowych encji zamyka tę lukę.

Kroki są proste. Zdefiniuj formaty swoich identyfikatorów. Przetestuj je na przykładowych wiadomościach. Wdróż wśród zespołu. IOD może wykonać to zadanie w ciągu jednego popołudnia. Od tej chwili wszystkie dane klientów są usuwane przed trafieniem do zewnętrznych systemów AI. Korzyść dla zgodności z przepisami utrzymuje się od tego momentu.

Źródła

Gotowy, aby chronić swoje dane?

Rozpocznij anonimizację PII z 285+ typami podmiotów w 48 językach.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.