By · Last updated 2026-05-31

Kembali ke BlogGDPR & Pematuhan

Melampaui SSN: Anonimisasi ID Dalaman

Setiap organisasi mempunyai pengecam dalaman — ID pekerja, nombor akaun, ID pesanan — yang boleh mengenal pasti individu dalam konteks tetapi diabaikan oleh alat PII standard.

May 31, 20267 min baca
custom PII detectionorganizational identifiersre-identification riskGDPR pseudonymizationcustom entity

Melampaui SSN: Menganonimisasi ID Dalaman Organisasi Anda

Alat GDPR anda mengalih keluar alamat e-mel. Ia mengalih keluar nombor telefon. Ia mengalih keluar nama. Anda menjalankan eksport sokongan melaluinya. Kemudian anda berkongsi output dengan pasukan analitik anda.

Nombor akaun pelanggan anda masih ada dalam setiap tiket. ID pesanan anda masih ada di sana. ID pengguna dalaman anda juga masih ada.

ID ini kelihatan tidak berbahaya sendiri. Tanpa jadual carian, mereka tidak menamakan seseorang. Tetapi pasukan analitik anda mempunyai jadual tersebut. CRM anda memilikinya. Pangkalan data sokongan anda memilikinya. Sesiapa yang mempunyai akses boleh mencari orang tersebut dalam beberapa saat.

Ini adalah kegagalan GDPR. Alat itu tidak rosak. Ia tidak pernah diberitahu untuk mencari ID anda.

Apa yang Alat PII Standard Kesan

Alat PII standard meliputi format sejagat. Mereka menangkap apa yang digunakan oleh setiap organisasi.

Alat standard mengesan:

  • Nombor jaminan sosial (SSN AS, NINO UK, format ID nasional EU)
  • Alamat e-mel
  • Nombor telefon
  • Nombor kad kredit
  • Nama
  • Nombor pasport dan lesen memandu

Alat standard tidak mengesan:

  • ID pekerja dalam format EMP-XXXXX anda
  • Nombor akaun pelanggan dalam format ACC-XXXXXXXX-XX anda
  • ID pesanan dalam format ORD-XXXXXXX anda
  • ID pengguna dalaman dalam UUID atau format tersuai
  • Kod rujukan khusus rakan kongsi

Alat standard mencari corak sejagat. ID dalaman anda bukan sejagat. Mereka memerlukan persediaan tersuai untuk ditemui.

Risiko Pengenalpastian Semula

Sebuah firma mengeksport tiket sokongan untuk semakan kualiti. Penyingkiran PII standard menyingkirkan nama, e-mel, dan nombor telefon. Nombor akaun dalam format ACC-XXXXXXXX-XX tidak disentuh.

Eksport pergi ke pasukan analitik. Seorang penganalisis menyertai jadual tiket dengan pangkalan data pelanggan pada nombor akaun. Orang tersebut ditemui serta-merta. Tiada helah khas diperlukan. Ia adalah SQL join rutin.

Artikel 4(5) GDPR mentakrifkan pseudonimisasi sebagai pemprosesan di mana data "tidak lagi dapat dikaitkan kepada subjek data tertentu tanpa penggunaan maklumat tambahan." Nombor akaun gagal ujian tersebut. Maklumat tambahan — pangkalan data pelanggan anda — ada di sana dalam organisasi anda.

Eksport yang "dianonimisasi" itu tidak anon.

Membina Corak Entiti Tersuai

Persediaan entiti tersuai adalah cepat. Pasukan pematuhan boleh melakukannya tanpa bantuan kejuruteraan.

Langkah 1: Senaraikan format ID anda.

Tuliskan setiap satu. Contohnya: akaun ACC-XXXXXXXX-XX, ID pesanan ORD-XXXXXXX, ID pekerja EMP-XXXXX.

Langkah 2: Huraikan format dalam bahasa biasa.

"Nombor akaun bermula dengan ACC, kemudian sengkang, kemudian 8 digit, kemudian sengkang, kemudian 2 huruf besar."

Penjana corak berbantu AI mengembalikan: ACC-\d{8}-[A-Z]{2}

Langkah 3: Uji pada data sampel.

Muat naik 20 hingga 30 dokumen. Sahkan semua kejadian ditemui. Sahkan tiada padanan palsu muncul.

Langkah 4: Pilih kaedah.

Untuk ID yang digunakan sebagai kunci sertai, di mana analisis perlu menghubungkan rekod:

  • Pseudonimisasi. Gantikan ACC-00123456-AB dengan ACC-99876543-XY setiap kali. Input yang sama sentiasa memberikan output yang sama. Sertai masih berfungsi. Nilai asal tidak boleh ditemui tanpa kunci.

Untuk ID yang tidak diperlukan dalam analisis:

  • Redaksi. Gantikan dengan [REDACTED]. Mudah. Kekal.

Langkah 5: Simpan sebagai praset yang dikongsi.

Simpan entiti tersuai — atau set daripadanya — ke praset yang dikongsi. Persediaan terpakai kepada semua penggunaan: muat naik kelompok, panggilan API, antara muka pelayar. Ahli pasukan baharu mendapat konfigurasi penuh serta-merta.

Kajian Kes: 180,000 Tiket Sokongan

Sebuah firma menemui 180,000 tiket sokongan dalam gudang analitik mereka. Nama dan e-mel telah dialih keluar. Nombor akaun tidak. Setiap tiket masih menyimpan nilai ACC-XXXXXXXX-XX yang hidup.

Garis masa penyelesaian:

  1. Pegawai pematuhan mentakrifkan corak ACC — 15 minit
  2. Mengujinya pada 30 tiket sampel — 20 minit
  3. Mengesahkan ketepatan — 10 minit
  4. Memproses 180,000 tiket dalam kelompok semalam
  5. Menggantikan jadual gudang dengan versi yang bersih

Jumlah masa untuk pegawai pematuhan: 45 minit. Tanpa sokongan entiti tersuai, pembaikan memerlukan tiket kejuruteraan, semakan kod, dan deploy. Itu mengambil masa minggu, bukan jam.

Untuk pandangan lebih dekat tentang cara ID tersuai mencipta risiko dalam alat sokongan AI, lihat panduan GDPR dan sokongan AI.

Di Mana ID Tersuai Tersebar

ID dalaman muncul di lebih banyak tempat daripada yang dijangka oleh kebanyakan pasukan.

Dokumen dalaman:

  • Nota mesyuarat dengan rujukan akaun atau ID pesanan
  • Urutan e-mel tentang kes pelanggan
  • Pembentangan dengan data kajian kes

Dikongsi dengan pihak ketiga:

  • Laporan kepada pengawal selia dengan nombor rujukan kes
  • Fail audit dengan rujukan pelanggan
  • Fail vendor yang membawa ID pelanggan

Penyelidikan dan analitik:

  • Set data perjalanan pelanggan
  • Eksport semakan kualiti sokongan
  • Data latihan untuk model ML dalaman

Setiap konteks memerlukan persediaan entiti tersuai yang sama untuk menghasilkan output yang benar-benar anon.

Pseudonimisasi vs. Anonimisasi

GDPR menetapkan garis yang jelas.

Pseudonimisasi menggantikan ID dengan pengganti. Orang asal boleh ditemui semula jika seseorang mempunyai jadual carian. Data ini masih merupakan data peribadi. Ia mengurangkan risiko. Ia tidak mengalih keluar kewajipan GDPR anda.

Anonimisasi mengalih keluar kemampuan untuk mengenal pasti semula. Data anon bukan data peribadi. GDPR tidak terpakai kepadanya.

Nombor akaun dan ID pesanan adalah pseudo-nim apabila jadual carian wujud. Menggantikannya dengan pengganti tetap menurunkan risiko, tetapi GDPR masih terpakai. Menggantikannya dengan token rawak — dan memadam kunci — mengalih keluar kewajipan GDPR, tetapi merosakkan analisis berasaskan sertai.

Untuk berkongsi dengan pihak ketiga yang tidak mempunyai jadual carian anda: pseudonimisasi mungkin mencukupi. Untuk analitik dalaman, anonimisasi penuh atau kawalan akses yang ketat diperlukan. Panduan pematuhan undang-undang merangkumi cara mendokumentasikan setiap pendekatan untuk ROPA anda.

Kesimpulan

Jurang itu bukan kegagalan alat. Ia adalah jurang persediaan. Tiada alat dapat mengetahui format nombor akaun anda melainkan anda memberitahunya.

Persediaan entiti tersuai menutup jurang dalam beberapa jam. Pasukan pematuhan mentakrifkan format, mengujinya pada data sampel, dan menggunakannya merentas semua mod penggunaan. Tiada bantuan kejuruteraan diperlukan.

180,000 nombor akaun yang tidak diredaksi tidak ada di sana kerana alat itu gagal. Ia ada di sana kerana alat itu tidak pernah diberitahu untuk mencarinya.

Sumber

Sedia untuk melindungi data anda?

Mulakan pengenalan PII dengan 285+ jenis entiti dalam 48 bahasa.

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.