Ez a cikk az LLM Modellválasztás Üzleti Döntései tanulmány 4. része. További részek: A 2026-os LLM piac térképe, Feladatalapú modellválasztás és benchmark-ok, Költségoptimalizálás és routing stratégia.
Biztonság, compliance és adatrezidencia
A mesterséges intelligencia üzleti bevezetésénél a teljesítmény és a költség mellett a harmadik — sokszor legfontosabb — dimenzió a biztonság és a szabályozási megfelelés. Egy rosszul megválasztott deployment modell nemcsak adatvédelmi kockázatot jelent, hanem jogi következményekkel is járhat. Ebben a fejezetben áttekintjük, melyik szolgáltató hogyan kezeli az adatokat, mit jelent az EU AI Act a modellválasztás szempontjából, és hogyan válasszunk szektorspecifikus igények alapján.
Az AI modell adatkezelési modelljei
Az alábbi táblázat összefoglalja a hat leggyakoribb deployment modellt abból a szempontból, hogy ki dolgozza fel az adatot, hol történik a feldolgozás, és felhasználják-e az adatot a modell további tanítására.
A legfontosabb különbség az, hogy az üzleti API-k alapértelmezetten nem használják az adatokat a modell továbbképzésére — de ez nem mindig volt így, és a feltételek változhatnak. Az Azure OpenAI és a Google Vertex AI előnye, hogy az adatfeldolgozás régiója választható, így EU-n belül tartható. A Mistral natívan európai szolgáltató, ami GDPR szempontból előnyös. A lokális modell pedig teljes kontrollt biztosít — de ennek ára a hardware és a karbantartás.
EU AI Act hatása a modellválasztásra (2026)
Az EU AI Act 2026-ban már aktívan hatályban van, és közvetlen hatással van arra, hogyan alkalmazhatók a nagy nyelvi modellek üzleti környezetben. A szabályozás két fő területen érinti a modellválasztást.
Magas kockázatú alkalmazások (egészségügy, foglalkoztatás, hitelezés):
- Kötelező emberi felügyelet — A modell csak javaslatot tehet, nem hozhat önálló döntést. Ez azt jelenti, hogy az AI rendszer kimenete minden esetben egy emberi döntéshozó elé kerül, aki jóváhagyja vagy felülbírálja azt.
- Átláthatóság — A felhasználónak tudnia kell, hogy mesterséges intelligenciával kommunikál. Ez különösen fontos chatbot és ügyfélszolgálati alkalmazásoknál, ahol a felhasználó természetes emberi interakciót feltételezhet.
- Dokumentáció — Az AI döntési lánca auditálható kell legyen. Minden bemenetet, kimenetet és a modell által alkalmazott logikát naplózni kell, hogy utólag visszakövethető legyen, miért született egy adott javaslat.
- Modellválasztási következmény — Előnyben részesítendők a dokumentált, auditálható modellek. Az OpenAI és Anthropic enterprise API-jai audit naplókkal rendelkeznek, amelyek megfelelnek ezeknek a követelményeknek. A lokális modelleknél a naplózást nekünk kell megoldani.
Általános célú AI modellek (GPAI):
- A 10^25 FLOP feletti tréning-kapacitással rendelkező modellek rendszerkockázatúnak minősülnek, ami extra kötelezettségeket ró a modell szolgáltatójára (nem a felhasználóra).
- Ez közvetlenül nem a modellt használó vállalat felelőssége, de a szolgáltató megfelelőssége befolyásolja a kockázati profilt. Ha egy szolgáltató nem felel meg az EU AI Act követelményeinek, az az őt használó vállalat számára is kockázatot jelent.
Szektorspecifikus adatvédelmi szempontok
Az adatvédelmi kockázat nem egyforma minden iparágban. Az alábbi táblázat az öt leggyakoribb szektor szempontjából foglalja össze, milyen típusú érzékeny adatokkal dolgozunk, és milyen deployment modellt ajánlunk.
Az egészségügyben és a jogi szektorban a legmagasabb a kockázat, ezért ezekben az ágazatokban a lokális modell vagy a garantáltan EU-n belüli feldolgozás az ajánlott. A pénzügyi szektorban a SOC 2 tanúsítvány jelenti a biztonsági minimumot. A szépségiparban — ahol személyes és egészségügyi adatok (például allergiák) keverednek — az EU-n belüli feldolgozás elegendő. A marketingben a kockázat alacsonyabb, itt bármely szolgáltató megfelelő, amennyiben rendelkezik Data Processing Agreement-tel (DPA).
A döntési fa: melyik deployment modellt válasszuk?
Az alábbi döntési fa segít eligazodni a leggyakoribb forgatókönyvek között:
Az adat érzékeny (egészségügyi, jogi)?
├── Igen → Az adat elhagyhatja a szervezetet?
│ ├── Nem → LOKÁLIS MODELL (Llama, Mistral 7B)
│ └── Igen, de EU-n belül → AZURE OPENAI EU vagy MISTRAL EU
└── Nem → Az ár a prioritás?
├── Igen → OPENAI API (GPT-4o-mini) vagy GEMINI FLASH
└── Nem, a minőség → CLAUDE SONNET vagy GPT-4o
A döntési fa első kérdése mindig az adatérzékenység. Ha az adat érzékeny és nem hagyhatja el a szervezetet, nincs más választás: lokális modell kell. Ha elhagyhatja, de EU-n belül kell maradnia, az Azure OpenAI EU vagy a Mistral a megoldás. Ha az adat nem érzékeny, akkor a döntés az ár és a minőség közötti kompromisszumra egyszerűsödik.
Lokális modellek — Mikor éri meg?
A lokális (on-premise vagy self-hosted) modellek egyre népszerűbbek, különösen azóta, hogy a Meta Llama és a Mistral nyílt súlyú modelljei megközelítik a zárt modellek teljesítményét. De a lokális futtatás nem minden esetben a legjobb választás. Nézzük meg részletesen, mikor éri meg és mikor nem.
Az előnyök
-
Teljes adatkontroll — Az adat soha nem hagyja el a szervert. Nincs harmadik fél, nincs adattovábbítás, nincs kockázat, hogy a szolgáltató megváltoztatja az adatkezelési feltételeit. Ez a legnagyobb előny az érzékeny szektorok számára.
-
Nulla API költség — A hardware amortizáción túl nincs token-enkénti díj. Aki napi tízezres nagyságrendben futtat lekérdezéseket, az hosszú távon jelentősen olcsóbban jár lokális modellel, mint cloud API-val.
-
Offline működés — Nincs internetfüggőség. Gyártósorokon, hajókon, repülőgépeken, távoli helyszíneken is működik. Ahol nincs stabil internet, ott a cloud API egyszerűen nem opció.
-
Latency kontroll — A válaszidőt a saját hardverünk határozza meg, nem a szolgáltató terhelése. Csúcsidőben nincs lassulás, nincs sorban állás, nincs rate limiting. A latency kiszámítható és tervezhető.
-
Korlátlan használat — Nincs rate limit, nincs token kvóta, nincs havi keretösszeg. A modellt annyiszor hívhatjuk, amennyiszer szükséges, bármilyen méretű kontextussal (a hardware korlátain belül).
A hátrányok
-
Hardware költség — Egyetlen NVIDIA A100 GPU ára körülbelül 15 000 dollár, éves cloud bérleti díja pedig körülbelül 12 000 dollár GPU-nként. Egy 70B-s modell futtatásához minimum 2 ilyen GPU kell, ami komoly kezdeti befektetést jelent.
-
Minőségi rés — A Llama 3.3 70B kiváló modell, de nem éri el a GPT-4o szintjét, különösen bonyolult reasoning, árnyalt magyar nyelvű szövegek és összetett tool calling feladatok esetén. A rés csökken, de még létezik.
-
Tool calling megbízhatatlanság — A nyílt modellek tool calling képessége jelentősen gyengébb, mint a zárt modelleké. Az OpenAI GPT-4o tool calling megbízhatósága 95% felett van, míg a Llama 3.3 70B-é 75–85% körül mozog. Üzletkritikus automatizációknál ez elfogadhatatlan.
-
Karbantartás — A modellfrissítések, GPU-monitorozás, skálázás, biztonsági mentés és hibaelhárítás mind a mi felelősségünk. Ez dedikált DevOps/MLOps kapacitást igényel, ami kisebb csapatoknál komoly terhet jelent.
-
Magyar nyelv — A nyílt modellek magyar nyelvi képessége gyengébb, mint a zárt modelleké. A Llama és Mistral modellek tréning adatának túlnyomó része angol nyelvű, ami azt jelenti, hogy magyar szövegek esetén fine-tuning szükséges a megfelelő minőséghez — ez pedig extra munka és szakértelem.
Mikor éri meg a lokális modell?
A táblázat világosan mutatja, hogy a lokális modell két fő esetben egyértelmű nyertes: nagy volumen és érzékeny adatok. A kis- és középvállalkozások számára, ahol napi néhány száz interakció történik, a cloud API lényegesen gazdaságosabb. A tool calling és a magyar nyelv terén a cloud modellek még mindig előnyben vannak, bár ez utóbbi fine-tuninggal javítható.
A hibrid megközelítés
A legtöbb vállalat számára a hibrid megoldás a legrealisztikusabb. Ez nem „vagy-vagy" döntés — a két világ kombinálható, és általában kombinálni is kell.
A hibrid modell lényege egyszerű:
- Érzékeny adatok (ügyfél-azonosítás, egészségügyi adatok, jogi dokumentumok) → lokális modell feldolgozza, az adat nem hagyja el a szervezetet.
- Általános feladatok (chatbot, e-mail generálás, CRM összefoglalók, tartalomkészítés) → cloud API kezeli, ahol a minőség magasabb és a költség alacsonyabb.
- A router dönt — az adattípus határozza meg, hová kerül a kérés. Ha a bemenő adat érzékeny mezőket tartalmaz (személyes azonosító, egészségügyi adat, jogi tartalom), a lokális modellhez irányítja. Ha nem, a cloud API kapja.
Ez a megközelítés egyesíti mindkét világ előnyeit: a cloud modellek minőségét és a lokális modellek adatbiztonságát. A router logikája viszonylag egyszerű, de a kategorizációnak pontosnak kell lennie — egy rosszul besorolt kérés adatvédelmi incidenssé válhat.
A döntési mátrix — Összefoglalás
Eddig elemeztük a szolgáltatókat, a feladattípusokat, a költségeket, a biztonsági szempontokat és a lokális modelleket. Most mindezt egyetlen döntési táblázatba sűrítjük, amely a CTO vagy technológiai vezető számára azonnali cselekvési útmutatót ad.
Az egyoldalas döntési tábla
Ez a táblázat nem azt mondja, hogy egyetlen modell a legjobb — hanem azt, hogy a legjobb modell az adott prioritástól függ. A legtöbb vállalat számára a megoldás egy kombináció: GPT-4o-mini a rutinfeladatokra, Claude Sonnet vagy GPT-4o a komplex feladatokra, és szükség esetén lokális Llama az érzékeny adatokra.
A CTO 5 lépéses akciótervje
Az alábbi öt lépés a modellválasztás gyakorlati megvalósítását segíti — a felméréstől a folyamatos optimalizálásig.
1. lépés: Audit — Milyen feladatokra használjuk (vagy fogjuk használni) az AI-t? Készítsünk listát kategóriánként: GYIK és ügyfélszolgálat, tool calling és automatizáció, adatelemzés és összefoglalás, tartalomkészítés, kódgenerálás. A lista legyen konkrét: ne „AI bevezetése" legyen az első sor, hanem „Napi 500 ügyfélszolgálati üzenet kategorizálása és válaszvázlat generálása".
2. lépés: Osztályozás — Minden feladatot soroljunk be három dimenzió mentén. Először komplexitás szerint: egyszerű (sablon alapú, rövid kontextus), közepes (többlépéses logika, közepes kontextus) vagy komplex (reasoning, tool calling, nagy kontextus). Másodszor adatvédelmi státusz szerint: érzékeny (személyes adatok, egészségügyi, jogi) vagy nem érzékeny (általános tartalom, nyilvános információ). Harmadszor kritikusság szerint: üzletkritikus (hibás kimenet közvetlen üzleti veszteséget okoz) vagy kiegészítő (a kimenet emberi felülvizsgálaton megy át).
3. lépés: Modell-hozzárendelés — A döntési tábla alapján rendeljünk modellt minden feladat-kategóriához. A legtöbb esetben ez a következő kombinációt jelenti: GPT-4o-mini a rutinfeladatokra (ügyfélszolgálat, kategorizálás, egyszerű összefoglalás), Claude Sonnet vagy GPT-4o a komplex feladatokra (reasoning, hosszú dokumentumok elemzése, minőségkritikus tartalom), és szükség esetén lokális Llama 3.3 70B az érzékeny adatokhoz. Ne rendeljünk a legdrágább modellt minden feladathoz — ez felesleges költség minőségi nyereség nélkül.
4. lépés: Provider-agnosztikus architektúra — Ne kódoljunk be egyetlen modellt se. Építsünk adapter réteget, ahol a modellválasztás konfigurációs szinten történik. A gyakorlatban ez azt jelenti, hogy a kód nem tartalmaz közvetlen OpenAI vagy Anthropic API hívásokat, hanem egy köztes rétegen keresztül kommunikál, ahol a modellt, a szolgáltatót és a paramétereket konfigurációval (nem kóddal) állítjuk be. Így ha holnap megjelenik egy jobb vagy olcsóbb modell, egyetlen konfigurációs változtatással átállhatunk rá.
5. lépés: Mérés és iteráció — Mérjünk három dolgot: modellenkénti költség (dollár per 1000 interakció), minőség feladattípusonként (emberi értékelés vagy automatizált metrikák) és latency (válaszidő a felhasználó szempontjából). Ezeket negyedévente vizsgáljuk felül — mert a piac gyorsan változik. Egy modell, ami ma a legjobb ár/érték arányt nyújtja, három hónap múlva lehet, hogy drágább, mint az új versenytárs.
Záró gondolat
A modellválasztás nem egyszeri döntés — hanem folyamatos optimalizáció. Aki ma kiválasztja a legjobb modellt és beégeti a rendszerbe, annak hat hónap múlva szuboptimális rendszere lesz. A piac olyan gyorsan mozog, hogy a 2025 elején legjobb megoldás 2026 elejére már nem a legversenyképesebb.
Aki viszont provider-agnosztikus architektúrát épít feladatalapú routinggal, az mindig a legjobb ár/teljesítmény kombinációt használja — bármit is hoz a piac. A cél nem az, hogy egyszer jól válasszunk. A cél az, hogy a rendszerünk képes legyen mindig jól választani.
Ez a sorozat az LLM Modellválasztás Üzleti Döntései átfogó tanulmányon alapul. Szeretné megtudni, melyik modell-kombináció illik legjobban az Ön vállalatához? Vegye fel velünk a kapcsolatot — segítünk megtalálni az optimális egyensúlyt a költség, a teljesítmény és a biztonság között.