By · Last updated 2026-06-03

Vissza a BlograJogi Technológia

Jogi személyes adatok: privilégium-érzékeny azonosítók felismerése

Az ügyszámok, ügyvédi kamarai nyilvántartási számok, bírósági iratlajstromszámok és ügyfélazonosítók jogilag érzékeny adatok, amelyeket a standard PII-eszközök figyelmen kívül hagynak.

June 3, 20267 perc olvasás
attorney-client privilegelegal document reviewcase numberslaw firm privacylegal tech

title: "Jogi személyes adatok: privilégium-érzékeny azonosítók felismerése" description: "Az ügyszámok, ügyvédi kamarai nyilvántartási számok, bírósági iratlajstromszámok és ügyfélazonosítók jogilag érzékeny adatok, amelyeket a standard PII-eszközök figyelmen kívül hagynak." category: legal-tech publishedAt: 2026-06-03 tags:

  • ügyvéd-ügyfél privilégium
  • jogi dokumentumok átvizsgálása
  • ügyszámok
  • ügyvédi iroda adatvédelme
  • legal tech readingTime: 7

Ügyvéd-ügyfél privilégium az AI korában: jogi személyes adatok, amelyeket az anonimizáló eszköznek fel kell ismernie

A standard PII-eszközök kiszűrik a neveket, e-mail-címeket és TB-számokat. Az ügyszám-hivatkozásokat, a kamarai nyilvántartási számokat és az ügyfélazonosítókat nem. Ezek komoly privilégiumi kockázatot hordoznak. Az általános célú eszközök ezt a rést nyitva hagyják.

Az ügyvédi irodák naponta küldenek fájlokat AI-eszközöknek. Ezek a fájlok privilégium-érzékeny jelölőket tartalmaznak, amelyeket a standard eszközök nem fognak el.

Amikor egy ügyvédi iroda fájlokat továbbít egy AI-asszisztensnek, a fájlokban a standard PII mellett jogi azonosítók is szerepelnek:

  • Ügyfélazonosító-jelölők: Az ügyiratra és az ügyfél nevére mutatnak vissza
  • Ügyszám-hivatkozások: Bíróság által kiadott kódok, amelyek nyilvános, de részletes adatokat tartalmazó iratokhoz kötődnek
  • Kamarai nyilvántartási számok: Nyilvánosan kereshető ügyvédi azonosítók
  • Bírósági iratlajstromszámok: Nyilvános iratrendszerekhez kapcsolódnak, teljes ügytörténettel
  • Bírói kirendelési kódok: Érzékeny ügyekben azonosítják az eljáró bírót

Ezek bármelyikének egy külső AI-szolgáltatóhoz való továbbítása potenciális privilégiumproblémát okoz.

Miért szükséges ezekhez az azonosítókhoz egyedi felismerés?

A bírósági iratlajstromszámok formátuma kerületi szintű mintákat követ. Egyetlen minta sem fed le minden szövetségi és tagállami bíróságot.

A szövetségi polgári ügyek kétjegyű évszámot, majd „cv” jelölést, majd ügyszámot használnak. A büntetőügyek ugyanott „cr” jelölést alkalmaznak. A tagállami bíróságok régiónként eltérnek, egységes szabvány nélkül.

A kamarai nyilvántartási számok tagállamonként különböznek. Kalifornia numerikus formátumot használ. New York nyilvántartási formátumot. Texas saját kamarai azonosítóformátumot. Nincs országos egységes formátum.

Az ügyfélazonosítók irodánként egyediek. Minden iroda saját formátumot alakít ki: év-ügyfél-ügy, szakmai csoporthivatkozások, sorrendi azonosítók.

A standard PII-eszközök egyedi beállítás nélkül nem ismerhetik ezeket.

A hiány valós. Egy dokumentumeszköz teljes ügyirat-kontextust kap. A lajstromszámok nyilvános iratokra mutatnak. Az ügyfélazonosítók jelen vannak. Az eszköz jelenti: a PII eltávolítva. A nevek és e-mail-címek valóban eltávolításra kerültek. A privilégium-érzékeny azonosítók nem.

A jogi AI-startup esete

Egy jogi AI-startup dokumentumeszközt épít ügyvédi irodák számára. A termék átvizsgálja a feltárási fájlokat, megtalálja a releváns kikötéseket, és jelöli a potenciálisan privilegizált tartalmakat. A vállalati ügyfelek megkövetelik az ügyfélazonosítók kiszűrését a standard PII mellett a feldolgozás előtt.

A megfelelési akadály: az AI-eszköz ügyfélazonosítókat tartalmazó fájladatokat dolgoz fel. A nyilvános bírósági iratokkal kombinálva ezek az azonosítók lehetővé tehetik az ügy azonosítását. A vállalati jogi műveleti csapatok ezt elfogadhatatlannak minősítik.

Egyedi entitásfelismerés nélkül:

  • Az átvilágítás feltárja a megfelelési rést
  • 3+ hónapos mérnöki várólistán egy egyedi NLP-modell
  • A vállalati szerződés várakozik

Egyedi entitás API-val:

  • A megfelelési vezető meghatározza az ügyfélazonosító formátumát az onboardingkor
  • A minta tesztelve mintafájlokon: 2 nap
  • Az egyedi entitás hozzáadva a folyamathoz: még 1 nap
  • A vállalati szerződés megkötve

A különbség 3 nap versus 3+ hónap. A munka minta beállítása és API-integráció. Nincs szükség NLP-modell betanítására.

Gyakori formátumok kategóriánként

Szövetségi bírósági lajstromszámok:

A szövetségi polgári ügyek formátuma: kétjegyű év + „cv” + 4–6 jegyű ügyszám. Példa: 24-cv-12345. Büntetőügyeknél ugyanott „cr” szerepel. Csődügyeknél „bk.” Fellebbezéseknél kétjegyű év és egy 4–5 jegyű, fellebbviteli bíróságonként változó szám.

Tagállami bírósági formátumok (példák):

A kaliforniai Superior Court hatjegyű előtagrendszert használ. New York évszámmal és sorszámmal kombinált indexformátumot. Texas évszám, sorszám és bírósági kód kombinációját alkalmazza.

Ügyfélazonosítók (jellemző irodai formátumok):

A legtöbb irodában három általános minta jelenik meg:

  • Kétjegyű év, ügyfél-azonosító, ügysorszám (pl. 24-ACME-001)
  • Szakmai csoport kezdőbetűi, év, majd négyjegyű sorszám (pl. LIT240042)
  • Ügyfél-előtag hatjegyű azonosítóval (pl. SMITHCO-000123)

Amerikai kamarai nyilvántartási azonosítók:

A legtöbb tagállamban 4–8 jegyű számokat alkalmaznak, néha tagállami előtaggal. Az USDC-belépési azonosítók kerületenként eltérnek, nincs egységes formátum.

Privilégium-tudatos feldolgozási folyamat

A dokumentumfelülvizsgálati AI-hoz egy réteges folyamat kezeli a teljes terjedelmet.

1. réteg — Standard PII-felismerés

Nevek, e-mail-címek, telefonszámok, címek, TB-számok. Magas pontossággal. A bevált eszközök ezt a réteget jól kezelik.

2. réteg — Egyedi kódfelismerés

Ügykódok, lajstromszámok, kamarai azonosítók. Az onboardingkor meghatározott irodaspecifikus minták. Ez a réteg tölti be azt a rést, amelyet a standard eszközök kihagynak.

3. réteg — Privilégium-felülvizsgálat (emberi)

Az automatikus felismerés után egy ügyvéd átvizsgálja a jelölt jelölőket. ATTORNEY-CLIENT fejlécek. WORK PRODUCT jelölések. BIZALMAS megjelölések. Az emberi felülvizsgálat ezen a szinten nem választható el.

4. réteg — Kontextus-kivétel felülvizsgálata

Nyilvános lajstromszámok, amelyek nem hordoznak privilégiumi kockázatot, versus ügyfélazonosítók, amelyek igen. Ez ügyvédi ítélőképességet igényel. Nem automatizálható.

Az 1. és 2. réteg a nagy mennyiségű munkát kezeli. A 3. és 4. réteg megtartja az ügyvédi ítélőképességet ott, ahol a privilégiumi döntések helye van. Az AI-eszközhasználat miatti privilégiumlemondásról lásd: ügyvéd-ügyfél privilégium és AI.

Beállítás fejlesztőknek

Onboarding-konfiguráció

Az ügyfélazonosító formátumokat az onboardingkor kell összegyűjteni a vállalati ügyfelektől. Minden iroda más formátumot használ. Irodaspecifikus egyedi entitásként kell tárolni őket. Az adott fiók összes feldolgozásánál alkalmazni kell.

Alapértelmezett presetek

Az előre beépített presetek egyedi munka nélkül lefedik az általános kontextusokat:

  • „Szövetségi bírósági dokumentumok” — szövetségi lajstromszám-minták polgári, büntető- és csődügyeknél
  • „Tagállami bírósági dokumentumok (CA/NY/TX)” — tagállam-specifikus formátumok három nagy joghatóságra
  • „Belső műveletek” — ügyazonosító és standard PII
  • „Külső ügyvédi portál” — számlahivatkozás, ügyazonosító és standard PII

Audit-dokumentáció

A feldolgozási naplóknak meg kell mutatniuk, hogy az egyedi kódok szerepeltek minden felismerési menetben. Ez alátámasztja az elemzési módszer munkatermék-védelmét.

A bírósági feltárásban felmerülő kiszűrési költségek skálázásáról lásd: e-discovery PII-automatizálás és jogi felülvizsgálati költségcsökkentés.

Összefoglalás

A privilégium-érzékeny azonosítók legalább annyira kockázatosak, mint a standard PII — gyakran még inkább. Az eszközök, amelyek kihagyják a lajstromszámokat és az ügyfélazonosítókat, valós rést hagynak a dokumentum-munkafolyamatokban.

A megoldás nem egy NLP-modell. Mintabeállítás kérdése. Ügyvédi irodai eszközöket építő fejlesztők számára ez a különbség egy 3 napos megoldás és egy 3 hónapos projekt között. Az ügyvédi irodák számára ez a különbség egy védhető, AI-asszisztált felülvizsgálat és egy privilégiumlemondási kockázat között.

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.