Statystyki porażek AI znamy na pamięć. Większość projektów GenAI nigdy nie wychodzi z pilotażu. Te, które wychodzą, rzadko przynoszą wymierne korzyści. Reszta trwa w zawieszeniu — zjada budżet, aż ktoś w końcu zapyta „po co to robimy?".
To ostatnie wydanie z serii o skalowaniu produkcyjnym. Czas na podsumowanie i wnioski.
Dlaczego standardowe checklisty nie wystarczają
Typowa reakcja na przedwdrożeniowy stres? Dłuższa lista kontrolna:
- Bezpieczeństwo — sprawdzone
- Infrastruktura — gotowa
- Monitoring — skonfigurowany
- Procedury awaryjne — opisane To wszystko trzeba mieć. Ale dla systemów AI w regulowanych branżach — to za mało.
Klasyczne listy Go/No-Go zakładają świat deterministyczny: wymagania się nie zmieniają, dane na produkcji wyglądają jak w testach, ludzie pracują według schematu. AI łamie wszystkie trzy założenia. Daje wyniki probabilistyczne, dryfuje w czasie, zmienia procesy wokół siebie.
Można odfajkować każdy punkt i nadal nie dostarczyć działającego rozwiązania.
Problem polega na tym, że gotowość produkcyjna to pytanie o governance, nie o kolejne pole w Jirze. Lista musi pomagać analizować te same ryzyka, które omawialiśmy w całej serii — i scalać je w jedną decyzję.
Powtórzę to jeszcze raz: Jeśli zasada governance nie potrafi automatycznie zablokować wdrożenia, to nie jest kontrola. To sugestia.
Trzy rodzaje ryzyka, które musisz sprawdzić
Przez ostatnie wydania mapowaliśmy przyczyny, przez które projekty AI umierają między pilotażem a produkcją. Przed startem wszystkie trzy trzeba zweryfikować.
1. Dane kontra rzeczywistość
W testach model widział czyste, dobrze opisane dane. W call center zobaczy formularze wypełnione w połowie, klientów zmieniających język w połowie zdania i procedury zmienione w zeszłym kwartale bez odpowiedniej dokumetnacji.
W wydaniu #26 nazwaliśmy to przepaścią między danymi treningowymi a produkcją. Nie da się jej zasypać dobrymi intencjami. Trzeba mieć dowody, że system sobie z nią radzi.
Przykład: Epic Systems wdrożył model wykrywania sepsy w setkach szpitali. W testach retrospektywnych wyglądał świetnie. W codziennej praktyce klinicznej - gdzie dane wpisywane są chaotycznie i z opóźnieniem - model przegapiał 67% przypadków sepsy, a jednocześnie generował tyle fałszywych alarmów, że lekarze nauczyli się go ignorować.
2. Automatyzacja chaosu
W wydaniu #27 pokazywałem, co się dzieje, gdy automatyzujesz nieefektywny proces: chaos zaczyna działać szybciej. Na produkcji AI nie działa w próżni. Zmienia obieg zadań, eskalacje, prawa do podejmowania decyzji.
Przed startem potrzebujesz trzech rzeczy: mapy procesu z jasno zaznaczonym miejscem dla AI, osoby odpowiedzialnej za całość (także gdy system padnie) i ścieżki powrotu do pracy ręcznej. Bez tego „gotowość produkcyjna" oznacza tylko „gotowość do szybszego bałaganu".
Przykład: Algorytm zakupu nieruchomości Zillow uczył się na danych z rosnącego rynku. Gdy ceny zaczęły spadać, model dalej kupował - po zawyżonych cenach. Zillow straciło ponad 500 mln USD i zlikwidowało dział zajmujący się tym obszarem. Proces nie uwzględniał Human-in-the-Loop - nikt nie sprawdzał, czy wyniki działania modelu są zgodne ze zdrowym rozsądkiem.
3. ROI na slajdach
W wydaniu #29 budowaliśmy kartę wyników ROI: sposób mierzenia tego, co naprawdę ma znaczenie po uruchomieniu systemu.
Przed startem musisz wiedzieć dwie rzeczy: czego oczekujesz od systemu (konkretnie, mierzalnie) i skąd będziesz brał dane, żeby to zweryfikować. I raczej źródłem nie powinien być PowerPoint przygotowany za ciężkie pieniądze przez konsultantów z Big4. Inaczej będziesz mieć system AI, którego korzyści nie da się obronić, gdy CFO zapyta, ile dzięki niemu zarobiliśmy lub zaoszczędziliśmy.
Przykład: IBM Watson for Oncology wdrożono w onkologicznych ośrodkach na całym świecie. Tylko w MD Anderson inwestycja wyniosła ponad 60 mln USD. Prezentacje wyglądały imponująco. Media pisały o przełomie. Ale gdy zweryfikowano, czy Watson poprawia wyniki leczenia w porównaniu ze standardową terapią — dowodów nie było. Projekt wycofano po cichu.
Checklista gotowości produkcyjnej
Dziesięć pytań, które można omówić na jednym spotkaniu zarządu. Do każdego — dowód, który powinien istnieć przed decyzją „start".
1. Właściciel
- Pytanie: Kto bierze odpowiedzialność za ten system na produkcji?
- Dowód: Konkretna osoba po stronie biznesu i po stronie IT, ze spisanym zakresem odpowiedzialności.
2. Miejsce w procesie
- Pytanie: Jakie procesy realizuje/wspiera ten system i kto odpowiada za całość, gdy system przestanie działać?
- Dowód: Mapa procesu (stan obecny i docelowy), punkty kontroli człowieka, ścieżka powrotu do pracy ręcznej.
3. Dane z rzeczywistości
- Pytanie: Czy system testowano na danych takich jak na produkcji, nie tylko na danych z PoC?
- Dowód: Wyniki testów na danych produkcyjnych — w tym na przypadkach rzadkich i na danych niepełnych lub zaszumionych.
4. Co może pójść źle
- Pytanie: Wiemy, jak system może się pomylić? Wiemy, co wtedy robimy?
- Dowód: Spisane scenariusze awarii, wyniki red-teamingu, procedura reakcji.
5. Wyłącznik
- Pytanie: Jak wyłączamy system w przypadku, gdy przestanie spełniać kryteria jakościowe? Co dzieje się zaraz potem?
- Dowód: Działający kill switch, przetestowany rollback, co najmniej jedna przeprowadzona próba.
6. Zależności
- Pytanie: Od czego zależy ten system — komponenty, API, prompty, źródła danych? Kto za co odpowiada?
- Dowód: Lista zależności z właścicielami i lokalizacją w repozytorium.
7. Jak się dowiemy, że coś jest nie tak
- Pytanie: Co nas natychmiast zaalarmuje, że system zachowuje się źle? To, co oznacza “natychmiast” zależy od charakterystyki procesu — mogą to być milisekundy lub dni.
- Dowód: Ustalone wskaźniki wczesnego ostrzegania, alerty trafiające do konkretnych ludzi, plan dyżurów supportu.
8. Czy to się opłaca
- Pytanie: Jak zmierzymy, czy system jest wart utrzymywania?
- Dowód: Karta wyników ROI zasilana prawdziwymi danymi.
9. Co pokażemy audytorowi
- Pytanie: Gdy audytor zapyta „dlaczego system podjął taką decyzję?" — co mu pokażemy?
- Dowód: Dokumentacja zakresu decyzji systemu, logi wejść i wyjść, prosty opis działania. Tu schodzą się wymagania SR 11-7 (Fed), EU AI Act dla systemów wysokiego ryzyka i NIST AI RMF. W regulowanych branżach audytorzy w końcu o to zapytają.
10. Próba generalna
- Pytanie: Czy przeszliśmy tę listę z ludźmi, którzy będą odpowiadać za system?
- Dowód: Notatka ze spotkania: otwarte ryzyka, przypisani właściciele.
Od listy do systemu
Jeśli przejdziesz tę listę raz i schowasz do szuflady — masz proces manualny, oparty na dobrej woli. Jeśli wbudujesz ją w pipeline wdrożeniowy — masz governance. Różnica jest taka: procesy oparte na dobrej woli działają, dopóki ktoś pamięta, systemy działają zawsze.
Dojrzałe organizacje budują pięć filarów:
- Feature Store — single point of truth danych przygotowanych dla modeli. Eliminuje różnice między tym, co widział model w treningu, a tym, co widzi na produkcji.
- Model Registry — kontrola wersji modeli z pełną historią: dane treningowe, kod, wyniki walidacji.
- AI Gateway — centralny punkt kontroli całego ruchu do modeli. Limity, anonimizacja danych osobowych, polityki dostępu — w czasie rzeczywistym.
- Observability Stack — wykrywanie dryfu, monitoring jakości, alerty o problemach, których nie widać w standardowych metrykach.
- Policy Engine — silnik Governance-as-Code. Reguły wykonują się automatycznie w pipeline. Dziś większość z Was przejdzie tę listę ręcznie. Z czasem większość punktów da się zautomatyzować. Celem nie jest zastąpienie ludzkiego osądu — tylko upewnienie się, że ludzie zajmują się właściwymi pytaniami, a nie tracą czas na rzeczy, które maszyna zrobi lepiej.
Co dalej
To wydanie zamyka pierwszy cykl The AI Equilibrium. Zaczynałem tę serię z myślą o technologii. Skończyłem pisząc o decyzjach — kto je podejmuje, na jakiej podstawie i co robić, gdy okażą się błędne.
Ta lista nie wygra konkursu piękności, ale można ją pokazać zarządowi i obronić. I o to właśnie chodzi w gotowości produkcyjnej: nie o perfekcję, tylko o to, żeby dało się uzasadnić, zweryfikować i obronić podjętą decyzję.
W kolejnych wydaniach weźmiemy tę listę i zastosujemy do konkretnych branż — decyzje kredytowe, contact center, ubezpieczenia, usługi publiczne. Przypadek po przypadku: jak przejść od teorii do praktyki.
Briefing
Brak governance = brak ROI
Raport Smarsh o AI w finansach: tylko 32% firm ma formalny program governance AI. Wspólny mianownik słabych wyników AI to nie złe modele - to brak ram operacyjnych. Dlatego ta lista istnieje.
Firewall nie ochroni twojego AI
Harvard Business Review pisze, że klasyczne zabezpieczenia IT nie obejmują zagrożeń specyficznych dla AI: prompt injection, zatruwania danych treningowych, exploity na konkretne modele. Artykuł cytuje lukę w Microsoft 365 Copilot z czerwca 2025, która ujawniła dane firmowe. Ryzyko AI wymaga osobnego podejścia — modelowania zagrożeń, red-teamingu, dedykowanego monitoringu. Punkty #4 i #7 na liście są właśnie po to.
EU AI Act nadchodzi
Przewodnik Scalevise opisuje, czego będą wymagać regulatorzy w 2026: spis systemów AI, udokumentowana logika decyzji, procedury nadzoru, ciągły monitoring. Przepisy dla systemów wysokiego ryzyka wchodzą w sierpniu 2026. W regulowanych branżach inwentaryzacja i audytowalność to już nie opcja — to luka, którą audytor znajdzie za ciebie.
Pytanie na ten tydzień
Przed następnym „go-live" zbierz zespół decyzyjny i przejdźcie razem tę listę. Na poważnie, nie dla formalności.
Na ile z tych dziesięciu pytań macie dziś odpowiedź popartą dowodami — nie założeniami?
Jeśli mniej niż siedem: właśnie wiesz, co blokuje wdrożenie. I raczej nie jest to model.
Zachowaj równowagę,
Krzysztof