By · Last updated 2026-06-05

Vissza a BlograGDPR & Megfelelés

HDPA Görögország: AFM és AMKA azonosítók felismerése

A generikus eszközök csupán 52%-os pontossággal ismerik fel a görög AFM azonosítót. A HDPA 2024-ben 89 határozatot hozott — ez 162%-os növekedés 2022-höz képest. Az idegenforgalmi és hajózási szektorban sajátos megfelelési kihívások mutatkoznak.

June 5, 20267 perc olvasás
Greece HDPAAFM AMKA detectionGreek alphabet NERtourism GDPRGreek identifiers

HDPA Görögország: AFM és AMKA azonosítók felismerése

A görög Adatvédelmi Hatóság (HDPA) 2024-ben 89 végrehajtási határozatot hozott — ez 162%-os növekedés a 2022-es 34 határozathoz képest. Az érvényesítés gyors felgyorsulása egyszerre tükrözi a HDPA megnövekedett kapacitását és az ágazat-specifikus megfelelési hiányosságokat: az idegenforgalom a HDPA-ügyek 38%-át teszi ki, és hasonlóan érintett a hajózási szektor is.

AFM: Görögország elsődleges kereskedelmi azonosítója

Az ΑΦΜ (Αριθμός Φορολογικού Μητρώου, adóazonosító szám) egy 9 jegyű szám, amelyet minden görög állampolgár, lakos és vállalkozás kap adóügyi nyilvántartás céljára. Az ellenőrző számjegy súlyozott összeg algoritmust alkalmaz: az 1–8. számjegyet rendre (256, 128, 64, 32, 16, 8, 4, 2) súlyokkal kell megszorozni, az eredményt összeadni, majd 11-es modulus szerint osztani. Ha az eredmény 10, a szám érvénytelen; egyébként az ellenőrző számjegy az eredmény 10-es maradéka.

Az AFM minden görög kereskedelmi dokumentumban megjelenik — számlákon, szerződésekben, munkaszerződésekben és kormányzati nyomtatványokon. Mind magánszemélyek, mind vállalkozások elsődleges kereskedelmi azonosítója Görögországban.

Felismerési pontosság: A generikus NLP-eszközök az AFM-t 52%-os pontossággal ismerik fel (HDPA 2024-es elemzése). A hibák fő okai:

  • Az AFM 9 jegyű formátuma sok más referenciaszámra és dátumrészletre hasonlít görög dokumentumokban
  • A kétlépéses súlyozott modulo-11/modulo-10 ellenőrző számjegy algoritmus nincs implementálva a generikus eszközökben
  • Görög dokumentumokban az AFM sokszor explicit jelzés nélkül jelenik meg (pl. beágyazva a cím blokkokba, „ΑΦΜ:” felirat nélkül)

AMKA: Görögország társadalombiztosítási azonosítója

Az ΑΜΚΑ (Αριθμός Μητρώου Κοινωνικής Ασφάλισης, Társadalombiztosítási Nyilvántartási Szám) egy 11 jegyű szám, amely kódolja a születési dátumot és a nemet:

  • 1–6. számjegy: születési dátum NNHHÉÉ formátumban
    1. számjegy: nem (páratlan = férfi, páros = nő)
  • 8–11. számjegy: sorszám ellenőrző számjeggyel

A születési dátum és nem kódolása miatt az AMKA szerkezetileg hasonlít a svéd personnummerra — és ugyanazt a GDPR különleges kategóriájú adatvédelmi problémát veti fel: a szám biológiai nemet rögzít.

Az AMKA minden görög egészségügyi dokumentumban, társadalombiztosítási bejelentésben és munkáltatói nyilvántartásban megjelenik. Minden görög állampolgár és jogszerű lakos rendelkezik AMKA-val — ez az egészségügyi ellátás és a szociális juttatások elérésének azonosítója, a társadalombiztosítási szám görög megfelelője.

A görög ábécé: az NLP-infrastruktúra kihívása

A görög szöveg a görög ábécét alkalmazza — ez teljes mértékben eltér a latin betűs írásmódtól. Ez alapvető infrastrukturális kihívást jelent a PII-felismerés számára.

Unicode-tartományok: A görög karakterek az U+0370–U+03FF tartományban (Görög és Kopt blokk) és az U+1F00–U+1FFF tartományban (Görög kiterjesztett, politonikus formákhoz) helyezkednek el. A csak ASCII vagy Latin Extended karaktereket kezelő eszközök a görög szövegeket egyáltalán nem tudják feldolgozni.

Görög NER-modellek: A spaCy el_core_news modellje biztosít görög NER-képességet — de kifejezett görög nyelvi konfigurációt igényel. Az alapértelmezett (jellemzően angolra beállított) konfigurációt használó szervezetek görög ábécés dokumentumokra semmilyen kimenetet nem kapnak.

Vegyes írású dokumentumok: A görög üzleti és kormányzati dokumentumok gyakran keverik a görög ábécét (a főtartalom) és a latin ábécét (márkanevekhez, műszaki terminusokhoz, angol megjegyzésekhez). Az NLP-csővezetékeknek mindkét írásrendszert kezelniük kell egyazon dokumentumon belül.

Görög névfelismerés: A görög nevek nominatívuszban jelennek meg (Γεώργιος Παπαδόπουλος), de görög mondatokban genitívuszi/akkuzatívuszi formában is előfordulnak (pl. Γεωργίου Παπαδόπουλου genitivuszban). Az eset-érzékeny NER-felismerés görög morfológiai elemzést igényel.

Az idegenforgalmi szektor: idényes adatkezelési megfelelés

Az idegenforgalom a HDPA-végrehajtási esetek 38%-át teszi ki. A megfelelési kihívás a méretben és az idényjellegen rejlik.

Szállodaszektor PMS-rendszerek: Az ingatlan-kezelő rendszerek (PMS) teljes vendéginformációt kezelnek — útlevélszámokat, állampolgárságot, születési dátumot, kapcsolattartási adatokat — minden vendég esetében. A HDPA-végrehajtás során kiderült, hogy sok szállodai PMS-rendszer 5 évnél hosszabb ideig tárolja a vendégadatokat dokumentált cél és az adatmennyiséggel arányos biztonsági intézkedések nélkül.

IBAN és fizetési adatok: Görög idegenforgalmi vállalkozások EU-s és nemzetközi vendégektől érkező fizetési adatokat kezelnek. A vendégszámlák részleges kártyaszámot tartalmaznak; a foglalási rendszerekben teljes fizetési adatok és lejárati dátumok szerepelnek. A PCI DSS-megfelelés átfed a fizetési adatokra vonatkozó GDPR-követelményekkel.

Személyzeti adatok fluktuációja: Az idegenforgalomban dolgozó szezonális munkások általában 4–6 hónapos szerződéssel dolgoznak. A HDPA-végrehajtás ismétlődő hiányosságokat tárt fel a távozó szezonális alkalmazottak rendszer-hozzáférésének visszavonása terén — ez a jelenség jellemző minden magas fluktuációjú iparágra.

A görög nyelvű HDPA-megfeleléshez technikai követelmény: AFM és AMKA felismerés ellenőrző összeg validálással, görög ábécé NER-támogatás (spaCy el_core_news), valamint görög útlevél- és személyigazolvány-szám felismerés. Az idegenforgalmi szektorban ezen felül szükséges a szállodai PMS adatmegőrzési dokumentáció és a szezonális személyzet hozzáférés-visszavonási eljárásainak kidolgozása — amint azt a HDPA-végrehajtás is egyértelművé tette.

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.