Odporność architektury AI: co zaudytujesz on-prem, a co ukrywa chmura

Czas czytania: ok. 9 minut. Klaster: architektura. Autor: Fryderyk.

Odpowiedź najpierw

Kiedy szef IT pyta „czy nasz AI jest odporny”, zwykle ma na myśli „czy nie padnie”. To złe pytanie. Odporność architektury AI to nie to samo co jej dostępność. System, który padł na kilkanaście godzin, po fakcie da się rozliczyć, jeśli wiesz, co dokładnie się zepsuło i na czym stało. System, który działa bez przerwy, ale opiera się na zależnościach, których nie umiesz wskazać ani zaudytować, jest kruchszy, tylko o tym jeszcze nie wiesz. Prawdziwy podział między on-prem a chmurą publiczną nie przebiega więc po linii „kto ma lepszy uptime”, bo tu hiperskalerzy zwykle wygrywają. Przebiega po linii audytowalności: co potrafisz udowodnić o własnym systemie, gdy zapyta audytor, regulator albo zarząd. On-prem daje wgląd w warstwy, których w modelu chmurowym po prostu nie zobaczysz. Ta notatka pokazuje, co konkretnie zaudytujesz sam, czego dostawca chmury ci nie odsłoni i dlaczego dla podmiotu kluczowego NIS2 to jest wymóg, nie kwestia gustu.

Spis treści

1. Dlaczego mylimy odporność z dostępnością
2. Awaria europe-west4 jako dowód, ale nie taki, jak się wydaje
3. Trzy warstwy zależności, które musisz umieć wskazać
4. Co realnie zaudytujesz on-prem
5. Czego hiperskaler ci nie odsłoni
6. Tabela: wymiar audytu, on-prem, chmura publiczna
7. Audytowalność to wymóg NIS2, nie preferencja
8. Gdzie on-prem nie wygrywa (uczciwie)
9. FAQ
10. Disclosure i biases
11. Czego tu nie pokrywam
12. Powiązane notatki

Dlaczego mylimy odporność z dostępnością

Dostępność to procent czasu, w którym usługa odpowiada. Jest mierzalna, wpisuje się ją do SLA i łatwo o nią spierać z dostawcą. Odporność to coś szerszego: zdolność systemu do przetrwania zdarzenia, którego nie przewidziałeś, i do wyjaśnienia po fakcie, co się właściwie stało. Te dwie rzeczy potrafią iść w przeciwnych kierunkach. Można kupić bardzo wysoką dostępność i jednocześnie mieć architekturę, której nikt w organizacji nie umie rozrysować do końca, bo połowa warstw jest zamknięta u dostawcy.

Dla systemu AI ta różnica jest ostrzejsza niż dla zwykłej aplikacji. Model inferencji stoi na dłuższym łańcuchu zależności: sprzęt akceleratorowy, sterowniki, warstwa serwowania, pipeline retrievalu, źródła danych, wersje modelu i promptów systemowych. Awaria albo cicha zmiana w którejkolwiek z tych warstw potrafi zmienić zachowanie systemu, nie zdejmując go z dostępności. Jeśli nie widzisz tych warstw, twój dashboard może świecić na zielono w momencie, w którym system od tygodnia odpowiada gorzej.

Awaria europe-west4 jako dowód, ale nie taki, jak się wydaje

W dniach 15 i 16 lipca 2026 region europe-west4 Google Cloud w Holandii miał blisko piętnastogodzinną awarię. Przyczyną nie był błąd oprogramowania, tylko zdarzenie fizyczne: usterka zasilania po stronie sieci energetycznej wywróciła chłodzenie, temperatura zaczęła rosnąć, a Google prewencyjnie wyłączył serwery, macierze i przełączniki, żeby nie uszkodzić sprzętu. Ucierpiały między innymi Google Cloud VMware Engine, Bare Metal Solution i NetApp Volumes.

Łatwo z tego wyciągnąć wniosek „chmura zawodzi, więc bierz on-prem”. To wniosek leniwy i nieuczciwy, bo własna serwerownia też potrafi stracić zasilanie i chłodzenie, czasem gorzej niż hiperskaler. Ciekawsze jest co innego. Usługi, które padły, to dokładnie te, które kupuje się po to, żeby mieć dedykowany, izolowany sprzęt wewnątrz chmury, czyli namiastkę kontroli. A mimo to klient dowiadywał się, co się dzieje, z komunikatów o statusie, nie z własnej telemetrii, bo do warstwy zasilania i chłodzenia nie ma i nie będzie miał wglądu. To nie jest zarzut wobec Google, każdy hiperskaler działa tak samo z dobrego powodu. To ilustracja jednej tezy: problemem chmury z perspektywy audytu jest nie tyle to, że coś się zepsuje, ile to, że nie jesteś w stanie samodzielnie prześledzić, na czym twój system stoi i dlaczego się zachował tak, a nie inaczej.

Trzy warstwy zależności, które musisz umieć wskazać

Zanim porównamy audytowalność, warto nazwać, o czym w ogóle mowa. W systemie AI są trzy warstwy zależności, o które audytor prędzej czy później zapyta.

Warstwa fizyczna i infrastrukturalna. Gdzie fizycznie stoi sprzęt, kto ma do niego dostęp, jak wygląda zasilanie, chłodzenie i sieć, kto może wejść do szafy. W modelu chmurowym ta warstwa jest dla ciebie czarną skrzynką z certyfikatem. On-prem to warstwa, którą widzisz do końca, bo jest twoja.

Warstwa oprogramowania i modelu. Wersje sterowników, obrazu systemu, warstwy serwowania, sam model i jego wagi, prompt systemowy, pipeline retrievalu. Tu chodzi o to, czy potrafisz odtworzyć, jaka dokładnie konfiguracja obsłużyła dane zapytanie w danym dniu, i czy ta konfiguracja nie zmieniła się bez twojej wiedzy.

Warstwa danych i przepływu. Które dokumenty trafiły do kontekstu, skąd, przez jakie granice sieciowe przeszedł ruch, gdzie wylądowały logi i kto miał do nich dostęp. To warstwa, która najczęściej decyduje o wyniku audytu NIS2 albo RODO, bo dotyka danych.

Audytowalność to zdolność do pokazania każdej z tych trzech warstw na żądanie, z dowodem, a nie deklaracją.

Co realnie zaudytujesz on-prem

On-prem nie jest magiczny, ale przesuwa granicę tego, co widzisz, znacząco w twoją stronę. Konkretnie zaudytujesz sam:

Ścieżkę fizyczną: masz listę urządzeń, plan szaf, dzienniki dostępu do pomieszczenia i realną kontrolę nad tym, kto podłącza się do sieci zarządzania. Gdy audytor pyta, kto mógł dotknąć sprzętu, masz odpowiedź z własnych źródeł.

Pełny stos oprogramowania: wersje sterowników, obrazu, warstwy serwowania i modelu są u ciebie i zmieniają się tylko wtedy, gdy ty je zmieniasz. Możesz zamrozić wersję, odtworzyć stan sprzed miesiąca i udowodnić, że prompt systemowy z konkretnego dnia wyglądał tak, a nie inaczej.

Dziennik zdarzeń modelu: jeśli observability jest zaprojektowana świadomie, masz zapis kto, kiedy, z jakiej tożsamości i o co pytał, jakie dokumenty weszły do kontekstu i jaka wersja modelu odpowiedziała. Ten dziennik trzymasz we własnym systemie zbierania logów, z własną polityką retencji i ochroną przed nadpisaniem. Pisałem osobno, co warto logować w on-prem LLM i jak spiąć to z audit trailem.

Granice sieciowe: segmentację, reguły ruchu i punkty styku projektujesz i logujesz sam, więc diagram stref i dziennik połączeń pochodzą z jednego źródła, które kontrolujesz.

Wspólny mianownik jest taki, że w on-prem dowód pochodzi z twoich systemów. Nie musisz ufać cudzemu raportowi, żeby odpowiedzieć na pytanie audytora.

Czego hiperskaler ci nie odsłoni

Druga strona tej samej monety. W modelu chmury publicznej pewnych rzeczy nie zaudytujesz, nie dlatego, że dostawca coś ukrywa w złej wierze, tylko dlatego, że model biznesowy chmury opiera się na tym, że te warstwy są wspólne i zamknięte.

Nie zobaczysz warstwy fizycznej: zasilania, chłodzenia, tego, kto i kiedy miał fizyczny dostęp do maszyny, na której liczył się twój model. Dostajesz certyfikat i raport zgodności, nie własny dziennik.

Nie zobaczysz pełnego sąsiedztwa: na współdzielonej infrastrukturze nie wiesz, co jeszcze działo się na tym samym sprzęcie i jak to wpływało na wydajność w danym momencie. Awaria z lipca pokazała to od strony fizycznej, ale współdzielenie ma też cichszą, codzienną wersję.

Nie zobaczysz łańcucha poddostawców w głąb: chmura często opiera się na własnych warstwach i podusługach, których pełnej listy klient nie dostaje. Do analizy art. 21 NIS2 to jest realny problem, bo mapujesz łańcuch dostaw, którego nie widzisz do końca. Pisałem o tym przy okazji analizy publicznej chmury LLM wobec NIS2.

Nie zamrozisz stanu na żądanie: aktualizacje warstw zarządzanych przez dostawcę dzieją się w jego rytmie, nie twoim. Możesz mieć wersjonowanie API, ale nie masz pełnej kontroli nad tym, co pod spodem zmieniło się między wtorkiem a środą.

Tabela: wymiar audytu, on-prem, chmura publiczna

Wymiar audytu	On-prem	Chmura publiczna
Warstwa fizyczna (zasilanie, dostęp, sprzęt)	Własny dziennik, pełny wgląd	Certyfikat i raport dostawcy, brak własnego dowodu
Wersje stosu i modelu	Zamrażalne, odtwarzalne u ciebie	Częściowo poza kontrolą, rytm dostawcy
Dziennik zdarzeń modelu	We własnym systemie logów	Zależny od tego, co dostawca eksponuje
Łańcuch poddostawców	Znany, bo twój	Częściowo nieujawniony
Granice sieciowe	Projektowane i logowane samodzielnie	Konfigurowalne, ale na cudzym fabricu
Dostępność / uptime	Zależy od twojej serwerowni	Zwykle wyższa niż u pojedynczej firmy

Uwaga do ostatniego wiersza: to jedyny wymiar, w którym chmura zwykle wygrywa, i dlatego nie należy sprzedawać on-prem hasłem „bezpieczniejszy, bo nie pada”. Pada, tylko inaczej. Przewagą on-prem jest audytowalność, nie magiczna niezawodność.

Audytowalność to wymóg NIS2, nie preferencja

Art. 21 ustawy o krajowym systemie cyberbezpieczeństwa wymaga środków adekwatnych do ryzyka, w tym w obszarze bezpieczeństwa łańcucha dostaw, obsługi incydentów i oceny skuteczności zabezpieczeń. Żaden przepis nie każe wprost wybierać on-prem. Ale każde z tych trzech wymagań w praktyce sprowadza się do pytania, na które musisz umieć odpowiedzieć dowodem: z czego składa się twój system, kto go dotyka i co się w nim wydarzyło. To jest pytanie o audytowalność.

Konsekwencja jest taka, że wybór między on-prem a chmurą przestaje być czysto techniczny albo kosztowy, a staje się pytaniem o to, czy będziesz w stanie wytworzyć dowód przed audytorem. Jeśli krytyczne warstwy są zamknięte u dostawcy, część odpowiedzi zawsze będzie brzmiała „mamy na to certyfikat dostawcy”, a nie „mamy własny zapis”. Dla podmiotu kluczowego, gdzie w grę wchodzi też osobista odpowiedzialność kierownictwa, ta różnica potrafi ważyć więcej niż kilka punktów procentowych uptime.

Gdzie on-prem nie wygrywa (uczciwie)

Byłoby nieuczciwe zostawić to bez drugiej strony. On-prem przegrywa w kilku miejscach i warto je nazwać, zanim ktoś zrobi to za ciebie na spotkaniu z zarządem.

Surowa dostępność bywa niższa: jedna serwerownia z jednym przyłączem energetycznym jest bardziej narażona na zdarzenie fizyczne niż region hiperskalera z redundancją, na którą cię nie stać. Bez zaprojektowanej redundancji on-prem to nie jest automatycznie odporniejsze.

Koszt i kompetencje: audytowalność, o której tu piszę, nie bierze się sama z faktu, że sprzęt stoi u ciebie. Bierze się z observability, polityki logów i dyscypliny wersjonowania, które trzeba zbudować i utrzymać. Bez tego on-prem daje ci tylko iluzję kontroli i szafę, w którą nikt nie zagląda. Wybór modelu utrzymania, od DIY po rozwiązanie zarządzane, opisywałem osobno.

Skala i elastyczność: jeśli obciążenie mocno faluje albo potrzebujesz eksperymentować z wieloma dużymi modelami naraz, elastyczność chmury bywa realną przewagą, a sztywny park GPU on-prem potrafi stać bezczynnie albo się zapchać.

Wniosek nie brzmi więc „zawsze on-prem”. Brzmi: jeśli twoim wymogiem jest udowodnienie kontroli nad architekturą, on-prem daje ci warstwy, których chmura z definicji nie odsłoni, a wtedy audytowalność, nie uptime, jest właściwym kryterium wyboru.

FAQ

Czy on-prem jest bezpieczniejszy niż chmura publiczna?

Nie w sensie „rzadziej pada”. Hiperskaler zwykle ma wyższą surową dostępność. On-prem wygrywa na audytowalności: dajesz radę samodzielnie udowodnić, z czego składa się system, kto go dotyka i co się w nim wydarzyło. Dla NIS2 to często ważniejsze niż uptime.

Czy awaria Google Cloud dowodzi, że trzeba uciekać z chmury?

Nie. Własna serwerownia też traci zasilanie i chłodzenie. Ta awaria pokazała co innego: nawet usługi kupowane dla dedykowanego sprzętu nie dają klientowi wglądu w warstwę fizyczną. To argument o audytowalności, nie o zawodności.

Co konkretnie zaudytuję on-prem, a czego nie w chmurze?

On-prem: warstwę fizyczną, wersje stosu i modelu, dziennik zdarzeń we własnym systemie, granice sieciowe, znany łańcuch dostaw. W chmurze te warstwy są częściowo zamknięte i dostajesz certyfikat dostawcy zamiast własnego dowodu.

Czy sam fakt postawienia sprzętu u siebie daje audytowalność?

Nie. Audytowalność bierze się z observability, polityki retencji logów i dyscypliny wersjonowania. Bez nich on-prem to szafa bez dziennika. Sprzęt to warunek konieczny, nie wystarczający.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad platformą AI uruchamianą poza chmurą publiczną. To bias w stronę kategorii on-prem i warto go znać przy czytaniu. Starałem się nie ukrywać miejsc, w których chmura wygrywa, bo tekst, który udaje, że on-prem nie ma wad, jest bezużyteczny dla kogoś, kto naprawdę podejmuje tę decyzję. Na rynku on-prem AI istnieje kilka kategorii rozwiązań, od samodzielnego składania na open-source, przez rozwiązania productized, po modele zarządzane, i każda ma inny profil kosztu i ryzyka. Ten tekst nie jest opinią prawną ani projektem architektury dla konkretnej organizacji.

// co tu nie pokrywamCzego tu nie pokrywam

Nie wchodzę w konkretne narzędzia observability ani stacki logowania, bo wybór zależy od tego, co już masz. Nie omawiam projektowania redundancji zasilania i chłodzenia we własnej serwerowni, choć to realny warunek, by on-prem był odporny, a nie tylko audytowalny. Nie liczę tu TCO obu modeli, bo koszt to osobny wątek. Pomijam też modele hybrydowe i federację między oddziałami, które zasługują na własną notatkę. Szczegóły prawne warto potwierdzić z zespołem compliance.

Powiązane notatki

• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
• Monitoring i observability dla on-prem LLM: co logować i jak
• Network isolation dla on-prem AI: minimalne wymagania NIS2
• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d
• DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje