On-prem LLM dla branż regulowanych: architektura bez wycieku danych

W branżach regulowanych większość rozmów o wdrożeniu AI kończy się na tym samym pytaniu: „A gdzie będą nasze dane?" Gdy pyta dyrektor medyczny, compliance officer banku albo partner kancelarii prawnej, to pytanie nie jest retoryczne — za złą odpowiedzią stoi kara finansowa, utrata licencji lub odpowiedzialność karna.

Ten artykuł nie dotyczy tego, *czy* iść on-prem — o tym pisaliśmy w porównaniu lokalnych LLM i chmury. To jest o tym, *jak* zbudować infrastrukturę on-prem LLM, która wytrzyma kontrolę regulatora, audyt IT i codzienną eksploatację.

Dlaczego chmura nie wystarczy — nawet gdy dostawca obiecuje GDPR

Dostawcy chmury mają doskonałe certyfikaty bezpieczeństwa. Problem nie leży w ich technologii — problem tkwi w konstrukcji prawnej i architekturze przepływów danych.

Gdy wysyłasz prompt do zewnętrznego API, dane fizycznie opuszczają Twoją infrastrukturę. Nawet jeśli dostawca nie utrwala Twoich żądań (a większość warstw enterprise twierdzi dziś, że nie utrwala), z punktu widzenia RODO art. 28 zawarłeś relację procesora danych osobowych. Wymaga to podpisanej umowy powierzenia przetwarzania (DPA), weryfikacji strony trzeciej i rejestru czynności przetwarzania.

Dla placówek medycznych dochodzi HIPAA w USA lub lokalna transpozycja wytycznych EROD w UE. Dla banków — EBA ICT Risk i ramy DORA. Dla kancelarii prawnych sprawa jest jeszcze prostsza: tajemnica adwokacka nie rozróżnia między papierem a żądaniem API.

On-prem eliminuje ryzyko wycieku danych w samej swojej zasadzie. Żaden token dotyczący Twoich pacjentów, klientów ani transakcji nie opuszcza Twojej sieci. To różnica, która nie jest kwestią marketingowego framingu — to audytowalny fakt techniczny.

Jednocześnie bądźmy szczerzy: samo on-prem nie wystarczy do compliance. Regulator chce zobaczyć logi audytowe, kontrole dostępu, szyfrowanie danych w spoczynku i w transporcie, udokumentowany proces reagowania na incydenty oraz regularną analizę ryzyka. „Działa u nas na serwerze" to punkt wyjścia, nie cel.

Co musi zawierać architektura on-prem LLM

Zanim wybierzesz GPU i model, musisz zdefiniować, co właściwie budujesz. Funkcjonalna architektura on-prem LLM dla branż regulowanych składa się z pięciu warstw:

1. Silnik serving i warstwa inferencji

Do produkcyjnego wdrożenia dla wielu użytkowników istotne są dwa główne frameworki:

• `vLLM` — przemysłowy standard dla high-throughput serving. PagedAttention drastycznie ogranicza fragmentację KV cache, continuous batching eliminuje oczekiwanie na najwolniejsze żądanie w partii. Najszersze wsparcie sprzętowe (NVIDIA, AMD, Gaudi).
• `SGLang` — korzystny przy workloadach RAG i wieloturowych dialogach dzięki RadixAttention, które buforuje KV cache wspólnych prefiksów. Na workloadach prefix-heavy osiąga wyższy throughput i niższe opóźnienie pierwszego tokenu (TTFT) niż vLLM.

Do eksperymentów jednego dewelopera i pilotów Ollama jest wystarczająca. Do systemu produkcyjnego z dziesiątkami równoległych użytkowników jest niedoszacowana — pod spodem działa llama.cpp, który nie jest zaprojektowany do obsługi concurrent requests, a różnica w throughpucie przy wielu równoległych żądaniach jest znacząca.

2. Model — na co możesz sobie pozwolić i co potrafi

Wybór modelu dla on-prem to przede wszystkim kwestia sprzętowa. Dostępna VRAM decyduje o tym, co możesz uruchomić.

Orientacyjne wymagania VRAM dla inferencji (dla formatów powszechnie używanych w on-prem):

• Model 7–9B: ~5–7 GB VRAM przy kwantyzacji Q4_K_M, ~8–13 GB przy Q8_0
• Model 13B: ~8 GB przy Q4_K_M, ~14 GB przy Q8_0
• Model 34B: ~17–20 GB przy Q4_K_M, ~30–34 GB przy Q8_0
• Model 70B: ~35–40 GB przy Q4_K_M, ~70–75 GB przy Q8_0

Do tego dochodzi KV cache — przy długich kontekstach może być równie duży jak same wagi modelu. Przy produkcyjnym wdrożeniu z wieloma równoległymi żądaniami i średnio długimi kontekstami zakładaj znaczący zapas VRAM ponad wagi samego modelu.

Spośród modeli open-weight, które mają sens dla branż regulowanych w 2026 roku:

• Llama 4 Maverick i Scout (Meta, własna licencja) — architektura MoE, mocna wydajność, kontekst 1M+. Niestandardowa licencja Meta jest wystarczająca dla większości wewnętrznych wdrożeń enterprise.
• Rodzina Qwen 3 (Alibaba, Apache 2.0) — doskonała wydajność przy zadaniach document-heavy, obsługa wielu języków w tym europejskich, permisywna licencja.
• Mistral Small (Apache 2.0) — europejski dostawca (plus dla argumentacji RODO), permisywna licencja. Większy Mistral Large ma własną licencję Mistral — przy komercyjnym wdrożeniu on-prem należy ją zweryfikować.
• Phi-4 (Microsoft, MIT) — dla przypadków użycia, gdzie wystarczy pojemność 7–14B parametrów; niskie wymagania sprzętowe, dobre śledzenie instrukcji.

Dla branż regulowanych zalecamy modele z permisywną licencją (Apache 2.0, MIT) — użycie komercyjne jest jednoznaczne, a audyt licencyjny jest nieskomplikowany.

3. Kwantyzacja — kompromis, który jest zazwyczaj akceptowalny

Kwantyzacja zmniejsza ślad VRAM i zwiększa throughput kosztem nieznacznie obniżonej precyzji. Dla branż regulowanych kluczowe pytanie brzmi: jaki kompromis jest akceptowalny dla danego zadania?

Praktyczny przegląd formatów:

• Q8_0 (GGUF): zachowuje ~98–99% jakości względem FP16, minimalna strata. Dla zadań krytycznych (analiza prawna, dokumentacja medyczna) to bezpieczny wybór.
• Q4_K_M (GGUF): ~92–95% jakości, znacznie niższe wymagania VRAM. Sweet spot dla większości przypadków użycia dokumentacyjnych i RAG. Różnica względem Q8 w zwykłej konwersacji jest trudno zauważalna.
• AWQ 4-bit: odpowiedni dla GPU NVIDIA, lepsza spójność przy długich wyjściach niż GPTQ.
• Q2 i niżej: wyraźna degradacja jakości — dla branż regulowanych niezalecane.

Ważna uwaga: różnice perplexity między Q4_K_M a BF16 są na większości benchmarków poniżej 6%. Nie oznacza to, że każde zadanie jest tak samo odporne — złożone wieloetapowe rozumowanie i precyzyjna ekstrakcja informacji strukturalnych mogą być bardziej wrażliwe. Przed wdrożeniem produkcyjnym zawsze waliduj model na próbce rzeczywistych danych z Twojej domeny.

4. Warstwa danych i RAG

Dla większości regulowanych przypadków użycia sam model nie wystarczy — trzeba go połączyć z wewnętrzną dokumentacją, przepisami, historią spraw. Tu wkracza RAG (Retrieval-Augmented Generation).

Kluczowe komponenty:

• Wektorowa baza danych wdrożona lokalnie: Qdrant (open-source, backend Rust, europejska firma przyjazna RODO), pgvector (rozszerzenie PostgreSQL, proste jeśli masz już PG) lub Milvus.
• Model embeddingów lokalnie: BGE-M3 (BAAI) obsługuje wiele języków europejskich i typów retrieval w jednym modelu. Działa lokalnie, bez chmury.
• Chunking i metadane: dla dokumentacji medycznej lub prawnej ustrukturyzowany chunking według logicznych jednostek (artykuł, akapit, sprawa) jest znacznie lepszy niż naiwny podział co N tokenów.

Rozmiar okna kontekstowego nowoczesnych modeli (1M+ tokenów) kusi, ale nie zastąpi RAG w systemie produkcyjnym. KV cache dla kontekstu 1M zajmuje dziesiątki GB VRAM więcej, opóźnienie TTFT gwałtownie rośnie. Dla większości przypadków dokumentacyjnych podejście hybrydowe (retrieval + krótszy kontekst) jest lepsze zarówno ekonomicznie, jak i wydajnościowo.

5. Audyt, kontrole dostępu i monitoring

To warstwa, którą zespoły techniczne najczęściej odkładają na później — i właśnie na niej koncentrują się regulatorzy.

Minimalne wymagania dla regulowanego on-prem LLM:

• Logi audytowe każdego żądania: kto pytał, kiedy, jaki był prompt (lub jego hash), jakie było wyjście (lub jego hash), jaka wersja modelu odpowiedziała. Logi muszą być tamper-evident (magazyn write-once lub podpisywanie).
• Kontrola dostępu oparta na rolach: lekarz widzi dokumentację swoich pacjentów, nie całego szpitala. Endpoint LLM musi respektować te same reguły ACL co reszta systemu.
• Szyfrowanie at-rest i in-transit: wagi modelu, baza wektorowa, logi — wszystko szyfrowane. TLS dla całej komunikacji wewnętrznej.
• Izolacja sieciowa: serwer inferencji LLM nie powinien mieć bezpośredniego dostępu do internetu. Air-gap lub minimalny firewall wyjściowy dla węzła serving.
• Pinning wersji modelu: w branżach regulowanych musisz być w stanie powiedzieć, jakim modelem podjęto daną decyzję — nawet rok później. Wersjonowanie wag i deterministyczna odtwarzalność to wymagania audytowe.

Sprzęt — czego naprawdę potrzebujesz

On-prem LLM nie jest tanim rozwiązaniem. To inwestycja, która ma sens tam, gdzie alternatywa — koszty compliance w chmurze, ubezpieczenie ryzyka wycieku, kara finansowa — jest droższa.

Orientacyjnie w 2026 roku:

• Entry level (model 7–13B, 1–5 równoległych użytkowników): jedna NVIDIA RTX 4090 (24 GB VRAM) lub A4000 (16 GB VRAM). Dla 13B w Q4_K_M to wystarczy, dla 13B w Q8_0 potrzeba dual-GPU lub 4090.
• Poziom średni (model 34B lub 70B w Q4_K_M, 5–20 równoległych użytkowników): dwie A5000 (24 GB × 2 = 48 GB), A6000 (48 GB) lub wariant konsumencki — dwie RTX 4090 w tensor parallelism przez NVLink/PCIe.
• Poziom produkcyjny (70B w Q8_0 lub wyżej, 20+ równoległych użytkowników): A100 80 GB lub H100 80 GB. Na jednej H100 możesz wygodnie serwować 70B Q8_0 z rozsądnym opóźnieniem.
• Alternatywa Apple Silicon: M4 Ultra / M5 Ultra z ujednoliconą pamięcią 128–192 GB to sensowny wybór on-prem dla 70B FP16, gdy priorytetem jest cichy serwerownia i niskie zużycie energii. Throughput jest niższy niż H100, ale dla wewnętrznego wdrożenia z niskim concurrency może być wystarczający.

Nie zapomnij o pamięci RAM — przy CPU offloading (gdy VRAM GPU nie wystarcza) część modelu działa w RAM. Do produkcyjnego wdrożenia z offloadingiem potrzebujesz co najmniej 128 GB RAM.

Czym on-prem LLM nie jest

Prawdopodobnie najczęstszy błąd w procesie decyzyjnym: on-prem LLM automatycznie nie oznacza compliance. Widzieliśmy organizacje, które zainstalowały Ollama na stacji roboczej i z pełnym przekonaniem twierdziły, że są zgodne z RODO, bo „AI działa lokalnie".

Compliance to proces, nie stan instalacji. Do infrastruktury on-prem musisz dodać:

• Formalną analizę ryzyka i DPIA (Data Protection Impact Assessment), jeśli przetwarzasz wrażliwe dane osobowe
• Rejestr czynności przetwarzania obejmujący system LLM
• Reguły retencji — jak długo przechowujesz logi audytowe, kto ma do nich dostęp
• Plan reagowania na incydenty — jeśli dojdzie do naruszenia bezpieczeństwa, co się dzieje z logami, kto zgłasza zdarzenie regulatorowi
• Regularne testy penetracyjne endpointów inferencji

Zespoły techniczne, które rozwiązują to samodzielnie bez udziału prawników, zazwyczaj tworzą system, który działa technicznie, ale nie przejdzie audytu compliance z powodu braków w dokumentacji procesowej.

Porównanie: on-prem vs sovereign cloud vs klasyczna chmura

Dla branż regulowanych istnieją w rzeczywistości trzy warianty, nie dwa:

• Klasyczne cloud API (OpenAI, Anthropic, Google): najniższe koszty ogólne, najwyższa wydajność, ale wyciek danych jest realny. Odpowiednie dla przypadków użycia, gdzie nie pracujesz z wrażliwymi PII ani danymi objętymi regulacjami sektorowymi.
• Sovereign cloud / region UE (Azure OpenAI EU, Anthropic Sovereign EU, OVH AI): dane pozostają w UE, dostawca jest związany umowami unijnymi, cennik wyższy. Dla wielu organizacji to lepszy kompromis niż pełne on-prem — mniejsza inwestycja w sprzęt, wyższa wydajność modeli, przy zachowaniu ram RODO.
• Pełne on-prem / air-gap: brak wycieku danych, pełna kontrola, audytowalność w najściślejszym sensie. Wymaga inwestycji w sprzęt, własnej eksploatacji, własnego stosu bezpieczeństwa. Jedyna opcja dla najbardziej rygorystycznych regulacji (np. przetwarzający informacje niejawne, niektóre typy danych medycznych).

Dla większości firm SK/EU w branżach regulowanych sovereign cloud połączony z selektywnym on-prem dla najbardziej wrażliwych workloadów to pragmatyczna droga. Nie wszystkie zadania LLM muszą działać on-prem — tylko te, których dane tego wymagają.

Guardrails i bezpieczeństwo modelu

Wdrożenie on-prem rozwiązuje zewnętrzny wyciek danych, ale nie wewnętrzne ryzyka. Model może halucynować, produkować mylące treści medyczne lub prawne albo zostać nadużyty przez prompt injection.

Dla branż regulowanych niezbędne są:

• Walidacja wyjść: wynik LLM powinien przechodzić przez warstwę walidacyjną przed wyświetleniem lub dalszym przetwarzaniem. Dla wyjść strukturalnych (ekstrakcja danych z dokumentów, klasyfikacja) używaj zdekodowania z ograniczeniami (XGrammar backend w vLLM lub SGLang).
• Human-in-the-loop dla krytycznych decyzji: żaden model on-prem nie powinien automatycznie podpisywać zaleceń medycznych, zatwierdzać kredytów ani generować prawnie wiążących dokumentów bez kontroli człowieka. Więcej na ten temat w artykule o human-in-the-loop dla agentów.
• Monitoring wyjść: śledzenie odmów, nietypowych wzorców w promptach, prób ekstrakcji systemowego promptu lub kontekstu.

Najczęstsze pytania

Czy on-prem LLM jest zawsze droższy niż chmura?

Przy niskim wolumenie wywołań (do kilku tysięcy żądań dziennie) cloud API jest tańsze — nie potrzebujesz inwestować w GPU. Przy wysokim wolumenie krzywe się przecinają: własny serwer GPU amortyzuje się typowo w ciągu 1–2 lat przy średnim obciążeniu. Dla branż regulowanych jednak kwestia nie jest przede wszystkim finansowa — chodzi o to, na co Twoja organizacja może sobie pozwolić z perspektywy compliance.

Ile VRAM GPU potrzebuję do typowego użytku firmowego?

Dla większości firmowych przypadków użycia (analiza dokumentów, wewnętrzny copilot, klasyfikacja) wystarczy model 7–13B w kwantyzacji Q4_K_M. Do tego potrzeba NVIDIA RTX 4090 (24 GB) lub A5000 (24 GB). Jeśli chcesz większy model (34B lub 70B) do bardziej wymagających analiz prawnych lub medycznych, zakładaj dual-GPU lub profesjonalną kartę z 48–80 GB VRAM.

Czy muszę mieć ISO 27001 lub inny certyfikat, żeby on-prem LLM był legalny?

Nie bezpośrednio — ani RODO, ani regulacje sektorowe nie wymagają konkretnych certyfikatów, ale wymagają „odpowiednich środków technicznych i organizacyjnych". ISO 27001 to praktyka, która dowodzi systematycznego zarządzania ryzykiem — znacząco upraszcza audyt compliance i jest coraz częściej wymagana przez partnerów handlowych.

Czy mogę używać modelu open-weight komercyjnie bez ryzyka prawnego?

Zależy od licencji. Apache 2.0 i MIT są w pełni dopuszczalne do użytku komercyjnego bez ograniczeń. Licencja Meta Llama zezwala na użycie komercyjne, ale przy liczbie aktywnych użytkowników powyżej 700 milionów wymaga specjalnej zgody — dla wewnętrznych wdrożeń enterprise to nieistotne. Zawsze sprawdź aktualne brzmienie licencji przy wyborze modelu.

Jak zapewnić, że model nie zachowuje ani nie przesyła danych firmowych?

W przypadku lokalnego wdrożenia model sam w sobie nie utrwala danych — LLM to statyczny zestaw wag, nie baza danych. Ryzyko leży w warstwach peryferyjnych: logi frameworku serving, KV cache na dysku (jeśli jest włączony), okno kontekstowe współdzielone między sesjami przy błędnej konfiguracji. Upewnij się, że silnik serving jest skonfigurowany bez współdzielenia kontekstu między sesjami, logi są wyłączone lub zaszyfrowane, a offload KV cache na dysk jest albo wyłączony, albo realizowany na zaszyfrowanym woluminie.

*Jeśli rozważasz on-prem LLM dla ochrony zdrowia, finansów lub prawa i nie wiesz, od czego zacząć — chętnie przyjrzymy się Twojej sytuacji konkretnie. Pomagamy z doborem sprzętu, architekturą stosu serving i tym, co będziesz musiał pokazać zespołowi compliance. Skontaktuj się z nami — zaczniemy od oceny Twoich rzeczywistych wymagań.*