By · Last updated 2026-06-02

Vissza a BlograAI Biztonság

GDPR-megfelelő support MI: egyéni azonosítók

A support MI ügyfélüzeneteket kap nevekkel, e-mail-címekkel ÉS rendelésazonosítókkal. A szabványos PII-eszközök kiszűrik az e-mail-címeket, de a rendelésazonosítókat érintetlenül hagyják.

June 2, 20267 perc olvasás
customer support AIGDPR AI complianceorder ID detectionIntercom GDPRZendesk privacyAI vendor data

GDPR és support MI: az egyéni azonosítók is személyes adatok

A support-csapata MI-t használ válaszok megszövegezésére és jegyek áttekintésére. A termelékenység nőtt. Aztán az adatvédelmi tisztviselője ellenőrzi a beállítást.

Egy tipikus ügyfélüzenet tartalmaz egy nevet, egy e-mail-címet és egy rendelésazonosítót. A név és az e-mail személyes adat. Ugyanúgy a rendelésazonosító is. Ez összekapcsol Sarah Johnsonnal a rendelési adatbázisban. Egy MI-szállító kereszthivatkozást készíthet. Ha a tanítóadat kiszivárog, az azonosító újraazonosíthatja őt.

Ezek bármelyikének elküldése egy külső MI-szállítóhoz jogalap nélkül GDPR-jogsértés.

Miért személyes adat a rendelésazonosító?

A GDPR 4. cikke tágan határozza meg a személyes adatot. A fogalom kiterjed minden, azonosított vagy azonosítható személyre vonatkozó információra. Az azonosíthatóság magában foglalja a közvetett azonosítást egy azonosítóra való hivatkozással.

Egy olyan rendelésazonosító, mint az ORD-4521893, közvetett azonosító. Önmagában nem nevezi meg Sarah Johnsont. A rendelési adatbázissal párosítva igen.

A GDPR 4. cikk (5) bekezdése a pszeudoanonymizálást tárgyalja. A rendelésazonosítók pszeudoanonimak. Egy második forrásra van szükségük az azonosított személy felfedéséhez. Amikor elküldi egyet egy külső MI-szállítónak, személyes adatot oszt meg. Jogalapra és adatfeldolgozói megállapodásra van szükség.

Lehet, hogy a szállítónak nincs meg az adatbázisa. Ez nem szünteti meg a kötelezettségét. Megosztott személyes adatot. A GDPR továbbra is érvényes.

A szabványos anonymizálás hiányossága

A support-csapatok sokszor PII-észlelést vetnek be a GDPR-megfelelőségért. A szabványos eszközök eltávolítják a szokásos entitástípusokat.

A szabványos észlelés megkapja az ügyfélneveket, e-mail-címeket, telefonszámokat és bankkártyaszámokat. Ezek átmennek.

A szabványos észlelés nem kapja meg az ORD-XXXXXXX formátumú rendelésazonosítókat. Kihagyja a számlaszámokat, a jegyhivatkozásokat, a belső felhasználói azonosítókat és az előfizetési azonosítókat. Ezek megbuknak.

Az eredmény így néz ki: „Szia, [PERSON_1] vagyok, és az ORD-4521893-as rendelésem még nem érkezett meg. Kérem, írjon a [EMAIL_1] címre.”

A rendelésazonosító még ott van. CRM-hozzáféréssel rendelkező bárki azonnal megtalálja Sarah Johnsont. Az anonymizálás hiányos. Ez a megfelelőségi hiányosság.

Chrome-bővítmény: észlelés a böngészőben

A Claude-ot, ChatGPT-t vagy Gemini-t böngészőben használó support-ügynökök számára a Chrome-bővítmény megakadályozza, hogy az egyéni azonosítók kiszivárogjanak.

Így működik. Az ügynök beilleszti az ügyfélüzenetet az MI-eszközbe. A bővítmény felismeri, hogy a cél MI-platform. Eltávolítja a szabványos PII-t. Majd alkalmazza az egyéni mintákat. Ezek illeszkednek a rendelésazonosító-formátumához, számlaszám-formátumához és minden más egyéni azonosítóhoz, amelyet a csapata használ. Az ügynök csak a tiszta üzenetet látja. A nyers adat soha nem jut el az MI-hez.

A megfelelőségi csapat egyszer állítja be az egyéni mintákat. Megoszt egy beállítást az összes ügynökkel. Az ügynököknek nem kell ezt kezelniük. Beillesztik az üzenetet. A bővítmény elvégzi a többit.

MCP Server: észlelés az API-rétegben

Egyes platformok API-n keresztül hívnak MI-t. Az Intercom MI-t használ válaszok megszövegezéséhez. A Zendesk MI-t használ válaszjavaslatok készítésére. Az MCP Server ezekhez a beállításokhoz az API-rétegben ad anonymizálást.

A folyamat a következő. Egy ügyfélüzenet megérkezik a support-platformra. Az MCP-végponton halad át, mielőtt elér az MI-hez. A végpont eltávolítja a szabványos és egyéni entitásokat. A tiszta üzenet kerül el az MI-hez. Az MI visszaad egy választ. Nem osztottak meg személyes adatot. Az ügynök ezután elolvassa és szerkeszti a választ a support-platformon.

Az ügynökök nem látnak változást a munkájukban. A folyamat ugyanolyannak tűnik. Az egyéni entitásokat egyszer kell beállítani az MCP-konfigurációban. Ettől fogva az összes API-hívás teljes entitásészleléssel fut.

Adatvédelmi tisztviselői megvalósítási ellenőrzőlista

1. Térképezze fel az MI-hez irányuló összes adatfolyamot.

Listázza, hol használnak az ügynökök MI-t. Beleértve a böngészős eszközöket, az API-alapú eszközöket és a fájlfeltöltéseket.

2. Listázza az ügyfelüzenetekben lévő összes azonosítótípust.

A szabványos PII — nevek, e-mail-címek, telefonszámok — alapértelmezés szerint lefedett. Az egyéni azonosítók — rendelésazonosítók, jegyhivatkozások, számlaszámok — egyéni mintákat igényelnek.

3. Adja hozzá az egyéni entitásmintákat.

Határozza meg az egyes formátumokat. Tesztelje mintaüzeneteken. Mentse el a csapatbeállításba.

4. Helyezze üzembe a megfelelő rétegben.

Böngészős MI: Chrome-bővítményt használjon megosztott beállítással. API-integrált MI: MCP Servert vagy API-szintű előfeldolgozást használjon.

5. Frissítse az adatkezelési tevékenységek nyilvántartását.

Rögzítse, hogy a support MI automatizált anonymizálást alkalmaz. Listázza a lefedett egyéni azonosítótípusokat. Ez a technikai biztosíték dokumentációja.

6. Tesztelje a beállítást.

Futtasson mintaüzeneteket minden azonosítótípussal. Ellenőrizze, hogy semmi nem jut el az MI-hez. A dokumentumsablonokért tekintse meg a jogi megfelelőségi útmutatót.

SaaS support-csapat: gyakorlati példa

Egy SaaS support-csapat Claude-ot használ egy belső MI-platformon keresztül. Az ügyfélüzenetek neveket, e-mail-címeket, rendelésazonosítókat és előfizetési azonosítókat tartalmaznak. Egyes funkciójelző nevek belső azonosítókat hordoznak.

GDPR-felülvizsgálat előtt: Minden tartalom az MI-hez került. A rendelés- és előfizetési azonosítók is benne voltak.

Az egyéni entitásészlelés után:

Az ORD-XXXXXXX és a SUB-XXXXXXXX egyéni entitásként lett hozzáadva. A Chrome-bővítményt megosztott beállítással vezették be. Az adatvédelmi tisztviselő teszteket futtatott, és megerősítette, hogy az összes azonosítót eltávolítják az MI-feldolgozás előtt.

Ügynöki munkafolyamat-változás: Nincsen. Az ügynökök ugyanúgy dolgoznak. Az anonymizálás a háttérben fut. Az adatvédelmi tisztviselőnek dokumentált biztosíték áll rendelkezésre.

Összefoglalás

A GDPR-megfelelő support MI nem csupán neveket és e-mail-címeket szűr. A rendelésazonosítók, számlaszámok és jegyhivatkozások személyes adatok. A szabványos eszközök kihagyják őket. Az egyéni entitáskonfiguráció zárja be a hiányosságot.

A lépések egyszerűek. Határozza meg az azonosítóformátumokat. Tesztelje mintaüzeneteken. Vezesse be a csapatnál. Egy adatvédelmi tisztviselő ezt egy délután elvégzi. Ezután az összes ügyféladat eltávolításra kerül, mielőtt külső MI-rendszerekhez jut. A megfelelőségi előny ettől fogva érvényes.

Források

Készen áll az adatai védelmére?

Kezdje el a PII anonimizálását 285+ entitástípuson 48 nyelven.

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.