> Példa DPIA-ra a GDPR 35. cikke szerint: egy AI-asszisztens, amely rendelési adatok alapján válaszol a vevői e-mailekre. Mikor kell, mik a kockázatok, ki a felelős.
>
> Web page: https://balazscsorba.com/hu/blog/dpia-llm-feature-worked-example · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/dpia-llm-feature-worked-example.md) · [Deutsch](https://balazscsorba.com/de/blog/dpia-llm-feature-worked-example.md)
> Author: Balázs Csorba · Published: 2026-10-01 · Keywords: DPIA for LLM features, data protection impact assessment AI assistant, GDPR Article 35 AI, DSFA-V Austria AI, LLM customer support GDPR, prompt injection data leak GDPR, AI Act Article 50 chatbot, DPIA template LLM

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

# DPIA egy LLM-es ügyfélszolgálati asszisztensre: példa a GDPR 35. cikke szerint

Példa DPIA-ra a GDPR 35. cikke szerint: egy AI-asszisztens, amely rendelési adatok alapján válaszol a vevői e-mailekre. Mikor kell, mik a kockázatok, ki a felelős.

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

-   DPIA
-   GDPR
-   LLM security
-   Data protection
-   AI Act

![Borítókép egy LLM-es ügyfélszolgálati asszisztens DPIA-jához: hat lépéses folyamat a magas kockázat vizsgálatától a felülvizsgálatig.](https://balazscsorba.com/images/blog/dpia-llm-feature-worked-example/cover.webp?v=05bd581318)

## A lényeg röviden

-   Az elemzést a magas kockázat vizsgálatával kezdd, ne a mesterséges intelligencia szóval. A GDPR 35. cikkének (1) bekezdése és a WP29-kritériumok döntenek, és egy olyan funkció, amely vevői e-maileket olvas és rendelési adatokkal kapcsol össze, egyszerre több kritériumnak is megfelelhet.
-   Ausztriában előbb a DSFA-AV fehérlistát nézd meg. Az ügyféladminisztráció ott mentesülhet, de a DSFA-V feketelista kifejezetten említi a mesterséges intelligenciát, ezért kérj jogi véleményt, mielőtt a mentességre támaszkodnál.
-   Az LLM-kockázatok konkrétak: kitalált személyes adatok, az ügyfél e-mailjébe rejtett utasítások, a szolgáltató naplói és az EU-n kívüli továbbítás.
-   Minden intézkedéshez rendelj felelőst és maradék kockázatot. Takard ki azt, amire a modellnek nincs szüksége, minden választ egy ember hagyjon jóvá, a megőrzési és betanítási feltételeket pedig a szerződésből vedd, ne a weboldalról.
-   Az AI Act nem helyettesíti a DPIA-t. Saját kötelezettségei vannak, például annak jelzése, hogy valakivel AI-rendszer beszél, valamint a listázott felhasználásokra, például a hitelbírálatra vonatkozó magas kockázatú szabályok.

Ezen az oldalon

1.  [Mikor szükséges a DPIA](https://balazscsorba.com/#when-required)
2.  [Ausztria: a feketelista és a fehérlista](https://balazscsorba.com/#austria)
3.  [A példa: asszisztens egy ügyfélszolgálati postafiókhoz](https://balazscsorba.com/#example)
4.  [Rendszerszintű leírás, szükségesség és arányosság](https://balazscsorba.com/#systematic-description)
5.  [Kockázatok azoknak, akik írnak](https://balazscsorba.com/#risks)
6.  [Intézkedések, felelősök és maradék kockázat](https://balazscsorba.com/#measures)
7.  [Hogyan illeszkedik az EU AI Act](https://balazscsorba.com/#ai-act)
8.  [Mit csinálnék először](https://balazscsorba.com/#first-steps)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Egy ügyfélszolgálati asszisztens, amely e-maileket olvas, megnézi a rendelést, és választ fogalmaz, kicsi funkciónak tűnik. Az adatvédelem szempontjából viszont nem az. Az e-mail szabad szöveg, amelyben bármi szerepelhet, a rendelési rekord személyes adat, a modell egy szolgáltatónál fut, a kimenet pedig visszamegy a vevőhöz. Ez a cikk egy adatvédelmi hatásvizsgálatot (DPIA) dolgoz ki pontosan erre a funkcióra – egy kitalált webáruházra –, és azzal a kockázati táblázattal zár, amelyet én egy adatvédelmi tisztviselő elé tennék.

Előre a válaszom: a hatásvizsgálatot még az első éles válasz előtt el kell végezni. A GDPR csak akkor írja elő a DPIA-t, ha a kezelés valószínűleg magas kockázattal jár, a WP29 útmutatója viszont ajánlja, ha ez nem egyértelmű. Ausztriában előbb a nemzeti listákat nézd meg. A fehérlista felmentheti az ügyféladminisztrációt, a feketelista viszont kifejezetten említi a mesterséges intelligenciát, ezért az számít, hogyan írod le a kezelést.

**Nem jogi tanács**

Ez egy mérnöki példa, nem jogi tanács. A webáruház, a szolgáltató és az osztrák listákra vonatkozó értelmezésem feltételezés, szemléltetés céljából. A fehérlista-kérdést és az adattovábbítási mechanizmust az indulás előtt egyeztesd az adatvédelmi tisztviselővel vagy egy jogásszal.

## Mikor szükséges a DPIA

A GDPR 35. cikkének (1) bekezdése szerint a DPIA-t a kezelés előtt kell elvégezni, ha a kezelés valószínűleg magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve, különösen új technológia alkalmazása esetén. A 35. cikk (3) bekezdése három esetet említ, amelyekben a DPIA különösen szükséges: a személyes szempontok szisztematikus és kiterjedt értékelését automatizált kezelés alapján, amelyre olyan döntések épülnek, amelyek jelentősen érintik az embereket; különleges adatkategóriák vagy büntetőjogi adatok nagy léptékű kezelését; és nyilvánosan hozzáférhető terület szisztematikus megfigyelését nagy léptékben. Egy ügyfélszolgálati asszisztens önmagában egyikbe sem tartozik, ezért a kérdés az általános magas kockázati tesztre szűkül.

A WP29 WP248 rev.01 útmutatója, amelyet 2017. április 4-én fogadtak el, és 2017. október 4-én módosítottak, ezt a tesztet kilenc szempontra bontja. Ha nem egyértelmű, hogy szükséges-e DPIA, a WP29 azt javasolja, hogy mégis készüljön egy. Ebből négy szempont releváns itt.

-   **Érzékeny vagy nagyon személyes jellegű adatok.** Az útmutató kifejezetten említi a személyes dokumentumokat és az e-maileket, mint olyan adatokat, amelyek e szempont alá eshetnek, nem csak a 9. cikk szerinti kategóriákat.
-   **Adatkészletek összevetése vagy összekapcsolása.** Az ügyfélszolgálati e-mailek és a rendelési rekordok különböző célból gyűlnek. Összekapcsolásuk a funkció lényege, és túlmehet azon, amire a vevők számítanak.
-   **Új technológia innovatív alkalmazása.** Az útmutató szerint az új technológia alkalmazása önmagában kiválthatja a DPIA szükségességét, és egy LLM-funkció a legtöbb ügyfélszolgálati csapatnak új technológia.
-   **Nagy léptékű adatkezelés.** Ez a személyek számától, az adatok mennyiségétől és körétől, a kezelés időtartamától és földrajzi kiterjedésétől függ. Sok vevővel, hosszú megőrzéssel és országos hatókörrel rendelkező webáruház több ilyen tényezőnek is megfelelhet.

Az útmutató szerint a két szempontnak megfelelő kezelés többnyire DPIA-t igényel, és egy szempont néha elég lehet. Az én olvasatomban ez a funkció a négyből legalább három szempontnak megfelel, így az értékelés nem határeset. Az alábbi folyamatábra mutatja azt a kérdéssorrendet, amelyet használok.

Olvasd felülről lefelé. A nemzeti listákat a DPIA-lépés előtt ellenőrizzük, és az indokokat rögzítjük, ha nem készül DPIA, ahogy az útmutató kéri.

## Ausztria: a feketelista és a fehérlista

Ausztria konkréttá teszi a kérdést. A DSFA-V (BGBl. II Nr. 278/2018) 2. §-ának (1) bekezdése szerint DPIA kell, ha a kezelés a GDPR 6., 9. és 10. cikke alapján jogszerű, és a DSFA-AV szerinti kivétel nem vonatkozik rá. A 2. § (2) bekezdése hat kritériumot sorol fel, és egy is elég. A Z 4 kritérium az új vagy újszerű technológiákkal végzett kezelésre vonatkozik, és kifejezetten említi a mesterséges intelligencia alkalmazását.

A 2. § (3) bekezdése egy második utat ad: öt kritérium közül kettő vagy több DPIA-t vált ki. Ezek: különleges adatkategóriák nagy léptékű kezelése, büntetőjogi adatok nagy léptékű kezelése, helyadatok, kiszolgáltatott személyek és az adatkészletek összekapcsolása. Az asszisztens az összekapcsolási kritériumnak is megfelelhet.

A fehérlista a csavar. A DSFA-AV (BGBl. II Nr. 108/2018) mellékletében szereplő kezeléseket mentesíti a GDPR 35. cikkének (1) és (5) bekezdése szerinti DPIA-kötelezettség alól. A DSFA-A01 bejegyzés az ügyféladminisztrációt, a könyvelést, a logisztikát és a számvitelt fedi le. Az én olvasatom szerint a német szöveg alapján ez a vevőkkel és beszállítókkal fennálló bármely üzleti kapcsolat keretében kezelt személyes adatokra vonatkozik, ami jól leírja egy webáruház ügyfélszolgálati postafiókját. A kizárás olyan vállalkozásokra irányul, amelyek tevékenysége olyan harmadik személyekről szóló adatok kezelése, akik nem a vállalkozás vevői. Egy e-mail, amely egy ajándék címzettjét említi, nem tartozik ebbe egyértelműen, de a vizsgálat kérdezheti, hogy a postafiók tartalmaz-e ilyen adatokat, ezért az indoklás a nyilvántartásba tartozik.

Az osztrák webáruházra nézve a becsületes válasz tehát ez: a fehérlista lefedheti az egyszerű ügyféltámogatási postafiókot. Az asszisztens azonban ennél több: olyan technológiát visz be, amelyet a feketelista nevesít, és személyes adatokat küld a webáruház saját rendszerein kívüli szolgáltatónak. Nem kapcsolnám ki az értékelést a fehérlistára hivatkozva. Rögzíteném a mentesség indokát, bemutatnám egy jogásznak vagy az osztrák adatvédelmi hatóságnak, és mégis elvégezném a teljes elemzést, mert a lent leírt kockázatok attól függetlenül érvényesek, melyik lista áll helyesnek.

## A példa: asszisztens egy ügyfélszolgálati postafiókhoz

A példabeli webáruház háztartási árukat árul online, és az ügyfélszolgálati e-maileket egyetlen közös postafiókban kapja. Az asszisztens minden új e-mailt elolvas, kinyeri a rendelésszámot, lekéri a rendelési rendszerből a státuszt, a tételeket és a szállítási várost, majd egy LLM-szolgáltatótól válaszvázlatot kér a vevő nyelvén. Egy ember a támogatási csapatból átszerkeszti a vázlatot, és elküldi. A promptokat és a vázlatokat minőségellenőrzéshez naplózzák. A szolgáltató az Egyesült Államokban dolgozza fel az adatokat. Ez feltételezés a példához, a saját szolgáltatódat neked kell ellenőrizned.

Személyes adatok kétszer lépik át a határt: a prompt kimegy, a vázlat visszajön. Egy ember az utolsó lépés, mielőtt a vevő bármit lát.

Két tervezési döntés határoz meg mindent. A modell csak vázlatot ír. Nincs olyan eszköze, amely e-mailt küld, rendelést módosít vagy visszatérítést indít. A prompt pedig csak azokat a rendelési mezőket tartalmazza, amelyekre a válasznak szüksége van, nem a teljes vevői rekordot.

## Rendszerszintű leírás, szükségesség és arányosság

A GDPR 35. cikkének (7) bekezdése a) és b) pontja a kezelés és céljainak rendszerszintű leírását, valamint a szükségesség és arányosság értékelését kéri. Ezt a 30. cikk (1) bekezdése szerinti kezelési nyilvántartásban tartom, és strukturált adatként írom le, nem szövegként, hogy a funkció változásakor össze lehessen hasonlítani. A példához tartozó minimális bejegyzés így néz ki:

```
# one entry per feature: the Article 30 record and the Article 35(7)(a) description
processing: support-email-drafts
purpose: draft a reply to an order enquiry; a person reviews and sends it
legal_basis:
  - Art. 6(1)(b): answering an enquiry about an existing order
prompt_fields:
  - order number, status, items, shipping city
  - email text with card and bank numbers masked
not_in_prompt:
  - full order history, account notes, marketing profile
recipients:
  - LLM provider as processor (Art. 28), documented instructions only
  - transfer to the United States: DPF certification or SCCs (Art. 46)
retention:
  - provider abuse logs: up to 30 days by default (provider documentation)
  - own prompt and draft log: <N> days, set by the data protection officer
review: new provider, new prompt field or any use of emails for training (Art. 35(11))
```

Ebből a bejegyzésből három dolog következik. Először: a meglévő rendelésre vonatkozó kérdés megválaszolása a GDPR 6. cikkének (1) bekezdése b) pontján alapul, amely a szerződés teljesítéséhez, illetve a szerződéskötést megelőzően az érintett kérésére tett lépésekhez szükséges kezelést fedi le. Másodszor: a vázlatok minőségjavítás céljából történő megtartása másik cél. Ehhez a 6. cikk (1) bekezdésének f) pontja szerinti jogos érdek kell, és a mérlegelési teszt a valódi munka. Az AI-modellekről szóló 28/2024. számú EDPB-véleményben szereplő háromlépéses tesztet alkalmaznám itt: azonosítani kell egy jogszerű, egyértelműen megfogalmazott, valós és jelenlegi érdeket; megvizsgálni, hogy a kezelés szükséges-e hozzá; majd mérlegelni az érintettek jogaival szemben, figyelembe véve az ésszerű elvárásaikat. Harmadszor: az adatvédelmi tájékoztatónak meg kell mondania, mikor kerülnek az adatok harmadik országba, és milyen garancia vonatkozik rájuk, ahogy a 13. cikk (1) bekezdésének f) pontja előírja.

Két különleges esetnek külön sort kell kapnia a leírásban. Először: az e-mailek tartalmazhatnak egészségügyi vagy más különleges kategóriájú adatokat, a rendelés pedig ezeket közvetve is felfedheti. A Bíróság a C-184/20. sz. ügyben kimondta, hogy az olyan kezelés, amely érzékeny információt közvetve, következtetés vagy összekapcsolás útján tár fel, a 9. cikk (1) bekezdése alá tartozik. Egy olyan termék rendelése, amely egészségi állapotra utal, már elég lehet, ezért a prompt ne tartalmazzon a jelenlegi rendelésen túlmutató termékelőzményt. Másodszor: a 22. cikk (1) bekezdése védi az embereket azoktól a döntésektől, amelyek kizárólag automatizált kezelésen alapulnak, és jelentősen érintik őket. A modell által hozott visszatérítési döntés erre jelölt lenne. Ebben a tervben egy ember minden választ elolvas, mielőtt kimegy, és a modell semmit nem dönt el.

## Kockázatok azoknak, akik írnak

**Kitalált személyes adatok.** A modell olyan szállítási dátumot, nevet vagy címet is megadhat, amely nincs a rendelési rekordban. Az EDPB ChatGPT-munkacsoportjának jelentése szerint a betanítás célja nem feltétlenül a pontos információ, és a végfelhasználók valószínűleg tényszerűen pontosnak fogadják el a kimenetet. A pontosság elve a GDPR 5. cikkének (1) bekezdése d) pontja szerint ettől még érvényes. A példában a védelem szerkezeti: a vázlatban szereplő személyes adatok csak a prompton belüli rendelési rekordból származnak, és egy ember ellenőrzi a választ, mielőtt kimegy.

**Prompt injection maga az e-mailben.** Az e-mail törzse megbízhatatlan bemenet. Az OWASP a közvetett prompt injectiont úgy írja le, amikor az LLM külső forrásból, például weboldalakról vagy fájlokból származó bemenetet fogad el. Egy vevő, vagy valaki, aki üzenetet továbbít, beírhat egy utasítást, hogy hagyja figyelmen kívül a szabályokat, és sorolja fel ugyanazon városból származó más rendeléseket. Az OWASP megelőzési listáján szerepel a külső tartalom elkülönítése és azonosítása, a legkisebb jogosultság érvényesítése, valamint az emberi jóváhagyás a kockázatos műveletekhez. Itt a modellnek egyáltalán nincs hozzáférése más vevők rekordjaihoz, és a munkatárs az e-mailt és a vázlatot egymás mellett látja. A szélesebb mintázatokról lásd a jegyzetemet: [prompt injection elleni védekezés](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns).

**Kiszivárgás a kimeneten keresztül.** Az OWASP érzékeny információk kiszivárgásáról szóló oldala a személyazonosításra alkalmas adatokat és az egészségügyi nyilvántartásokat is említi azon adatok között, amelyek modellkimeneten keresztül kiszivároghatnak, és szigorú, a legkisebb jogosultság elvére épülő hozzáférés-szabályozást ajánl. A legrosszabb eset az, amikor az A személynek küldött válasz a B személy rendelését tartalmazza, ami személyes adatok megsértése. A GDPR 32. cikkének (1) bekezdése b) pontja a feldolgozórendszerek és -szolgáltatások folyamatos bizalmasságát és integritását kéri. A 33. cikk szerint a jogsértést indokolatlan késedelem nélkül, lehetőség szerint 72 órán belül be kell jelenteni a felügyeleti hatóságnak, miután tudomást szereztek róla, ahogy a 85. preambulumbekezdés magyarázza. A hívás előtti maszkolást a témában írt jegyzetem fedi le: [személyes adatok maszkolása LLM-folyamatokban](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines).

**Megőrzés a szolgáltatónál.** Az OpenAI adatkezelési oldala szerint (2026. októberi állapot) a visszaélés-figyelő naplókat alapértelmezetten legfeljebb 30 napig őrzik, a Zero Data Retention pedig az OpenAI előzetes jóváhagyásához kötött. Ugyanez az oldal szerint 2023 márciusa óta az API-adatokat nem használják betanításra, kivéve, ha az ügyfél kifejezetten hozzájárul. Ezek a szolgáltató alapértelmezései, amelyek változhatnak, ezért a szerződésnek kell megmondania, melyik érvényes, nem a weboldalnak. A GDPR 28. cikkének (3) bekezdése a) pontja szerint az adatfeldolgozó csak dokumentált utasítás alapján járhat el, az átadásokat is beleértve. Az EDPB 07/2020. számú iránymutatása kimondja, hogy az adatfeldolgozó nem kezelhet másként, mint az adatkezelő utasításai szerint. A szélesebb lehetőségekről lásd a jegyzetemet: [GDPR és adatrezidencia LLM API-knál](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency).

**Harmadik országba irányuló továbbítás.** A Bizottság (EU) 2023/1795. számú, 2023. július 10-i végrehajtási határozata megállapítja, hogy az Egyesült Államok az EU–USA adatvédelmi keretrendszerben tanúsított szervezetek számára lényegében egyenértékű védelmet nyújt. Ha a szolgáltató nincs tanúsítva, a GDPR 46. cikke szerinti, a Bizottság által elfogadott szerződési záradékok jelentik a tartalék megoldást, ahogy a 108. preambulumbekezdés leírja. A megfelelőségi határozat felfüggeszthető, módosítható vagy visszavonható, ha a védelem már nem biztosított, ezért a szerződéses záradékoknak készen kell állniuk, mielőtt szükség lenne rájuk.

**Betanítás ügyfél-e-mailekkel.** Az EDPB 28/2024. számú véleménye szerint azt, hogy a személyes adatokkal betanított AI-modell anonim-e, esetenként kell megítélni, mert a személyes adatok a modellből egyes esetekben közvetlenül vagy lekérdezések révén kinyerhetők. Ugyanez a vélemény szerint a jogellenesen kezelt személyes adatokkal fejlesztett modell befolyásolhatja későbbi üzembe helyezésének jogszerűségét, hacsak a modell nincs megfelelően anonimizálva. A funkciónak ezért nem szabad ügyfél-e-mailekkel finomhangolnia a modellt. Bármilyen ilyen terv új cél, amelynek külön értékelésre van szüksége.

## Intézkedések, felelősök és maradék kockázat

A táblázat minden kockázatot felsorol az intézkedések előtti és utáni saját besorolásommal, valamint azzal az intézkedéssel, amely a besorolást megváltoztatja. A felelősök szerepkörök, nem nevek, így a nyilvántartás túléli a személyi változásokat. A besorolások az én ítéletem erre a példára, nem mért értékek.

Kockázat és alap

Előtte

Intézkedés és felelős

Utána

Kitalált személyes adatok a vázlatban (GDPR 5. cikk (1) bekezdés d) pont)

Nagy valószínűség, közepes hatás

Csak a prompton belüli rendelési rekordból származó adatok; minden választ egy ember hagy jóvá (ügyfélszolgálati vezető, ML-mérnök)

Alacsony

B személy adatai A személy válaszában (32. és 33. cikk)

Közepes valószínűség, nagy hatás

A lekérdezés az ellenőrzött feladóra szűkítve; kliensek közötti szivárgás tesztje minden kiadás előtt (backend-vezető)

Alacsony

Az e-mailbe rejtett utasítások (OWASP LLM01)

Nagy valószínűség, nagy hatás

Nincs e-mailt küldő vagy rendelést módosító eszköz; az e-mail szövege adatként kezelve; piros csapatos tesztkészlet kiadás előtt (biztonsági mérnök)

Közepes, az ellenőrzésnél kiszűrve

Naplók és megőrzés a szolgáltatónál (28. cikk, 5. cikk (1) bekezdés e) pont)

Alapértelmezetten valószínű, közepes hatás

Adatfeldolgozói feltételek dokumentált utasításokkal; írásban rögzített megőrzési idő; Zero Data Retention csak jóváhagyással (jogi és beszerzési terület)

Alacsony–közepes

Továbbítás az EU-n kívüli szolgáltatónak (13. cikk (1) bekezdés f) pont, 46. cikk)

Biztos, közepes hatás

DPF-tanúsítás ellenőrzése vagy szerződéses záradékok aláírása; továbbítási közlemény az adatvédelmi tájékoztatóban (adatvédelmi tisztviselő)

Alacsony, a megfelelőségi határozat változásakor újra vizsgálva

Különleges adatok következtetése a rendelési előzményekből (9. cikk (1) bekezdés)

Közepes valószínűség, nagy hatás

A promptba csak az aktuális rendelés kerül; az egészségre utaló termékelőzmény kizárva (ügyfélszolgálati vezető)

Alacsony

E-mailek betanításra használva (6. cikk (1) bekezdés f) pont, 28/2024. vélemény)

Kis valószínűség, nagy hatás

A szerződés kizárja az API-adatok betanítását; e-mailekkel nem finomhangolunk új értékelés nélkül (termékfelelős)

Alacsony

Egyik sor sem marad magas az intézkedések után, ezért ezek a feltevések mellett nincs szükség a 36. cikk szerinti előzetes konzultációra. Két sor marad az „alacsony” szint felett: a prompt injection és a szolgáltatónál történő megőrzés. Mindkettőt elfogadnám és rögzíteném, az adatvédelmi tisztviselő véleményével együtt.

## Hogyan illeszkedik az EU AI Act

Az AI Act nem helyettesíti a DPIA-t, a kettő párhuzamosan fut. A rendelet a 113. cikk szerint 2026. augusztus 2-tól alkalmazandó. Egy ügyfélszolgálati asszisztensnél az átláthatósági kötelezettség az, amelyet először ellenőriznék, ahogy a 132. preambulumbekezdés leírja: az embereket tájékoztatni kell arról, hogy AI-rendszerrel lépnek kapcsolatba, kivéve, ha ez egy észszerűen tájékozott személy számára nyilvánvaló. Ezek fejlesztői oldalához lásd az [50\. cikkről szóló ellenőrzőlistámat](https://balazscsorba.com/hu/blog/eu-ai-act-article-50-developer-checklist). A 20. preambulumbekezdés a szolgáltatók, a használók és az érintett személyek MI-kompetenciáját is hangsúlyozza, ez a második dolog, amire készülni kell.

A magas kockázatú kötelezettségek más kérdés. A III. melléklet 5. pontjának b) alpontja azokat az AI-rendszereket sorolja fel, amelyeket természetes személyek hitelképességének értékelésére vagy hitelpontszám megállapítására használnak, a csalásfelderítés kivételével. Egy ügyfélszolgálati asszisztens nincs ezen a listán. A 2026/1744. számú rendelet (a digitális omnibusz az MI-ről), 2026. július 8-án kelt, a III. melléklet szerinti magas kockázatú szabályok alkalmazási dátumát 2027. december 2-ra, az I. melléklet szerinti rendszerekét pedig 2028. augusztus 2-ra tolja el. A módosítás 40. preambulumbekezdése továbbra is 2026. augusztus 2-t tekinti az általános alkalmazási dátumnak. Az 50. cikk szerinti átláthatósági kötelezettségeket a módosítás nem halasztotta el: ezek 2026. augusztus 2-tól alkalmazandók.

## Mit csinálnék először

1.  Írd le a célt, a prompt-mezőket és a megőrzést egy nyilvántartásban, és küldd el az adatvédelmi tisztviselőnek, mielőtt az első pilot elindul.
2.  Írd le írásban a fehérlistás mentesség indokát, és kérj jogi véleményt a DSFA-A01-ről és a továbbított e-mailekben szereplő harmadik fél adatairól.
3.  Korlátozd a promptot a rendelési mezőkre és egy maszkolt e-mailre, és csak azt naplózd, amire a minőségellenőrzésnek szüksége van.
4.  Készíts valódi e-mailekből piros csapatos tesztkészletet, benne a becsempészett utasításokkal, és tedd a kiadási ellenőrzés részévé.
5.  Írd alá az adatfeldolgozói feltételeket a szolgáltatóval, a megőrzési és betanítási beállításokat pedig a szerződésből vedd, ne egy weboldalról.
6.  Állítsd be a felülvizsgálati kiváltókat a nyilvántartásban: új szolgáltató, új promptmező és az e-mailek bármilyen betanításra való használata.

## Források

1.  [Az (EU) 2016/679 rendelet (GDPR), EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
2.  [A WP29 DPIA-iránymutatása, WP248 rev.01 (az Európai Bizottság oldala)](https://ec.europa.eu/newsroom/article29/items/611236/en)
3.  [WP248 rev.01 PDF, elfogadva 2017. április 4-én, módosítva 2017. október 4-én](https://ec.europa.eu/newsroom/just/document.cfm?doc_id=47711)
4.  [EDPB-iránymutatás 07/2020: az adatkezelő és az adatfeldolgozó fogalma](https://www.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf)
5.  [EDPB-vélemény 28/2024 az AI-modellekről, elfogadva 2024. december 17-én](https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf)
6.  [EDPB-közlemény a 28/2024. számú véleményről](https://www.edpb.europa.eu/news/edpb-opinion-on-ai-models-gdpr-principles-support-responsible-ai_en)
7.  [EDPB: a ChatGPT-munkacsoport munkájáról szóló jelentés, 2024. május 23.](https://www.edpb.europa.eu/system/files/2024-05/edpb_20240523_report_chatgpt_taskforce_en.pdf)
8.  [DSFA-V, BGBl. II Nr. 278/2018 (RIS)](https://www.ris.bka.gv.at/eli/bgbl/II/2018/278)
9.  [DSFA-AV, BGBl. II Nr. 108/2018 (RIS)](https://www.ris.bka.gv.at/eli/bgbl/II/2018/108)
10.  [OWASP Top 10 LLM-alkalmazásokhoz, 2025: LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
11.  [OWASP Top 10 LLM-alkalmazásokhoz, 2025: LLM02 Érzékeny információk kiszivárgása](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)
12.  [OpenAI: adatkezelési beállítások az OpenAI-platformon](https://developers.openai.com/api/docs/guides/your-data)
13.  [A Bizottság (EU) 2023/1795. számú végrehajtási határozata az EU–USA adatvédelmi keretrendszerről](https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj/eng)
14.  [EU Bíróság, C-184/20. sz. ügy, OT kontra Vyriausioji tarnybinės etikos komisija](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62020CJ0184)
15.  [Az (EU) 2024/1689 rendelet (AI Act), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
16.  [Az (EU) 2026/1744 rendelet (digitális omnibusz az MI-ről), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)

## Gyakori kérdések

Kell DPIA minden ügyfélszolgálati chatbothoz?

Nem. A GDPR 35. cikkének (1) bekezdése csak akkor írja elő, ha a kezelés valószínűleg magas kockázattal jár, a WP29-kritériumok pedig segítenek eldönteni ezt. Egy sablon, amely egyetlen mezőből tölti ki a választ, lehet, hogy egyiknek sem felel meg. Egy asszisztens, amely e-maileket olvas, rendelési adatokkal kapcsol össze és külső szolgáltatónak küld, többnek is megfelelhet, ezért érdemes elvégezni és leírni az elemzést.

Kötelező-e DPIA Ausztriában az MI-funkciókhoz?

Lehet. A DSFA-V (BGBl. II Nr. 278/2018) 2. §-a DPIA-t ír elő, ha hat kritérium közül legalább egy teljesül, és a Z 4 kritérium kifejezetten említi a mesterséges intelligenciát. Ami a DSFA-AV (BGBl. II Nr. 108/2018) szerint mentesül, nem igényel DPIA-t, és az ügyféladminisztráció szerepel ezen a listán. Hogy a mentesség illik-e a konkrét kezelésre, jogi kérdés, ezért kérj jogi véleményt, mielőtt támaszkodnál rá.

Mit kell tartalmaznia egy DPIA-nak?

A GDPR 35. cikkének (7) bekezdése négy dolgot kér: a kezelés és céljainak rendszerszintű leírását, beleértve a jogos érdeket, ha van ilyen; a szükségesség és az arányosság értékelését; az érintettekre nézve fennálló kockázatok értékelését; és a kockázatok kezelésére tervezett intézkedéseket, beleértve a garanciákat és a biztonságot.

Mikor kell konzultálni a felügyeleti hatósággal?

A GDPR 36. cikke szerint, ha a DPIA azt mutatja, hogy a tervezett intézkedések után is magas a kockázat. A konzultációt a kezelés megkezdése előtt kell lefolytatni.

Helyettesíti az EU AI Act a DPIA-t?

Nem. Az AI Act saját kötelezettségeket állapít meg, például annak jelzését, hogy valakivel AI-rendszer beszél, és a listázott felhasználásokra vonatkozó magas kockázatú szabályokat. A GDPR szerinti kötelezettség, hogy értékeld az emberek adataira nézve fennálló kockázatot, ezek mellett továbbra is érvényes.

Í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

-   [Kódoló ügynökök és titkok: kulcsok a kontextuson, logokon és commitokon kívül](https://balazscsorba.com/hu/blog/coding-agent-secrets-hygiene)
-   [AI-kódolóeszközök és üzemi tanács: mikor számít megfigyelésnek a napló](https://balazscsorba.com/hu/blog/works-council-ai-tools-austria-germany)
-   [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)
-   [EU AI Act, Article 50: a fejlesztők teendői 2026. augusztus 2-tól](https://balazscsorba.com/hu/blog/eu-ai-act-article-50-developer-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)