TL;DR
Az API-alapú AI-használat egyszerű, de minden kéréssel adatot küldesz egy külső szervernek. GDPR-érzékeny, bizalmas üzleti és orvosi adatok esetén ez nemcsak kockázat, hanem jogszabályi tilalom. A lokális modell-futtatás (on-premise LLM) ma már nem csak a nagyoknak szóló lehetőség — kis és közepes vállalkozások is deployálhatnak 7-14B paraméteres modelleket olyan hardveren, ami beefér egy szobába. A kérdés nem technológiai — hanem az, hogy ki viseli a felelősséget az adatért.
A kolléga, aki minden meetingjegyzetét beillesztette a ChatGPT-be
Ismerem ezt a szituációt. Egy kkv-ban dolgozó vezető tanácsadó naponta összefoglaltatja a ChatGPT-vel a belső megbeszélések szöveges átiratát. Gyors, kényelmes, az összefoglalók jók. A kolléga boldog. Az IT vezető — aki erről csak hónapokkal később értesül — kevésbé.
Nem azért, mert a ChatGPT “rossz”. Hanem mert minden egyes kérés elküldte az OpenAI szervereire a belső stratégiai megbeszélések tartalmát. Ügyféladatokkal. Üzleti tervekkel. Néhány esetben személyes adatokkal, amelyek GDPR-hatálya alá esnek.
Ez nem elvont jogi aggály. Ez a mindennapi AI-használat legrejtettebb kockázata.
Mit jelent a “data residency” és miért számít?
A “data residency” (adat-elhelyezkedés) azt jelöli, hogy az adatokat fizikailag hol tárolják és dolgozzák fel. Az EU GDPR keretein belül ez kritikus: személyes adatokat csak olyan szerveren szabad feldolgozni, amely megfelel az EU adatvédelmi követelményeinek — vagy ahol az adatkezelő érvényes adatfeldolgozói megállapodást kötött.
Az API-alapú AI-modell esetén a helyzet a következő:
- Az adat elhagyja a vállalatot és átmegy egy külső szerverre
- A szerverek fizikailag lehetnek az USA-ban, Írországban, bárhol
- A prompt tartalma potenciálisan bekerülhet a modell jövőbeli tanítóadatai közé (amennyiben nem kötöttél opt-out megállapodást)
- A felelősség megosztott — és bizonyítani kell
Ezzel szemben az on-premise futtatásnál az adat soha nem hagyja el a vállalati infrastruktúrát. Ez nem marketing szöveg — ez egy architekturális tulajdonság. A modell fut a saját szerveredén, a kérés helyben feldolgozódik, a kimenet helyben marad.
Konkrét iparágak, ahol ez nem opció — hanem kötelező
Három iparág, ahol az on-premise LLM ma már nem ajánlás, hanem elvárás:
Egészségügy és klinikai döntéstámogatás
Az orvosi dokumentáció, betegadatok, diagnózisok GDPR szempontból különleges kategóriájú személyes adatok. Ezeket kórházon, klinikán kívülre küldeni — beleértve egy API-kérésbe csomagolva is — szabálysértés. Több európai kórházcsoport már telepített helyi Llama-alapú modelleket orvosi összefoglalók és ápolási dokumentáció generálásához. Nem azért, mert olcsóbb (néha nem az), hanem mert törvényesen csak így mennek a dolgok.
Jogi és pénzügyi tanácsadás
Egy ügyvédi iroda belső szerződésvázlatai, egy bank ügyfél-hitelkérelmei, vagy egy M&A tranzakció dokumentumai nem mehetnek ki a szervezeti hálózatból — sem felhőbe, sem partnerhez, sem AI API-ba. A titokvédelmi és üzleti titoktartási kötelezettségek ezt explicit tiltják. On-premise LLM esetén a dokumentum-összefoglaló, a kockázatkeresés és a jogi szöveg-elemzés belső infrastruktúrán futhat.
Gyártóipari és védelmi ipari KKV-k
A duális felhasználású technológiák, a gyártási eljárások, az anyagösszetételek és a minőség-ellenőrzési protokollok ipari titkot alkotnak. Egy külföldi API-nak küldött prompt ezeket potenciálisan kiteszi. Különösen igaz ez a NATO-ellátási láncban részt vevő vállalatokra, ahol a biztonsági előírások az adatkezelésre vonatkozóan szigorúbbak a GDPR-nál is.
Hogyan mérhető az adatvédelmi kockázat API vs. on-premise között?
Nem minden adat egyforma. Érdemes egy egyszerű kockázati kerettel gondolkozni:
Alacsony kockázat — API mehet:
- Nyilvánosan elérhető tartalom feldolgozása
- Általános szövegírás, marketing copy, SEO tartalom
- Semmilyen személyes vagy bizalmas adatot nem érint a prompt
Közepes kockázat — körültekintés kell:
- Belső dokumentumok, ahol nincs személyes adat, de üzleti stratégia igen
- Partneri levelezés, amely üzleti tervet tartalmaz
- Fejlesztői kód, amely infrastruktúra-detaileket tartalmaz
Magas kockázat — on-premise kötelező:
- Személyes adatot tartalmazó dokumentumok (GDPR-érzékeny)
- Orvosi, pénzügyi, jogi ügyféladatok
- Minősített vagy üzleti titkot alkotó anyagok
- Belső HR folyamatok, teljesítményértékelések
A kockázat mérése nem rakétatudomány: elegendő végigmenni a feldolgozandó dokumentumokon és megkérdezni — “ha ez kiszivárogna, ki szenvedne kárt és mennyit?”
Az on-premise LLM nem egy szerverfarm
Az egyik legelterjedtebb tévhit: az on-premise futtatás csak nagyvállalatoknak lehetséges, mert drága és összetett infrastruktúrát igényel.
2026-ban ez már nem igaz. A jelenlegi reális lehetőségek:
Egy Qwen2.5-14B Q4_K_M kvantizált modell egy NVIDIA RTX 4090-es GPU-n (24 GB VRAM) production minőségű szöveggenerálást futtat, latenciája 1-3 másodperc / válasz. Az RTX 4090 ára ma kb. 1500-1800 EUR. Egy közepes méretű cégnél ez egyszeri infrastruktúra-beruházás, ami megtérül az API-megtakarításon.
Még ennél is kisebb footprinttel: egy Apple M2/M3 Pro Mac Studio (64 GB unified memory) stabil minőséggel futtat 13-30B paraméteres modelleket. Sok tanácsadó iroda és klinika ezt a megoldást választja — asztali méretű, csendes, egyszerű karbantartású.
A szoftver oldalon az Ollama és az LM Studio tette mindezt telepíthető és menedzselhető szintre. Egy IT-értő csapat egy nap alatt deployálhat egy működő, API-hívható belső LLM-et.
A felelősség kérdése
Az on-premise vs. API döntés végső soron nem technológiai — hanem felelősségi kérdés.
Ha API-t használsz: az adatkezelési felelősség egy részét átadod a szolgáltatónak. Cserébe kényelmet és teljesítményt kapsz. Ez elfogadható megállapodás — de tudatosan kell megkötni, és dokumentálni kell.
Ha on-premise-t választasz: teljes kontrollt tartasz. Az adatok nem hagyják el az infrastruktúrát, a feldolgozás auditálható, a megfelelőség bizonyítható. Cserébe több munkát vállalsz a telepítésben és a karbantartásban.
A probléma nem az API vagy az on-premise. A probléma az, amikor valaki nem döntött tudatosan — csak elkezdte használni a legkényelmesebb eszközt, anélkül hogy feltette volna a kérdést: “ki viseli a felelősséget ezért az adatért?”
Mert ha ezt nem teszed fel, a válasz alapértelmezésben te leszel.
Kapcsolódó gondolatok
- GGUF kvantizálás a gyakorlatban — Q4, Q5, Q8: melyiket válaszd?
- Kis modellek, nagy hatás — a 7B elég?
Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership Az adatért mindig valaki felel — legyen az tudatos döntés, ne véletlen következmény.