# Gdzie znika ROI po pilotażu AI: anatomia value leakage
Ten artykuł jest częścią klastra pilotaż -> produkcja i pokazuje, gdzie wartość wycieka po uruchomieniu rozwiązania. Bariery przed produkcją opisuje `scaling-pilots-do-not-reach-production`.
W pilotażu wszystko wygląda obiecująco. Zespół pokazuje krótszy czas realizacji zadania, wyższą produktywność i pozytywny feedback użytkowników testowych. Kilka miesięcy później CFO pyta o wynik finansowy, a organizacja nie potrafi pokazać trwałego efektu. Narzędzie działa, ale ROI nie materializuje się w skali.
To zjawisko nazywamy value leakage: wartość deklarowana w pilotażu nie dociera do wyniku biznesowego po wdrożeniu. Nie dlatego, że technologia nagle przestaje działać, ale dlatego, że wartość "wycieka" na kolejnych etapach operacyjnych.
Centralna teza tego case lens jest następująca: ROI po pilotażu znika głównie przez luki decyzyjne i operacyjne między eksperymentem a codziennym procesem. Jeśli organizacja nie mierzy i nie kontroluje tych luk, będzie multiplikować aktywność AI bez multiplikowania wartości.
Co naprawdę oznacza value leakage
Value leakage nie jest pojedynczym błędem. To suma małych strat na różnych odcinkach ścieżki wartości.
Przykładowo: model skraca pracę o 30 procent w teście, ale w produkcji użytkownicy muszą ręcznie poprawiać odpowiedzi, więc realny zysk czasu spada do 10 procent. Dodatkowo część zespołu nie używa narzędzia regularnie, więc efekt wolumenowy jest niski. Do tego dochodzą koszty utrzymania, review i integracji, które nie były ujęte w business case pilotażu.
W efekcie nominalna korzyść jest duża, ale ekonomiczna wartość netto pozostaje mała albo znika całkowicie.
Framework operacyjny: cztery punkty wycieku wartości
Praktycznym punktem odniesienia jest prosty model operacyjny oparty na publicznie opisywanych lukach wdrożeniowych: wartość traci się na etapach "translation", "adoption", "execution" i "control", a nie tylko na etapie idei. Taki podział jest spójny z obserwacjami z dużych badań adopcji AI (np. McKinsey Global Survey "The State of AI", 2025), które pokazują, że bariera wartości jest głównie organizacyjna i procesowa.
Konkretnie dla AI: - Translation leakage: korzyść z pilotażu nie jest poprawnie przeliczona na realny workflow i baseline kosztowy. - Adoption leakage: użytkownicy nie zmieniają zachowań tak, jak zakładano w modelu ROI. - Execution leakage: proces i integracje powodują rework, opóźnienia lub dodatkowe koszty. - Control leakage: brak monitoringu jakości i kosztu powoduje dryf wartości po starcie.
Ta rama jest użyteczna, bo zmienia pytanie z "czy pilot działał?" na "gdzie dokładnie tracimy wartość po pilotażu?".
Anatomia wycieku wartości po pilotażu
Pierwszy wyciek pojawia się na etapie tłumaczenia wyniku pilotażu na model ekonomiczny. Zespół pokazuje oszczędność czasu na zadaniu, ale nie uwzględnia, czy ten czas da się realnie odzyskać w planowaniu pracy i kosztach.
Drugi wyciek dotyczy adopcji. W pilotażu pracują zwykle najbardziej zmotywowani użytkownicy. W produkcji narzędzie trafia do pełnej populacji, w której część osób nie ufa AI, nie ma czasu na zmianę nawyków albo nie widzi korzyści.
Trzeci wyciek to wykonanie procesu. AI bywa dołożone obok workflow, więc każdy wynik wymaga dodatkowych kroków i review. Te kroki konsumują sporą część zakładanej oszczędności.
Czwarty wyciek to kontrola. Po wdrożeniu często brakuje ownera wartości i cyklicznego value review. Bez tego jakość, koszt tokenów, koszt wsparcia i rework mogą rosnąć niezauważenie.
Piąty wyciek dotyczy decyzji portfelowych. Organizacja utrzymuje use case, który "już działa", mimo że ekonomicznie powinien zostać przeprojektowany lub zamknięty.
Anti-pattern: ROI jako metryka launchowa
Powszechny anti-pattern brzmi: "Skoro pilot pokazał poprawę, uznajmy ROI za dowiedzione i skupmy się na rollout."
To błąd, bo ROI nie jest metryką startu. ROI jest metryką eksploatacji. Wymaga danych po wdrożeniu: rzeczywistego wolumenu użycia, kosztu utrzymania, poziomu rework, wpływu na KPI procesu i stabilności jakości.
Gdy organizacja traktuje ROI jako jednorazowe potwierdzenie z pilotażu, przestaje monitorować wyciek wartości. Wtedy nawet dobry use case może stać się ekonomicznie słaby.
Zły -> dobry przykład decyzji
Zła decyzja: "Pilotaż pokazał 25 procent oszczędności czasu, więc wdrażamy globalnie i raportujemy ten sam efekt w planie rocznym."
Co poszło źle: brak korekty o realną adopcję, brak wyceny reworku, brak kosztów integracji i brak mechanizmu stop-loss, gdy jakość spadnie.
Dobra decyzja: "Wdrażamy etapowo, a business case liczymy na trzech scenariuszach adopcji. Dodajemy próg stop-loss: jeśli rework przekroczy 15 procent lub aktywna adopcja spadnie poniżej 60 procent, projekt wraca do redesign."
Co się poprawia: zarząd dostaje wiarygodniejszy profil wartości, a zespół ma jasne warunki kontynuacji zamiast optymistycznego założenia bazowego.
Case lens: dział operacji i automatyzacja odpowiedzi
Firma usługowa wdraża asystenta AI do przygotowania odpowiedzi na zapytania klientów. Pilotaż na małej grupie pokazuje świetne wyniki: krótszy czas odpowiedzi i zadowolenie zespołu testowego. Decyzja o skali zapada szybko.
Po kwartale okazuje się, że ROI jest niższe od planu. Dlaczego?
Po pierwsze, aktywna adopcja zatrzymała się na 55 procent. Część pracowników wróciła do wcześniejszych praktyk, bo nowe narzędzie nie było dobrze osadzone w ich codziennym workflow.
Po drugie, wzrósł rework. Managerowie jakości częściej poprawiali odpowiedzi AI w przypadkach złożonych, co zjadało znaczną część oszczędności czasu.
Po trzecie, koszty utrzymania były wyższe od założeń: więcej wsparcia operacyjnego, dodatkowe integracje i nieplanowane prace nad biblioteką instrukcji.
Po czwarte, firma nie miała regularnego value review. Problem został zauważony dopiero podczas kwartalnego przeglądu finansowego, kiedy przestrzeń na korektę była mniejsza.
Po wprowadzeniu checklisty kontroli value leakage i cotygodniowych przeglądów KPI proces wrócił na ścieżkę poprawy, ale wymagał redesignu workflow, a nie tylko korekty promptów.
Checklista kontroli value leakage
Poniższa checklista służy do kontroli po pilotażu i w pierwszych miesiącach skali.
1) Translation control - Czy baseline kosztowy i czasowy został policzony na danych produkcyjnych, nie testowych? - Czy korzyść jest przeliczona na realny efekt ekonomiczny (koszt, przychód, ryzyko), a nie tylko "zaoszczędzone minuty"? - Czy business case zawiera scenariusze adopcji zamiast jednego optymistycznego założenia?
2) Adoption control - Jaki jest odsetek aktywnych użytkowników względem populacji docelowej? - Czy menedżerowie egzekwują nowy standard pracy i mają wskaźniki adopcji? - Czy zespół zbiera i zamyka bariery użytkowników w krótkim cyklu?
3) Execution control - Jaki jest rework rate po wygenerowaniu wyniku AI? - Czy AI jest osadzone w workflow, czy działa jako dodatkowy krok obok procesu? - Czy koszty integracji i wsparcia są monitorowane wobec planu?
4) Quality and risk control - Czy są progi jakości i jasne warunki eskalacji? - Czy high-impact output ma adekwatny human review? - Czy zmiany modeli/promptów są wersjonowane i oceniane pod kątem wpływu na KPI?
5) Value governance control - Kto jest ownerem wartości netto use case'u po starcie? - Czy działa regularny rytm value review (np. tygodniowy operacyjny i miesięczny finansowy)? - Czy istnieje jawna decyzja stage gate: scale, redesign, hold, stop?
Jak używać checklisty w praktyce
Checklista działa tylko wtedy, gdy jest podłączona do decyzji. Jeśli pozostaje dokumentem kontrolnym bez konsekwencji, nie zatrzyma wycieku wartości.
Dobry rytm wygląda tak: zespół operacyjny co tydzień monitoruje adopcję, jakość i rework, a właściciel biznesowy co miesiąc ocenia wartość netto. Raz na kwartał portfel AI przechodzi decyzję stage gate na poziomie leadership.
Kluczowa zasada: nie pytaj "czy AI działa", pytaj "czy ekonomika procesu poprawia się po uwzględnieniu pełnych kosztów i zachowań użytkowników".
W praktyce oznacza to również zmianę sposobu raportowania do CFO i leadership. Zamiast pojedynczego wskaźnika „ROI use case'u” warto raportować trzy liczby równolegle: efektywność brutto (np. oszczędność czasu), koszt absorpcji organizacyjnej (rework, szkolenia, wsparcie, integracje) oraz wartość netto po 90 dniach pracy w skali. Ten układ pokazuje, czy wartość utrzymuje się po zejściu z poziomu pilota.
Sygnały wczesnego ostrzegania
Istnieje kilka sygnałów, które zwykle pojawiają się zanim ROI formalnie "zniknie".
Pierwszy sygnał to rozjazd między deklarowaną oszczędnością czasu a realnym obciążeniem zespołu. Jeśli ludzie mówią, że jest szybciej, ale backlog nie maleje, wartość może już wyciekać.
Drugi sygnał to rosnący odsetek wyjątków. Im więcej przypadków wymaga ręcznego obchodzenia narzędzia, tym większa strata wartości netto.
Trzeci sygnał to brak stabilności jakości po zmianach promptów lub modelu. Jeśli każda aktualizacja resetuje przewidywalność wyniku, proces nie jest gotowy do skali.
Czwarty sygnał to niejasna odpowiedzialność finansowa. Gdy nikt nie odpowiada za wartość netto use case'u, decyzje są podejmowane głównie na podstawie narracji, nie danych.
Co liderzy powinni zrobić teraz
Najpierw potraktuj ROI z pilotażu jako hipotezę, nie dowód. Potrzebujesz potwierdzenia na danych operacyjnych.
Następnie przypisz jednego ownera wartości netto dla każdego kluczowego use case'u AI. Ta rola musi mieć mandat do decyzji redesign lub stop.
Potem uruchom checklistę value leakage jako obowiązkowy element wejścia do skali i pierwszych 90 dni po wdrożeniu.
Na końcu połącz wynik checklisty z finansowaniem. Projekty, które nie domykają warunków adopcji, jakości i ekonomiki, nie powinny dostawać automatycznej kontynuacji budżetu.
Executive Takeaway
Co się zmieniło? Organizacje przechodzą od oceny pilotażu do oceny ekonomiki eksploatacji AI. To przesuwa uwagę z demo quality na value sustainability.
Dlaczego to ważne? Większość utraconego ROI nie wynika z samego modelu, tylko z wycieków na etapie tłumaczenia korzyści, adopcji, wykonania i kontroli. Bez aktywnego monitoringu wartość znika mimo poprawnej technologii.
Co liderzy powinni zrobić? Wdrożyć checklistę kontroli value leakage, przypisać ownera wartości netto i wprowadzić decyzje stage gate oparte na danych operacyjnych, nie na narracji po pilotażu.


