Drogi Czytelniku,
Oto statystyka, która powinna spędzać ci sen z powiek: 87% modeli ML nigdy nie osiąga poziomu produkcyjnego. Ale 85% tych, które osiągają poziom produkcyjny, zawodzi po cichu. Infrastruktura zdrowa, prognozy zepsute, nikt tego nie zauważa przez miesiące.
Kiedy zdarzają się awarie, pulpity nawigacyjne pozostają zielone, podczas gdy produkcyjne bazy danych są wymazywane, modele serwują błędne prognozy przez tygodnie, a naruszenia compliance kumulują się po cichu, dopóki audyt ich nie ujawni.
Czwarty moduł z serii Production OS. #31 zbudował uzasadnienie biznesowe. #32 wprowadził infrastrukturę. #33 zaprojektował interfejsy człowiek-AI. Ten numer omawia architekturę produkcyjną, która albo działa o 3 nad ranem, albo nie.
Algorytmy działają. Wszystko inne zawodzi.
18-miesięczne wąskie gardło IT#
Twój zespół data science zbudował model na laptopie. IT twierdzi, że wdrożenie na produkcję zajmie 18 miesięcy. Wszyscy zakładają, że przyczyną jest biurokracja, podczas gdy rzeczywiste blokady są bardziej konkretne.
Luka infrastrukturalna. Produkcja wymaga 1000 predykcji na sekundę z 99.9% uptime – 100-1000-krotny mnożnik względem demo. Szafy z infrastrukturą AI pobierają 30-150 kW w porównaniu do 5-15 kW dla tradycyjnych serwerów. Większość centrów danych nie została do tego zbudowana.
Integracja ze starymi systemami. Systemy core’owe to mainframe z lat 90. bez API. Samo zbudowanie warstwy integracyjnej kosztuje 500k-5M zł i zajmuje 6-18 miesięcy – zanim ktokolwiek dotknie modelu.
Wymagania compliance. Zgodnie z wymogami regulacyjnymi, każdy model wymaga 50-100 stron dokumentacji, niezależnej walidacji i ciągłego monitorowania. Tworzenie tego ręcznie: 3-6 miesięcy na model.
Część opóźnienia jest wyimaginowana – “najpierw potrzebujemy idealnych danych” nigdy się nie zdarza. Ale większość jest realna. I podczas tych 18 miesięcy, gdy IT buduje system do uruchomienia działającego modelu, kumulują się straty, którym można było zapobiec.
Piekło wersjonowania modeli#
Wyobraź sobie, że wdrażasz wersję 2.3 swojego silnika rekomendacji. Trzy tygodnie później odkrywasz, że klienci widzą prognozy z wersji 1.0 – sprzed sześciu miesięcy. Pipeline wdrożeniowy raportuje zielone światło. Co się stało?
Model, pipeline funkcji i schemat danych były wersjonowane niezależnie. Niedopasowanie przeszło kaskadowo przez cały stos. Diagnoza zajmuje tygodnie, ponieważ każdy poszczególny komponent raportuje, że jest zdrowy.
W tradycyjnym oprogramowaniu cofasz commit i wdrażasz ponownie. W ML cofasz kod, wagi modelu, feature engineering, pipeline preprocessingu, schemat danych i stan rejestru modeli. Cofnięcie modelu bez jego zależności psuje produkcję w inny sposób.
Powstają modele-cienie: niewłaściwa wersja serwuje prognozy, podczas gdy każdy komponent raportuje, że wszystko działa.
Michelangelo Ubera wdraża każdy model atomowo – model, funkcje i konfigurację razem – z rollbackiem poniżej jednej minuty. Większość organizacji wciąż używa arkuszy kalkulacyjnych.
Ślepota monitorowania#
Model scoringu kredytowego działa przez osiem miesięcy. Pulpity na zielono. Opóźnienie w ramach SLA. Wskaźniki błędów zerowe. Następnie audyt compliance odkrywa, że wskaźniki zatwierdzeń odchyliły się o 15% od rozkładów treningowych. Model po cichu dyskryminował przez miesiące. Zgodnie z przepisami, kary mogą sięgać 4% rocznego globalnego obrotu.
Tradycyjny monitoring śledzi kontenery, nie predykcje. Model może odpowiadać w 100ms, zwracać poprawny JSON i produkować całkowicie błędne wyniki. Żaden alert nie działa.
Dwa typy dryfu to powodują. Data drift: rozkłady wejściowe zmieniają się wraz ze zmianami demograficznymi i ewolucją rynków. Concept drift: relacja między wejściami a wyjściami się zmienia. Większość zespołów monitoruje pierwsze. Większość całkowicie omija drugie.
Bez automatycznego monitorowania, mediana czasu wykrycia to 3-6 miesięcy. Z wielowymiarowym monitorowaniem, czas wykrycia spada do godzin. Technologia istnieje. Większość organizacji jej nie wdrożyła.
Panika przy rollbacku#
Wersja 3.0 modelu ryzyka pacjenta wchodzi na produkcję w piątek po południu. Prognozy degradują się o 12% względem bazowej dokładności. Zespół próbuje rollbacku. Skrypt rollbacku zawodzi – pipeline danych przetworzył już miliony rekordów używając nowego schematu. Poprzedni model nie może parsować nowego formatu.
To jest deployment “drzwi w jedną stronę” – nie dlatego, że rollback jest technicznie niemożliwy, ale dlatego, że nikt nie przetestował procedury rollbacku. Model, pipeline funkcji, schemat danych i konfiguracja tworzą łańcuch zależności. Cofnięcie jednego ogniwa bez pozostałych tworzy inny błąd.
Osiemnaście godzin downtime’u. Dwunastu inżynierów wciągniętych w pracę weekendową. Te awarie nie są rzadkie.
Wdrożenia blue-green i canary rozwiązują to dla tradycyjnego oprogramowania. Działają też dla ML – ale wymagają traktowania deploymentu jako first-class engineering concern, a nie basha uruchamianego w piątek po południu.
Pierwotna przyczyna#
Te cztery wzorce mają wspólny korzeń: traktowanie systemów ML jak tradycyjnego oprogramowania. Systemy ML to kod plus dane, plus modele, plus funkcje, plus pipeline’y, plus monitoring, plus compliance. Zmiana w danych treningowych propaguje się przez wszystko downstream.
Artykuł Google z 2015 roku “Hidden Technical Debt in Machine Learning Systems” to zidentyfikował. Dług architektury ML akumuluje się w tempie ~7% rocznie. Koszty naprawy rosną o 600% w ciągu dwóch lat.
Siedem kategorii długu się powtarza:
- Dług danych – 30-40% awarii produkcyjnych. Niedokumentowane zależności, training-serving skew.
- Dług modeli – Chaos wersjonowania. Modele-cienie.
- Dług konfiguracji – Dryfujące środowiska. “U mnie działa.”
- Dług systemowy – Ślepota monitorowania. 85% wskaźnik cichych awarii.
- Dług specyficzny dla LLM – Chaos wersjonowania promptów, starzenie się embeddingów, akumulacja halucynacji.
- Dług compliance – Brak audit trails, brak monitoringu fairness. Kary do 4% globalnego obrotu.
- Dług organizacyjny – Zespoły w silosach, myślenie projektowe zamiast platformowego.
Każda badana organizacja, która odniosła sukces z wykorzystaniem analityki – Uber, Netflix, Stripe, DoorDash, Airbnb – rozwiązała to w ten sam sposób: zunifikowane platformy MLOps. Żadna nie zrobiła tego w trzy miesiące. Realistyczny timeline: 18-24 miesięcy.
Jak wygląda production-ready#
Cztery wzorce architektury referencyjnej, każdy dopasowany do innych ograniczeń:
- Lightweight cloud-native – Poniżej 10 modeli, 5K-20K zł/miesiąc, 3-6 miesięcy do produkcji. Zarządzane usługi, serverless inference.
- Real-time low-latency – Finanse, fraud, ad tech. Sub-100ms P95, feature store obowiązkowy, 50K-250K zł/miesiąc.
- Enterprise managed – Branże regulowane. Compliance by design: przepływy zatwierdzania, model cards, audit logging, fairness monitoring.
- LLM i RAG – Bazy wektorowe, pipeline’y embeddingów, zarządzanie promptami, detekcja halucynacji. Koszty tokenów zmienne.
Kluczowy insight: żadna udana organizacja nie używa platformy żadnego dostawcy end-to-end. Wszystkie budują własną orkiestrację.
Dziesięć pytań określających gotowość produkcyjną:
- Czy możesz wdrożyć nową wersję i cofnąć się w ciągu 5 minut?
- Czy możesz odtworzyć każdą wersję modelu z dowolnej daty?
- Czy dowiesz się w ciągu 24 godzin, jeśli prognozy się pogarszają?
- Czy funkcje są obliczane identycznie w czasie treningu i serwowania?
- Czy masz automatyczną walidację danych?
- Czy masz canary lub shadow testing na produkcji?
- Czy możesz wygenerować audit trail dla dowolnej predykcji w 5 minut?
- Czy znasz koszt na model na miesiąc?
- Czy jeden zespół zarządza modelem end-to-end?
- Czy nowy inżynier może zrozumieć system w ciągu tygodnia?
Wynik: 0-3 odpowiedzi “tak” oznacza 87% prawdopodobieństwo awarii produkcyjnej. 10 na 10 oznacza production-ready.
The Briefing#
Enterprise AI ROI: 30-40 mld USD zainwestowane, 90-95% widzi znikome zwroty
Analiza Consulting Magazine: pomimo 30-40 miliardów dolarów zainwestowanych globalnie do 2025 roku, większość organizacji widzi znikomy zwrot. Pierwotna przyczyna to nie awaria technologii, ale niedopasowanie między możliwościami AI a modelami operacyjnymi przedsiębiorstw – copiloty nałożone na istniejące przepływy pracy bez redefiniowania autorytetu decyzyjnego. Tylko 20% liderów finansowych raportuje zadowolenie ze zwrotów z inwestycji technologicznych.
Podatności MCP ujawniają warstwę integracyjną jako krytyczną powierzchnię ataku
Styczniowe incydenty bezpieczeństwa AI pokazują, że zagrożenia coraz częściej atakują punkty integracyjne, nie modele. Siedem podatności o wysokiej krytyczności (AISSI 7.0+) w implementacjach MCP: luka BodySnatcher w ServiceNow, ataki reprompt na Microsoft Copilot, luki w Anthropic MCP Git Server. Warstwa architektury, gdzie agenci integrują się z systemami enterprise, wymaga takiej samej rygorystycznej ochrony jak bramy API.
Deloitte: 60% ma dostęp do AI, tylko 25% osiąga produkcję
Badanie Deloitte wśród 3,200+ liderów: sześciu na dziesięciu pracowników ma zatwierdzony dostęp do narzędzi AI, ale tylko jedna czwarta organizacji przenosi eksperymenty na produkcję. Trzy czwarte planuje wdrożenie agentic AI w ciągu dwóch lat, jednak tylko jedna piąta ma modele governance dla autonomicznych agentów. “18-miesięczne wąskie gardło IT” skwantyfikowane.
EU AI Act wchodzi w egzekucję: śledztwo Grok sygnalizuje koniec okresu przejściowego
Komisja Europejska rozpoczęła pierwsze śledztwo w ramach AI Act 26 stycznia 2026, celując w Grok AI od X. AI Office ma teraz uprawnienia do żądania danych wewnętrznych, przeprowadzania inspekcji na miejscu i zawieszania funkcji w UE. Koniec okresu “czekaj i patrz” – regulatorzy są gotowi wdrażać maksymalne kary (do 7% globalnego obrotu) aby ustanowić precedensy.
Pytanie na ten tydzień#
Architektura produkcyjna to mało efektowna praca. Nie ma przemówień ani rund finansowania. To decyzje o infrastrukturze, pipeline’y wdrożeniowe, pulpity monitorowania i procedury rollbacku. Ale to jest miejsce, gdzie AI albo działa, albo nie.
Dla twojego najbardziej krytycznego systemu ML na produkcji: ile czasu zajęłoby wykrycie 15% spadku dokładności? Jeśli nie wiesz, lub jeśli odpowiedź brzmi “gdy ktoś się poskarży,” nie masz monitoringu. Masz nadzieję.
Większość treści o MLOps mówi, jak wdrożyć model. Ten artykuł wyjaśnia, dlaczego twój zespół IT mówi, że zajmie to 18 miesięcy – i o co naprawdę im chodzi.
Bo działająca produkcyjna architektura ML to nie tylko algorytmy i infrastruktura. To systemy, które działają bezpiecznie o 3 nad ranem i przechodzą audyty compliance.
Do następnego razu,
Krzysztof