AlignDP az egészségügyben: LLM-ek adatvédelmi zárja

A kórházakban és rendelőkben ma már nem az a kérdés, hogy lesz-e generatív AI, hanem az, hogy hogyan lehet úgy bevezetni, hogy a betegadatok ne csússzanak ki a rendszerből. A valós kockázat nem csak az, hogy valaki „megnézi” a modellt. Hanem az, hogy egy rosszul védett nyelvi modellből vissza lehet nyerni érzékeny információkat: ritka diagnózist, egyedi eseményt, vagy akár olyan mondatokat, amelyek túl közel vannak a tanító adatokhoz.

A 2025.12.22-én frissen megjelent AlignDP kutatás egy érdekes irányt képvisel: nem utólagos ellenőrzésre (monitoring, watermark) épít, hanem a tudás „átvitelét” próbálja megakadályozni már az adat-interfésznél. Magyarul: mintha nem a szivárgást keresnénk a padlón, hanem eleve elzárnánk a csapot.

Az egészségügyben ez különösen aktuális, mert a betegadatoknál a „ritka” nem mellékes kategória: pont a ritka esetek a legkönnyebben visszakövethetők. És gyakran pont ezek a legértékesebbek klinikai szempontból.

Miért veszélyesek a nyelvi modellek az egészségügyben?

A lényeg: az LLM-eket ki lehet „faggatni”. Nem mindig, nem minden esetben, de a támadási felület valós, és több csatornán jöhet.

Kivonás, desztilláció, jogosulatlan finomhangolás – mi ez a gyakorlatban?

• Model extraction (modellkivonás): valaki sok lekérdezéssel közelíti a modell viselkedését, és készít egy „másolat-szerű” modellt.
• Distillation (desztilláció): a nagy modell válaszai alapján tanítanak egy kisebbet (olcsóbb futtatás, könnyebb terjesztés).
• Unauthorized fine-tuning (jogosulatlan finomhangolás): a modellt úgy finomhangolják, hogy a kimenete megfeleljen egy külső szereplő céljainak, akár a belső adatok „kijátszására” is.

Az egészségügyben ezek azért fájnak, mert egy modellből kinyerhető:

• egy ritka betegség + konkrét élethelyzet kombinációja,
• egyedi kezelési útvonalak,
• intézményi protokollokra utaló belső szövegek,
• vagy egyszerűen olyan kifejezések, amelyek egy adott betegcsoportra „rámutatnak”.

Röviden: a betegadatoknál nem csak a név és a TAJ érzékeny. Az is, ami „ritkán fordul elő” – mert az válik azonosítóvá.

AlignDP: kétlépcsős védelem, ritkaságra optimalizálva

Az AlignDP ötlete egy mondatban: külön kezeli a ritka és a nem ritka mezőket, és más-más adatvédelmi eszközt választ mindkettőre.

1) Ritka mezők: „szinte zéró” lokális adatvédelem PAC-indisztingválhatósággal

A szerzők a ritka kategóriákat (rare fields) olyan védelemmel fedik, amit PAC indisztingválhatóságnak neveznek. A cikk állítása szerint ez a gyakorlatban effektíve zéró-epszilon lokális differenciális adatvédelem (local DP) jellegű védelmet ad a ritka eseményekre.

Egészségügyi fordításban: ha valami ritka (például egy nagyon kevés embert érintő genetikai szindróma, egy ritka gyógyszer-mellékhatás, vagy egy szűk demográfiai csoporthoz kötött állapot), akkor a rendszer úgy viselkedik, hogy az egyedi ritkaság ne „lógjon ki” a statisztikából.

Itt a legfontosabb döntés nem matematikai, hanem termék- és adatstratégiai:

• Mit tekintünk ritkának?
• Hol húzzuk meg a küszöböt?
• Mi történik, ha egy mező idővel gyakoribbá válik?

2) Nem ritka mezők: RAPPOR-alapú zajosítás, de használható statisztikákkal

A gyakoribb mezőknél (non-rare fields) AlignDP a RAPPOR módszert használja. Ennek lényege, hogy lokális DP mellett is lehet torzítatlan gyakorisági becslést készíteni, ha elég adat érkezik, és jól kalibrált a zaj.

Klinikai és operatív példák:

• tünetek gyakorisága (pl. köhögés, láz, mellkasi fájdalom),
• osztályos folyamatok (pl. átlagos ápolási idő),
• telemedicina-üzenetek témái (pl. gyógyszerkérdés, kontroll időpont),
• protokoll-szintű események (pl. milyen gyakran rendelnek el bizonyos vizsgálatot).

A cél itt nem az, hogy minden egyedi sor „igaz” maradjon, hanem hogy összesítve értelmes, döntéstámogató képet kapjunk.

3) Globális aggregátor: költségkeret (privacy budget) és kompozíció

AlignDP bevezet egy globális aggregátort, ami felügyeli, hogy a különböző adatvédelmi mechanizmusok összhatása ne fusson túl a vállalt privacy budgeten.

Ez egészségügyben kritikus, mert a valós rendszerekben:

• sok lekérdezés fut,
• sok osztály kér adatot,
• sok modell és dashboard él egymás mellett,
• és a „még egy riport” jellegű igények szépen lassan felemésztik az adatvédelmi keretet.

Az AlignDP szemlélete itt hasznos: költségvetésként kezeli a privát információ „elkölthetőségét”.

Hogyan nézne ki AlignDP egy kórházi AI-rendszerben?

Az ötlet akkor válik kézzelfoghatóvá, ha elképzelünk egy tipikus kórházi felhasználást: egy belső, zárt generatív asszisztens segít a dokumentációban, triázs-összefoglalókban és a betegutak elemzésében.

Példa: telemedicina + tünetösszefoglaló LLM

Adatforrás: beteg chatüzenetek, előzmények, zárójelentés-részletek.

• Ritka mezők: ritka diagnózisok, ritka gyógyszerkombinációk, extrém laborértékek, nagyon specifikus élethelyzetek.
• Nem ritka mezők: általános tünetek, időpontfoglalási témák, gyakori gyógyszerek, standard vizsgálatok.

Mit csinál AlignDP?

1. A ritka elemeket olyan módon védi, hogy a modell kimenetében ne legyen „kihúzható” ritka információ.
2. A gyakori elemeket zajosítja, de úgy, hogy a rendszer később is vissza tudja becsülni: mi mennyire gyakori.
3. Az aggregátor figyeli, hogy a rendszer ne „pazarlja el” a privacy budgetet a sok kérdezéssel.

A hozadék: az asszisztens képes segíteni a mindennapi folyamatokban, miközben a ritka, azonosítható esetek kevésbé válnak kinyerhetővé.

A legfontosabb trade-off: adatvédelem vs. klinikai hasznosság

Az AlignDP egyik értéke, hogy kimondja: nem ugyanazt kell védeni ugyanúgy. A ritka eseményeknél az adatvédelmi kár sokkal nagyobb, mint amennyi hasznosságot egy „pontos” ritka-statisztika ad.

Mikor éri meg agresszíven védeni a ritkát?

Egészségügyben szerintem szinte mindig, ha:

• a ritkaság önmagában azonosító lehet (kis település + ritka betegség),
• a kimenet szöveges (narratív), és könnyen „idézhető”,
• a modell külső vagy félig külső felületre kerül (partner, alvállalkozó, több intézmény).

Mikor fontosabb a pontosság a gyakori eseményeknél?

• kapacitástervezés (ágykihasználtság, triázs-terhelés),
• járványszerű tünetminták észlelése (szezonális hullámok),
• telemedicina csatornák optimalizálása,
• minőségbiztosítás és folyamatfejlesztés.

A trükk: a gyakori eseményeknél a zaj „kisimul” sok adat esetén. A ritka eseményeknél viszont a zaj nem kisimul, hanem pont a lényeget rejti el. És ez itt cél.

Gyakorlati bevezetési ellenőrzőlista (kórházaknak és fejlesztőknek)

Ha az AlignDP gondolatát egy egészségügyi AI-projektben szeretnéd használni, ezek a lépések működnek jól.

1) Definiáld a „ritka” küszöböt üzleti és etikai alapon

Ne csak statisztikából indulj ki. A küszöb legyen összhangban:

• betegjogi kockázattal,
• intézményi reputációs kockázattal,
• és a klinikai értékkel.

2) Oszd szét az adatmezőket két szintre

Készíts egy egyszerű táblázatot:

• Ritka mezők (szigorú védelem)
• Nem ritka mezők (lokális DP zajosítás)

Ezt érdemes időszakosan felülvizsgálni (például negyedévente), mert a gyakoriság változik.

3) Tervezz privacy budgetet úgy, mint pénzügyi keretet

A legtöbb szervezet ott rontja el, hogy a budget „láthatatlan”. Pedig ettől lesz irányítható.

• Mely riportok kapnak több keretet?
• Mely API-k hívhatók gyakrabban?
• Milyen felhasználók kapnak részletesebb aggregációt?

4) Mérd a hasznosságot konkrét hibaszámokkal

Az AlignDP is hangsúlyozza a hasznossági kompromisszumot. Ezt a gyakorlatban így érdemes mérni:

• gyakori kategóriáknál átlagos abszolút hiba (MAE) gyakoriságokra,
• ritka kategóriáknál „szivárgási tesztek” (pl. célzott promptok),
• üzleti KPI-k (várakozási idő, újrafelvétel, dokumentációs idő).

Mit jelent ez a „Mesterséges intelligencia az egészségügyben” sorozat szempontjából?

A diagnosztikai támogatás, az orvosi képalkotás és a kórházi működésoptimalizálás mind ugyanabba a falba ütközik: adat kell, de nem mindegy, hogyan védjük. A generatív modellek esetében ráadásul az adat nem csak adatbázisban él, hanem „mintázatként” a modellben is.

Az AlignDP üzenete számomra egyszerű és hasznos: a privát információ nem homogén. A ritka esetek aránya kicsi, de a kockázatuk nagy. Ezért érdemes ritkaság-tudatos adatvédelmet tervezni, és nem egyetlen, mindent egyformán kezelő mechanizmust ráhúzni a teljes rendszerre.

A következő lépés az egészségügyi bevezetéseknél az lesz, hogy a privacy engineering ugyanúgy része lesz a projektnek, mint a modellválasztás vagy az MLOps. És aki ezt előbb építi fel jól, az gyorsabban fog tudni biztonságosan skálázni.

Ha 2026-ban belső LLM-et vezetsz be kórházi környezetben, a „ritka események védelme” nem extra funkció. Alapfeltétel.

Ha érdekel, hogyan lehet egy telemedicina vagy kórházi asszisztens rendszert úgy megtervezni, hogy a klinikai hasznosság megmaradjon, de a privacy budget kontrollálható legyen, érdemes a következő tervezési workshopot már ezzel a szemlélettel indítani: ritkát elrejteni, gyakorit mérni, budgetet menedzselni. Hol kezdenéd a saját adataidnál a „ritka” definícióját?