By · Last updated 2026-06-02

Atgal į BlogąAI Saugumas

BDAR ir palaikymo DI: pasirinktiniai identifikatoriai svarbūs

Palaikymo DI gauna klientų pranešimus su vardais, el. paštais IR užsakymų ID. Standartiniai ADA įrankiai pašalina el. pašto adresus, bet palieka užsakymų ID nepaliestus.

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

BDAR ir palaikymo DI: pasirinktiniai identifikatoriai svarbūs

Jūsų palaikymo komanda naudoja DI atsakymams parengti ir bilietams peržiureti. Produktyvumas didėja. Tada jūsų DPO patikrina sąranką.

Įprastas klientų pranešimas apima vardą, el. pašto adresą ir užsakymo ID. Vardas ir el. paštas yra asmens duomenys. Taip pat ir užsakymo ID. Jis susieja su Saroje Johnson jūsų užsakymų duomenų bazėje. DI tiekėjas gali jį kryžmiškai nuorodoti. Jei mokymo duomenys nuteka, ID gali ją pakartotinai identifikuoti.

Bet kuris iš šių siuntimas išoriniam DI tiekėjui be teisinio pagrindo yra BDAR pažeidimas.

Kodėl užsakymų ID yra asmens duomenys

BDAR 4 straipsnis plačiai apibrėžia asmens duomenis. Sąvoka apima visą informaciją, susijusią su nustatytu arba nustatytinu asmeniu. Nustatymumas apima netiesioginę identifikaciją pagal nuorodą i identifikatorių.

Užsakymo ID kaip ORD-4521893 yra netiesioginis identifikatorius. Vienas jis nepavadina Saros Johnson. Kartu su jūsų užsakymų duomenų baze - taip.

BDAR 4 straipsnio 5 dalis apima pseudonimizavimą. Užsakymų ID yra pseudonimai. Jiems reikia antro šaltinio, norint atskleisti asmenį už jų. Kai siunčiate viena išoriniam DI tiekėjui, dalijatės asmens duomenimis. Reikalingas teisinis pagrindas ir Duomenų Tvarkymo Sutartis.

Tiekėjas gali netureti jūsų duomenų bazės. Tai nepabaigia jūsų pareigos. Jūs dalijotės asmens duomenimis. BDAR vis dar taikomas.

Standartinės anonimizacijos spraga

Palaikymo komandos dažnai diegia ADA aptikimą BDAR atitikčiai. Standartiniai įrankiai pašalina bendrus esybių tipus.

Standartinis aptikimas pagauna klientų vardus, el. pašto adresus, telefono numerius ir kredito kortelių numerius. Jie visi praeina.

Standartinis aptikimas nepagauna užsakymų ID ORD-XXXXXXX formate. Jis praleidžia paskyros numerius, bilietų nuorodas, vidinius vartotojų ID ir prenumeratos ID. Jie nepereina.

Rezultatas atrodo taip: "Sveiki, aš esu [PERSON_1] ir mano užsakymas ORD-4521893 dar neatvyko. Prašau parašyti man el. paštu [EMAIL_1]."

Užsakymo ID vis dar ten yra. Bet kuris, turintis CRM prieigą, gali iš karto rasti Sarą Johnson. Anonimizavimas yra neišsamus. Tai yra atitikties spraga.

Chrome plėtinys: Aptikimas naršyklėje

Palaikymo agentai, naudojantys Claude, ChatGPT arba Gemini, dirba savo naršyklėje. Chrome plėtinys neleidžia pasirinktiniams identifikatoriams palikti.

Stai kaip tai veikia. Agentas įklijuoja klientų pranešimą i DI įrankį. Plėtinys mato, kad taikinys yra DI platforma. Jis pašalina standartinį ADA. Tada jis taiko pasirinktinus modelius. Jie atitinka jūsų užsakymo ID formatą, jūsų paskyros numerio formatą ir bet kurį kitą pasirinktinį identifikatorių, kurį naudoja jūsų komanda. Agentas mato tik švarų pranešimą. Neapdoroti duomenys niekada nepasiekia DI.

Atitikties komanda kartą nustato pasirinktinus modelius. Ji dalijasi išankstine konfigūracija su visais agentais. Agentai to valdyti nereikia. Jie įklijuoja pranešimą. Plėtinys tvarko likusį darbą.

MCP serveris: Aptikimas API lygmeniu

Kai kurios platformos skambina DI per API. Intercom naudoja DI atsakymams rengti. Zendesk naudoja DI atsakymų pasiūlymams. MCP serveris prideda anonimizavimą API lygmeniu šiems nustatymams.

Stai srautas. Klientų pranešimas atvyksta i palaikymo platformą. Jis praeina per MCP galutinį tašką prieš pasiekdamas DI. Galutinis taškas pašalina standartinius ir pasirinktinus objektus. Švarus pranešimas eina i DI. DI grąžina atsakymą. Jokie asmens duomenys nebuvo bendrinti. Agentas tada skaito ir redaguoja atsakymą palaikymo platformoje.

Agentai nemato jokio darbo pobūdžio pokyčio. Procesas atrodo vienodai. Pasirinktinės esybės nustatomos kartą MCP konfigūracijoje. Visi API skambučiai nuo to momento naudoja visą esybių aptikimą.

DPO diegimo kontrolinis sąrašas

1. Pavaizduokite visus duomenų srautus i DI.

Išvardinkite, kur agentai naudoja DI. Įtraukite naršyklės įrankius, API pagrįstus įrankius ir failų įkėlimus.

2. Išvardinkite visus identifikatorių tipus klientų pranešimuose.

Standartinis ADA - vardai, el. paštai, telefonai - pagal nutylėjimą yra apimtas. Pasirinktiniai identifikatoriai - užsakymų ID, bilietų nuorodos, paskyros numeriai - reikalauja pasirinktinių modelių.

3. Pridėkite pasirinktinių esybių modelius.

Apibrėžkite kiekvieną formatą. Išbandykite jį su pavyzdiniais pranešimais. Išsaugokite jį i komandos išankstinę konfigūraciją.

4. Diekite tinkamame lygmenyje.

Naršyklės DI: naudokite Chrome plėtinį su bendrinamą išankstine konfigūracija. API integruotas DI: naudokite MCP serverį arba API lygmens išankstinį apdorojimą.

5. Atnaujinkite savo ROPA.

Užregistruokite, kad palaikymo DI naudoja automatinį anonimizavimą. Išvardinkite apimtus pasirinktinių identifikatorių tipus. Tai yra jūsų techninių apsaugos priemonių dokumentavimas.

6. Išbandykite sąranką.

Paleiskite pavyzdinius pranešimus su visais identifikatorių tipais. Patikrinkite, kad niekas nepasiekia DI. Dokumentų šablonams žr. teisinės atitikties vadovas.

SaaS palaikymo komanda: Praktinis pavyzdys

SaaS palaikymo komanda naudoja Claude per vidinę DI platformą. Klientų pranešimai apima vardus, el. paštus, užsakymų ID ir prenumeratos ID. Kai kurie funkcijų žymėjimo pavadinimai neša vidinius identifikatorius.

Prieš BDAR peržiurą: Visas turinys ėjo i DI. Užsakymo ir prenumeratos ID buvo įtraukti.

Po pasirinktinių esybių aptikimo:

ORD-XXXXXXX ir SUB-XXXXXXXX buvo pridėti kaip pasirinktinės esybės. Chrome plėtinys buvo idiegtas su bendrinamą išankstine konfigūracija. DPO atliko testus ir patvirtino, kad visi identifikatoriai buvo pašalinti prieš DI apdorojimą.

Agentų darbo srautų pokytis: Jokio. Agentai dirba vienodai. Anonimizavimas vyksta fone. DPO turi dokumentuotą apsaugos priemonę faile.

Išvada

BDAR atitinkantis palaikymo DI atlieka daugiau nei tik pašalina vardus ir el. paštus. Užsakymų ID, paskyros numeriai ir bilietų nuorodos yra asmens duomenys. Standartiniai įrankiai juos praleidžia. Pasirinktinių esybių konfigūracija uždaro spragą.

Žingsniai yra paprasti. Apibrėžkite savo identifikatorių formatus. Išbandykite juos su pavyzdiniais pranešimais. Diekite komandai. DPO tai gali užbaigti per popietę. Po to visi klientų duomenys pašalinami prieš pasiekiant išorinius DI sistemas. Atitikties nauda išlieka nuo to momento.

Šaltiniai

Pasiruošę apsaugoti savo duomenis?

Pradėkite anonimizuoti PII su 285+ subjektų tipais 48 kalbomis.

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.