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