Drogi Czytelniku,
Przez ostatnie cztery tygodnie omówiłem cztery moduły techniczne Production OS: business case (#31), governance gateway (#32), przekazywanie zadań między człowiekiem a AI (#33) i architekturę produkcyjną (#34). Dziś piąty — model operacyjny, który decyduje, czy pierwsze cztery zadziałają razem.
Każdy moduł z osobna rozwiązuje realny problem. Każdy moduł, dostarczony osobno, zawiedzie.
Bank buduje świetny AI Gateway — policy-as-code, tokenizacja PII, pełna ścieżka audytu — ale nikt nie połączył go z business case’em, który określa, które modele przez niego przechodzą. Telekom projektuje protokoły przekazywania, ale architektura produkcyjna nie potrafi kierować wyjątków do właściwej kolejki. Ubezpieczyciel pisze czterdziestostronicową politykę governance, ale system monitoringu śledzi kondycję kontenerów, a nie jakość predykcji.
Moduły w silosach produkują dokumentację. Dopiero połączone ze sobą tworzą system operacyjny.
Dlaczego powstają silosy#
Nikt nie planuje rozłączonych modułów. Silosy powstają, bo różne zespoły są właścicielami różnych warstw.
Finanse odpowiadają za business case — modelują koszt na transakcję. Dział prawny odpowiada za governance — pisze polityki. Operacje odpowiadają za przekazywanie zadań — projektują ścieżki eskalacji. Inżynieria odpowiada za infrastrukturę — buduje pipeline’y wdrożeniowe.
Każdy zespół optymalizuje swoją warstwę. Nikt nie optymalizuje systemu.
Efekt: business case zbudowany na założeniach, których architektura nie jest w stanie zrealizować. Polityka governance, której gateway nie egzekwuje. Protokół przekazywania, którego monitoring nie jest w stanie zmierzyć.
Mapa integracji#
Production OS to nie sekwencja, tylko pięć równoległych warstw, które muszą być zsynchronizowane.
Strategia (#31): Czy warto to robić? Ekonomika jednostkowa, koszt na transakcję, założenia dotyczące wskaźnika weryfikacji i punkty decyzyjne.
Governance (#32): Jak to kontrolujemy? AI Gateway egzekwuje policy-as-code w runtime. Tokenizacja PII, routing modeli, limity wydatków i logowanie audytowe.
Proces (#33): Gdzie jest miejsce człowieka? HITL, HOTL lub HIC — wybór zależy od ryzyka, wolumenu i szybkości. Mechanizmy wymuszające świadomą analizę zamiast automatycznego zatwierdzania. Przekazywanie zadań z pełnym kontekstem, nie surowym zrzutem danych.
Architektura (#34): Czy to działa o trzeciej w nocy? Dług techniczny ML w siedmiu kategoriach (od danych po organizację — pełna lista w #34), cztery wzorcowe architektury referencyjne, monitoring dryfu i wdrożenia atomowe.
Model Operacyjny (#35 — ten numer): Kto odpowiada za spójność całości? Przegląd gotowości produkcyjnej, synchronizacja warstw, wspólne metryki i cykl ciągłego doskonalenia.
Każda warstwa wytwarza dane konsumowane przez pozostałe. I właśnie tu spójność się rozpada — nie dlatego, że warstwy są złe, ale dlatego, że nikt nie sprawdza, czy mówią tym samym językiem.
Jedna zmienna, pięć warstw#
Jedna zmienna przewija się przez wszystkie warstwy: wskaźnik weryfikacji — procent wyników AI wymagających przeglądu przez człowieka.
W Strategii i business case projektu — to jedna z najbardziej wrażliwych zmiennych w kalkulacji kosztu na transakcję. Przykład z #31: 6 euro za zgłoszenie w pełni manualnie, 3,50 euro przy 50% weryfikacji ludzkiej, 1,10 euro przy 10%. Business case stoi lub upada na tej jednej liczbie.
W Governance gateway kieruje transakcje na podstawie progów pewności, które bezpośrednio określają wskaźnik weryfikacji. Próg za wysoki — kierujesz wszystko do ludzi, niwecząc cel wdrożenia. Za niski — przepuszczasz błędy, tworząc ryzyko prawne.
W Procesie model przekazywania określa górny pułap wskaźnika weryfikacji. HITL oznacza 100% weryfikacji z założenia. HOTL — tylko wyjątki. HIC — brak weryfikacji per transakcja.
W Architekturze monitoring musi śledzić rzeczywisty wskaźnik weryfikacji na produkcji i alarmować, gdy odbiega od założeń. Jeśli w budżecie założyłeś 10% weryfikacji, a rzeczywistość to 40% — Twój business case jest martwy. Nie dowiesz się o tym, jeśli monitoring tego nie mierzy.
W Modelu Operacyjnym przegląd gotowości wymusza, by wszystkie warstwy operowały na tym samym wskaźniku. Jeśli strategia zakłada 10%, a proces dostarcza 40% — przegląd to wyłapie, zanim system trafi na produkcję.
Gdy warstwy są rozłączone, finanse modelują jedną liczbę, operacje dostarczają inną, a nikt tego nie zauważa, dopóki CFO nie zapyta, dlaczego projekt za milion złotych nie przyniósł mierzalnego wpływu na P&L. ![[issue35-hero.png]]
Przegląd gotowości produkcyjnej#
Piąta warstwa — model operacyjny — realizuje się przede wszystkim jako bramka jakości, przy której muszą usiąść wszystkie zespoły, zanim system AI trafi na produkcję.
Nie komitet governance. Nie rytuał zbierania podpisów. Ustrukturyzowana ocena, która ściąga właściwych ludzi do jednego stołu i zmusza ich do odpowiedzi na pięć pytań — po jednym na każdą warstwę.
Czy business case przetrwa zderzenie z produkcją? Czy założenia z canvasu — wskaźnik weryfikacji, koszt inferencji, punkty decyzyjne — wytrzymują konfrontację z tym, co architektura faktycznie jest w stanie dostarczyć?
Czy warstwa governance egzekwuje to, co obiecuje polityka? Każda reguła w polityce AI — czy jest wyrażona jako kod w gateway’u? Kontrola PII, limity wydatków, ograniczenia dostępu do modeli — egzekwowane w runtime czy tylko na papierze?
Czy projekt przekazywania pasuje do środowiska produkcyjnego? Wybrany model nadzoru — czy architektura go wspiera? Jeśli wybrałeś HOTL, czy system faktycznie kieruje wyjątki do ludzi? Czy mechanizmy wymuszające świadomą analizę są zaimplementowane w interfejsie, czy opisane w dokumencie procesowym?
Czy architektura przechodzi test gotowości? Dziesięć pytań z #34: rollback w 5 minut, wykrywanie dryfu w 24 godziny, ścieżka audytu dla dowolnej predykcji w 5 minut, end-to-end ownership. Trzy lub mniej odpowiedzi „tak" oznacza 87% prawdopodobieństwo porażki na produkcji.
Czy ktoś odpowiada za spójność całości? Kto zwołuje przegląd? Kto ma mandat, żeby zatrzymać uruchomienie? Kto śledzi, czy liczby z poszczególnych warstw się zgadzają? Jeśli odpowiedź brzmi „nikt konkretny" — nie masz modelu operacyjnego.
Ten przegląd to nie jednorazowe wydarzenie. Odbywa się przed uruchomieniem, po 30 dniach, po 90 dniach i potem kwartalnie. Założenia się zmieniają. Dane dryfują. Wskaźniki weryfikacji się przesuwają. System, który przeszedł przegląd w styczniu, może nie zdać go w kwietniu.
Gdy warstwy się nie zgadzają#
Prawdziwa wartość przeglądu to ujawnianie konfliktów między warstwami przed produkcją.
Luka ekonomika–architektura. Business case zakłada 10% weryfikacji. Zespół procesowy zaprojektował HITL — 100% weryfikacji. Architektura to wspiera. Ale HITL na dużą skalę kosztuje więcej niż manualny proces, który miał zastąpić. Business case jest pod wodą. Rozwiązanie: przeprojektować przekazywanie na HOTL z routingiem opartym na wyjątkach albo zrezygnować z projektu.
Luka governance–proces. Polityka AI wymaga znaczącego nadzoru ludzkiego zgodnie z art. 14 AI Act. Zespół procesowy wdrożył HOTL z eskalacją opartą na poziomie pewności. Ale gateway nie loguje, czy ludzie faktycznie przeglądali eskalowane sprawy. Nie da się udowodnić zgodności. Rozwiązanie: dodać logowanie weryfikacji do gateway’a przed uruchomieniem.
Luka proces–architektura. Protokół przekazywania wymaga, żeby AI przekazało sprawę z kontekstem — podsumowaniem i wyjaśnieniem przyczyny eskalacji. System produkcyjny zrzuca surowe dane do kolejki recenzenta, bo funkcja podsumowań została wycięta z zakresu, żeby zdążyć z terminem. Rozwiązanie: opóźnić uruchomienie albo wdrożyć minimalne podsumowanie. Nie uruchamiaj z przekazaniem bez kontekstu i nie nazywaj tego nadzorem.
Te konflikty są normalne. Ich ujawnienie przed produkcją jest celem. Ujawnienie ich po incydencie jest kosztowne.
Trzy sygnały, że Twoje warstwy są rozłączone#
Finanse i operacje raportują różne wskaźniki weryfikacji. Jeśli business case zakłada 10%, a produkcja dostarcza 40%, obie strony operują na różnych liczbach — i żadna o tym nie wie.
Twoja polityka governance istnieje jako dokument, nie jako kod. Jeśli nie jesteś w stanie wskazać linii w konfiguracji gateway’a, która egzekwuje daną regułę — reguła istnieje tylko na papierze.
Twój monitoring śledzi infrastrukturę, nie jakość predykcji. Zielone dashboardy i zepsute wyniki. 85% wskaźnik cichych awarii z #34.
Rozwiązaniem jest ustrukturyzowany przegląd, który wymusza, by wszystkie pięć warstw spotkało się w jednym pokoju, z tymi samymi danymi, odpowiadając na te same pytania.
Przegląd tygodnia#
Governance daje 12x więcej AI na produkcji
Gartner przewiduje, że do końca 2026 roku 40% aplikacji enterprise będzie zawierać wyspecjalizowanych agentów AI — w porównaniu z mniej niż 5% w 2025. Liczba, która ma znaczenie: organizacje korzystające z narzędzi AI Governance wprowadzają na produkcję 12 razy więcej projektów AI. Wskaźnik 40% anulowanych projektów agentowych, o którym pisałem w #31, nie musi być wyrokiem — governance to nie narzut, tylko warstwa integracji, która zamienia eksperymenty w systemy.
Od middleware do „mindware"
CIO pisze o przejściu od tradycyjnego middleware do „mindware" — inteligentnej warstwy integracji, która rozumie intencję, egzekwuje politykę i steruje autonomicznymi decyzjami, zanim dotrą do systemów docelowych. Koncepcja mapuje się wprost na AI Gateway z #32: scentralizowana płaszczyzna kontrolna między AI a infrastrukturą enterprise. Middleware łączy systemy. Mindware łączy decyzje.
Ukryte koszty zabijają więcej projektów niż złe modele
Badania MIT via Fortune: organizacje niedoszacowują łączną inwestycję w AI o 40–60%, głównie w przygotowanie danych i zarządzanie zmianą — nie w rozwój modeli. 61% liderów wyższego szczebla raportuje większą presję na wykazanie ROI z AI niż rok temu. Organizacje stosujące ustrukturyzowane ramy oceny ROI mają 3-krotnie większe szanse na osiągnięcie pozytywnych zwrotów w ciągu 24 miesięcy. Business Case Validation Canvas z #31 jest jednym z takich narzędzi.
Amerykańskie stanowe prawo AI: governance bez federalnego fundamentu
Przegląd Wilson Sonsini na 2026: Colorado AI Act wchodzi w życie w 2026 roku, obok nowych przepisów z Kalifornii i Nowego Jorku. Brak federalnego ustawodawstwa AI. Dla firm działających jednocześnie pod EU AI Act w Europie i stanowymi przepisami w USA — scentralizowana warstwa governance przestaje być opcjonalna.
Pytanie na ten tydzień#
Pięć tygodni Production OS. Pięć warstw.
Weź swoją najbardziej zaawansowaną inicjatywę AI. Czy potrafisz prześledzić jedną linię od założeń business case’u, przez mechanizmy governance, przez projekt przekazywania, przez architekturę produkcyjną, do przeglądu operacyjnego — i potwierdzić, że liczby się zgadzają na każdej warstwie?
Jeśli nie — nie masz Production OS. Masz pięć dokumentów w pięciu działach.
Konsultanci dostarczają moduły. System operacyjny dostarcza wyniki.
Pozostań w równowadze,
Krzysztof