> Hol takard ki a PII-t LLM-pipeline-ban, visszafordítható token vs. maszkolás, Presidio és felhős DLP, német és magyar hiányok, GDPR a pszeudonimizálásról, tesztelés.
>
> Web page: https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/pii-redaction-llm-pipelines.md) · [Deutsch](https://balazscsorba.com/de/blog/pii-redaction-llm-pipelines.md)
> Author: Balázs Csorba · Published: 2026-10-02 · Keywords: PII redaction LLM, how to remove PII before sending to LLM, Microsoft Presidio tutorial, PII detection German Hungarian, pseudonymisation vs anonymisation GDPR, reversible tokenization LLM prompts, redact PII in logs and traces, LLM data masking, PII guardrail LiteLLM, test PII detection recall

[Blog](https://balazscsorba.com/hu/blog)/Biztonság és megfelelés

# PII-kitakarás LLM-pipeline-okban: hol, hogyan, és mit mond a GDPR

Hol takard ki a PII-t LLM-pipeline-ban, visszafordítható token vs. maszkolás, Presidio és felhős DLP, német és magyar hiányok, GDPR a pszeudonimizálásról, tesztelés.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·12 perc olvasás

-   PII redaction
-   GDPR
-   Microsoft Presidio
-   LLM security
-   Pseudonymisation

![Diagram: a felhasználói bevitel az LLM előtt egy kitakarási kapun megy át, egy tokenszéf a kimenet ellenőrzése után visszaadja a valódi értékeket, a logok és a trace-ek csak kitakart szöveget látnak.](https://balazscsorba.com/images/blog/pii-redaction-llm-pipelines/cover.webp?v=a2981a446d)

## A lényeg röviden

-   Minden határnál takarj ki, ne csak egyszer: az ingest, a prompt, a kimenet, a logok és a trace-ek mind másképp szivárognak, és a logokat meg a trace-eket felejtik el leggyakrabban.
-   A visszafordítható tokenek (egy széf, amely a helyőrzőket valódi értékekhez rendeli) megőrzik a válaszok használhatóságát, de maga a széf személyes adatot tároló rendszerré válik, ezért kulcs, hozzáférés-szabályozás és rövid megőrzés kell hozzá.
-   Egyik detektor sem talál meg mindent. A Presidio ezt maga is kimondja, és a német lefedettség sokkal jobb, mint a magyar. Mérd a recallt nyelvenként a saját adatodon, ne egy gyártói lista alapján dönts.
-   A GDPR szerint a pszeudonimizált adat a kulcs birtokosa számára személyes adat marad. Az EU Bíróságának 2025. szeptember 4-i ítélete hozzáteszi, hogy egy olyan címzettnek, aki nem tudja visszaazonosítani az érintetteket, nem feltétlenül az, de ezt igazolni kell, nem feltételezni.
-   A kitakarást mélységi védelemként kezeld a szerződések, az EU-s hosting és a hozzáférés-szabályozás mellett, és teszteld úgy, mint bármely funkciót: címkézett többnyelvű adathalmazzal, recall-célokkal és regressziós kapuval a CI-ban.

Ezen az oldalon

1.  [Hol takarj ki: öt határ](https://balazscsorba.com/#where-to-redact)
2.  [Kitakarás, maszkolás, tokenizálás: a technika megválasztása](https://balazscsorba.com/#techniques)
3.  [Visszafordítható tokenizálás: hasznos, széffel](https://balazscsorba.com/#reversible-tokens)
4.  [Tool-ok: Presidio, felhős szolgáltatások és NER-modellek](https://balazscsorba.com/#tools)
5.  [Német és magyar: a lefedettségi rés](https://balazscsorba.com/#german-hungarian)
6.  [Álnegatívok: a hiba, amely számít](https://balazscsorba.com/#false-negatives)
7.  [A GDPR nézőpontja: a pszeudonimizált nem anonim](https://balazscsorba.com/#gdpr)
8.  [A kitakarás tesztelése, mint egy funkcióé](https://balazscsorba.com/#testing)
9.  [Mivel kezdeném](https://balazscsorba.com/#first-steps)
10.  [Források](https://balazscsorba.com/#sources)

A legtöbb csapat így kezeli a PII-t egy LLM-funkciónál: egy regex az e-mail-címekre az API-hívás előtt, és egy jegyzet a backlogban. A demóban működik, élesben elbukik, mert a személyes adat nem egyetlen ponton lép be egy LLM-rendszerbe. Ott van a felhasználói üzenetben, az indexelt dokumentumokban, az ügynök által olvasott tool-eredményekben, aztán átmásolódik a modell kimenetébe, az alkalmazás logjába, a trace-backendbe és az értékelő adathalmazba.

Ez a cikk azt mutatja, hogyan tervezném meg a kitakarást egy európai cég számára: hol vannak a kapuk, melyik ponton melyik technika illik, mit tudnak és mit nem a tool-ok (a német és a magyar nyelvre is), hogyan érdemes olvasni a pszeudonimizált adatokról szóló aktuális GDPR-álláspontot, és hogyan teszteld az egészet. Mérnöki tanács, nem jogi tanácsadás, és kiegészíti a hostingról és a szerződésekről szóló [GDPR és LLM API-k: EU-s adattárolás](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency) cikket.

## Hol takarj ki: öt határ

Úgy gondolj a pipeline-ra, mint öt határra, ahol a szöveg olyan rendszerbe lép át, amelyet nem teljesen te kontrollálsz, vagy amely tovább él a kérésnél. Mindegyikhez külön döntés kell.

A modell csak helyőrzőket lát. A széf adja vissza a valódi értékeket a felhasználónak, és sosem hagyja el a bizalmi határodat; a logok és a trace-ek sosem látnak valódi értéket.

-   **Ingest.** A dokumentumokat a chunkolás és az embedding előtt takard ki. A nyers személyes adattal teli vektortárból nehéz törölni, és minden későbbi szivárgást növel. Forrásonként döntsd el, kell-e egyáltalán a valódi érték. Az indexelés kompromisszumait a [RAG pipeline: chunkolás, hibrid keresés, reranking](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking) cikk tárgyalja.
-   **Prompt.** A felhasználói üzenet, a lekért kontextus és a tool-eredmények közvetlenül az API-hívás előtt mennek át a kapun. Ez a legfontosabb határ, mert ez dönti el, mit kap a szolgáltató.
-   **Kimenet.** A modell megismételhet, kikövetkeztethet vagy kitalálhat személyes adatot. Ellenőrizd a választ, mielőtt megjelenik vagy tárolódik, és csak ott állítsd vissza a tokeneket, ahol a nézőnek látnia szabad a valódi értéket.
-   **Logok.** Az alkalmazás- és gateway-logok a klasszikus szivárgás. A kitakart promptot vagy egy hasht és a méretet naplózd, sosem a nyers üzenetet.
-   **Trace-ek és evalok.** Az observability-eszközök a promptokat és a válaszokat teljes egészében tárolják, ez a céljuk. A Langfuse például maszkoló hookokat kínál, amelyek exportálás előtt futnak, a tiszta OpenTelemetry-beállítások pedig az alkalmazásban vagy egy collectorban maszkolhatnak. Az éles forgalomból épített értékelő adatok mindent öröklnek, ami a trace-ekben van.

Egy olyan gateway, mint a LiteLLM, átvállalhatja a prompt oldali kaput. A Presidio guardrailje futhat a hívás előtt, a válasz után vagy csak naplózásra, és a modell kimenetét feldolgozva a maszkolt tokeneket visszacserélheti az eredeti értékekre. Kényelmes kezdés, de tudd a korlátját: a kérést és a választ fedi, az ingest jobodat és a trace-backendedet nem.

## Kitakarás, maszkolás, tokenizálás: a technika megválasztása

A felismerés megtalálja a szövegrészeket, a technika dönti el, mi kerül a helyükre. A választás kompromisszum a modell számára megmaradó haszon, a visszafordíthatóság és a szivárgás okozta kár között. A táblázat az én értékelésem, a Presidio és a Google Cloud Sensitive Data Protection által dokumentált operátorokra építve.

Technika

Visszafordítható

Haszon a modellnek

Fő kockázat

Mire jó

Eltávolítás (üres vagy REDACTED)

Nem

Alacsony: a mondatszerkezet összeomlik

Információvesztés

Logok, analitika, ahol az érték sosem kell

Típusos helyőrző (PERSON\_1)

Csak széffel

Magas: a szerepek és kapcsolatok látszanak

A széf adattárrá válik

Promptok, összefoglalók, support-jegyek

Karaktermaszkolás (_\*_\*1234)

Nem

Alacsony és közepes között

Részértéket és hosszt árul el

Kártya- vagy telefonszám-végződés megjelenítése

Sózott vagy kulcsolt hash

Nem

Közepes: stabil join, olvashatatlan szöveg

Kis entrópiánál kitalálható

Deduplikáció, join-kulcsok analitikában

Determinisztikus vagy formátumőrző titkosítás

Igen, kulccsal

Közepes és magas között: azonos érték, azonos token

Kulcskezelés; az egyenlőség látszik

Strukturált mezők, dokumentumok közti konzisztencia

Valósághű helyettesítő (hamis név)

Csak széffel

Magas, természetesen olvasható

A hamis érték egy valódi személyre eshet

Demók, tesztadatok, evalok

A Presidio replace, redact, hash, mask, encrypt és egyéni függvény operátorokat ad, a decrypt a beépített visszafordítás. A Google dokumentálja a determinisztikus titkosítást (AES-SIV), a formátumőrző titkosítást (FPE-FFX) és a HMAC-SHA-256 hashelést, az első kettő visszafordítható, és Cloud KMS-sel csomagolt kulcsokat javasol. Az alapértelmezésem promptokhoz a típusos, sorszámozott helyőrző: a modell így is következtethet arra, hogy PERSON\_1 írt PERSON\_2-nek, te pedig a kimeneti határnál döntöd el, ki mit láthat.

## Visszafordítható tokenizálás: hasznos, széffel

A visszafordítható tokenek megoldják a használhatósági problémát: a felhasználó választ kér egy ügyfélnek, a modell PERSON\_1 köré fogalmazza, és a kapud a megjelenítés előtt visszaállítja a valódi nevet. Három tervezési szabály tartja ezt biztonságosan.

-   **A tokeneket session-re vagy kérésre korlátozd.** Beszélgetésenként friss hozzárendelés elkerüli a globális keresőtáblát, és megakadályozza, hogy a tokenek beszélgetéseken átívelő azonosítóvá váljanak.
-   **Titkosítsd a széfet és járasd le.** Futtasd a saját infrastruktúrádban, titkosítsd menedzselt kulccsal, és töröld a hozzárendeléseket a beszélgetés végén vagy rövid TTL után. Személyes adatot tartalmaz, ugyanolyan törlési útvonal kell hozzá, mint a többihez.
-   **Csak a peremen állíts vissza.** A visszacserét abban a rétegben végezd, amely jogosult felhasználónak renderel, ne az ügynökciklusban. Különben egy tool-hívás valódi értékeket vihet olyan helyekre, ahová a modellnek nem szabadna jutnia.

**A helyőrzők támadhatók**

Ha a modell PERSON\_1-et lát, és a kimenet egy tool-hoz megy, egy beinjektált utasítás továbbra is kérheti a valódi érték visszaállítását vagy kiszivárogtatását. Kezeld a széfet kiemelt jogosultságként, és tartsd a modell elérésén kívül. A [prompt injection és a lethal trifecta](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns) mintái itt közvetlenül érvényesek.

## Tool-ok: Presidio, felhős szolgáltatások és NER-modellek

Nincs egyetlen válasz, három család van, és sok éles rendszer kombinálja őket.

-   **Microsoft Presidio** (open source, saját üzemeltetésű). Named-entity recognitiont, reguláris kifejezéseket, szabályalapú logikát, ellenőrzőösszegeket és kontextusszavakat kombinál. Ez a szokásos kiindulópont, mert te kontrollálod, hová megy a szöveg, és recognizereket adhatsz hozzá. A dokumentáció őszinte: mivel a felismerés automatikus, nincs garancia arra, hogy minden érzékeny információt megtalál.
-   **Felhős szolgáltatások.** A Google Cloud Sensitive Data Protection hosszú infoType-listát kínál típusonkénti hellyel, köztük német típusokkal, mint útlevél, személyi igazolvány, jogosítvány, adóazonosító és SCHUFA-azonosító. Az Azure Language a németet és a magyart is listázza szöveges PII-hez, a beszélgetés-PII-t pedig csak angolra, franciára, németre és spanyolra dokumentálja. Az Amazon Comprehend PII-felismerést angol vagy spanyol szövegre dokumentál. Menedzseltek és könnyű velük indulni, de a nyers szöveg harmadik fél detektorának küldése maga is adattovábbítás, amelyet indokolnod kell.
-   **NER-modellek és hibridek.** A finomhangolt transzformerek helyben futtathatók. Egy hibrid felismerésről szóló kutatás (reguláris kifejezések és LLM-ek, 13 alacsony erőforrású nyelven tesztelve) egyértelműen jobb súlyozott F1-et mutat, mint a finomhangolt NER-modellek és a zero-shot LLM-ek. Vedd útmutatásnak, hogy a determinisztikus mintákat kontextusérzékeny modellekkel kombináld, ne kész termékként.

A szabályom: determinisztikus, validált recognizerek (IBAN-ellenőrzőösszeg, adóazonosító-formátum) a strukturált azonosítókra, NER-modell a nevekre és helyekre, és LLM-alapú menet csak ott, ahol a recall fontosabb a költségnél, és a modell a határaidon belül fut.

## Német és magyar: a lefedettségi rés

A legtöbb detektor angolul a legerősebb. Egy ausztriai vagy magyarországi cégnél ez a gyakorlati kockázat, mert a szöveg német vagy magyar, gyakran angollal keverve.

-   **Német.** A Presidio dokumentál német recognizereket adóazonosítóra, útlevélre, személyi igazolványra, egészségbiztosítási számra és rendszámra, a spaCy betanított német pipeline-okat ad, a LiteLLM pedig támogatott guardrail-nyelvként említi a németet. A neveket meg kell különböztetni a sok nagybetűs köznévtől is, ezért a névfelismerés recallját németül külön teszteld.
-   **Magyar.** A Presidio entitáslistájában és a Google infoType-referenciájában nem találtam magyar recognizert, a spaCy pedig nem mutat betanított magyar pipeline-t. Az Azure listázza a magyart szöveges PII-hez. Léteznek nyílt modellek, például egy huBERT-alapú NER-modell, amelyet a NerKor korpuszon finomhangoltak PER, ORG, LOC és MISC címkékkel, de GPL-licencű, és a bemenet 448 tokenre korlátozott, ami hosszú dokumentumoknál számít.
-   **Nyelvspecifikus kontextus.** A Presidio-recognizerek egyenként egy nyelvet támogatnak, és a dokumentáció szerint a minták, például a reguláris kifejezések nyelvfüggetlenek, a megbízhatóságot növelő kontextusszavak viszont nem. Egy német recognizernek olyan szavak kellenek, mint a „Steuernummer”, egy magyarnak az „adószám” vagy a „TAJ-szám”, és a magyar ragok miatt a nevek alakja változik (Péter, Péternek, Péterrel).

A magyar azonosítók, például az adószám vagy a TAJ-szám könnyen hozzáadhatók egyéni mintaalapú recognizerként ellenőrzőösszeggel, én ott kezdeném. A nevek a nehéz rész, ahhoz modell és saját kiértékelés kell.

## Álnegatívok: a hiba, amely számít

Egy álpozitív ártalmatlan szót cserél le, és egy kis minőségbe kerül. Egy álnegatív valódi nevet küld a szolgáltatónak, és logba írja. A fontos entitásoknál a recallra optimalizálj, a zajos precisiont fogadd el.

-   **Nevek szabad szövegben:** becenevek, kisbetűs gépelés chatben, köznévként is létező nevek és ragozott alakok.
-   **Kontextusfüggő azonosítók:** egy beosztás, egy kisváros és egy dátum egyetlen szembetűnő entitás nélkül is azonosíthat valakit.
-   **Formátumváltozatok:** szokatlan szóközökkel írt telefonszámok, több sorra tört IBAN-ok, URL-ekben vagy kódblokkokban lévő azonosítók.
-   **Nem szöveges bemenetek:** beszkennelt dokumentumok OCR-kimenete, JSON tool-eredmények és fájlnevek.

E hiányosságok miatt ne csak a kitakarásra támaszkodj. Egészítsd ki szolgáltatói oldali kontrollokkal (EU-s régió, nincs tanítás az adatokon, zero retention, ahol kínálják), minimális jogosultságú retrievallal, és azzal a szabállyal, hogy a különleges kategóriák (például egészségügyi adat) nem mennek általános modellhez, hacsak nincs dokumentált jogalap.

## A GDPR nézőpontja: a pszeudonimizált nem anonim

A GDPR 4. cikk 5. pontja a pszeudonimizálást olyan adatkezelésként határozza meg, amely után az adat kiegészítő információ nélkül már nem kapcsolható konkrét személyhez, feltéve hogy ezt az információt külön tárolják, és technikai és szervezési intézkedések védik. Ez védelmi intézkedés, nem kiút a rendeletből. Az EDPB 2025. január 16-án fogadta el a pszeudonimizálásról szóló 01/2025 iránymutatását, és 2025 elején konzultált róla. Végleges változatot nem tudtam megerősíteni, és 2025 decemberében az EDPB érdekelti rendezvényt tartott a témáról, ezért az iránymutatást még alakulónak tekintsd.

Az EU Bírósága 2025. szeptember 4-én az EDPS kontra SRB ügyben (C-413/23 P) egy árnyalattal egészítette ki a képet. Az ügyben a Single Resolution Board pszeudonimizálta az adatokat, és megtartotta a kulcsot, mielőtt a Deloitte-nak elküldte. A bíróság megerősítette, hogy az ilyen adat az eredeti adatkezelőnek személyes adat lehet, de nem feltétlenül annak a címzettnek, akinek nincsenek ésszerű eszközei a visszaazonosításra, és hogy az adatkezelő tájékoztatási kötelezettsége a címzett nézőpontjától függetlenül fennáll. A kommentárok azt javasolják, hogy dokumentáld, miért nem tudja a címzett visszaazonosítani az érintetteket, és értékeld újra, ha a technológia vagy az adathalmazok változnak.

Mit jelent ez egy LLM-pipeline-ra, az én olvasatomban: a saját rendszereid, amelyek a széfet vagy a kulcsot tartják, továbbra is személyes adatot kezelnek. Hogy a modellszolgáltató személyes adatot kap-e, azon múlik, vannak-e ésszerű eszközei a visszaazonosításra, és ez tényszerű kérdés az általad küldött szövegről. Gyenge bizonyíték az a szabad szöveges prompt, amelyben a kitakarás után ritka részletkombinációk maradnak. Dokumentáld az értékelést, tartsd pontosan az adatkezelési tájékoztatódat a továbbításról, és a helyőrzős szöveget ne nevezd anonimnak.

**A jog még mozoghat**

A Bizottság 2025 novemberi Digital Omnibus javaslata relatív személyesadat-fogalmat és egy 41a. cikket javasolt, amellyel a Bizottság meghatározhatná, mikor nem személyes adat a pszeudonimizált adat. Egy 2026 februári, kiszivárgott tanácsi kompromisszum elhagyta az újradefiniálást, az EDPB és az EDPS pedig a 41a. cikk törlését javasolta. A végső kimenetet nem tudtam ellenőrizni, ezért a mai szabályokra tervezz.

## A kitakarás tesztelése, mint egy funkcióé

A kitakarás egy osztályozó, ezért úgy teszteld, és kösd ugyanazokhoz a gyakorlatokhoz, mint a többi LLM-funkciót (lásd [LLM evalok termékfunkciókhoz](https://balazscsorba.com/hu/blog/llm-evals-for-product-features)).

1.  Építs címkézett adathalmazt minden kiszolgált nyelvhez, valósághű zajjal: elgépelések, kisbetűs nevek, német vagy magyar és angol keveréke, táblázatok és kódblokkok.
2.  Jelents recallt és precisiont entitástípusonként, és állíts külön recall-célt a nevekre, az elérhetőségekre és az azonosítókra. Kövesd a kihagyott entitások arányát, ne csak az átlagot.
3.  Adj a tesztforgalomhoz canary-értékeket (kitalált, de valódinak tűnő neveket, IBAN-okat és adóazonosítókat), és CI-ban ellenőrizd, hogy soha nem jelennek meg szolgáltatói kérésekben, logokban, trace-ekben vagy cache-ekben.
4.  Teszteld a körforgást: tokenizálás, modellhívás, visszaállítás. Ellenőrizd, hogy a tokenek túlélik az átfogalmazást, hogy az ismeretlen tokeneket nem állítja vissza, és hogy a megfelelő session nélkül a visszaállítás lehetetlen.
5.  Futtasd újra a csomagot, ha az NLP-modell, egy recognizer vagy a nyelvi konfiguráció változik, és az éles forgalom mintáit nézd át kézzel, hogy észrevedd a driftet.

## Mivel kezdeném

Kezdd egy prompt oldali kapuval Presidióval vagy egyenértékűvel, típusos helyőrzőkkel és session-enkénti széffel, kitakarással indexelés előtt, és maszkolással a trace-backendben. Add hozzá az egyéni recognizereket a német és magyar azonosítókra, mérd a recallt a saját szövegeden, és párosítsd mindezt EU-s hostinggal és szerződésekkel. A cél nem a tökéletes felismerés, amit egyetlen tool sem ígér, hanem egy olyan pipeline, amelyben egy kihagyott név nem kerül öt rendszerbe.

## Források

1.  [Microsoft Presidio: documentation (limitations, methods)](https://presidio.dataprivacystack.org/)
2.  [Presidio: supported entities and country-specific recognizers](https://presidio.dataprivacystack.org/supported_entities/)
3.  [Presidio: supporting additional languages](https://presidio.dataprivacystack.org/analyzer/languages/)
4.  [Presidio: anonymizer operators](https://presidio.dataprivacystack.org/anonymizer/)
5.  [Google Cloud: infoTypes reference](https://docs.cloud.google.com/sensitive-data-protection/docs/infotypes-reference)
6.  [Google Cloud: pseudonymization in Sensitive Data Protection](https://docs.cloud.google.com/sensitive-data-protection/docs/pseudonymization)
7.  [Microsoft Learn: Azure Language PII detection language support](https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/language-support)
8.  [AWS: Detecting PII entities with Amazon Comprehend](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html)
9.  [spaCy: models and languages](https://spacy.io/usage/models)
10.  [Hugging Face: novakat/nerkor-hubert (Hungarian NER)](https://huggingface.co/novakat/nerkor-hubert)
11.  [arXiv: An Evaluation Study of Hybrid Methods for Multilingual PII Detection](https://arxiv.org/abs/2510.07551)
12.  [LiteLLM: Presidio PII masking guardrail](https://docs.litellm.ai/docs/proxy/guardrails/pii_masking_v2)
13.  [Langfuse: masking](https://langfuse.com/docs/observability/features/masking)
14.  [GDPR Article 4: definitions (pseudonymisation, 4(5))](https://gdpr-info.eu/art-4-gdpr/)
15.  [EDPB: Guidelines 01/2025 on Pseudonymisation](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en)
16.  [IAPP: EDPB publishes draft guidelines on pseudonymization](https://iapp.org/news/a/-what-s-in-a-name-edpb-publishes-draft-guidelines-on-pseudonymization)
17.  [Taylor Wessing: Analysis of the CJEU judgment in C-413/23 P (EDPS v SRB)](https://www.taylorwessing.com/en/insights-and-events/insights/2025/09/analysis-of-the-cjeu-judgment)
18.  [Jones Day: CJEU clarifies scope of personal data in EDPS v SRB](https://www.jonesday.com/en/insights/2025/09/cjeu-clarifies-scope-of-personal-data-in-edps-v-srb-decision)
19.  [IAPP: leaked Council Digital Omnibus compromise drops the revised personal data definition](https://iapp.org/news/a/eu-member-states-leaked-digital-omnibus-compromise-proposal-eliminates-revised-gdpr-definition-of-personal-data)
20.  [Law Health Tech: Pseudonymisation under the GDPR and the Digital Omnibus (May 2026)](https://lawhealthtech.com/2026/05/04/pseudonymisation-under-the-gdpr-where-we-are-what-may-change-under-the-digital-omnibus-and-what-regulators-think/)

## Gyakori kérdések

Hogyan távolítsam el a PII-t, mielőtt az adat az LLM-hez kerül?

Tegyél egy kitakarási kaput az alkalmazás és a modell API-ja közé. Az entitásokat minták, ellenőrzőösszegek és egy NER-modell keverékével ismerd fel (például Microsoft Presidio), mindegyiket cseréld típusos helyőrzőre, például PERSON\_1, küldd el a kitakart szöveget, a választ pedig szükség esetén képezd vissza. Ugyanez a kapu kell a dokumentumok indexelése elé, valamint a logokra és a trace-ekre.

Mi a különbség a kitakarás, a maszkolás és a tokenizálás között?

A kitakarás eltávolítja az értéket, a maszkolás a karaktereket szimbólumra cseréli, a tokenizálás pedig egy helyettesítővel, amely egy különálló széfen keresztül visszafejthető. Csak a tokenizálás (vagy a titkosítás) fordítható vissza. A hash egyirányú, de kis entrópiájú értéknél, például telefonszámnál kitalálható.

Személyes adat-e a pszeudonimizált adat a GDPR szerint?

Annak számára, aki birtokolja a visszaazonosításhoz szükséges kiegészítő információt, igen. A 4. cikk 5. pontja a pszeudonimizálást védelmi intézkedésként határozza meg, nem anonimizálásként. Az EU Bírósága 2025. szeptember 4-én (C-413/23 P) kimondta, hogy ugyanaz az adat olyan címzettnél, akinek nincsenek ésszerű eszközei a visszaazonosításra, lehet, hogy nem személyes adat, vagyis az értékelés nézőpontfüggő.

Támogatja a Microsoft Presidio a németet és a magyart?

A Presidio az NLP-motor konfigurációján keresztül más nyelveken is futhat, és a dokumentációja német recognizereket sorol fel, például adóazonosítóra és személyi igazolványra. Magyar recognizert nem találtam a listában, a spaCy-nek pedig nincs betanított magyar pipeline-ja. Magyarhoz tehát saját recognizer vagy transzformer-modell és saját kiértékelés kell.

Garantálhatja a PII-felismerés, hogy semmi nem szivárog?

Nem. A Presidio maga írja, hogy az automatikus felismerés miatt nincs garancia arra, hogy minden érzékeny információt megtalál. A nevek, a szabad szöveg, az elgépelések és a kontextusfüggő azonosítók álnegatívokat okoznak. A kitakarás ezért csak egy réteg legyen a hozzáférés-szabályozás, a szerződések és az EU-s adattárolás mellett.

Hogyan teszteljek egy PII-kitakarási pipeline-t?

Építs címkézett adathalmazt minden kiszolgált nyelven, valósághű zajjal, és mérd a recallt entitástípusonként, mert egy kihagyott név többet árt, mint egy téves riasztás. Adj hozzá canary-értékeket, amelyek soha nem jelenhetnek meg logban vagy a szolgáltatónak küldött kérésben, futtasd a csomagot CI-ban, és ismételd meg, ha a modell, a nyelvi modellek vagy a recognizerek változnak.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Az AI-ügynökök identitások: least privilege nem emberi felhasználóknak](https://balazscsorba.com/hu/blog/ai-agent-identity-least-privilege)
-   [EU AI Act az 50. cikken túl: GPAI, magas kockázatú határidők, teendők](https://balazscsorba.com/hu/blog/eu-ai-act-gpai-high-risk-2026)
-   [Prompt injection elleni védelem: a lethal trifecta és hat tervezési minta](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns)
-   [MCP biztonsági ellenőrzőlista: tool poisoning, rug pull és OAuth](https://balazscsorba.com/hu/blog/mcp-server-security-checklist)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)