AI a GDPR szorításában — és miért a telepítés helyén dől el a megfelelés

Ma minden magyar cég egyetlen „másol–beilleszt” mozdulatra van attól, hogy mesterséges intelligenciát használjon. Egy szerződés, egy bejövő számla vagy egy ügyféllevél bemásolható egy chatbotba, és másodpercek múlva kész az összefoglaló vagy a kiemelt adat. Éppen ez a könnyedség rejti el a valódi kockázatot: ugyanaz a mozdulat egyben adatvédelmi döntés is, mert abban a másodpercben a dokumentumban lévő személyes adat elhagyja a céget, és egy külső szolgáltató szerverére kerül.

2026-ban a kérdés ezért már nem az, hogy használjunk-e AI-t, hanem az, hogy hová kerül az adat, amikor használjuk. És bár a téma jogi köntösben érkezik — GDPR, EU AI Act, hatósági bírságok —, a megfelelés meglepően nagy része nem jogi, hanem építészeti kérdés. Azon dől el, hol fut a rendszer.

Nézzük végig, mi vonatkozik ránk, mi élesedik éppen most, és hol dől el a gyakorlatban, hogy egy AI-bevezetés megfelelő lesz-e.

Két szabály, ami egyszerre él

A leggyakoribb félreértés, hogy az AI Act „leváltja” vagy „felülírja” a GDPR-t. Nem: a kettő párhuzamosan alkalmazandó. Ha az AI személyes adatot érint, márpedig egy dokumentumfeldolgozó rendszer szinte biztosan érint, akkor mindkét szabályrendszernek egyszerre kell megfelelni.

A kettő más kérdést tesz fel. A GDPR azt kérdezi: jogszerűen és tisztességesen kezeled-e a személyes adatot? — van-e jogalapod, tájékoztattad-e az érintettet, tudod-e teljesíteni a jogait. Az AI Act azt kérdezi: maga a rendszer biztonságos, átlátható és kockázatarányos-e? — kockázati kategóriába sorolható-e, van-e emberi felügyelet, tudják-e a felhasználók, hogy AI-jal van dolguk.

Érdemes korán tisztázni a szerepeket is, mert ez dönti el, kire mi hárul. A legtöbb magyar cég a saját bevezetésében üzembehelyező (deployer) az AI Act értelmében, és adatkezelő (controller) a GDPR értelmében, vagyis az övé a felelősség azért, hogy mire és milyen alapon használja a rendszert. Aki a rendszert szállítja, az szolgáltató (provider) és adatfeldolgozó (processor), az ő felelőssége, hogy a rendszer maga megfelelő és biztonságos legyen. A jó megoldás e két szerep egészséges munkamegosztásán áll vagy bukik.

A tét pedig nem jelképes. A GDPR bírságkerete a globális éves árbevétel 4%-áig vagy 20 millió euróig terjed; az AI Act a tiltott gyakorlatoknál ennél is feljebb megy, 7%-ig vagy 35 millió euróig, a magas kockázatú rendszereknél pedig 3%-ig vagy 15 millió euróig. A két szankció egymás mellett is állhat ugyanazért a rendszerért. A hazai adatvédelmi hatóság (NAIH) is aktívan figyeli a területet, külön ágazati áttekintést tett közzé a magyar bankszektor MI-használatáról, tehát a téma itthon is napirenden van, nem pusztán brüsszeli elmélet.

Mi élesedik éppen most? A 2026-os menetrend

Itt jön a cikk „hírértéke”, mert a menetrend nemrég változott. 2025 végén az Európai Bizottság előállt a Digital Omnibus csomaggal, amely egyszerűsíti az AI Act egyes szabályait, és ami a legfontosabb, elhalasztja a legnehezebb kötelezettségeket. A csomag AI-részét a Tanács 2026. június 29-én véglegesen elfogadta (a Parlament június 16-án szavazta meg), a hivatalos lapban való kihirdetés júliusra várható.

A kulcsüzenet, amit sokan félreértenek: a magas kockázatú kötelezettségek tolódtak el, az átláthatóság viszont nem.

1. ábra — Az EU AI Act aktualizált határidői a Digital Omnibus után.

Konkrétan:

• 2026. augusztus 2. — élesedik az AI Act 50. cikke, az átláthatósági kötelezettség. Ha a rendszered emberekkel lép interakcióba (pl. chatbot) vagy AI-tartalmat állít elő, jelezned kell, hogy AI-ról van szó. Ezt a határidőt az Omnibus nem tolta el. Ekkortól él a felügyeleti szervek teljes szankcionálási jogköre is.
• 2026. december 2. — a már piacon lévő rendszereknél lejár a szintetikus tartalom géppel olvasható jelölésének (watermarking) türelmi ideje, és hatályba lépnek az új tiltások (pl. beleegyezés nélküli intim, illetve gyermekekről készült visszaélésszerű tartalmakat generáló rendszerek).
• 2027. december 2. — ekkortól kell megfelelniük az önálló magas kockázatú (Annex III) rendszereknek — például HR-szűrés, hitelbírálat, biometrikus azonosítás, oktatási értékelés. Ez a határidő korábban 2026. augusztus 2. volt; az Omnibus tolta ide.
• 2028. augusztus 2. — a termékbe ágyazott (Annex I) magas kockázatú rendszerek határideje (korábban 2027. augusztus).

Fontos, józan következtetés: a halasztás nem pihenő. A magas kockázatú megfelelés — kockázatkezelési rendszer, műszaki dokumentáció, konformitásértékelés — hónapok, nem hetek munkája. A nyert időt felkészülésre érdemes fordítani, nem halogatásra.

A GDPR oldalán is volt egy fontos fordulat. A csomag eredeti tervezete szűkítette volna a személyes adat fogalmát (bizonyos pszeudonimizált adat kikerülhetett volna a rendelet hatálya alól), de ezt a javaslatot végül kivették. Vagyis a személyes adat fogalma tág maradt: mivel a látszólag „névtelen” adat is gyakran visszafejthető vagy kikövetkeztethető, a legtöbb dokumentumban lévő adat továbbra is a GDPR alá esik. Az európai adatvédelmi testület (EDPB) egyébként korábban is óvatosságra intett: a személyes adaton tanított AI-modell nem tekinthető automatikusan anonimnak.

Hol fáj ez a gyakorlatban? Öt nyomáspont

Amikor AI-t engedünk rá a dokumentumainkra, öt konkrét kérdés merül fel, ezek a tényleges „fájáspontok”:

1. Jogalap. Milyen alapon kezeled a dokumentumban lévő személyes adatot? Szerződés teljesítése, jogi kötelezettség, esetleg jogos érdek? Ha jogos érdekre hivatkozol, az EDPB szerint háromlépcsős mérlegelés kell: van-e valós, jogszerű érdek; szükséges-e hozzá az adatkezelés; és nem előzik-e meg az érintett jogai. Ez nem formalitás, dokumentálni kell.

2. Átláthatóság és tájékoztatás. Tudja-e az érintett, hogy a folyamatban AI is részt vesz, és mi történik az adatával? A tájékoztatás hiánya az egyik leggyakoribb hatósági kifogás, és 2026 augusztusától az AI Act külön átláthatósági rétege is ráépül erre.

3. Érintetti jogok. Ki tudod-e adni, javítani vagy törölni a személyes adatot, ha az érintett kéri? Ez könnyűnek tűnik, amíg az adat egy adatbázisban van, de bonyolultabb, ha egy modellbe „beépült”. Épp ezért számít, hogy a rendszered hol és hogyan tárolja az adatot.

4. Automatizált döntéshozatal. A GDPR 22. cikke korlátozza, hogy kizárólag automatizált módon, emberi felügyelet nélkül szülessenek jogilag jelentős döntések az emberekről. A helyes minta a human-in-the-loop: az AI előkészít és javasol, a döntést ember hozza.

5. Adattovábbítás harmadik országba. Itt van a legnagyobb, és leggyakrabban alábecsült kockázat. Ha a dokumentum egy külföldi felhő-AI-hoz kerül, akkor az adat elhagyja az EU-t, és ezzel a Schrems II döntés óta jól ismert jogi mocsárba lépünk.

E fölött pedig ott lebeg néhány általános kötelezettség: nagy volumenű vagy rendszeres adatkezelésnél gyakran kötelező az adatvédelmi hatásvizsgálat (DPIA), minden adatfeldolgozóval kell adatfeldolgozói szerződés (DPA), és mindig kell megfelelő adatbiztonság.

Az öt pont közül a legélesebb, a továbbítás, teljes egészében azon múlik, hová megy az adat. És itt lép be a cikk igazi tézise.

A döntő kérdés: hová megy az adat?

Minden felhőalapú AI-szolgáltatásnál, amikor elküldesz egy promptot (és benne egy dokumentumot), az adat elhagyja a hálózatodat, és egy külső szolgáltató infrastruktúráján dolgozódik fel. A legtöbb hétköznapi feladatnál ez elfogadható. Szabályozott, személyes vagy üzleti szempontból érzékeny adatnál viszont nem.

Itt bukik el a leggyakoribb tévhit is: „de EU-s adatközpontot használok, tehát rendben vagyok.” Sajnos nem feltétlenül. Az amerikai CLOUD Act kiterjed az amerikai szolgáltató bárhol tárolt adatára, beleértve az EU-ban működő szervereit is. Vagyis egy amerikai felhő EU-régiója megoldja az adat földrajzi elhelyezését, de nem oldja meg a szuverenitást: az adat továbbra is idegen joghatóság alá eshet.

2. ábra — Ugyanaz a dokumentum, két architektúra. A felhő-AI-nál az adat átlépi a határt; on-premise esetén végig a cégen belül marad.

A tiszta építészeti válasz erre az on-premise (helyben futó) telepítés: a modell a szervezet saját infrastruktúráján fut, és az adat soha nem hagyja el a hálózatot. Ezzel:

• a harmadik országba történő továbbítás kockázata megszűnik (nincs mit átvinni a határon);
• ez a GDPR 25. cikkének — a beépített és alapértelmezett adatvédelemnek — a gyakorlati megvalósítása; az adatvédelem nem utólagos ráépítés, hanem az architektúra része;
• ha nyílt súlyú (open-weight) modellt használsz, amelyet nem tanítanak újra a te adataidon, akkor az adat nem „épül be” a modellbe, és a dokumentációs terhed is jóval tisztább.

Itt jön viszont a szakértői őszinteség, ami elválasztja a valós tanácsot a marketingtől: az on-premise szükséges, de nem elégséges. Attól, hogy a rendszer helyben fut, még kell hozzá jogalap (6. cikk), szükség esetén hatásvizsgálat (35. cikk), az érintetti jogok technikai megvalósíthatósága, valamint rendes hozzáférés-kezelés, naplózás és biztonság (32. cikk). Az on-premise a legerősebb kiindulópont, nem a célvonal.

Hogy ez mennyire nem szűk szakmai téma, jól mutatja: a szuverén AI mára igazgatósági szintű kérdéssé vált. A Gartner előrejelzése szerint 2030-ra az európai vállalatok többsége „hazatelepíti” majd az érzékeny AI-terheléseit, miközben ma még 5% alatt van ez az arány.

Így közelítjük meg mi

A DocAI-t pontosan e köré az elv köré építjük: magyar nyelvű, helyben futó dokumentum-intelligencia, amelyben az adat a cégnél marad. A gyakorlatban ez azt jelenti, hogy a feldolgozás az ügyfél saját (vagy általunk üzemeltetett, dedikált on-premise) infrastruktúráján történik. A dokumentumok nem kerülnek külső felhő-AI-hoz, nincs OpenAI, Anthropic vagy Google API a képben.

A modellt saját üzemeltetésben, nyílt súlyú alapokon futtatjuk, és nem tanítjuk az ügyfél adatain, az adat tehát nem épül be a modellbe. A folyamatba magyar nyelvű személyesadat-felismerés (NER/PII) épül, így a személyes adat azonosítható és kezelhető a dokumentumban, ami támogatja az adattakarékosságot és a célhoz kötöttséget. Ahol lehet, determinisztikus feldolgozási utakat használunk, hogy kevesebb legyen a „fekete doboz”. A rendszer pedig az embert segíti a döntésben, nem helyettesíti, összhangban a 22. cikk logikájával.

És mert a technológia önmagában kevés, a jogi váz is a helyén van: adatfeldolgozói megállapodás (DPA) a GDPR 28. cikke szerint, az EU AI Act-re épülő hivatkozásokkal és rendezett felelősségi kerettel.

Egy dolgot fontos tisztán kimondani: ez nem „automatikus GDPR-megfelelés”. Ilyen nem létezik. Ez a lehető legjobb kiindulópont, amelyre a cég a saját jogalapját, hatásvizsgálatát és folyamatait ráépíti, és ebben partnerek vagyunk.

Gyakorlati checklist a magyar cégnek

Ha AI-bevezetésen gondolkodsz, ez a kilenc pont jó kiindulás:

• AI-leltár — mely folyamatban használsz vagy terveznél AI-t, és milyen adaton?
• Kockázati besorolás — tiltott, magas vagy korlátozott kockázatú a felhasználás? (Annex III?)
• Jogalap rögzítve minden AI-s adatkezeléshez (6. cikk)
• Tájékoztatás — tudja-e az érintett, hogy AI is részt vesz? (13–14. cikk + AI Act 50. cikk)
• Adattovábbítás — elhagyja-e az adat az EU-t vagy a szervezetet? Ha igen, van-e rá garancia? (Schrems II)
• DPIA ott, ahol nagy volumenű vagy rendszeres a kezelés (35. cikk)
• DPA minden adatfeldolgozóval (28. cikk)
• Emberi felügyelet a jelentős hatású döntéseknél (22. cikk)
• Naplózás és tárolási korlát — ne őrizd a személyes adatot a szükségesnél tovább

Az on-premise telepítés több pontot „alapból” kedvezőbbé tesz, mindenekelőtt a továbbítást és a felhő-AI-val kötendő adatfeldolgozói szerződést, de a jogalap, a hatásvizsgálat és az érintetti jogok a te felelősséged maradnak.

Összegzés

A szabályozás nem az AI ellensége, sokkal inkább a rossz architektúráé. Aki jól teszi fel a kérdéseket — hová megy az adat, ki hozza a döntést, mi a jogalap —, annak a megfelelés nem fék, hanem versenyelőny: olyan bizalom, amelyet az ügyfél is ellenőrizni tud. A magas kockázatú kötelezettségek 2027 végi határidejéig van idő felkészülni, de a felkészülést most érdemes elkezdeni. A jó hír pedig, hogy a legnehezebbnek tűnő kérdés, a személyes adat védelme, jórészt egyetlen, jól meghozható döntésen múlik: hol fut a rendszer.

Ez a cikk tájékoztató jellegű, és nem minősül jogi tanácsadásnak. Konkrét helyzetben érdemes adatvédelmi szakértőt vagy jogászt bevonni.