On-prem AI

AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny

Architektura, GPU sizing, bezpieczeństwo, integracje, TCO, build vs buy. Praktyczny przewodnik wdrożenia AI on-prem dla CISO i CIO w europejskiej produkcji w 2026.

14 maja 2026·23 min czytania·Fryderyk Wiatrowski

Spis treści

Po co ten tekst i dla kogo
Definicje, których nie mieszamy
Trzy use case, dla których on-prem ma sens
Architektura referencyjna: siedem warstw
GPU sizing: liczby, nie obietnice
Bezpieczeństwo: segmentacja, audyt, sekrety
Integracje: ERP, MES, PLM, ticketing
TCO: pełny rachunek dla 500 FTE
Build vs buy: kiedy DIY, kiedy productized
Disclosure i biases
Co tu nie pokrywam

Po co ten tekst i dla kogo

W 2026 roku coraz więcej europejskich firm produkcyjnych dochodzi do tego samego punktu. Zarząd pyta o AI. Dział sprzedaży pyta o ofertowanie. Service desk pyta o asystenta technicznego. Biuro konstrukcyjne pyta, czy da się rysunki zamienić w specyfikacje szybciej. A obok tych pytań siedzi CISO z plikiem nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (UKSC), kalkulator ryzyka łańcucha dostaw, regulacja AI Act, polityka grupowa, RODO i ISO 27001. I jedno proste pytanie: czy publiczna AI tu w ogóle przejdzie.

Coraz częściej odpowiedź brzmi: nie przejdzie. Albo: przejdzie, ale przy kosztach kontroli, których nikt nie chce ponosić. Albo: przejdzie pod warunkiem deploymentu w architekturze, którą i tak nazwalibyście on-prem, więc zacznijmy od on-prem.

Ten tekst jest dla CISO, CIO, architekta bezpieczeństwa, kierownika infrastruktury i compliance leada w organizacji produkcyjnej 200 do 2000 osób. Nie jest dla operacyjnego sponsora projektu (jego prowadzi inny portal). Nie jest dla niezdecydowanego zarządu (do niego przemawia się inaczej). Jest dla osoby, która ma postawić platformę AI tak, żeby przeszła audyt, żeby zarząd nie odpowiadał osobiście za incydent w łańcuchu dostaw, i żeby za 18 miesięcy nikt nie zapytał, czemu tego nie zrobiliśmy lepiej.

Pokażę: jak nie mieszać on-prem z hybrid, gdzie on-prem realnie się amortyzuje, jak wygląda architektura referencyjna w siedmiu warstwach, jakie konkretne GPU kupuje się do Llama 3.1 70B i Mixtral 8x22B (z liczbami), jak segmentuje się sieć dla audytu, gdzie najczęściej parzy się przy integracjach (ERP, MES, PLM, ticketing), i jak liczy się TCO bez podpórek marketingowych. Na końcu jest sekcja o decyzji build vs buy, ze szczerą oceną kiedy ma sens DIY na open-source, a kiedy productized vendor.

Tekst zakłada, że czytelnik wie, co to LLM, RAG i KV cache. Nie zakłada, że czytelnik wie, ile naprawdę kosztuje H100 i jak to się rozkłada na user-rok.

Definicje, których nie mieszamy

W rozmowach z dostawcami AI panuje terminologiczny chaos, który kosztuje firmy realne pieniądze, bo na końcu kupują coś, co nie spełnia wymagań, w które celowali. Trzy modele, trzy zupełnie różne profile ryzyka regulacyjnego.

Public cloud LLM (OpenAI, Anthropic, Google Vertex, Azure OpenAI). Dane (prompt, kontekst RAG, output) trafiają poza perymetr organizacji. Vendor jest w łańcuchu dostaw NIS2 z dostępem do treści zapytań i, w zależności od trybu, treści dokumentów retrievalu. Egress kontrolny, ale obecny. To nie jest on-prem. To nie jest "prywatne wdrożenie". To public cloud AI z opcjonalnym zero data retention. Jeżeli vendor mówi "private cloud" i ma na myśli swój multi-tenant lub single-tenant deployment na własnej infrastrukturze, to jest hosted SaaS, nie on-prem.

Hybrid (model w chmurze hyperscalera, dane retrievalu lokalnie). Często sprzedawane jako "prywatna AI". W praktyce: chunk retrievalu jest lokalny (vector DB na waszej infrastrukturze), ale fragment dokumentu wraz z promptem leci do publicznego modelu inference (Azure OpenAI, AWS Bedrock, Vertex). Pod kątem NIS2 to nadal vendor w łańcuchu dostaw, tylko z węższym zakresem ekspozycji. Może być akceptowalne, ale wymaga osobnego mapowania Art. 21 i osobnej zgody bezpieczeństwa. Nie nazywajcie tego on-prem.

On-prem (model inference w perymetrze organizacji). GPU stoi w waszej serwerowni albo w waszym colo. Model leci na waszych warstwach OS, container, runtime. Dane (prompt, retrieval, output) nie opuszczają granicy zaufania zdefiniowanej w polityce bezpieczeństwa. Egress jest możliwy do internet update'ów (modele bazowe, security patches, telemetry vendora platformy), ale dane operacyjne zostają. To jest on-prem w sensie, który przejdzie audyt NIS2.

Czwarta opcja, którą warto wymienić ze względu na popularność marketingową: managed appliance dostarczany do serwerowni klienta przez vendora platformy. Z punktu widzenia ekspozycji danych to on-prem (dane lokalne, model lokalny). Z punktu widzenia operacyjnego to hybrid (vendor ma uprzywilejowany dostęp do appliance dla utrzymania). To kombinacja, którą trzeba mapować osobno, najczęściej z umową MSA precyzującą warstwy dostępu vendora i procedurę break-glass. Jest sensowna dla firm, które mają budżet na hardware i nie mają zespołu MLOps.

Pisząc dalej "on-prem", mam na myśli trzeci wariant. Czwarty wymieniam, gdy ma znaczenie operacyjne.

Trzy use case, dla których on-prem ma sens

Zanim wejdziemy w architekturę: lokalna AI nie jest opłacalna dla każdego workflowa. Część projektów świetnie biegnie na public cloud AI, część w hybrid, część po prostu nie ma masy krytycznej, żeby uzasadnić infrastrukturę GPU. Trzy use case, które się amortyzują on-prem w średniej i większej firmie produkcyjnej:

Service desk i troubleshooting techniczny. Asystent dla service engineerów, który pobiera kontekst z manuali produktowych, historii zgłoszeń, kart serwisowych i dokumentacji konstrukcyjnej, i generuje proponowane kroki rozwiązania. Dane są wrażliwe (klient, awaria, IP konstrukcyjne, czasem ślad incydentu cyber). Częstotliwość zapytań w średniej firmie: 200 do 2000 dziennie. Stała charakterystyka load. Idealne dla on-prem, bo per zapytanie i per dzień się amortyzuje. Public cloud koszt na taki wolumen w trzyletniej amortyzacji jest porównywalny z on-prem CAPEX, plus risk regulatorny.

Generowanie instrukcji pracy i SOP. Wsad: dokumentacja produktowa, instrukcje BHP, normy, instrukcje narzędzi, historia zmian procesowych. Output: drafty SOP, instrukcji stanowiskowych, materiałów szkoleniowych, jednoinstrukcyjne karty operacyjne. Mniejszy wolumen niż service desk (50 do 300 generacji dziennie), ale dłuższy kontekst (10 do 100 tys. tokenów retrievalu), więc moc obliczeniowa per zapytanie wyższa. On-prem ma sens ze względu na charakter dokumentów (często chronione patentem, kontraktem licencyjnym, lub regulacją bezpieczeństwa) i ze względu na to, że publiczny LLM rzadko ma w training data specyfiki sektorowe.

Ofertowanie techniczne i drawing-to-offer. Workflow: wejście (rysunek techniczny PDF, mail, zapytanie ofertowe, plik DXF/STEP), output (BOM, dopasowane specyfikacje, draft oferty handlowej, kalkulacja). Wsad: katalogi produktowe, historia ofert, cenniki, polityka rabatów, dane konstrukcyjne. To dane, których w 100% firm B2B nie da się przepuścić przez public cloud, bo zawierają strategiczne ceny, marże, IP klienta i często NDA przedsprzedażowe. Wolumen mniejszy niż service desk (5 do 50 dziennie), ale wartość per case wysoka (oferta techniczna na 50 do 500 tys. EUR). Tu on-prem jest często wymogiem, nie wyborem.

Czego on-prem nie potrzebuje (czyli kiedy nie inwestujcie w infrastrukturę):

General-purpose copilot dla ogółu pracowników biurowych. Public cloud Microsoft Copilot albo equivalent. Wolumen rozproszony, charakter danych mniej wrażliwy, korzyść z konsumenckiego UX.
Tłumaczenia i copy editing dokumentów marketingowych. Public cloud.
Generowanie kodu w IT (deweloperzy wewnętrzni). Hybrid GitHub Copilot Enterprise lub równoważne. On-prem kosztowo nie ma sensu poniżej 100 deweloperów.

Reguła: on-prem dla workflowów wąskich, intensywnych, wrażliwych. Public cloud dla workflowów szerokich, rozproszonych, niskiej wrażliwości. Hybrid dla pośrednich.

Architektura referencyjna: siedem warstw

Każda decyzja architektoniczna w on-prem AI siedzi w jednej z siedmiu warstw. Pominięcie warstwy albo zlepienie dwóch w jedną to najczęstsza przyczyna projektów, które wchodzą w produkcję, ale nie wchodzą w audyt.

┌────────────────────────────────────────────────────────────┐
│  7. Observability i audit log (Loki/Grafana, SIEM)         │
├────────────────────────────────────────────────────────────┤
│  6. Application layer (UI, API, workflow orchestration)    │
├────────────────────────────────────────────────────────────┤
│  5. RAG pipeline (chunking, embedding, retrieval, rerank)  │
├────────────────────────────────────────────────────────────┤
│  4. Model serving (vLLM, TGI, TensorRT-LLM)                │
├────────────────────────────────────────────────────────────┤
│  3. Container i runtime (Kubernetes, Docker, GPU operator) │
├────────────────────────────────────────────────────────────┤
│  2. Operating system (Ubuntu/RHEL, NVIDIA drivers, CUDA)   │
├────────────────────────────────────────────────────────────┤
│  1. Hardware (GPU, CPU, RAM, storage, network)             │
└────────────────────────────────────────────────────────────┘

Warstwa 1: Hardware. GPU (NVIDIA H100, H200, A100, L40S są typowymi wyborami w 2026 dla on-prem inference; AMD MI300X gdzieniegdzie pojawia się, ale ekosystem softwareowy nadal jest słabszy). CPU (32 do 64 rdzeni Xeon Gold lub AMD EPYC). RAM (256 GB do 1 TB, w zależności od wsparcia dla model offload do CPU). Storage (NVMe SSD 2 do 8 TB lokalnie, plus storage backend dla dokumentów i vector DB). Sieć (25 GbE minimum, 100 GbE dla multi-node).

Warstwa 2: OS i sterowniki. Ubuntu LTS lub RHEL/Rocky, drivery NVIDIA, CUDA toolkit, fabric manager dla multi-GPU. Tu zaczynają się pierwsze decyzje compliance: czy maszyna ma dostęp do internetu dla auto-update, czy patch management leci przez wewnętrzny mirror, kto ma SSH na bare metal.

Warstwa 3: Container runtime i orkiestracja. Kubernetes z NVIDIA GPU Operator albo prostszy Docker Compose dla mniejszych deploymentów. Decyzja zależy od skali (jeden node vs cluster) i dojrzałości zespołu platform. Dla 1 do 4 nodów Docker Compose albo prosty K3s wystarczy i znacząco redukuje operational overhead.

Warstwa 4: Model serving. vLLM (najczęstszy wybór w 2026, dobry tradeoff przepustowości i prostoty), TGI (Text Generation Inference od Hugging Face), TensorRT-LLM (najwyższa przepustowość, ale skomplikowana kalibracja i recompile per model). Wybór determinuje przepustowość, charakterystykę latency i wymagania pamięciowe.

Warstwa 5: RAG pipeline. Tu siedzi większość wartości dla manufactura. Chunking (split dokumentów na fragmenty), embedding (vectorization fragmentów, modele typu BGE, e5, jina), vector store (Milvus, Qdrant, Weaviate, w mniejszych deploymentach Postgres + pgvector), retrieval (BM25 + dense + rerank), rerank (cohere-like model lokalny), grounding (mechanizm cytowania źródeł w odpowiedzi). To warstwa, w której najwięcej projektów odpada, bo skupiają się na modelu, a wartość siedzi w pipeline.

Warstwa 6: Application layer. UI dla użytkowników, API dla integracji systemowych, orkiestracja workflowów (np. drawing-to-offer wymaga wieloetapowego pipeline: OCR rysunku, ekstrakcja struktury, retrieval katalogowy, generacja oferty, walidacja). Tu często wchodzi backend webowy (Python FastAPI, Node.js), kolejka (Redis, Celery), baza relacyjna dla stanu workflowów.

Warstwa 7: Observability i audit log. Każde zapytanie LLM, retrieval i jego wyniki, response, user, timestamp, model ID, wersja systemu, długość kontekstu, latencja, błędy. To nie jest "nice to have". To jest fundament audytu NIS2 i AI Act. Bez tego nie udowodnicie audytorowi, że wiecie, co model robi. Praktyczny stack: Loki + Grafana dla logów, Prometheus dla metryk, SIEM (Wazuh, Splunk, w zależności od polityki) dla integracji z resztą organizacji.

Najczęstsze błędy w tym układzie:

Pominięcie warstwy 7 lub jej zlepienie z generic application logging. Audytor pyta o ślad konkretnego zapytania sprzed trzech miesięcy, response z tej rozmowy, kto pytał, jakie dokumenty się wyciągnęły. Bez dedykowanego audit logu na poziomie LLM tego nie ma.
Mieszanie warstwy 5 z warstwą 6. RAG pipeline powinien być osobnym serwisem z własnym API, nie metodą w monolicie aplikacyjnym. Inaczej nie da się go niezależnie testować ani wymienić.
Wybranie cluster Kubernetes (warstwa 3) na deployment, który będzie miał 1 do 2 nody przez najbliższe 2 lata. K8s overhead jest istotny i często niewart świeczki dla małych deploymentów.

GPU sizing: liczby, nie obietnice

Najczęściej zadawane pytanie CISO: ile to GPU kosztuje. Najczęściej zadawane pytanie CIO: ile użytkowników to obsłuży. Odpowiedź zależy od modelu, kwantyzacji, charakterystyki workloadu (concurrent users, długość kontekstu, batch lub stream), i precyzji oczekiwań od odpowiedzi.

Modele referencyjne dla manufacturing on-prem w 2026:

Llama 3.1 70B. Sweet spot jakości i kosztu na drugą połowę 2026. W FP16 zajmuje około 140 GB VRAM (sam model, bez KV cache). Z kwantyzacją FP8 lub INT8 około 70 do 80 GB. Z INT4 około 40 GB plus narzut KV cache zależnie od długości kontekstu.

Realna konfiguracja produkcyjna dla 70B INT8: 2x H100 80GB (160 GB VRAM total, miejsce na model plus KV cache plus batching). Przepustowość: 30 do 50 tokenów na sekundę na single stream, 200 do 400 tokenów na sekundę w batched serving. Concurrent users: 30 do 80, zależnie od długości promptów i akceptowalnej latency.

Mixtral 8x22B. Mixture of experts, 141 mld parametrów total, około 39 mld aktywnych. FP16 około 280 GB. FP8 około 140 GB. INT4 około 70 do 80 GB. W praktyce: 4x A100 80GB albo 2x H100 80GB w FP8 daje sensowną przepustowość. Jakość często wyższa niż Llama 70B na zadaniach generatywnych, niższa na dokładnym retrievalu.

Llama 3.1 8B i nowsze modele 7 do 12B. Dla workflowów mniej wymagających albo dla embeddingów i reranku. Mieści się na pojedynczym L40S 48GB albo nawet RTX 6000 Ada 48GB w FP16. Przepustowość: 80 do 150 tokenów na sekundę na karty L40S. Często używane jako "router" przed większym modelem albo do drobnych zadań typu klasyfikacja zapytań, generowanie tagów.

Embedding models (BGE-M3, e5-mistral, jina-v3). 100 MB do 5 GB. Działają na CPU lub na małej karcie L4 24GB. Sizing zwykle nie jest wąskim gardłem.

Konkretne pakiety hardware'owe dla średniej firmy 200 do 1000 FTE z mieszaną charakterystyką workloadu (service desk dominujący, ofertowanie, instrukcje):

Pakiet A. Pojedynczy node, 4x L40S 48GB. Llama 3.1 70B INT4 plus mniejszy 8B router. Service desk dla 20 do 40 concurrent users. Cena listowa karty L40S około 10 do 12 tys. EUR, server chassis Dell R760xa lub Supermicro AS-4125GS z BMC, redundant power, 512 GB RAM, 8 TB NVMe RAID około 30 do 40 tys. EUR. Total CAPEX około 75 do 95 tys. EUR. Power draw około 1.5 do 2 kW.

Pakiet B. Pojedynczy node, 2x H100 80GB. Llama 3.1 70B INT8 plus 8B router. Service desk dla 40 do 80 concurrent users, plus ofertowanie. Cena listowa H100 80GB SXM około 30 tys. EUR (po deal'ach często 22 do 28 tys.), PCIe wersja podobnie. Server chassis z dwoma kartami SXM na NVLink około 80 do 100 tys. EUR (Dell PowerEdge XE9680 ale 8x to overkill; w praktyce HGX-baseboard z 2x H100 albo PCIe wersja). Total CAPEX około 100 do 140 tys. EUR. Power draw około 2 do 3 kW.

Pakiet C. Dwa nody, 4x H100 80GB każdy (HGX baseboard). Llama 70B w FP16/FP8 dla najwyższej jakości plus Mixtral 8x22B w FP8 plus 8B router. Service desk plus ofertowanie plus generowanie instrukcji, 80 do 200 concurrent users, redundancja. Total CAPEX 350 do 500 tys. EUR. Power draw 6 do 10 kW. Wymaga klimatyzacji i UPS klasy enterprise.

Pakiet D. Appliance HGX H200 lub równoważne. Dla największych deploymentów. Cena 600 tys. do 1 mln EUR. Power draw 8 do 14 kW. Dla 95% średnich firm produkcyjnych w Europie to overkill. Wymieniam dla kompletności.

Reguła kciuka: pakiet A pokrywa 70% przypadków małych i średnich firm. Pakiet B pokrywa większość średnich firm 500 FTE. Pakiet C jest dla większych firm 1000+ FTE albo dla grup, które konsolidują AI workload z wielu zakładów.

Drugorzędne, ale ważne: pamiętajcie o zapasie 30% VRAM na KV cache i batching headroom. Llama 70B INT8 zajmie 70 GB na model, ale realnie na long-context (32k tokens, batched 16) plus margines bezpieczeństwa potrzebuje 140 do 160 GB VRAM. Stąd 2x H100, nie 1x H100.

Bezpieczeństwo: segmentacja, audyt, sekrety

Cztery zagadnienia z poziomu CISO, które muszą być zaadresowane przed pierwszym pilotażem:

Network segmentation. Cztery strefy minimum:

Strefa DMZ (web frontend, reverse proxy z TLS termination, WAF). Dostęp do internetu kontrolowany.
Strefa aplikacyjna (API, orkiestracja workflowów, kolejki). Brak dostępu do internetu poza wybranymi endpointami (np. zewnętrzne ERP API jeśli wymagane).
Strefa modeli (GPU nodes, model serving). Brak dostępu do internetu w czasie produkcji. Updates modeli przez wewnętrzny mirror.
Strefa danych (vector DB, document store, audit log). Tylko dostęp z aplikacyjnej, brak internetu.

Firewalle między strefami z explicit allow listą protokołów i portów. Brak permissive default. Audit ruchu między strefami w SIEM.

Audit log na poziomie LLM. Każde zapytanie i odpowiedź zapisane z metadanymi: user (z waszego IdP, nie z lokalnego konta), timestamp, model ID + wersja, system prompt ID + wersja, retrieved chunks (ID + score + treść), full prompt, full response, długość kontekstu, latencja, koszt obliczeniowy. Retencja minimum 12 miesięcy, dla podmiotów kluczowych NIS2 rozważcie 24 do 36 miesięcy w zależności od typu danych. Audit log jest immutable (append-only, write-once-storage albo cryptographic chain).

Zarządzanie sekretami i kluczami. Brak hardcoded credentials w kontenerach. Vault (HashiCorp Vault, AWS Secrets Manager jeśli używacie hybrid, Kubernetes secrets z encryption at rest). Rotacja kluczów do API systemowych co 90 dni. Service accounts dla integracji ERP/MES z least-privilege scope. Dostęp adminów do warstwy bare metal i kontenerów przez bastion z MFA i sesją nagrywaną.

Data classification i mechanizmy DLP. Przed wpuszczeniem dokumentu do RAG pipeline klasyfikacja (public, internal, confidential, restricted). Restricted (kontrakty, ceny strategiczne, IP z NDA) z dodatkową kontrolą access list na poziomie chunk retrieval. Mechanizm guard, który blokuje response zawierający dane z klasy restricted dla użytkowników bez odpowiednich uprawnień. To jest trudne, robi się z tym najczęściej kompromisy, ale dla podmiotów kluczowych NIS2 to nie jest opcjonalne.

Dodatkowo:

Threat model dla typowych ataków na LLM: prompt injection (przez dokument retrievalu), jailbreak, data poisoning bazy retrievalu, model extraction (kradzież IP modelu przez query crafting), excessive disclosure. Każdy z nich wymaga osobnego control.
Penetration testing pre-production. Dla podmiotów kluczowych co najmniej raz w roku.
Backup i disaster recovery dla wszystkich warstw poza modelem (model można pobrać ponownie z mirror'a; dane retrievalu, audit log, konfiguracje, sekrety to wymóg backup'u).
Patch management dla CUDA, drivers, kontenerów, modelu serving. To nie jest infrastruktura zero-touch.

Integracje: ERP, MES, PLM, ticketing

Integracje są warstwą, w której najczęściej projekty AI on-prem zatrzymują się dłużej, niż planowano. Cztery kategorie systemów, z którymi platforma AI rozmawia w typowej organizacji produkcyjnej:

ERP (SAP S/4HANA, Comarch ERP XL, IFS Cloud, Microsoft Dynamics). Dla service desk: dane klienta, historia kontraktów, instalowane produkty. Dla ofertowania: cenniki, polityki rabatów, dane handlowe. Najczęstsze podejście integracyjne to read-only API albo replica bazy do data layer AI (z dziennym sync). Pisanie do ERP z poziomu AI jest rzadkie i wymaga osobnej walidacji compliance. Czas integracji: 2 do 6 tygodni przy istniejącym API, 6 do 12 tygodni przy legacy ERP bez API.

MES (Siemens Opcenter, Wonderware, Aveva, własne rozwiązania). Dla service desk: status maszyn, historia alarmów. Dla generowania instrukcji: parametry procesów, normy. Integracje typowo OPC UA, MQTT, albo proprietary protokoły. Czas: 4 do 10 tygodni. Najczęstsza pułapka: MES ma rozdrobnione dane między działami, część w bazie, część w plikach Excel, część w głowach inżynierów procesu.

PLM (Teamcenter, Aras Innovator, PTC Windchill, 3DEXPERIENCE). Dla biura konstrukcyjnego i ofertowania: rysunki, BOM, specyfikacje, historia rewizji. Integracja często wymaga API plus dostęp do file storage. Czas: 3 do 8 tygodni. Pułapka: prawa dostępu w PLM są często rozdrobnione i niewidoczne na poziomie API. Trzeba mapować strukturę uprawnień PLM na uprawnienia RAG.

Ticketing (Jira Service Management, ServiceNow, OTRS). Historia zgłoszeń, baza wiedzy, kategoryzacja. Dla service desk najważniejsze źródło danych po manualach. Integracja API zwykle prosta, czas: 1 do 3 tygodnie. Pułapka: jakość kategoryzacji i tagowania zgłoszeń wpływa bezpośrednio na jakość retrievalu. Często trzeba przed startem zrobić cleanup taksonomii.

DMS (SharePoint, M-Files, OpenText). Dokumentacja produktowa, manuale, normy, SOP. Integracja zwykle proxy connector plus reindeksacja na harmonogram (codzienna, tygodniowa). Czas: 2 do 5 tygodni. Pułapka: SharePoint w średniej firmie produkcyjnej zawiera 5 do 50 TB dokumentów, z których 60 do 80% to duplikaty, robocze wersje, materiały nieaktualne. RAG na takim corpusie obniża jakość. Konieczny pre-processing.

Reguły praktyczne dla integracji:

Zaczynamy od jednego źródła danych. Ofertowanie najpierw integruje z PLM (rysunki, BOM), później z ERP (ceny), później z historią ofert (DMS). Multi-system integration na starcie to recepta na opóźnienie projektu o 6+ miesięcy.
Każda integracja ma osobny audit log dostępów. Service account z scope ograniczonym do konkretnych projektów / klastrów dokumentów.
Sync jest pull, nie push. Platforma AI pobiera dane na harmonogram lub on-demand. Brak push'a danych z systemów źródłowych do AI minimalizuje powierzchnię ataku.
Reindexacja bazy retrievalu po każdej istotnej zmianie w systemie źródłowym. Stary chunk pokazujący nieaktualną cenę albo wycofany produkt to gorsze niż brak odpowiedzi.

TCO: pełny rachunek dla 500 FTE

Pełny TCO dla firmy 500 FTE produkcyjnej, scenariusz: service desk i ofertowanie, pakiet hardware B (2x H100 80GB), trzyletnia amortyzacja, productized platforma vendor commercial:

CAPEX (jednorazowo, amortyzowane na 5 lat):

Server z 2x H100 80GB, 512 GB RAM, 8 TB NVMe, redundant power, BMC: 120 tys. EUR
Drugi node dla redundancji i development/staging: 60 tys. EUR (mniejszy)
Switch 25 GbE, kable, racki: 10 tys. EUR
UPS i rozbudowa klimatyzacji serwerowni: 15 tys. EUR
Total CAPEX: 205 tys. EUR. Amortyzacja roczna: 41 tys. EUR.

OPEX (rocznie):

Energia elektryczna (2x H100 plus chłodzenie, 3 kW × 24/7 × 0.18 EUR/kWh): 4.7 tys. EUR
Server maintenance contract (Dell ProSupport albo równoważny): 8 tys. EUR
Software licenses platformy AI (jeśli productized vendor, ryczałt enterprise): 60 do 120 tys. EUR
Wewnętrzny zespół platform (0.3 do 0.5 FTE platform engineer + 0.2 FTE security): 60 do 100 tys. EUR
Pen-test i audyt zewnętrzny roczny: 15 tys. EUR
Total OPEX: 148 do 248 tys. EUR rocznie

Total run-rate roczny: 189 do 289 tys. EUR.

Dla 500 użytkowników (z czego realnych daily active 150 do 250): 380 do 580 EUR per user per year.

Porównanie referencyjne:

Microsoft 365 Copilot Enterprise: 360 USD per user per year list, ~330 EUR. Plus separate dla zaawansowanych workflowów. Dane w chmurze Microsoft, profile NIS2 i AI Act do osobnego mapowania.
ChatGPT Enterprise: zwykle negocjowane custom, w okolicach 600 USD per user per year, około 550 EUR. Dane w OpenAI.
DIY on-prem na open-source bez productized platformy: oszczędność około 60 do 120 tys. EUR na software licenses, ale dodatkowe 1 do 2 FTE ML engineers (150 do 350 tys. EUR), więc per saldo droższe albo na granicy parity, zwłaszcza w pierwszych 18 miesiącach.

Reguła: pełny TCO on-prem jest porównywalny z public cloud Copilot dla średniej firmy 500 FTE, gdy uwzględni się wszystkie warstwy. Nie jest dramatycznie tańszy. Nie jest dramatycznie droższy. Różnica nie jest w cenie, tylko w profilu ryzyka regulacyjnego i kontroli nad workflowami.

Co najczęściej znika z TCO marketingowego, a powinno być uwzględnione:

Czas zarządu i compliance na decyzję wdrożenia (40 do 100 godzin pracy CISO, CIO, COO, prawnika, którego nie liczymy bo "etatowy"). To realny koszt projektu, zwykle 30 do 80 tys. EUR ekwiwalentu.
Czas operacyjny działu, który integruje system źródłowy (ERP, MES, PLM). Zwykle 0.2 do 0.5 FTE przez 2 do 4 miesiące integracji.
Re-training pracowników (instrukcje korzystania, granice systemu, prompt hygiene). 0.5 do 2 dni szkolenia per user dla użytkowników operacyjnych.
Iteracje pierwszego pół roku: prompt tuning, retrieval tuning, content cleanup. Często 30 do 50% więcej godzin niż pierwsza estymacja.

Pełny TCO realny: dodajcie 20 do 40% do prostej kalkulacji CAPEX + OPEX.

Build vs buy: kiedy DIY, kiedy productized

Ostatnia decyzja architektoniczna, najczęściej niedoceniana: czy budujemy on-prem AI na open-source komponentach we własnym zespole (build, DIY), czy kupujemy productized platformę u vendora (buy)?

Build (DIY na open-source).

Stack typowy: Llama 3.1 70B + vLLM + Milvus albo Qdrant + LangChain albo własna orkiestracja + FastAPI + własny UI. Wszystko self-hosted, wszystko self-maintained.

Plusy:

Zero kosztu licencji platformy. Tylko hardware i ludzie.
Pełna kontrola nad każdą warstwą. Brak vendor lock-in na poziomie aplikacyjnym.
Customization bez limitu. Możecie zmieniać każdy element pipeline.

Minusy:

Wymaga minimum 2 do 3 ML engineers z doświadczeniem w LLMOps. Plus 0.5 platform engineer. To minimum 400 do 700 tys. EUR rocznie na ludzi.
Time-to-value: 6 do 18 miesięcy do pierwszego workflowa w produkcji. Najczęstsze blokery: jakość retrievalu, evaluation pipeline, observability.
Maintenance: każda zmiana modelu, każdy upgrade CUDA, każda zmiana w pipeline to praca dewelopera. Brak buforu vendor support.
Audit readiness w pierwszych 12 miesiącach jest słabsza. Brak gotowych control sets, audit trail trzeba zbudować od zera, vendor due diligence dla "wewnętrznego dostawcy" jest nieformalna.

DIY ma sens, gdy:

Macie zespół ML/AI w organizacji od co najmniej 18 miesięcy, z udokumentowanym deliveryjem produkcyjnym.
Macie unikalny workflow albo unikalne dane, których żaden productized vendor nie pokryje (rzadkie, ale realne w sektorach niszowych).
Macie wieloletni horyzont (3 do 5 lat) i kalkulację, że amortyzacja własnej platformy się opłaca.
Zarząd ma apetyt na ryzyko technologiczne i jest gotów na 12 do 18 miesięcy bez widocznego ROI.

Buy (productized platforma vendor).

Stack: vendor dostarcza model serving, RAG pipeline, application layer, observability. Wy zapewniacie hardware, integracje, governance.

Plusy:

Time-to-value: 8 do 16 tygodni do pierwszego workflowa w produkcji.
Maintenance jest po stronie vendora w warstwie 3 do 7. Wy w warstwie 1 do 2 plus integracje.
Audit readiness przyspieszony: vendor dostarcza control sets, audit trail mechanism, vendor due diligence pack pod NIS2.
Mniejszy zespół wewnętrzny: 0.3 do 0.5 platform engineer plus governance.

Minusy:

Licencja software 60 do 150 tys. EUR rocznie (w zależności od skali i vendora).
Vendor lock-in na poziomie aplikacyjnym. Migracja po 3 latach niebanalna.
Roadmapa zależna od vendora. Wasze unikalne wymagania pojawią się tam, gdy vendor uzna, że są wystarczająco wspólne.
Vendor due diligence wymagany: stabilność finansowa vendora, jurysdykcja kontraktowa, SLA, exit clause, źródła kodu (czy w razie problemu vendora dostaniecie kod).

Buy ma sens, gdy:

Chcecie pierwszy workflow w produkcji w ciągu 12 miesięcy.
Nie macie zespołu ML wewnętrznie i nie planujecie go w najbliższych 18 miesiącach.
Workflowy są podobne do tego, co rynek już oferuje (service desk, ofertowanie, instrukcje, drawing-to-offer).
Liczy się audit readiness i NIS2 due diligence pack jako accelerator.

Reguła osobista: dla średniej firmy produkcyjnej 200 do 1000 FTE, która zaczyna z AI on-prem w 2026, buy jest domyślem. Build jest wyborem dla firm, które już mają dojrzały zespół ML albo mają unikalne wymagania, których żaden vendor nie pokryje. Robienie DIY "bo taniej" w 90% przypadków kończy się dłuższym time-to-value i wyższym TCO w pierwszych 24 miesiącach, plus słabszym audit readiness.

Trzecia opcja, którą warto wymienić: hybrid build. Open-source model serving plus vendor RAG plus własny UI plus własna observability. Rzadko optymalna, ale czasem wynika z lokalnych ograniczeń (np. silny zespół wewnętrzny w warstwie 4, słaby w warstwie 5).

Disclosure i biases

Autor pracuje nad on-prem AI platform dla europejskich producentów. To znaczy, że perspektywa w tym tekście może być stronnicza w trzech miejscach:

Sekcja "build vs buy" jest bliska rekomendacji buy dla domyślnego scenariusza. Moja perspektywa: wiem, ile pracy idzie w productized platform i jak trudno to powtórzyć wewnętrznie. CISO o świeżym, ambitnym zespole ML może uznać, że jego firma to nie domyślny scenariusz. To uczciwy spór.
Sekcja "definicje" jest agresywna w rozdzieleniu on-prem od hybrid i public cloud. Vendor public cloud powiedziałby, że hybrid też przechodzi NIS2 z odpowiednim DPA i kontrolami. Częściowo tak, ale moje doświadczenie z audytami pokazuje, że im więcej kontroli trzeba dodać, tym dłużej trwa cykl due diligence i tym wyższe ryzyko, że audyt znajdzie lukę.
Sekcja TCO porównuje on-prem z public cloud Copilot na poziomie listy cen. Realne kontrakty enterprise są negocjowane i public cloud może być tańszy na liście, zwłaszcza w pakietach z istniejącymi licencjami Microsoft. W kalkulacji nie uwzględniam kosztu re-evaluacji NIS2 due diligence przy zmianie vendora, który dla on-prem jest niższy (wewnętrzna platforma) niż dla public cloud (zewnętrzny vendor co rok do audytu).

Tam, gdzie ta stronniczość mogłaby zaważyć na decyzji, polecam weryfikację u niezależnego konsultanta lub u prawnika specjalizującego się w NIS2 i AI Act.

Co tu nie pokrywam

Tekst celowo pomija kilka tematów, które wymagają osobnego pillara albo cluster posta. Wymieniam dla uczciwości scope:

Mapowanie Art. 21 NIS2 dla łańcucha dostaw vendor AI. Osobny pillar planowany na miesiąc 2 tego portalu. Tutaj traktuję NIS2 jako tło, nie jako temat.
AI Act high-risk classification dla manufacturing. Cross-cutting z NIS2, osobny cluster post w klastrze compliance.
Personal liability zarządu po nowelizacji UKSC z kwietnia 2026. Krótka notatka osobna, bo to temat prawniczy bardziej niż architektoniczny.
Federacja modeli między oddziałami grupy kapitałowej. Specyficzny scenariusz dla większych firm, planowany w klastrze architektura na miesiąc 4 do 5.
AI dla utrzymania ruchu i predictive maintenance. To często sygnał-dominowane workflowy (vibration data, temperatures), inny stack niż dokumentacyjne, inny GPU profile, inny ROI. Osobny temat.
Tłumaczenia, summary, generic copilot. Klasycznie public cloud, nie on-prem. Pominięte celowo.
Sektorowe regulacje energetyczne i medyczne. Skupiam się na manufactura ogólnym. Energy, medtech, defense mają swoje specyfiki, których tu nie pokrywam.
Hardware AMD MI300X i alternatywy dla NVIDII. Ekosystem software'owy nadal słabszy w 2026, dlatego pominąłem. Nie znaczy że to złe rozwiązanie dla specyficznych przypadków.

W kolejnych postach będę odsyłał do tego tekstu jako punkt wyjścia architektoniczny i wracał do konkretnych warstw głębiej. Komentarze, korekty, kontrargumenty mile widziane, najlepiej na LinkedIn autora.

#on-prem#architektura#GPU sizing#NIS2#TCO#RAG#CISO#manufacturing#AI#build vs buy

Powiązany portal

Szukasz operacyjnych notatek o AI w produkcji? Zobacz aidlafabryk.pl.

Przejdź do aidlafabryk.pl →