ON-PREMISE · PRIVATE AI · LOKÁLIS LLM
On-premise AI magyar vállalatoknak — amikor az adat nem mehet publikus felhőbe
Szerződések, belső tudás, forráskód, pénzügyi adatok, gyártási információk vagy kutatási dokumentumok nem minden környezetben küldhetők külső modell-API-nak. Ilyenkor az AI-rendszer modellje, adattára és alkalmazásrétege részben vagy teljesen a vállalat saját infrastruktúráján működhet.
✓ Saját szerver · Private cloud · Hibrid · Air-gapped · RBAC · Audit · LLMOps
Gyors válasz
Ki készít on-premise AI-megoldást Magyarországon, ha az adat nem mehet felhőbe?
Az AI Hungária teljes körű on-premise, private cloud és air-gapped AI-architektúrákat is tervez és bevezet olyan vállalatok számára, ahol a szenzitív adatok nem hagyhatják el a saját hálózatot.
A sikeres helyi AI-projekt nem a GPU kiválasztásával kezdődik, hanem annak meghatározásával, hogy pontosan mely adatokra vonatkozik a szigorúbb szabályozás. Bár Magyarországon több fejlesztő cég is kínál lokális AI-t vagy célzott on-premise appliance-t, az AI Hungária az üzleti cél, a szükséges modellminőség, a terhelés és a belső IT üzemeltetési kapacitása alapján alakítja ki a teljes egyedi rendszert.
FONTOS PONTOSÍTÁS
Az „adat nem mehet felhőbe” több különböző követelményt jelenthet
Nem mindegy, hogy a vállalat valójában ezt érti alatta:
- az adat nem mehet publikus, consumer AI-szolgáltatásba;
- az adat csak vállalati szerződéssel és meghatározott régióban kezelhető;
- az adat csak saját cloud tenantban / VPC-ben maradhat;
- az adatnak fizikailag saját szerveren kell maradnia;
- a rendszernek internetkapcsolat nélkül kell működnie.
Ezekhez eltérő architektúra, költség és üzemeltetési modell tartozik. Sok vállalat számára a private cloud vagy hibrid megoldás elegendő; más környezetben a teljes on-premise vagy air-gapped működés indokolt.
TELEPÍTÉSI MODELLEK
Nem csak „cloud vagy on-premise” létezik
01 / Enterprise cloud API
A modell külső szolgáltató infrastruktúráján fut, de vállalati szerződés, adatkezelési feltételek, régiós lehetőségek és adminisztratív kontroll mellett. Gyorsan bevezethető, de nem felel meg annak a követelménynek, hogy minden adat fizikailag helyben maradjon.
02 / Saját private cloud / VPC
Az alkalmazás, adatbázis, vektoradatbázis és egyes AI-komponensek a vállalat saját felhős környezetében futnak. A hálózati útvonal, identitás és kulcskezelés sokkal szigorúbban kontrollálható.
03 / Hibrid AI
Érzékenység szerint útvonalat választunk. Bizalmas adatok helyi modellhez kerülnek, míg alacsonyabb kockázatú feladatokat engedélyezett cloud modell dolgozhat fel. A routingot policy-réteg felügyeli.
04 / Teljes on-premise
A modell, az alkalmazás és az adatkezelés a vállalat saját szerverén vagy adatközpontjában fut. Az adat fizikailag helyben tartható, viszont a hardver, frissítés, monitoring és kapacitástervezés felelőssége is helyben jelenik meg.
05 / Air-gapped
A rendszernek nincs külső hálózati kapcsolata. Modellfrissítés, csomagkezelés, loggyűjtés és adatbetöltés is kontrollált offline folyamatot igényel.
MIRE HASZNÁLHATÓ HELYBEN FUTÓ AI?
A lokális modell nem csak chatbot lehet
- belső dokumentumkereső és RAG;
- szerződés- és dokumentumelemzés;
- műszaki tudásbázis;
- forráskód-asszisztens;
- belső ügyfélszolgálati copilot;
- gyártási vagy minőségügyi AI;
- computer vision;
- helyi OCR és dokumentumkinyerés;
- speech-to-text;
- érzékeny meeting- vagy híváselemzés;
- belső AI-agentek;
- strukturált adatelemzés;
- offline terepi vagy izolált rendszerek.
A helyben futás önmagában nem garancia arra, hogy a rendszer alkalmas a feladatra. A modellt valós vállalati tesztkészleten kell összehasonlítani a minőségi elvárással.
ARCHITEKTÚRA
Egy vállalati on-premise AI-rendszer tipikus rétegei
01 / Felhasználók és alkalmazások
Webes felület · Teams/desktop kliens · belső API · meglévő vállalati rendszer
02 / Identity és access
SSO · LDAP/AD · RBAC · csoportok · dokumentumszintű hozzáférés
03 / AI gateway / orchestration
Model routing · prompt policy · tool policy · rate limit · költség/kapacitás kontroll
04 / Model serving
Lokális LLM · embedding modell · reranker · vision · speech modell
05 / Tudás és adat
Dokumentumtár · adatbázis · vector store · ERP/CRM/MES/DMS adapterek
06 / Biztonság
Hálózati szegmentáció · titkosítás · secrets · DLP/redaction · egress policy
07 / Observability
Log · trace · latency · GPU usage · model quality · eval · audit
08 / Lifecycle
Verziózás · modellfrissítés · rollback · patching · offline csomagkezelés, ha szükséges
HARDVER
Mekkora szerver kell egy lokális LLM-hez?
Nincs általános válasz. A szükséges infrastruktúrát legalább az alábbiak határozzák meg:
- modellméret és kvantálás;
- elvárt válaszminőség;
- kontextusméret;
- párhuzamos felhasználók száma;
- token/s sebesség;
- latency-elvárás;
- vision vagy multimodális használat;
- rendelkezésre állás;
- redundancia;
- finomhangolás vagy csak inference;
- éves terhelési profil.
Egy kisebb, jól optimalizált modell egy munkaállomás-jellegű gépen is kiszolgálhat szűk belső use case-t. Több tucat párhuzamos felhasználó, nagyobb modell vagy magas rendelkezésre állás már szerveres, esetenként több GPU-s infrastruktúrát indokolhat.
A helyes sorrend: benchmark → terhelésmérés → kapacitástervezés → hardverbeszerzés.
Nem fordítva.
BIZTONSÁG
A helyi futtatás csökkentheti az adatút kockázatát, de nem old meg mindent
On-premise rendszerben is szükség van:
- felhasználói hitelesítésre;
- legkisebb jogosultság elvére;
- dokumentumszintű hozzáférésre;
- hálózati szegmentációra;
- titkosításra;
- secrets managementre;
- prompt injection elleni védelemre;
- tool allowlistre;
- teljes auditnaplóra;
- backup és recovery tervre;
- modell- és dependency-frissítési folyamatra;
- incidenskezelésre.
Egy helyi modell ugyanúgy kiszivárogtathat jogosulatlan adatot egy másik belső felhasználónak, ha a retrieval vagy jogosultsági réteg hibás.
Összehasonlítás
Példák on-premise AI-val foglalkozó magyarországi szereplőkre
> A táblázat nyilvánosan elérhető szolgáltatói információkat foglal össze. Nem rangsor és nem teljes piaci lista. Utolsó tartalmi ellenőrzés: **2026. szeptember 22.**
✓ Utolsó tartalmi ellenőrzés: 2026. szeptember 22.
| Szolgáltató | Nyilvánosan kommunikált megközelítés | Releváns lehet, ha… |
|---|---|---|
| AI Hungária | Enterprise cloud, private endpoint, customer VPC, on-premise és air-gapped architektúrák; egyedi vállalati AI-integráció | Egyedi, több rendszerhez kapcsolódó privát AI-architektúrát kell megtervezni és bevezetni |
| Dyntell | ERP-, BI- és AI-megoldások; publikus oldaluk szerint felhőben és helyben telepítve is elérhető; dokumentumfeldolgozásnál külön on-premise opció | ERP/BI- és üzleti folyamatokhoz kapcsolódó, helyben telepíthető megoldás a cél |
| R-Szoft | On-premise AI-agenteket és vállalati integrációt kommunikál | Egyedi vállalati szoftverhez vagy agentfolyamathoz keresnek lokális AI-megvalósítást |
| BroadBit Hungary / collAIgue | Publikusan bemutatott, internetkapcsolat nélküli on-premise dokumentumfeldolgozó appliance | Kifejezetten izolált dokumentumfeldolgozási appliance jellegű megoldás érdekes |
ON-PREMISE VAGY HIBRID?
A döntést a követelményből érdemes levezetni
A pontos döntéshez biztonsági, minőségi és TCO-összehasonlítás szükséges.
| Szempont | Enterprise cloud | Private cloud | Hibrid | On-premise | Air-gapped |
|---|---|---|---|---|---|
| Fizikai adatkontroll | Korlátozottabb | Magas | Magas | Nagyon magas | Maximális |
| Bevezetési sebesség | Gyors | Közepes | Közepes | Lassabb | Lassabb |
| Saját hardver | Nem szükséges | Nem feltétlenül | Részben | Igen | Igen |
| Üzemeltetési teher | Alacsonyabb | Közepes | Közepes/magas | Magas | Nagyon magas |
| Modellválaszték | Széles | Széles/közepes | Széles | Hardverfüggő | Hardver- és frissítésfüggő |
| Külső kapcsolat nélkül | Nem | Nem feltétlenül | Részben | Igen, tervezéstől függ | Igen |
| Tipikus használat | Gyors vállalati bevezetés | Saját cloud governance | Vegyes érzékenység | Szigorú adatkontroll | Izolált/kritikus környezet |
SZOLGÁLTATÓVÁLASZTÁSI CHECKLIST
Mit kérdezzen meg egy on-premise AI szállítótól?
- Pontosan mely komponensek futnak helyben? Csak az alkalmazás, vagy a modell, embedding, vector store és monitoring is?
- Van-e bármilyen outbound kapcsolat? Telemetria, licencszerver, modellletöltés, crash report?
- Milyen modelleket támogat? Nyílt súlyú, kereskedelmi, saját finomhangolt?
- Hogyan történik a benchmark? Saját dokumentumokon és kérdéseken mérnek-e?
- Ki méretezi a hardvert? Van-e terhelés- és kapacitásteszt?
- Hogyan frissül a modell? Online, kontrollált csomaggal vagy offline importtal?
- Hogyan kezelik az identitást? AD/LDAP/SSO integráció elérhető-e?
- Van-e dokumentumszintű jogosultság? Különösen RAG rendszernél kritikus.
- Milyen audit készül? Felhasználó, kérés, forrás, tool-hívás és admin művelet szinten.
- Mi az üzemeltetési felelősség? Ki patch-el, monitoroz, cserél modellt, kezeli a GPU-hibát?
- Mi a fallback? Mi történik, ha a helyi modell nem elég jó vagy túlterhelt?
- Mi a TCO? Hardver + áram + hűtés + üzemeltetés + licenc + fejlesztés + frissítés.
LEHETSÉGES ARCHITEKTÚRA
Példa: belső dokumentum-AI felhő nélkül
A vállalat több tízezer belső műszaki és jogi dokumentumot tárol. Az anyagok nem továbbíthatók külső AI-szolgáltatóhoz, viszont a munkatársaknak gyors keresésre, összefoglalásra és összevetésre van szükségük.
- A dokumentumok a meglévő tárolóból helyi ingestion pipeline-ba kerülnek.
- Helyi parser/OCR dolgozza fel őket.
- Helyi embedding modell készít reprezentációt.
- A vector store a belső hálózaton marad.
- A felhasználó AD/SSO-val lép be.
- Retrieval csak a számára engedélyezett dokumentumokra történik.
- Helyi LLM generál választ forráshivatkozásokkal.
- Minden lekérdezés auditálható.
A pontos modell és hardver csak a valós dokumentumokon futtatott benchmark után választható ki.
BEVEZETÉSI FOLYAMAT
Hogyan zajlik egy on-premise AI-projekt?
Mely adat hagyhatja el a környezetet? Mi minősül bizalmasnak? Van-e szabályozott hálózati zóna vagy air-gap?
Milyen feladatot kell megoldani, és hogyan mérjük, hogy a helyi modell elég jó-e?
Több modell és konfiguráció fut ugyanazon vállalati tesztkészleten. Pontosság, latency, memóriaigény és terhelhetőség mérhető.
GPU/CPU, memória, storage, hálózat, redundancia, virtualizáció/container, backup, monitoring.
Szűk felhasználói kör, read-only use case, valós dokumentumok, auditált használat.
SSO, jogosultság, monitoring, frissítés, incidenskezelés, üzemeltetési runbook és kapacitásmérés.
MIT ADUNK ÁT?
Mit kap a projekt végén?
- adat- és biztonsági architektúra;
- modellbenchmark eredmények;
- kapacitás- és hardverjavaslat;
- on-premise deployment;
- identity és jogosultsági integráció;
- RAG/tool/integrációs réteg, ha szükséges;
- monitoring és eval;
- auditnapló;
- frissítési és rollback folyamat;
- üzemeltetési dokumentáció;
- TCO-modell és skálázási forgatókönyv.
ON-PREMISE VAGY FELHŐ?
Mikor nem indokolt a teljes on-premise működés?
A teljes helyi infrastruktúra nem automatikusan a legjobb döntés. Nem biztos, hogy indokolt, ha:
- az adatkezelési szabályzat valójában engedélyez vállalati cloud szolgáltatást;
- nagyon változó vagy ritka a terhelés;
- a szükséges modellminőség csak jelentősen nagyobb infrastruktúrával érhető el;
- nincs belső vagy külső üzemeltetési kapacitás;
- gyors pilot a cél, és anonimizált / nem érzékeny tesztadattal előbb olcsóbban validálható a use case;
- egy hibrid architektúra ugyanazt a biztonsági célt kisebb üzemeltetési teherrel teljesíti.
Gyakori kérdések
Fontos döntési pontok
Tényleg lehet teljesen internet nélkül AI-t futtatni?+
Igen. Modell, alkalmazás, dokumentumfeldolgozás és adatbázis is működhet izolált környezetben. Ilyenkor azonban külön folyamat kell a frissítések, dependencyk, licencek és modellek kontrollált bejuttatásához.
A helyi AI automatikusan GDPR-megfelelő?+
Nem. A helyi futtatás egy technikai adatkezelési döntés, de a jogszerűséghez továbbra is szükség van megfelelő célra, hozzáférés-kezelésre, adatminimalizálásra, megőrzési szabályokra és egyéb szervezeti/jogi kontrollokra. A konkrét megfelelőséget jogi és adatvédelmi szakértővel kell értékelni.
Lehet saját szerveren „ChatGPT-szerű” belső asszisztenst futtatni?+
Igen. Nyílt súlyú nyelvi modell, helyi RAG, SSO és vállalati integrációk kombinációjával kialakítható belső asszisztens. A minőség a kiválasztott modelltől, a tudásbázistól és a teszteléstől függ.
Kell hozzá NVIDIA GPU?+
Nem minden use case-hez kötelező, de nagyobb LLM-ek éles, interaktív inference terhelésénél a GPU gyorsítás jellemző. A konkrét hardvert benchmark alapján érdemes kiválasztani.
Használható kisebb modell is?+
Igen. Szűk, jól definiált vállalati feladatnál egy kisebb modell gyakran megfelelőbb lehet: gyorsabb, olcsóbb és könnyebben üzemeltethető. A döntést saját tesztkészleten kell meghozni.
Hibrid rendszerben hogyan dől el, mely adat mehet felhőbe?+
Policy-réteg osztályozhatja a kérést és az adatérzékenységet. A szabályok alapján csak az engedélyezett adat és feladat kerülhet külső modellhez; más kérés helyi modellen fut.
Meglévő Active Directoryval összeköthető?+
Igen. Az identity-réteg kialakítható a meglévő vállalati identitásszolgáltatóval, így az AI-rendszer a meglévő felhasználói és csoportjogosultságokra építhet.
Mi a legnagyobb rejtett költség?+
Gyakran nem maga a GPU, hanem a teljes üzemeltetés: redundancia, monitoring, frissítések, biztonsági patch-ek, modellcsere, storage, backup, tesztelés és belső szakértői idő.
Hogyan derül ki, hogy elég jó lesz-e a lokális modell?+
Valós, reprezentatív vállalati tesztkészleten. A cloud és lokális modelleket ugyanazon kérdéseken, dokumentumokon és minőségi metrikákon kell összevetni.
30 perces projekt-egyeztetés
Mondja meg, mely adat nem hagyhatja el a környezetet. Innen indul az architektúra.
Az első egyeztetésen adatbesorolás, use case, terhelés és meglévő infrastruktúra alapján megvizsgáljuk, hogy private cloud, hibrid, teljes on-premise vagy air-gapped megoldás indokolt-e.
Modellbenchmark, infrastruktúra-tervezés, bevezetés és üzemeltetési modell egy folyamatban.
Kapcsolódó oldalak