Két éve még az volt a kérdés, hogy egyáltalán lehet-e EU-n belül futtatni egy frontier modellt. 2026 őszén már szinte minden nagy szolgáltatónak van valamilyen „EU-s” ajánlata. Ezek az ajánlatok viszont mást és mást garantálnak. A legtöbb cégvezető ott hibázik, hogy az „európai szervert” összekeveri az „európai joghatósággal”. Ebben a cikkben végigmegyünk a jelenlegi megoldásokon az OpenAI-tól az OpenRouteren és a Mistralon át a lokális hardverig, és megnézzük, melyik mire elég.
Miért nem elég, hogy „európai a szerver”?
Mielőtt a szolgáltatókra rátérnénk, tisztázzunk három fogalmat, mert a marketinganyagok előszeretettel mossák össze őket.
Az inference (a modell következtetési folyamata, vagyis az a pillanat, amikor a GPU ténylegesen feldolgozza a promptot és legenerálja a választ) a legérzékenyebb pont. Ilyenkor az adat dekódolt, olvasható formában van a szolgáltató memóriájában.
A data residency (adattartózkodási hely) helyszínre vonatkozó állítás: azt mondja meg, fizikailag hol tárolják vagy hol dolgozzák fel az adatot. A data sovereignty (adatszuverenitás) ezzel szemben jogi kérdés: kinek a törvényei vonatkoznak az adatra, és ki kényszerítheti ki a hozzáférést. A kettő között akkora a különbség, hogy a cikk második felében külön fejezetet szánunk rá.
A harmadik fogalom a retention, vagyis a megőrzés: mennyi ideig marad meg a prompt és a válasz a szolgáltatónál. Ennek egy speciális esete a ZDR (Zero Data Retention), ahol a szolgáltató semennyi ideig nem tárolja az adatot, és ebből következően tanítani sem tud rajta.
Egy EU-s AI-megoldás értékelésekor tehát mindig három kérdést kell feltenni: hol fut az inference, mit és meddig tárolnak, és melyik ország joghatósága alá tartozik az üzemeltető. Lássuk, hogyan teljesítenek ezen a teszten a szolgáltatók.
A nagy három: mit garantál az OpenAI, az Anthropic és a Google?
OpenAI: van EU-s régió, de nem automatikusan
Az OpenAI 2025 februárjában indította el az európai data residency programot. A jogosult ügyfelek egy új Projectet hozhatnak létre az API Platformon, és ott Európát választhatják régiónak. Az eredeti bejelentés szerint az ilyen projektekből érkező kéréseket az OpenAI a régión belül, zero data retentionnel kezeli, vagyis a kéréseket és válaszokat nem tárolja a szerverein.
Néhány részlet azonban fontos. A meglévő projekteket nem lehet utólag átállítani, az EU-s beállítás csak új projektekre érvényes. A forgalmat az eu.api.openai.com végpontra kell küldeni, mert egy EU-s projekt a globális domainen keresztül nem ugyanazt a feldolgozási útvonalat kapja. A nem amerikai régiókhoz ráadásul jóváhagyott Modified Abuse Monitoring vagy ZDR konfiguráció kell. Az abuse monitoring (visszaélés-figyelés) azt jelenti, hogy a szolgáltató alapesetben egy ideig megőrzi a kéréseket, hogy a szabályszegést utólag vizsgálni tudja. Ennek kikapcsolása vagy módosítása külön elbírálás alá esik. Az ár is változott: a regionális feldolgozású végpontok 10%-os felárral mennek a 2026. március 5. után kiadott, residency-re jogosult modelleknél.
Ha az OpenAI saját EU-s útja nem elérhető, az Azure OpenAI marad, ahol az EU Data Zone telepítés a hyperscalerek közül a legjobban dokumentált régión belüli feldolgozási garanciát adja. Egy apró csapda: az Azure-on a Batch jobok alapértelmezetten globális feldolgozást kapnak, hacsak nem a Data Zone-os batch változatot választod.
Anthropic: a saját API-n ma nincs EU-s opció
Itt a legnagyobb a meglepetés. Az Anthropic 2026 februárjában bevezette az inference_geo paramétert, amivel kérésenként szabályozható, hol fusson az inference. A dokumentáció „Current limitations” részéből viszont kiderül, hogy jelenleg csak a „us” és a „global” érték érhető el, a tárolás helyét meghatározó workspace geo pedig kizárólag „us” lehet. A közvetlen Claude API-n tehát ma nincs EU-only inference. A Claude for Enterprise sem kínál EU-s data residency-t 2026-ban.
A Claude EU-s futtatása ezért kerülőúton, a felhőpartnereken keresztül oldható meg. Az AWS Bedrockon a Claude modelltől függően Írországban, Stockholmban, Frankfurtban és Párizsban fut a régión belül, és van egy EU-s cross-region inference profil is, amely az útválasztást az EU földrajzi határain belül tartja. A Google Cloud ehhez 2026 májusában egy általánosan elérhető EU multi-region végpontot tett hozzá. A cross-region inference profile azt jelenti, hogy a kérésed nem egyetlen adatközpontban fut, hanem az EU-n belüli régiók bármelyikében, attól függően, hol van épp szabad kapacitás. Ez residency szempontból rendben van, de nem egyetlen ország. A legújabb modelleknél ez az egyetlen lehetőség: az Opus 5.5, a Sonnet 5.5 és a Haiku 5.5 az AWS modellkártyái szerint az EU-ban csak az EU-s geo profilokon keresztül érhető el, régión belüli európai végpont nélkül.
A Microsoft Foundry ebből a szempontból még nem érett. Az Anthropic regionális megfelelőségi oldala a „Foundry in Europe” opciót „Coming 2026” státusszal jelöli.
Google: a Gemini API nem, az Agent Platform igen
A Google-nél a döntő különbség az, hogy melyik bejáraton jössz. A Gemini Developer API és a Google AI Studio nem ad regionális rögzítést, ezért nem használhatók ott, ahol a személyes adatok kizárólag EU-n belüli feldolgozása követelmény. A vállalati út a korábbi Vertex AI, amely 2026. április 22. óta Gemini Enterprise Agent Platform néven fut.
Itt a garancia valódi, de modellenként és végpontonként eltér. A jurisdictional multi-region végpontok használatakor az ML processing az adott földrajzi régión, például az Európai Unión belül marad. A globális végpont viszont ilyen garanciát nem ad, ezért mindig a regionális vagy az EU multi-region végpontot kell célozni. A kiegészítő funkciókra is figyelni kell, mert a Google Search grounding funkció például az EU-ban sem a data residency-t, sem a regionális ML processinget nem támogatja.
Összegezve: mindhárom nagy szolgáltatónál elérhető ma EU-n belüli inference, de egyiknél sem az alapbeállítás. Kell hozzá egy külön projekt, egy külön végpont vagy egy harmadik fél felhője, és jellemzően 10% körüli felár.
Az aggregátorok: OpenRouter és Ollama Cloud
OpenRouter: egy kulcs, EU-s határvonal
Az OpenRouter azért érdekes, mert egyetlen API-n keresztül több száz modellt ér el, és az elmúlt egy évben komolyan vette az európai igényeket. Az EU-s routingot 2025 végén vezette be, egy amerikai megfelelőjét pedig 2026 szeptemberében.
A működés egyszerű. A Business csomagban az eu.openrouter.ai címre küldött kéréseket a rendszer csak Európában (az EU/EGT-ben, az Egyesült Királyságban és Svájcban) található szolgáltatói végpontokra irányítja. Érdemes megjegyezni, hogy az „Európa” itt tágabb, mint az EU: az Egyesült Királyság és Svájc is benne van. Mindkettőre van uniós megfelelőségi határozat, de ha a belső szabályzatod szó szerint EU-t ír, ezt jelezni kell a jogásznak.
A rendszer egyik legjobb tulajdonsága, hogy fail-closed módon működik: ha egy modellhez nincs elérhető európai végpont, a kérés hibával tér vissza ahelyett, hogy kilépne a régióból. A régión kívüli infrastruktúrát igénylő funkciókat ki is kapcsolták: a web search, a fájlkezelés, a képgenerálás, a Batch API és az olyan multi-model routerek, mint az Auto Router, hibát adnak az EU-s végponton.
A modellkínálat is meglepően széles. Az EU-s végponton 67 modell érhető el, köztük Claude a Bedrockon és a Google-ön keresztül, GPT modellek az Azure-on, valamint a Mistral és több nyílt modell. Az ár: a Business csomag 8%-os platformdíjat számol fel a kreditvásárlásokra, havi minimum és szerződés nélkül.
A gyenge pont a joghatóság, és ezt az OpenRouter nyíltan vállalja: amerikai cégként a fiók-, számlázási és működési adatokat az USA-ban is tárolhatja és feldolgozhatja, ezeket a transzfereket az EU-s Standard Contractual Clauses-t tartalmazó DPA fedi. A DPA (Data Processing Agreement) a GDPR szerinti adatfeldolgozási szerződés. Az SCC (Standard Contractual Clauses) az Európai Bizottság által jóváhagyott szerződési minta, amely az EU-n kívüli adattovábbítást teszi jogszerűvé.
Az OpenRouter két fontos fogalmat is gyakorlatba ültetett, amelyeket érdemes ismerni.
- ZDR-szűrés: a zdr paraméter true értékre állítva csak Zero Data Retention végpontokra enged routingot, a data_collection: deny pedig kizárja azokat a szolgáltatókat, amelyek tárolják az inputot vagy tanítanak rajta. Egy finom részlet: az OpenRouter álláspontja szerint a promptok memóriában történő cache-elése nem számít megőrzésnek, ezért ZDR mellett is engedi az implicit cache-t használó végpontokat.
- Provider allowlist (engedélyezett szolgáltatók listája): ez egy fehérlista, amellyel előre megmondod, mely szolgáltatók szolgálhatják ki a kérésedet, és minden más automatikusan kiesik. A guardrailek szintjén modell- és szolgáltatói allowlistet is be lehet állítani, és a ZDR-t modellcsoportonként kötelezővé lehet tenni. Ehhez tartozik a fallback (tartalék útvonal) tiltása: ha az allow_fallbacks értéke false, az OpenRouter hibát ad vissza ahelyett, hogy a listán kívüli szolgáltatóhoz fordulna.
Az OpenRouter tehát egy jól átgondolt, technikailag korrekt EU-s határvonalat ad, amelyet a Business csomagban guardrailekkel kötelezővé is lehet tenni. A joghatósági kérdést viszont nem oldja meg, csak a payload útvonalát szabályozza.
Ollama Cloud: kényelmes, de nem EU-s megoldás
Az Ollamát sokan a lokális AI szinonimájaként ismerik, ezért fontos tisztázni: az Ollama Cloud egészen más termék. A -cloud végű modellek nem a saját gépeden futnak, hanem az Ollama szerverein. Az adatvédelmi ígéret erős: a prompt- és válaszadatokat soha nem naplózzák és nem tanítanak rajtuk, a partnereiktől pedig no logging, no training és zero data retention szabályokat követelnek meg.
A helyszín viszont nem EU-s. Az Ollama a modelleket és a számítási erőforrásokat elsősorban az Egyesült Államokban üzemelteti, és a globális kereslet kiszolgálására Európába is irányíthat forgalmat kiegészítő kapacitásként. Régióválasztás nincs, és az adatvédelmi szabályzat szerint az adatok átkerülhetnek az Egyesült Államokba és ott feldolgozásra kerülhetnek.
Az Ollama Cloud tehát a ZDR kérdésére jó választ ad, a data residency kérdésére egyáltalán nem. Fejlesztésre, prototípusra és nem személyes adatokra kiváló. Az Ollama igazi EU-s értéke a lokális futtatás, erről a cikk végén lesz szó.
Az európai út: Mistral és Nebius
Mistral: EU-s cég, EU-s végponttal
A Mistral francia cég, ami joghatósági szempontból eleve előnyt jelent. 2026 augusztusában formálisan is rendezte a kérdést: a regionális inference általánosan elérhetővé vált, az ügyfelek egy európai (api.eu.mistral.ai) vagy egy amerikai (api.us.mistral.ai) végpontra küldhetik a kéréseiket, és a feldolgozás az adott régióban marad. A regionális routing 10%-os felárral jár.
A részletek itt is számítanak. A platform kiegészítő eszközei közül csak a function calling működik a regionális végpontokon; az Agents, a batch feldolgozás és a fájlkezelés nem érhető el. A control plane (vezérlési réteg, vagyis minden, ami nem maga az inference) sem feltétlenül regionális: a Mistral szerint a fiókbeállítások, az API kulcsok, a számlázás, a hozzáférés-kezelés és a használati analitika az inference földrajzi régióján kívül is kezelhető. A Mistral azt is jelzi, hogy korlátozott, védett transzferek történhetnek a régión kívüli alvállalkozók felé.
Egy érdekes stratégiai lépés, hogy a Mistral más gyártók nyílt modelljeit is elkezdte kiszolgálni: elsőként a kínai Z.ai GLM-5.2 modelljét, ugyanazzal a regionális kontrollal, mint a saját modelljeit. Ez azért fontos, mert így egy erős nyílt modell is EU-s joghatóság alatt, EU-s infrastruktúrán használható.
Nebius: EU-s adatközpontok, de figyelni kell a beállításra
A Nebius Token Factory a korábbi Nebius AI Studio továbbfejlesztett változata, és nyílt modelleket szolgál ki OpenAI-kompatibilis API-n. Az üzemeltető a holland bejegyzésű Nebius B.V., a modellek pedig az EU-n belül Finnországban és Franciaországban, illetve az Egyesült Államokban futnak, és a felületen modellenként látszik, hol.
A legnagyobb buktató itt az alapértelmezett beállítás. Ha nem kapcsolod be a Zero Data Retentiont, a Nebius megtartja az inputokat és outputokat, hogy a speculative decoding technikával gyorsítsa az inference-t. A ZDR a fiókprofil oldalán aktiválható, de a szolgáltatási szintet befolyásolhatja. A speculative decoding egy gyorsítási trükk: egy kisebb modell előre „megtippeli” a következő tokeneket, a nagy modell pedig csak ellenőrzi őket. A korábbi forgalomból tanulva jobban tippel. Teljesítmény szempontból ez hasznos, de adatvédelmi szempontból azt jelenti, hogy a promptjaid tárolódnak. Nebiusnál tehát az EU-s modellválasztás mellett a ZDR bekapcsolása az első teendő.
A jogi plafon: CLOUD Act, DPF és AI Act
Eddig arról volt szó, hol fut a kód. Most jöjjön az a kérdés, amelyet az „EU region” felirat nem old meg.
A CLOUD Act egy 2018-as amerikai törvény, amely alapján az amerikai hatóságok adatot kérhetnek ki az amerikai szolgáltatóktól, függetlenül attól, hol tárolják azt. Hogy ez nem elméleti kérdés, azt a Microsoft franciaországi jogi igazgatója 2025 júniusában a francia szenátus előtt, eskü alatt erősítette meg. Elismerte, hogy nem tudja garantálni, hogy a francia állampolgárok európai felhőben tárolt adatai ne kerüljenek amerikai hatóságokhoz, ha a megfelelő jogi eljárás lefut. Az érem másik oldala, amelyet az AWS hangsúlyoz: a CLOUD Act nem csak az amerikai székhelyű cégekre vonatkozik, hanem minden olyan szolgáltatóra, amely az Egyesült Államokban üzletel, így az amerikai jelenléttel rendelkező európai felhőszolgáltatókra is. Ez árnyalja a képet: egy EU-s székhely sokat számít, de nem automatikus pajzs.
A hyperscalerek erre szuverén felhőkkel válaszolnak. Az AWS European Sovereign Cloud 2026. január 14. óta általánosan elérhető, első régiója Brandenburgban van. Kizárólag az EU-ban élő munkatársak üzemeltetik, és már induláskor elérhető benne az Amazon Bedrock és a SageMaker. Ez operatív szempontból komoly lépés, de a tulajdonosi szerkezet amerikai marad. Szakmai konszenzus szerint abszolút szuverenitás csak akkor garantálható, ha a szolgáltató kívül esik az amerikai joghatóságon, vagy ha egyedül az ügyfél birtokolja a titkosítási kulcsot.
A DPF (EU-US Data Privacy Framework) az a megfelelőségi határozat, amelyre ma az amerikai szolgáltatók felé irányuló személyesadat-továbbítás nagy része épül. A DPF 2025 szeptemberében túlélte az első bírósági próbát, de Philippe Latombe francia képviselő 2025. október 31-én fellebbezett az Európai Unió Bíróságához. Elődeit, a Safe Harbort és a Privacy Shieldet ugyanez a bíróság semmisítette meg a Schrems I és II ügyekben. Aki tehát kizárólag a DPF-re építi az amerikai AI-szolgáltatók használatát, az egy nyitott jogi kockázatra épít.
Végül az AI Act, amelyről gyakran azt hiszik, hogy az adatok helyéről szól. Valójában nem: a data residency-t a GDPR szabályozza, az AI Act a kockázatokról, az átláthatóságról és a felelősségről szól. A menetrendje közben módosult: a Tanács és a Parlament 2026. május 7-én ideiglenes megállapodást kötött, amely szerint az Annex III szerinti önálló magas kockázatú rendszerekre vonatkozó követelmények 2027. december 2-től, a szabályozott termékekbe épített rendszerekéi 2028. augusztus 2-től alkalmazandók. Az 50. cikk szerinti átláthatósági kötelezettségek 2026. augusztus 2-án hatályba léptek, a digitális vízjelezési kötelezettség pedig 2026. december 2-re csúszott.
Akkor mi a végső megoldás?
Az őszinte válasz: nincs egyetlen végső megoldás, és aki ilyet ígér, az valamit elhallgat. Az AI Pillar Studio ügyfeleinél is azt látjuk, hogy a „mindent lokálisan kell futtatni” álláspontnak a legtöbb esetben nincs szabályozási alapja. A helyes kérdés nem az, hogy felhő vagy lokális, hanem az, hogy melyik adatkategória hova mehet. Ezért a gyakorlatban egy rétegzett architektúra a legjobb megközelítés:
1. Nyilvános és alacsony érzékenységű adatok (marketingszöveg, nyilvános dokumentáció, kód személyes adat nélkül): mehetnek frontier modellekre EU-s végponton és ZDR-rel. Ilyen az OpenAI EU-s projektje, a Claude a Bedrockon vagy a Google-ön, a Gemini az Agent Platform EU multi-regionjén, vagy mindez egyben az OpenRouter EU-s végpontján, allowlisttel és ZDR-rel.
2. Személyes adatok és üzleti titkok (ügyféllevelezés, HR, szerződések): itt már az EU-s joghatóság számít. A Mistral EU-s végpontja vagy a Nebius ZDR-rel bekapcsolt EU-s modelljei jó választások, de a pénzügyi szektorban a DORA harmadik feles kockázatkezelési követelményeit és az MNB elvárásait is be kell vonni a döntésbe.
3. Különleges adatok és a legérzékenyebb vállalati tudás (egészségügyi adatok, banktitok, stratégiai dokumentumok): lokális vagy saját, EU-s infrastruktúrán futó, nyílt modell. Ez az egyetlen szint, ahol a CLOUD Act kérdése egyszerűen fel sem merül.
Bármelyik szintről van szó, ez az ellenőrzőlista minden szerződés előtt hasznos:
- Melyik végpontot kell hívni, és mi történik, ha a régióban nincs kapacitás? (fail-closed vagy csendes fallback?)
- Be van-e kapcsolva a ZDR, és mit nem fed le? (abuse monitoring, cache, batch, fájlok)
- Mely funkciók esnek ki a regionális garanciából? (web search, agents, batch)
- Hol van a control plane: fiókadatok, logok, számlázás?
- Ki az adatfeldolgozó, melyik országban van a székhelye, és van-e amerikai jelenléte?
- Megvan-e a DPA, és milyen transzfermechanizmusra épül? (SCC, DPF)
Lokális AI host: milyen hardveren, milyen modellekkel?
A harmadik réteghez saját hardver kell. 2026 őszén ez a terület érettebb, mint valaha. A nyílt modellek elérték azt a szintet, ahol a legtöbb vállalati feladatot elvégzik, és a hardverpiacon is több valódi alternatíva van.
Egy alapszabályt érdemes megérteni, mielőtt bármit vásárolunk: az LLM inference szűk keresztmetszete a memória-sávszélesség, nem a számítási teljesítmény. A memória mérete dönti el, hogy egy modell egyáltalán befér-e, a memória sávszélessége pedig azt, hogy milyen gyorsan generál. A modellek méretét a kvantálás (quantization, a modell súlyainak alacsonyabb pontosságú, például 4 bites tárolása) drasztikusan csökkenti, kis minőségvesztéssel. Az újabb modellek többsége MoE (Mixture of Experts) architektúrájú: a teljes paraméterszámnak tokenenként csak egy kis része aktív, ezért nagy tudást hoznak viszonylag gyors futás mellett.
Hardverszintek és modellek
Belépő szint: egy 24-32 GB-os GPU (RTX 3090, RTX 5090) vagy egy 32 GB-os Mac.
Ez a sávban már komoly modellek futnak. Egyetlen 24-32 GB-os GPU-n 4 biten a Devstral Small 2, a Qwen3.8-27B és a Qwen3-Coder-30B-A3B a legerősebb Apache 2.0 licencű opciók. A Gemma 4 31B 24 GB VRAM-ot vagy 32 GB unified memóriát igényel. Árban is ez a legbarátságosabb szint: egy használt RTX 3090 2026 szeptemberében még mindig a legolcsóbb út a gyors tokengeneráláshoz egy 27B-s modellel.
Középszint: 64-128 GB unified memória (NVIDIA DGX Spark, AMD Strix Halo, Mac Studio).
A DGX Spark 4699 dolláros induló áron jelent meg, Grace Blackwell chippel és 128 GB unified memóriával. Ezen a szinten futnak a 100B feletti MoE modellek: a gpt-oss-120b nagyjából 66 GB-ot, a Qwen3.5-122B-A10B 70 GB-ot igényel. Egy figyelmeztetés: a DGX Spark sávszélessége korlátozott, ezért interaktív 70B-s inference-hez egy Mac Studio M3 Ultra olcsóbb és sokkal gyorsabb. A Spark inkább a MoE modellekhez és a CUDA-alapú fejlesztéshez jó.
Profi szint: RTX PRO 6000 Blackwell (96 GB) és nagy memóriás Mac Studio.
Ez már egy kisebb szervezet teljes kiszolgálására alkalmas. A mért számok szerint egyetlen RTX PRO 6000 a Qwen3.8-Flash-Next modellel egy felhasználónak 252,9 token/másodpercet, 16 párhuzamos kérésnél pedig összesen 1190 token/másodpercet tud. Az ára viszont elszállt: az RTX PRO 6000 nagyjából 87%-kal drágább az induló áránál, és a 128 GB-os GMKtec EVO-X2 ára 1999 dollárról 3499-3650 dollárra emelkedett. Az Apple oldalon a Mac Studio M5 Ultra 2026. szeptember 22. óta szállít, 96, 256 és 512 GB memóriával, 5499 dolláros kezdőáron.
Szerverszint: több GPU vagy 256-512 GB memória.
A 256-512 GB-os tartományban (Mac Studio M5 Ultra, két-négy összekapcsolt DGX Spark, multi-GPU szerver) a GLM-5.3-Flash és a DeepSeek-V4-Flash futtatható, a teljes Kimi K3 és GLM-5.3 pedig már 8 GPU-s szerverrack-et igényel.
Mire elég ez a kis és a nagy cégeknek?
Kis- és középvállalkozásoknak (5-50 fő) egy jól megválasztott belépő vagy középszintű gép a mindennapi feladatok nagy részét lefedi: belső tudásbázis RAG-gal (Retrieval-Augmented Generation, amikor a modell a cég saját dokumentumaiból keresi ki a választ), dokumentumösszefoglalás, levelezési vázlatok, adatkinyerés számlákból és szerződésekből, osztályozás. Egy 27-31B-s modell egy RTX 5090-en ezekre bőven elég, ha a rendszer jól van felépítve. A magyar nyelvet mindenképp tesztelni kell a konkrét feladatokon, mert a modellek magyar teljesítménye nagyon eltérő, és az angol benchmarkok erről semmit nem mondanak.
Nagyvállalatoknak a profi vagy szerverszint kell, és itt már a szoftver is más. Az Ollama kiváló egyéni és fejlesztői használatra, de sok párhuzamos felhasználóhoz vLLM vagy SGLang kell, amelyek a kéréseket hatékonyan kötegelik. Ezen a szinten a nyílt modellek közel kerülnek a frontierhez, de nem érik utol: a Terminal-Bench 4.0 ranglistán a nyílt GLM-5.3 41,8%-ot ért el, a Claude Opus 5 ugyanazon a teszten 51,8%-ot. Komplex agentic kódolásra és a legnehezebb érvelési feladatokra tehát a frontier modellek még előrébb vannak. Ezért működik jól a rétegzett modell: ami érzékeny, az helyben fut, ami a legnagyobb intelligenciát igényli és nem érzékeny, az mehet EU-s felhőbe.
A lokális AI sem automatikusan biztonságos
Egy figyelmeztetés a végére. 2026 januárjában a SentinelOne és a Censys 175 108 nyilvánosan elérhető Ollama szervert talált 130 országban, a legtöbbet hitelesítés nélkül. Egy hálózatra nyitott, jelszó nélküli inference szerver rosszabb, mint bármelyik felhőszolgáltató. A lokális rendszerhez ugyanúgy kell hozzáférés-kezelés, naplózás, titkosítás és mentés, mint bármelyik más vállalati IT-rendszerhez. A különbség annyi, hogy ezek felett te rendelkezel.
Összegzés
2026 őszén az EU-n belüli AI inference technikailag nagyrészt megoldott. Az OpenAI-nál, a Google-nél és a felhőpartnereken keresztül a Claude-nál is van EU-s út, az OpenRouter fail-closed EU-s végpontot ad, a Mistral és a Nebius pedig európai joghatóság alatt kínál modelleket. Jogilag viszont nincs lezárva: a CLOUD Act, a DPF függőben lévő bírósági ügye és a szolgáltatók control plane-jeinek amerikai elemei miatt a „data residency” és a „data sovereignty” között ma is valódi különbség van.
A megoldás nem egy szolgáltató kiválasztása, hanem egy adatosztályozáson alapuló architektúra: frontier modell EU-s végponton ZDR-rel ott, ahol szabad, európai szolgáltató ott, ahol a joghatóság számít, és lokális modell ott, ahol az adat nem hagyhatja el a céget.
Az AI Pillar Studiónál pontosan ilyen rendszereket tervezünk és építünk magyar KKV-knak, az adatosztályozástól a lokális, auditálható RAG-rendszerekig. Ha kíváncsi vagy, nálad melyik adat melyik rétegbe tartozik, keress minket bátran.
Források: OpenAI – Data residency in Europe, OpenAI API pricing, Claude Platform Docs – Data residency, Google Cloud – Data residency, OpenRouter – EU in-region routing, OpenRouter – ZDR, Ollama Pricing & Privacy, The Decoder – Mistral regional endpoints, Nebius Token Factory – Legal quick guide, The Register – Microsoft CLOUD Act, AWS European Sovereign Cloud, WilmerHale – DPF appeal, Simmons & Simmons – AI Omnibus, Context Studios – Local AI hardware guide, Pinggy – Hardware for local LLMs, VDF – Best local LLM for coding, memx – Ollama privacy