V regulovaných odvetviach väčšina konverzácií o AI nasadení skončí pri rovnakej otázke: „A kde budú naše dáta?" Keď hovorí vedúci lekár, compliance officer banky alebo partner advokátskej kancelárie, táto otázka nie je rétorická — za nesprávnou odpoveďou stojí pokuta, odvolanie licencie alebo trestnoprávna zodpovednosť.
Tento článok nie je o tom, *či* ísť on-prem — o tom sme písali v porovnaní lokálnych LLM a cloudu. Toto je o tom, *ako* postaviť on-prem LLM infraštruktúru, ktorá obstojí pred regulátorom, IT auditom aj dennou prevádzkou.
Prečo cloud nestačí — aj keď provider sľubuje GDPR
Cloud provideri majú vynikajúce bezpečnostné certifikáty. Problém nie je ich technológia — problém je právna konštrukcia a architektúra dátových tokov.
Keď odošlete prompt na externé API, dáta fyzicky opustia vašu infraštruktúru. Aj keď provider nepersistuje vaše requesty (a väčšina enterprise tier-ov dnes tvrdí, že nepersistuje), z pohľadu GDPR čl. 28 ste uzatvorili vzťah spracovateľa osobných údajov. To si vyžaduje podpísanú zmluvu o spracovaní dát (DPA), preverenie tretej strany, záznam o spracovateľských činnostiach.
Pre zdravotnícke zariadenia pristupuje HIPAA v US alebo lokálna transpozícia odporúčaní EDPB v EÚ. Pre banky prichodí EBA ICT Risk a DORA framework. Pre advokácie je otázka ešte jednoduchšia: advokátske tajomstvo nerozlišuje medzi papierom a API requestom.
On-prem eliminuje data egress risk v princípe. Žiadny token vašich pacientov, klientov ani transakcií neopúšťa vašu sieť. To je rozdiel, ktorý nie je o marketingovom framing-u — je to auditovateľný technický fakt.
Zároveň buďme úprimní: on-prem sám osebe nestačí na compliance. Regulátor chce vidieť audit logy, access kontroly, šifrovanie dát v pokoji aj v pohybe, zdokumentovaný proces reakcie na incident, pravidelnú analýzu rizík. „Beží to u nás na serveri" je začiatok, nie cieľ.
Čo architektúra on-prem LLM musí obsahovať
Pred výberom GPU a modelu je nutné definovať, čo vlastne staviate. Funkčná on-prem LLM architektúra pre regulované odvetvia má päť vrstiev:
1. Serving engine a inferenčná vrstva
Pre produkčné multi-user nasadenie sú relevantné dva hlavné frameworky:
- `vLLM` — priemyselný štandard pre high-throughput serving. PagedAttention dramaticky znižuje fragmentáciu KV cache, continuous batching eliminuje čakanie na najpomalší request v dávke. Najširší HW support (NVIDIA, AMD, Gaudi).
- `SGLang` — výhodný pri RAG workloadoch a viackolových dialógoch vďaka RadixAttention, ktorý kešuje KV cache zdieľaných prefixov. Na prefix-heavy workloadoch dosahuje vyšší throughput aj nižšiu latenciu prvého tokenu (TTFT) ako vLLM.
Pre single-developer experimenty a piloty je Ollama v poriadku. Pre produkčný systém s desiatkami súbežných používateľov je podhodnotený — pod ním beží llama.cpp, ktorý nie je navrhnutý pre concurrent requests, a rozdiel v throughpute je pri viacerých paralelných požiadavkách podstatný.
2. Model — čo si môžete dovoliť a čo to dokáže
Výber modelu pre on-prem je primárne HW otázka. Objem VRAM určuje, čo viete spustiť.
Orientačné požiadavky na VRAM pre inferenciu (pre formáty bežne používané na on-prem):
- 7–9B model: ~5–7 GB VRAM pri Q4_K_M kvantizácii, ~8–13 GB pri Q8_0
- 13B model: ~8 GB pri Q4_K_M, ~14 GB pri Q8_0
- 34B model: ~17–20 GB pri Q4_K_M, ~30–34 GB pri Q8_0
- 70B model: ~35–40 GB pri Q4_K_M, ~70–75 GB pri Q8_0
K tomu sa pripočítava KV cache — pri dlhých kontextoch môže byť rovnako veľký ako samotné váhy modelu. Pre produkčné nasadenie s viacerými súbežnými requestmi a stredne dlhými kontextami počítajte s výraznou rezervou nad VRAM pre samotné váhy.
Z open-weight modelov, ktoré dávajú zmysel pre regulované odvetvia v roku 2026:
- Llama 4 Maverick a Scout (Meta, vlastná licencia) — MoE architektúra, silný výkon, 1M+ kontext. Meta custom licencia je postačujúca pre väčšinu enterprise interných nasadení.
- Qwen 3 rodina (Alibaba, Apache 2.0) — výborný výkon na document-heavy úlohách, viacjazyčná podpora vrátane európskych jazykov, permisívna licencia.
- Mistral Small (Apache 2.0) — európsky provider (plus pre GDPR argumentáciu), permisívna licencia. Väčší Mistral Large má vlastnú Mistral licenciu — pre komerčné on-prem nasadenie ju treba overiť.
- Phi-4 (Microsoft, MIT) — pre use-casy kde kapacita 7–14B parametrov stačí; nízke HW požiadavky, dobré sledovanie inštrukcií.
Pre regulované odvetvia odporúčame modely s permisívnou licenciou (Apache 2.0, MIT) — komerčné použitie je jednoznačné a licenčný audit je priamočiary.
3. Kvantizácia — kompromis, ktorý je väčšinou akceptovateľný
Kvantizácia znižuje VRAM footprint a zvyšuje throughput za cenu mierne nižšej presnosti. Pre regulované odvetvia je kľúčová otázka: aký kompromis je akceptovateľný pre danú úlohu?
Praktický prehľad formátov:
- Q8_0 (GGUF): zachováva ~98–99 % kvality oproti FP16, minimálna strata. Pre kritické úlohy (právna analýza, medicínska dokumentácia) je toto bezpečná voľba.
- Q4_K_M (GGUF): ~92–95 % kvality, výrazne nižšie VRAM požiadavky. Sweet spot pre väčšinu dokumentačných a RAG use-casov. Rozdiel oproti Q8 je pri bežnej konverzácii ťažko pozorovateľný.
- AWQ 4-bit: vhodné pre NVIDIA GPU, lepšia koherencia pri dlhých výstupoch ako GPTQ.
- Q2 a nižšie: výrazná degradácia kvality — pre regulované odvetvia neodporúčané.
Dôležitá poznámka: rozdiely v perplexite medzi Q4_K_M a BF16 sú na väčšine benchmarkov pod 6 %. To neznamená, že každá úloha je rovnako odolná — komplexné viacstupňové uvažovanie a precízna extrakcia štrukturovaných informácií môžu byť citlivejšie. Pred produkčným nasadením vždy validujte model na vzorke reálnych dát z vašej domény.
4. Dátová vrstva a RAG
Pre väčšinu regulovaných use-casov nestačí samotný model — potrebujete ho pripojiť na internú dokumentáciu, predpisy, históriu prípadov. Tu nastupuje RAG (Retrieval-Augmented Generation).
Kľúčové komponenty:
- Vektorová databáza lokálne nasadená:
Qdrant(open-source, Rust backend, GDPR-friendly európska firma),pgvector(rozšírenie PostgreSQL, jednoduché ak už máte PG), aleboMilvus. - Embedding model lokálne:
BGE-M3(BAAI) pokrýva viacero európskych jazykov a retrieval typov v jednom modeli. Beží lokálne, žiadny cloud. - Chunking a metadáta: pre zdravotnícke záznamy alebo právne dokumenty je štruktúrovaný chunking podľa logických jednotiek (článok, odsek, prípad) výrazne lepší ako naivné delenie po N tokenoch.
Veľkosť kontextového okna moderných modelov (1M+ tokenov) je lákavá, ale nie je náhradou za RAG v produkčnom systéme. KV cache pre 1M kontext zaberá desiatky GB VRAM navyše, latencia TTFT dramaticky rastie. Pre väčšinu dokumentačných use-casov je hybridný prístup (retrieval + kratší kontext) ekonomicky aj výkonnostne lepší.
5. Audit, access kontroly a monitoring
Toto je vrstva, ktorú technické tímy najčastejšie odkladajú — a práve na nej regulátori lipnú.
Minimálne požiadavky pre regulovaný on-prem LLM:
- Audit logy každého requestu: kto sa pýtal, kedy, aký bol prompt (alebo hash promptu), aký bol výstup (alebo hash), aká verzia modelu odpovedala. Logy musia byť tamper-evident (write-once úložisko alebo podpisovanie).
- Role-based access: lekár vidí záznamy svojich pacientov, nie celú nemocnicu. LLM endpoint musí rešpektovať tie isté ACL pravidlá ako zvyšok systému.
- Šifrovanie at-rest aj in-transit: váhy modelu, vektorová databáza, logy — všetko šifrované. TLS pre všetku internú komunikáciu.
- Network isolation: LLM inference server by nemal mať priamy internetový prístup. Air-gap alebo minimálny výstupný firewall pre serving node.
- Model version pinning: v regulovaných odvetviach musíte vedieť povedať, akým modelom bolo rozhodnutie urobené — aj o rok. Verziovanie váh a deterministická reprodukovateľnosť sú audit požiadavky.
Hardvér — čo reálne potrebujete
On-prem LLM nie je lacné riešenie. Je to investícia, ktorá dáva zmysel tam, kde alternatíva (cloud compliance réžia, poistenie rizika úniku, pokuta) je drahšia.
Pre orientáciu v roku 2026:
- Entry level (7–13B model, 1–5 súbežných používateľov): jedna NVIDIA RTX 4090 (24 GB VRAM) alebo A4000 (16 GB VRAM). Pre 13B v Q4_K_M to stačí, pre 13B v Q8_0 potrebujete buď dual-GPU alebo 4090.
- Mid tier (34B model alebo 70B v Q4_K_M, 5–20 súbežných používateľov): dve A5000 (24 GB × 2 = 48 GB), A6000 (48 GB), alebo consumer route — dve RTX 4090 v tensor parallelizme cez NVLink/PCIe.
- Production tier (70B v Q8_0 alebo vyššie, 20+ súbežných používateľov): A100 80 GB alebo H100 80 GB. Na jednej H100 viete pohodlne servovať 70B Q8_0 s rozumnou latenciou.
- Apple Silicon alternatíva: M4 Ultra / M5 Ultra s unifikovanou pamäťou 128–192 GB je zmysluplná on-prem voľba pre 70B FP16 tam, kde je prioritou tichý server room a nízka spotreba. Throughput je nižší ako H100, ale pre interné nasadenie s nízkym concurrency to môže byť dostatočné.
Nezabudnite na CPU pamäť — pri CPU offloading-u (ak GPU VRAM nestačí) beží časť modelu v RAM. Pre produkčné nasadenie s offloadingom potrebujete aspoň 128 GB RAM.
Čo on-prem LLM nie je
Pravdepodobne najčastejší omyl v procese rozhodovania: on-prem LLM automaticky neznamená compliance. Videli sme organizácie, ktoré si nainštalovali Ollama na workstation, a s istotou tvrdili, že sú GDPR compliant, pretože „AI beží lokálne".
Compliance je proces, nie stav inštalácie. K on-prem infraštruktúre musíte pridať:
- Formálnu analýzu rizík a DPIA (Data Protection Impact Assessment) ak spracúvate citlivé osobné údaje
- Záznamy o spracovateľských činnostiach zahŕňajúce LLM systém
- Pravidlá retencie — ako dlho uchovávate audit logy, kto má prístup
- Plán pri incidente — ak dôjde k narušeniu bezpečnosti, čo sa stane s logmi, kto sa hlási regulátorovi
- Pravidelné penetračné testovanie inference endpointov
Technické tímy, ktoré toto riešia samy bez právneho vstupu, väčšinou vyrobia systém, ktorý funguje technicky, ale zlyhá pri compliance audite na procesnej dokumentácii.
Porovnanie: on-prem vs sovereign cloud vs klasický cloud
Pre regulované odvetvia existujú v skutočnosti tri varianty, nie dva:
- Klasický cloud API (OpenAI, Anthropic, Google): najnižšia réžia, najvyšší výkon, ale data egress je reálny. Vhodné pre use-casy kde nepracujete s citlivými PII alebo dátami pokrytými sektorovými reguláciami.
- Sovereign cloud / EU region (Azure OpenAI EU, Anthropic Sovereign EU, OVH AI): dáta zostávajú v EÚ, provider je zaviazaný EU zmluvami, cenovník vyšší. Pre mnohé organizácie je toto lepší kompromis ako full on-prem — menšia HW investícia, vyšší výkon modelov, pri zachovaní GDPR rámca.
- Full on-prem / air-gap: žiadny data egress, plná kontrola, auditovateľnosť v najprísnejšom zmysle. Vyžaduje HW investíciu, vlastnú prevádzku, vlastný security stack. Jediná voľba pre najprísnejšie regulácie (napríklad spracovatelia klasifikovaných informácií, niektoré typy zdravotníckych dát).
Pre väčšinu SK/EU firiem v regulovaných odvetviach je sovereign cloud kombinovaný so selektívnym on-prem pre najcitlivejšie workloady pragmatická cesta. Nie všetky LLM úlohy musia bežať on-prem — iba tie, kde dáta to vyžadujú.
Guardrails a bezpečnosť modelu
On-prem nasadenie rieši externý data egress, ale nie interné riziká. Model môže halinovať, produkovať zavádzajúci medicínsky alebo právny obsah, alebo byť zneužitý cez prompt injection.
Pre regulované odvetvia sú nevyhnutné:
- Output validation: LLM výstup by mal prechádzať validačnou vrstvou pred zobrazením alebo ďalším spracovaním. Pre štruktúrované výstupy (extrakcia údajov z dokumentov, klasifikácia) používajte constraintovanú dekódovanie (
XGrammarbackend vvLLMaleboSGLang). - Human-in-the-loop pre kritické rozhodnutia: žiadny on-prem model by nemal automaticky podpisovať zdravotné odporúčania, schvaľovať úvery alebo generovať právne záväzné dokumenty bez ľudskej kontroly. Viac o tomto v human-in-the-loop pre agentov.
- Monitoring výstupov: sledovanie odmietnutí, nezvyčajných vzorov v promptoch, pokusov o extrakciu systémového promptu alebo kontextu.
Časté otázky
Je on-prem LLM vždy drahší ako cloud?
Pri nízkom objeme volaní (do niekoľko tisíc requestov denne) je cloud API lacnejší — nepotrebujete investovať do GPU. Pri vysokom objeme sa krivky prelínajú: vlastný GPU server sa amortizuje typicky do 1–2 rokov pri strednej záťaži. Pre regulované odvetvia však nejde primárne o cenu — ide o to, čo si vaša organizácia môže dovoliť z hľadiska compliance.
Akú VRAM GPU potrebujem pre bežné firemné použitie?
Pre väčšinu firemných use-casov (dokumentová analýza, interný copilot, klasifikácia) postačuje 7–13B model v Q4_K_M kvantizácii. Na to stačí NVIDIA RTX 4090 (24 GB) alebo A5000 (24 GB). Ak chcete väčší model (34B alebo 70B) pre náročnejšie právne alebo medicínske analýzy, počítajte s dual-GPU alebo profesionálnou kartou s 48–80 GB VRAM.
Musím mať ISO 27001 alebo iný certifikát, aby bol on-prem LLM legálny?
Nie priamo — GDPR ani sektorové regulácie nevyžadujú konkrétne certifikáty, ale vyžadujú "primerané technické a organizačné opatrenia". ISO 27001 je prax, ktorá dokazuje, že ste systematicky riadili riziká — výrazne zjednodušuje compliance audit a je stále viac požadovaný obchodnými partnermi.
Môžem použiť open-weight model komerčne bez právnych rizík?
Závisí od licencie. Apache 2.0 a MIT sú plne komerčne použiteľné bez obmedzení. Meta Llama licencia dovoľuje komerčné použitie, ale pri počte aktívnych používateľov nad 700 miliónov vyžaduje špeciálny súhlas — pre enterprise interné nasadenie to nie je relevantné. Vždy skontrolujte aktuálne znenie licencie pri výbere modelu.
Ako zabezpečím, že model nezachová alebo neprenesie firemné dáta?
Pri lokálnom nasadení model sám o sebe dáta nepersistuje — LLM je statická sada váh, nie databáza. Riziko je v periférnych vrstvách: logy serving frameworku, KV cache na disku (ak je povolená), kontext okno zdieľaný medzi sessions pri chybnej konfigurácii. Zabezpečte, že serving engine je nakonfigurovaný bez cross-session zdieľania kontextu, logy sú buď vypnuté alebo šifrované, a KV cache offload na disk je buď zakázaný alebo na šifrovanom zväzku.
*Ak zvažujete on-prem LLM pre zdravotníctvo, financie alebo právo a neviete, kde začať — radi sa pozrieme na vašu situáciu konkrétne. Pomáhame s výberom HW, architektúrou serving stacku a tým, čo budete musieť ukázať compliance tímu. Kontaktujte nás a začneme posúdením vašich skutočných požiadaviek.*