Trzy modele deploymentu on-prem AI: koszty, profil ryzyka, kiedy który

Spis treści

1. Po co rozróżniać trzy modele
2. Model A: bare-metal we własnej serwerowni
3. Model B: colo z dedykowanym sprzętem
4. Model C: managed appliance vendora
5. Profil ryzyka NIS2 w trzech modelach
6. Porównanie liczbowe: 500 FTE, 36 miesięcy
7. Kiedy żaden z trzech modeli nie ma sensu
8. Decyzyjnik w pięciu pytaniach
9. Disclosure i biases
10. Co tu nie pokrywam

---

<a id="po-co-rozrozniac"></a>

Po co rozróżniać trzy modele

W poprzednim pillarze o architekturze on-prem AI zdefiniowałem on-prem jako wariant, w którym model inference siedzi w perymetrze organizacji, a dane operacyjne nie opuszczają granicy zaufania. To jednak nadal dość gruba kategoria. W rozmowach z dyrektorami IT i CISO widzę, że pod hasłem "on-prem" kupuje się trzy zupełnie różne deploymenty, z różnym CAPEX, różnym OPEX, różnym profilem ryzyka regulacyjnego i różną zależnością od vendora.

Trzy modele, które warto rozróżniać już na etapie RFP:

• Model A: bare-metal we własnej serwerowni. GPU, server chassis, switche stoją w infrastrukturze klienta, w pomieszczeniu zarządzanym przez wewnętrzny dział IT. Klient kupuje sprzęt, klient go utrzymuje, klient odpowiada za zasilanie i chłodzenie.
• Model B: colo z dedykowanym sprzętem. Klient kupuje sprzęt (CAPEX), ale chassis stoi w komercyjnym data center kolokacyjnym. Dostawca colo zapewnia zasilanie, chłodzenie, fizyczną kontrolę dostępu, łącza. Klient nadal odpowiada za warstwę OS i wyżej.
• Model C: managed appliance vendora platformy. Vendor dostarcza i utrzymuje pełen stack hardware plus warstwy 2 do 5. Klient zapewnia powierzchnię (serwerownię, colo albo wariant hybrydowy), płaci subskrypcję obejmującą sprzęt jako OPEX i odpowiada za integracje plus governance.

Każdy z trzech modeli przechodzi NIS2, jeśli jest zrobiony porządnie. Każdy ma inny rozkład kosztu w czasie, inny rozkład odpowiedzialności wobec audytora i inną krzywą time-to-value. W tym tekście biorę każdy po kolei, pokazuję liczby dla średniej firmy produkcyjnej 500 FTE i kończę decyzyjnikiem w pięciu pytaniach, którym można zamknąć rozmowę z zarządem.

Pomijam wariant managed cloud appliance z hostowaniem u vendora (typu AWS Outposts pod inference). To jest hybrid w przebraniu, niezależnie od marketingu. Trzymam się trzech wariantów, w których dane operacyjne realnie nie opuszczają perymetru klienta.

---

<a id="model-a"></a>

Model A: bare-metal we własnej serwerowni

Klasyka, którą w polskiej produkcji widzi się najczęściej. Firma ma serwerownię od dwóch dekad, ma zespół infrastruktury, ma procedury patchingu i monitoring. Dodanie kolejnej szafy z dwoma do czterema GPU mieści się w istniejących procesach. Nie wymaga od zarządu wyjścia poza obszar, który zna.

Co kupujemy. Serwer rack-mount z 2x lub 4x H100 80GB (alternatywnie 4x L40S 48GB, jeśli celujemy w mniejszy budżet i mniejszy wolumen), 512 GB do 1 TB RAM, 8 do 16 TB lokalnego NVMe, redundant power, BMC z out-of-band management. Switch 25 lub 100 GbE, jeśli nie mamy infrastruktury sieciowej w tej klasie. UPS o adekwatnej pojemności, najczęściej rozszerzenie istniejącego. Klimatyzacja precyzyjna, jeśli istniejąca nie wytrzymuje dodatkowych 2 do 6 kW ciepła. To często jest ten składnik, który zaskakuje budżet.

Co utrzymujemy. Wszystko od warstwy 1 do 7 z poprzedniego pillara. Sprzęt, OS, drivery NVIDIA i CUDA, runtime kontenerów, model serving, RAG pipeline, application layer, observability. Plus zasilanie, chłodzenie, dostęp fizyczny, backup, disaster recovery. To znaczy: dedykowany zespół minimum 0.5 FTE platform engineer plus 0.2 FTE security plus część etatu data center engineer plus dostęp do MLOps na warstwie 4 do 5 (zwykle 0.3 do 0.5 FTE wewnętrznie albo kontrakt z platformowym vendorem).

Ramy czasowe wdrożenia. Od decyzji do produkcji w optymistycznym scenariuszu 12 tygodni, w realistycznym 16 do 24 tygodnie. Hardware delivery samo trafia 4 do 12 tygodni w zależności od dostępności GPU i polityki zakupowej firmy. Adaptacje serwerowni (zasilanie, klimatyzacja) potrafią dorzucić kolejne 4 do 8 tygodni, jeśli wcześniej nie była przygotowana pod karty 700 W TDP każda.

Profil ryzyka i compliance. Najsilniejszy z trzech modeli. Audytor NIS2 widzi pełną kontrolę klienta nad każdą warstwą. Wszystkie wektory ataku są w obszarze odpowiedzialności klienta, co znaczy, że są też w obszarze widoczności klienta. SIEM widzi wszystko. IdP widzi wszystko. Patch management jest pod waszą kontrolą, więc opóźnienia w łatkach (i ich konsekwencje audytowe) zależą od dyscypliny waszych ludzi, nie od kontraktu z vendorem.

Słaby punkt tego profilu: jeśli wasz dział IT nie ma kompetencji w warstwie 4 do 5 (model serving, RAG pipeline), audyt znajdzie luki w obserwowalności LLM, ślad konkretnego zapytania, mechanizm cytowania źródeł. Posiadanie własnej platformy nie oznacza, że ją rozumiecie. Audytor wymaga rozumienia.

Kiedy ma sens. Macie istniejącą, dojrzałą serwerownię z headroomem zasilania i chłodzenia. Macie zespół infrastruktury, który jest komfortowy z dorzuceniem GPU stack do istniejących procedur. Macie dłuższy horyzont (3 do 5 lat) i kalkulację, że pełne CAPEX się amortyzuje. Macie ograniczenia kontraktowe wykluczające colo (np. polityki grupowe NIS2 określające lokalizację przetwarzania danych jako "siedziba spółki").

Kiedy nie ma sensu. Serwerownia nie wytrzyma dodatkowych 2 do 6 kW, a remont w 18-miesięcznym horyzoncie nie jest realny. Dział IT nie ma osoby, która chce wejść w GPU stack. Horyzont projektu jest niejasny (pilotaż 12 miesięcy bez decyzji co dalej). Macie wymóg redundancji geograficznej, którego pojedyncza serwerownia nie spełnia.

---

<a id="model-b"></a>

Model B: colo z dedykowanym sprzętem

Drugi model, w polskiej produkcji rosnący w popularności od 2024. Klient kupuje sprzęt (więc CAPEX nie znika), ale chassis trafia do komercyjnego colo (Atman, Beyond.pl, Equinix, Polcom, lokalne data centers regionalne). Klient płaci miesięczną opłatę za powierzchnię, zasilanie, chłodzenie, łącza, fizyczną kontrolę dostępu. Klient nadal odpowiada za warstwę OS i wyżej.

Co kupujemy. To samo, co w modelu A, od warstwy 1 do 7. Hardware (GPU, server, switche), software (OS licenses jeśli RHEL, vLLM lub TGI lub TensorRT-LLM, RAG stack, application layer). Plus kontrakt z colo na konkretne U w racku, konkretny power feed (zwykle redundantny A+B po 16A lub 32A), konkretną klasę chłodzenia (in-row CRAC, cold corridor, niektóre nowoczesne colo oferują direct-to-chip liquid cooling dla GPU racks), konkretne łącza (BGP do internetu plus dedykowane VPN do siedziby klienta).

Co utrzymujemy. Warstwa OS i wyżej, identycznie jak w modelu A. Plus zarządzanie relacją z colo: SLA, dostęp fizyczny (kto z waszego zespołu wchodzi do data center, w jakim trybie, z jaką procedurą break-glass), procedury awaryjne. Brak własnej elektrowni, klimatyzacji i fizycznej kontroli dostępu z waszej strony zmniejsza zakres odpowiedzialności o 30 do 50%, ale wymaga dyscypliny kontraktowej.

Ramy czasowe. Wdrożenie szybsze niż model A, jeśli colo jest gotowe na GPU stack. Od decyzji do produkcji 8 do 16 tygodni. Hardware delivery taki sam, ale brak konieczności adaptacji własnej serwerowni przyspiesza krytyczną ścieżkę. Wymaga jednak czasu na due diligence wybranego colo (lokalizacja, certyfikacje ISO 27001, ISO 22301, EN 50600, w niektórych przypadkach NIS2 self-assessment dostawcy), co dodaje 2 do 4 tygodnie pracy compliance.

Profil ryzyka i compliance. Trochę słabszy niż model A. Audytor NIS2 widzi, że klient kontroluje warstwy 1 do 7, ale fizyczny dostęp do sprzętu jest po stronie dostawcy colo. To jest sub-processor w mapowaniu Art. 21 NIS2 (artykuł 21 ust. 2 lit. d, security of supply chain). Wymaga dodatkowego DPA z dostawcą colo, klauzul prawa do audytu, SLA i procedur incident reporting. Wymaga osobnego mapowania.

Drugi aspekt: dane są w innej lokalizacji niż siedziba spółki. Jeśli polityka grupowa albo wymóg sektorowy określa "dane w siedzibie spółki", colo jest poza tym scope. To bywa pułapką w sektorach z dodatkowymi regulacjami (energia, niektóre podmioty kluczowe w sektorze chemicznym, defence-adjacent).

Plus: colo zwykle ma własną kontrolę dostępu (badge, biometria, sluzy, sztywne procedury wpuszczania serwisantów), które są lepsze niż w typowej zakładowej serwerowni. To jest podpora compliance, nie tylko jego komplikacja.

Kiedy ma sens. Nie macie własnej serwerowni klasy enterprise lub remont takiej nie zwraca się w horyzoncie projektu. Chcecie redundancji geograficznej i druga lokalizacja w kolejnym colo regionie pasuje do polityki BCP. Macie zespół infrastruktury skłonny przejść na tryb remote management. Polityka grupowa pozwala na colo i akceptuje proces sub-processor.

Kiedy nie ma sensu. Macie istniejącą sprawną serwerownię z miejscem i headroomem zasilania. Macie sztywne wymogi sektorowe co do lokalizacji danych. Zespół infrastruktury nie jest gotowy na tryb data center remote operations (a to wymaga konkretnej dojrzałości procedur).

Wariant pośredni, który warto rozważyć: hybrid colo, gdzie produkcyjny stack jest w komercyjnym colo, a development plus staging jest we własnej serwerowni. Audytowo bardziej skomplikowane, ale operacyjnie sensowne dla średnich firm 500 do 1000 FTE.

---

<a id="model-c"></a>

Model C: managed appliance vendora

Trzeci model, najmłodszy w polskiej produkcji, ale z największym tempem wzrostu od 2025. Vendor platformy AI dostarcza pre-skonfigurowaną appliance (typowo 1U lub 2U rack-mount, czasem 4U dla wielo-GPU). Klient zapewnia powierzchnię (własną serwerownię albo colo, niektórzy vendorzy oferują też hosting w wybranych data centers), zasilanie i chłodzenie. Vendor utrzymuje warstwy 2 do 5 (OS, runtime, model serving, RAG pipeline). Klient odpowiada za warstwę 1 fizycznie (dostęp do appliance), warstwę 6 częściowo (application layer, integracje, własny UI jeśli customizujecie) i warstwę 7 (observability na poziomie organizacji).

Co kupujemy. Appliance jako CAPEX albo, częściej, jako OPEX w modelu subskrypcyjnym z hardware included. Subskrypcja typowo obejmuje: appliance, zdalne utrzymanie warstw 2 do 5, dostęp do nowych modeli i ich integracji w stack, SLA, vendor due diligence pack pod NIS2 (kontrola dostępu, audit log, security architecture, sub-processor list). Subskrypcja jest typowo 3-letnia z opcją przedłużenia.

Co utrzymujemy. Warstwa 1 fizycznie (zasilanie, chłodzenie, dostęp), warstwa 6 funkcjonalnie (integracje z waszym ERP, MES, PLM, własne workflowy), warstwa 7 częściowo (observability z waszych systemów, SIEM, IdP). Wymaga 0.2 do 0.4 FTE platform engineer plus 0.2 FTE security plus zespół integracyjny dla pierwszych 12 miesięcy.

Ramy czasowe. Najszybszy z trzech modeli. Od decyzji do produkcji 6 do 12 tygodni dla typowego use case (service desk, ofertowanie, instrukcje). Vendor dostarcza appliance pre-skonfigurowaną, podstawowy stack jest gotowy do uruchomienia w pierwszym tygodniu. Reszta czasu idzie na integracje i tuning RAG pipeline dla waszej dokumentacji.

Profil ryzyka i compliance. Najbardziej zniuansowany. Vendor jest sub-processorem w głębszym sensie niż w modelu B (colo). Vendor ma uprzywilejowany dostęp do appliance dla utrzymania, co znaczy, że ma potencjalny dostęp do warstw, w których przepływają dane operacyjne. To jest fundamentalna decyzja due diligence: czy ten konkretny vendor, z tym konkretnym kontraktem, z tymi konkretnymi kontrolami dostępu, jest akceptowalny w mapowaniu Art. 21 NIS2.

Plus, który warto wymienić: dobrzy vendorzy productized platform mają audit logs lepsze niż większość firm zbuduje wewnętrznie. Mają wbudowany mechanizm cytowania źródeł, prompt versioning, eval pipeline. To bardzo przyspiesza audit readiness. Minus: trzeba im zaufać, że ten mechanizm działa zgodnie z dokumentacją.

Konkretne klauzule kontraktowe, których brak powinien zatrzymać podpis:

• Logging dostępu vendora do appliance, dostępny dla klienta read-only w czasie rzeczywistym lub z opóźnieniem maksymalnie 24h.
• Procedura break-glass z notifikacją klienta, audytowalną decyzją w SIEM.
• Right to audit raz w roku, fizyczny lub remote, z dostępem do logów i procedur.
• Sub-processor list z prawem klienta do veta dla nowych sub-processorów.
• Exit clause z procedurą wydania danych w czytelnym formacie plus kodu konfiguracji (model weights, prompt templates, retrieval indexes) w przypadku zakończenia kontraktu lub upadłości vendora.
• Source code escrow albo równoważny mechanizm dostępu do kodu krytycznego w razie problemu vendora. Mniej standardowe, ale dla podmiotów kluczowych warto.
• Stabilność finansowa vendora (rating, audyt finansowy, jurysdykcja kontraktowa). Dla podmiotów kluczowych NIS2 to nie jest opcjonalne.

Kiedy ma sens. Chcecie pierwszy workflow w produkcji w 6 do 12 tygodni. Wewnętrzny zespół IT jest niewielki (do 8 osób), nie planuje budowy kompetencji ML w warstwie 4 do 5. Audit readiness jest priorytetem (vendor dostarcza gotowy pack pod NIS2). Roadmapa modeli i pipeline jest po stronie vendora, i to jest cecha, nie problem (nie chcecie sami śledzić nowych modeli Llama lub Mixtral).

Kiedy nie ma sensu. Macie unikalny workflow, którego żaden productized vendor nie pokryje (sektor niszowy, custom AI dla bardzo specyficznych danych). Polityka grupowa zakazuje uprzywilejowanego dostępu zewnętrznego vendora do infrastruktury (rzadkie, ale realne w niektórych podmiotach kluczowych energii i defence-adjacent). Vendor nie spełnia waszych wymogów due diligence (finansowych, geograficznych, klauzul kontraktowych). Macie dojrzały zespół ML, który chce budować wewnętrzną platformę dla strategicznej kontroli.

---

<a id="ryzyko-nis2"></a>

Profil ryzyka NIS2 w trzech modelach

NIS2 i nowelizacja UKSC z kwietnia 2026 nie wykluczają żadnego z trzech modeli. Każdy może przejść audyt podmiotu kluczowego, jeśli jest zrobiony porządnie. Różnica jest w rozkładzie odpowiedzialności i w tym, ile pracy wymaga mapowanie.

Model A: bare-metal. Najmniej sub-processorów, najwięcej własnej odpowiedzialności. Mapowanie Art. 21 obejmuje wewnętrzny dział IT (który nie jest sub-processorem w sensie NIS2, ale ma swoje obowiązki w systemie kontroli wewnętrznej) plus dostawców hardware (NVIDIA, OEM server, switche). Sub-processorów typowo 3 do 5, wszyscy w warstwie hardware. Audytor sprawdza wewnętrzną organizację bezpieczeństwa, procedury patch management, IAM, SIEM, BCP. To są kontrole, które wasza organizacja już ma dla istniejącej infrastruktury, tylko trzeba rozszerzyć scope na AI workload.

Model B: colo. Średnia złożoność. Mapowanie Art. 21 obejmuje wewnętrzny dział IT, dostawców hardware plus dostawcę colo. Sub-processorów typowo 5 do 8. Dostawca colo jest kluczowym sub-processorem z dostępem fizycznym do sprzętu (audit dostępu fizycznego, procedury wpuszczania, kontrola tożsamości, monitoring CCTV) i częściowo do warstwy sieciowej (jeśli używacie ich łączy internetowych). Wymaga osobnego DPA z dostawcą colo i osobnego self-assessment NIS2 dostawcy (większość polskich i europejskich colo to dostarcza standardowo, ale warto zweryfikować).

Model C: managed appliance. Najwyższa złożoność mapowania. Vendor platformy jest najgłębszym sub-processorem, z dostępem do warstw, w których przepływają dane operacyjne (warstwa 4 do 5 oczywiście, warstwa 6 częściowo). Sub-processorów typowo 6 do 12, w tym vendor platformy plus jego własni sub-processorowie (cloud provider dla model updates, observability provider, security provider). Każdy sub-processor wymaga osobnego mapowania w Art. 21, plus prawa do veta dla nowych sub-processorów.

Konkretne sekcje Art. 21, na które warto patrzeć w każdym z trzech modeli:

• Art. 21 ust. 2 lit. d (bezpieczeństwo łańcucha dostaw). Wszystkie trzy modele wymagają mapowania dostawców. Model C wymaga najgłębszego mapowania.
• Art. 21 ust. 2 lit. e (bezpieczeństwo pozyskiwania, rozwoju i utrzymywania sieci i systemów informatycznych). Model A daje pełną kontrolę. Model C deleguje istotną część do vendora, co wymaga klauzul kontraktowych i prawa do audytu.
• Art. 21 ust. 2 lit. h (zasady i procedury dotyczące korzystania z kryptografii). We wszystkich modelach klient powinien kontrolować klucze. Model C wymaga klauzuli, że vendor nie ma dostępu do kluczy klienta (BYOK albo HSM po stronie klienta).
• Art. 21 ust. 2 lit. i (bezpieczeństwo zasobów ludzkich). Model B i C wymagają oceny pracowników sub-processorów (background checks, NDA, mechanizmy reagowania na zwolnienia z dostępem do systemów klienta).

Dla podmiotu kluczowego NIS2 w sektorze produkcyjnym, pełne mapowanie dla modelu C wymaga zwykle 40 do 80 godzin pracy compliance plus 20 do 40 godzin pracy CISO plus 20 do 40 godzin pracy prawnika z doświadczeniem w NIS2. Dla modelu A pełne mapowanie wymaga 20 do 40 godzin pracy compliance. To istotna różnica w pierwszym roku wdrożenia.

Szybką analizę konkretnego artykułu Art. 21 ust. 1 lit. d w kontekście public cloud LLM mam w osobnym poście o łańcuchu dostaw. Pillar o pełnym mapowaniu Art. 21 dla łańcucha dostaw vendor AI publikuję w drugim miesiącu tego portalu.

---

<a id="porownanie"></a>

Porównanie liczbowe: 500 FTE, 36 miesięcy

Wszystkie liczby w tej sekcji są przybliżone i mają charakter referencyjny. Realne kontrakty są negocjowane, hardware ma różne cykle cenowe, a koszty pracy w polskiej produkcji rosną co kwartał. Liczby uśredniam dla scenariusza: 500 FTE, mieszany workload (service desk dominujący plus ofertowanie plus instrukcje), 36-miesięczna amortyzacja, pakiet B z poprzedniego pillara (2x H100 80GB plus mniejszy node redundancyjny).

Model A: bare-metal we własnej serwerowni.

CAPEX rok 0: 205 tys. EUR (dwa nody plus switche plus UPS plus adaptacja klimatyzacji). OPEX roczny: 4.7 tys. (prąd) + 8 tys. (server maintenance) + 60 do 100 tys. (zespół: 0.5 FTE platform engineer + 0.2 FTE security + część etatu data center engineer) + 15 tys. (pen-test) + 60 do 120 tys. (software licenses platformy AI, jeśli kupujecie productized stack platformowy w warstwie 4 do 5; jeśli DIY, koszt przesuwa się w stronę zespołu MLOps z 0.5 do 1 FTE dodatkowo). Suma 36 miesięcy: CAPEX 205 + (148 do 248) × 3 = 649 do 949 tys. EUR.

Model B: colo z dedykowanym sprzętem.

CAPEX rok 0: 180 tys. EUR (bez UPS i bez adaptacji klimatyzacji, te są w cenie colo, ale czasem przesunięcie kosztu kompensuje się wzrostem opłaty miesięcznej). OPEX roczny: opłata colo (typowo 2 do 4 tys. EUR miesięcznie za rack z 6 kW power feed) = 30 do 50 tys. + 8 tys. (server maintenance) + 50 do 80 tys. (zespół: 0.4 FTE platform engineer + 0.2 FTE security, bez data center engineer) + 15 tys. (pen-test) + 60 do 120 tys. (software licenses platformy AI lub MLOps DIY). Suma 36 miesięcy: CAPEX 180 + (163 do 273) × 3 = 669 do 999 tys. EUR.

W przybliżeniu parity z modelem A. Różnica jest w rozkładzie kosztów (CAPEX vs OPEX, mniej zaangażowania zespołu data center, więcej fixed monthly cost colo) i w profilu ryzyka, nie w bezwzględnej wartości.

Model C: managed appliance vendora.

CAPEX rok 0: 0 do 30 tys. EUR (zwykle hardware jest w subskrypcji, czasem onboarding fee). OPEX roczny: subskrypcja appliance plus platforma plus utrzymanie (rynkowo 150 do 300 tys. EUR rocznie dla scenariusza średniej firmy 500 FTE z mieszanym workloadem; rozrzut zależy od vendora, modelu, custom integracji) + 4.7 tys. (prąd) + 8 tys. (colo lub własna serwerownia) + 30 do 60 tys. (zespół: 0.3 FTE platform engineer + 0.2 FTE security, znacznie mniej niż w modelu A i B) + 15 tys. (pen-test). Suma 36 miesięcy: 0 do 30 + (207 do 387) × 3 = 621 do 1191 tys. EUR.

Rozrzut jest szerszy, bo zależy istotnie od polityki cenowej vendora. W dolnym progu model C jest najtańszy z trzech (mniej własnego zespołu kompensuje subskrypcję). W górnym progu jest najdroższy (vendor enterprise pricing dla podmiotów kluczowych potrafi być wysoki). Dla średniej firmy z dyscypliną kontraktową model C w 36-miesięcznej perspektywie jest porównywalny z A i B, ale z istotnie krótszym time-to-value (6 do 12 tygodni vs 16 do 24 dla A i 8 do 16 dla B).

Co znika z tej kalkulacji.

• Time-to-value jako koszt utraconych korzyści. Jeśli AI realnie skraca cykl ofertowy o 30%, każdy miesiąc opóźnienia we wdrożeniu to 1/12 rocznej oszczędności, której nie zrealizowaliście. Dla modelu C oszczędzacie 8 do 16 tygodni vs model A. Dla średniej firmy ofertującej 5 do 15 mln EUR rocznie to 50 do 200 tys. EUR niezrealizowanej oszczędności w pierwszym roku.
• Koszt due diligence przy zmianie vendora w przyszłości. Model A: brak. Model B: średni (zmiana colo trwa 2 do 4 miesiące). Model C: wysoki (zmiana vendora platformy to faktycznie nowe wdrożenie).
• Ryzyko vendor lock-in długoterminowe. Trudne do skwantyfikowania, ale realne. Model A: minimum. Model B: niski. Model C: średni do wysoki, w zależności od vendora i klauzul.
• Ryzyko własnego zespołu w modelu A i B. Jeśli platform engineer odchodzi, kto przejmuje? Single point of failure dla zespołów poniżej 5 osób w warstwie 1 do 7.

Liczby z tej sekcji są punktem wyjścia, nie ostatecznym rozstrzygnięciem. Każda organizacja ma swój kontekst (istniejąca infrastruktura, zespół, kontrakty grupowe, polityki sektorowe), który modyfikuje obraz.

---

<a id="kiedy-nie"></a>

Kiedy żaden z trzech modeli nie ma sensu

Uczciwie: są scenariusze, w których on-prem AI w 2026 nie jest właściwą decyzją. Wymieniam dla kompletności:

• Firma poniżej 100 FTE bez intensywnych workflowów dokumentowych. Wolumen zapytań nie uzasadnia CAPEX ani OPEX hardware'u. Public cloud Copilot lub hybrid jest tańszy i mniej operacyjnie obciążający.
• Firma bez wyraźnego use case, w trybie "AI bo zarząd chce AI". On-prem to inwestycja decyzyjna, nie eksperymentalna. Eksperyment robi się na hybrid albo public cloud z DPA.
• Firma z planem fuzji lub akwizycji w horyzoncie 18 miesięcy. Nowa infrastruktura tuż przed M&A komplikuje due diligence i często ląduje na liście do likwidacji. Lepiej poczekać.
• Firma z polityką grupową wymuszającą konkretny stack chmurowy (Azure, AWS, Google). Walka z polityką grupową kosztuje więcej, niż zyskujecie z on-prem. Sensowne tylko jeśli macie poparcie zarządu spółki matki.
• Firma w sektorze, w którym public cloud z odpowiednim DPA jest akceptowalny dla regulacji i nie ma ryzyka strategicznego. Nie każda firma jest podmiotem kluczowym NIS2. Nie każdy workflow wymaga on-prem.

Wniosek nie jest "wszyscy na on-prem". Wniosek jest: jeśli already wiecie, że on-prem to wasz kierunek, te trzy modele są realnymi opcjami.

---

<a id="decyzyjnik"></a>

Decyzyjnik w pięciu pytaniach

Pięć pytań do zadania na zebraniu zarządu lub na komitecie wdrożeniowym. Każde z nich praktycznie rozstrzyga między modelami.

1. Czy mamy serwerownię klasy enterprise z headroomem zasilania i chłodzenia na dodatkowe 2 do 6 kW, lub remont w 18-miesięcznym horyzoncie jest realny?

Tak → model A i C są w grze, model B opcjonalny. Nie → model B i C są w grze, model A wymaga inwestycji w serwerownię, której często nikt nie planował.

2. Ile mamy ludzi w dziale platform engineering plus security, którzy mogą przejąć warstwy 1 do 7 stacka GPU?

Powyżej 3 FTE z odpowiednim doświadczeniem → model A i B realne. 1 do 3 FTE → model C jest bezpieczniejszy, A i B wymagają wsparcia kontraktowego dla MLOps. Poniżej 1 FTE → tylko model C, inne modele to ryzyko operacyjne.

3. Jaki jest dopuszczalny time-to-value dla pierwszego workflowa?

3 do 4 miesiące → tylko model C. 6 miesięcy → model C lub B, model A na styku. 12+ miesięcy → wszystkie trzy modele realne.

4. Czy polityka grupowa lub regulacja sektorowa zakazuje uprzywilejowanego dostępu zewnętrznego vendora do infrastruktury?

Tak → model C wykluczony, zostają A i B. Nie → wszystkie trzy modele realne, model C wymaga klauzul kontraktowych.

5. Jaki jest horyzont projektu i jak elastyczna jest decyzja w kolejnych 36 miesiącach?

Stabilny 3 do 5 lat → CAPEX-heavy modele A i B mają sens, amortyzacja gra na waszą korzyść. Niejasny lub pilotażowy z opcją wycofania → model C, OPEX-heavy, łatwiejszy do zatrzymania. Szybki wzrost wolumenu z 1 do 10x w 18 miesięcy → model C jest elastyczniejszy w skalowaniu, model A i B wymagają planowanej rozbudowy.

Pięć odpowiedzi zwykle zbiega się do jednego modelu lub do mieszanki dwóch. Jeśli odpowiedzi są w pełni rozproszone i każdy model ma argumenty za i przeciw, to zwykle sygnał, że nie macie wystarczająco precyzyjnie zdefiniowanego use case ani profilu organizacji. Wracajcie do roadmapy AI, nie do wyboru modelu deploymentu.

---

<a id="disclosure"></a>

// disclosure i biasesDisclosure i biases

Autor pracuje nad on-prem AI platform dla europejskich producentów. Trzy miejsca, w których ta perspektywa może być stronnicza:

• Sekcja modelu C jest bardziej szczegółowa niż sekcje A i B w opisie klauzul kontraktowych. To dlatego, że jako vendor productized platformy widzę te klauzule z bliska i wiem, które są krytyczne. Nie znaczy to, że A i B nie wymagają klauzul (do dostawców hardware i colo), tylko że tam są bardziej standardowe i mniej dyskutowane. Niezależny audytor mógłby uznać, że to balans niesymetryczny.
• Decyzyjnik w pięciu pytaniach faworyzuje model C w trzech z pięciu pytań (czas, zespół, niejasny horyzont). To wynika z mojego doświadczenia, że średnia firma produkcyjna ma mniejsze zespoły IT i mniejszy apetyt na wieloletni CAPEX projekt niż firma wierzy w siebie na początku rozmowy. Bias jednak jest. CIO o silnym zespole infrastrukturalnym i strategicznym horyzoncie 5 lat ma prawo wybrać model A z innych powodów niż wymieniam.
• Liczby TCO modelu C są szersze (621 do 1191 tys. EUR) niż A i B. W dolnym progu C wychodzi najtaniej, w górnym najdrożej. Dolny próg widziałem w realnych deploymentach. Górny próg pochodzi z negocjacji enterprise, które niekoniecznie reprezentują polski sweet spot rynkowy. Realistyczne wycenienie dla średniej polskiej firmy 500 FTE jest bliżej środka tego przedziału (700 do 900 tys. EUR za 36 miesięcy), nie dolnego progu.

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. Komentarze, korekty, kontrargumenty mile widziane, najlepiej na LinkedIn autora.

---

<a id="co-tu-nie-pokrywam"></a>

// co tu nie pokrywamCo tu nie pokrywam

• Pełne mapowanie Art. 21 NIS2 dla każdego z trzech modeli. Osobny pillar w klastrze NIS2, miesiąc drugi.
• Konkretne klauzule kontraktowe MSA dla modelu C. Cluster post planowany w klastrze vendor-eval, miesiąc trzeci do czwartego.
• Porównanie konkretnych dostawców colo na rynku polskim i europejskim. Wymaga osobnego rozpoznania rynkowego, nie chcę robić tego na pamięć.
• Hardware financing (leasing, lending, hardware-as-a-service poza modelem C). Wpływa na strukturę CAPEX vs OPEX, ale wykracza poza architekturę.
• Wariant hybrid colo plus on-site dla redundancji geograficznej. Wymieniony przelotnie, zasługuje na osobny tekst.
• Disaster recovery i backup strategies dla trzech modeli. Cross-cutting, planowany w klastrze architektura.
• Modele appliance z hostingiem u vendora (nie pure colo klienta). Wykluczone z definicji on-prem w tym tekście, planowane w osobnym poście o hybrid.

W kolejnych tekstach wracam do pojedynczych modeli głębiej, zwłaszcza w klauzulach kontraktowych i mapowaniu Art. 21.