Większość projektów AI nie zatrzymuje się dlatego, że technologia nie działa. Zatrzymuje się dlatego, że organizacja nie potrafi jednoznacznie ocenić, czy technologia przyniosła wartość.
To istotna różnica.
Modele są coraz lepsze. Infrastruktura jest dostępna. Narzędzia AI można uruchomić szybciej niż jeszcze kilka lat temu. Koszty eksperymentowania spadły, a presja na wdrożenia wzrosła. Mimo to wiele organizacji po kilku miesiącach pilotażu nadal nie potrafi odpowiedzieć na proste pytanie zarządu: czy AI realnie poprawiło nasz proces?
Właśnie w tym miejscu pojawia się problem.
Demo działa. Zespół jest zainteresowany. Dostawca pokazuje obiecujące wyniki. Pojawiają się pierwsze testy, prezentacje, warsztaty i rekomendacje. Ale po kilku miesiącach projekt nie przechodzi do produkcji. Nie zostaje też formalnie zamknięty. Trwa dalej, bo nikt nie ma wystarczająco twardych danych, żeby podjąć decyzję GO albo NO-GO.
Po kilkudziesięciu rozmowach z organizacjami, które albo utknęły w pilotażach, albo przeszły z AI do realnego wdrożenia, widać powtarzalny wzorzec. Projekty, które wychodzą poza pilotaż, niekoniecznie mają lepszą technologię. Częściej mają lepszą metodę oceny.
Wzorzec, który powtarza się w projektach AI
Projekty AI, które nie wychodzą poza pilotaż, zwykle mają co najmniej jedną z trzech cech: zaczynają od technologii, nie mają punktu odniesienia albo nie mają właściciela decyzji.
Każda z tych cech z osobna wystarczy, żeby projekt utknął. Razem tworzą pilotaż bez daty końcowej.
Pierwszy problem polega na tym, że projekt zaczyna się od pytania o model, narzędzie albo dostawcę. Organizacja pyta: czy użyjemy Copilota, OpenAI, modelu lokalnego, rozwiązania chmurowego, platformy vendorowej? To są ważne pytania, ale nie powinny być pierwsze.
Pierwsze pytanie powinno brzmieć inaczej: który konkretnie proces chcemy poprawić i po czym poznamy, że się poprawił?
Jeśli ta odpowiedź nie pada na początku, technologia bardzo szybko staje się celem samym w sobie. Zespół testuje funkcjonalności, sprawdza możliwości modelu, buduje przypadki użycia, ale nie wiadomo, jaki proces biznesowy ma się zmienić. Wtedy nawet dobre demo nie prowadzi do decyzji inwestycyjnej.
Drugi problem to brak punktu odniesienia. Nikt nie zmierzył, jak proces wyglądał przed AI. Po trzech miesiącach testów trudno więc odpowiedzieć, czy nastąpiła poprawa. Można pokazać przykłady działania modelu, kilka dobrych rezultatów i opinię użytkowników, ale nie ma twardego porównania.
W takiej sytuacji zdanie „wyniki są obiecujące” może trwać w nieskończoność. Jest bezpieczne, ale decyzyjnie puste.
Trzeci problem to brak osoby, która może podjąć decyzję. Projekt jest „sprawą IT”, elementem programu transformacji albo inicjatywą komitetu sterującego. Wszyscy są zaangażowani, ale nikt nie ma realnego mandatu, żeby powiedzieć: kończymy test, wynik jest negatywny, przechodzimy dalej.
W efekcie projekt trwa, bo kontynuacja jest organizacyjnie łatwiejsza niż zamknięcie.
Co robią inaczej organizacje, które dochodzą do wdrożenia
Organizacje, które przechodzą z AI do produkcji, działają inaczej już na starcie. Nie zaczynają od technologicznej możliwości, tylko od mierzalnego problemu.
Nie mówią: „AI mogłoby pomóc w obsłudze klienta”. Mówią raczej: „mediana czasu obsługi reklamacji wynosi 11 dni, 40% spraw wraca z powodu błędów w pierwszej odpowiedzi, a każda eskalacja angażuje dodatkowo lidera zespołu”.
To jest zupełnie inny poziom rozmowy.
Jeżeli problem jest sprecyzowany liczbowo, kryterium sukcesu AI staje się znacznie łatwiejsze do ustalenia. Można powiedzieć: test ma skrócić medianę czasu obsługi o 20%, zmniejszyć liczbę błędnych klasyfikacji albo ograniczyć udział spraw wymagających ręcznej interwencji. Bez takiego punktu odniesienia projekt będzie dryfował między opiniami.
Organizacje, które wdrażają AI skutecznie, mają też twardą datę zakończenia testu. Pilotaż bez daty końcowej jest w praktyce pilotażem bez decyzji. Dobry test powinien mieć określony horyzont, najczęściej 2-4 tygodnie, oraz z góry ustalone kryteria GO/NO-GO.
Taki termin nie jest formalnością. Wymusza dyscyplinę po obu stronach. Organizacja musi dostarczyć dane, dostęp do ekspertów i właściciela procesu. Partner technologiczny lub wdrożeniowy musi dostarczyć działający test, a nie serię prezentacji.
Brak deadline’u usuwa presję. A bez presji decyzja zawsze może poczekać.
NO-GO nie jest porażką projektu AI
Jedna z najważniejszych różnic między organizacjami dojrzałymi a tymi, które utykają w pilotażach, dotyczy podejścia do wyniku negatywnego.
W wielu firmach NO-GO jest traktowane jak porażka. Jeśli projekt nie przechodzi do wdrożenia, ktoś musi się tłumaczyć. Zespół obawia się, że straci wiarygodność. Sponsor nie chce przyznać, że inicjatywa nie przyniosła oczekiwanego efektu. Dostawca próbuje przedłużyć test, bo formalne zamknięcie oznaczałoby koniec budżetu.
To bardzo niezdrowy mechanizm.
NO-GO po trzech tygodniach kosztuje nieporównywalnie mniej niż sześciomiesięczne wdrożenie, które nie daje efektów. Jeśli test pokazuje, że proces nie jest dobrym kandydatem, dane są zbyt słabe, wolumen jest za niski albo ryzyko regulacyjne jest zbyt wysokie, organizacja zyskuje wartościową wiedzę.
Taki wynik nie zamyka tematu AI. Pozwala ustawić kolejny test mądrzej.
W praktyce negatywny wynik może prowadzić do kilku sensownych decyzji. Można poprawić jakość danych. Można zawęzić zakres procesu. Można wybrać inny punkt decyzyjny. Można przesunąć projekt do czasu zakończenia wdrożenia nowego systemu. Można też uznać, że w danym obszarze AI nie jest dziś priorytetem.
To jest normalne zarządzanie portfelem inicjatyw, nie porażka.
Adopcja użytkowników nie zaczyna się po wdrożeniu
Technicznie sprawny model, którego nikt nie używa, ma ROI równe zero. To zdanie brzmi banalnie, ale wiele projektów AI nadal zachowuje się tak, jakby adopcja była etapem po wdrożeniu.
Najpierw budujemy model. Potem integrujemy. Potem szkolimy ludzi. Potem liczymy na to, że zaczną korzystać.
Organizacje, które dochodzą do wdrożenia, odwracają tę logikę. Planują adopcję równolegle z modelem. Już na etapie testu ustalają, kto będzie korzystał z wyników AI, w jakim momencie procesu, z jaką odpowiedzialnością i według jakich zasad.
To szczególnie ważne w procesach operacyjnych. Jeśli AI klasyfikuje sprawy, pracownik musi wiedzieć, kiedy może przyjąć rekomendację, a kiedy powinien ją zakwestionować. Jeśli AI wskazuje ryzyko, użytkownik musi rozumieć, jak interpretować sygnał. Jeśli AI przygotowuje odpowiedź do klienta, ktoś musi odpowiadać za jej akceptację.
Bez tego narzędzie staje się ciekawostką. Pracownicy po szkoleniu wiedzą, że AI „coś potrafi”, ale nie wiedzą, jak zmienia się ich codzienna praca.
Dobra adopcja oznacza, że użytkownik rozumie trzy rzeczy: kiedy korzystać z rekomendacji AI, kiedy ją zakwestionować i co zrobić w sytuacji niejednoznacznej.
Feedback od pracowników korzystających z modelu na co dzień jest też jednym z najlepszych źródeł informacji o tym, gdzie rozwiązanie zawodzi. To użytkownicy najszybciej zobaczą, że model myli podobne kategorie, nie radzi sobie z konkretnym typem dokumentu albo rekomenduje zbyt ostrożną ścieżkę dla prostych spraw.
Jeżeli ich głos nie jest uwzględniony w teście, projekt może wyglądać dobrze na slajdach, ale nie zadziała w operacjach.
Dodatkowa warstwa trudności w sektorze finansowym
W bankach, towarzystwach ubezpieczeniowych, firmach pożyczkowych, leasingowych, faktoringowych, windykacyjnych i fintechach do typowych problemów projektów AI dochodzą ograniczenia specyficzne dla branży.
Pierwszym z nich są regulacje. RODO, oczekiwania nadzorcze, audytowalność, bezpieczeństwo informacji i AI Act to realne ograniczenia. Nie są jednak zakazem używania AI. Są ramami, w których projekt trzeba zaprojektować.
Problem zaczyna się wtedy, gdy organizacja traktuje regulacje albo jako powód, żeby nic nie robić, albo jako temat do załatwienia na końcu. Oba podejścia są ryzykowne.
W dobrze przygotowanym projekcie model bezpieczeństwa jest obecny od pierwszego dnia. Dane powinny być pseudonimizowane albo anonimizowane, jeśli cel testu na to pozwala. Środowisko powinno być odizolowane od produkcji. Dostęp do danych musi być ograniczony. Działania systemu powinny być logowane. Umowy dotyczące poufności, powierzenia danych i odpowiedzialności stron powinny być uzgodnione przed rozpoczęciem pracy na realnych danych.
Drugi problem dotyczy danych osobowych klientów. Eksport danych do zewnętrznego narzędzia AI bez pseudonimizacji, bez jasnego modelu przetwarzania i bez odpowiedniej umowy nie jest drobną luką techniczną. To ryzyko prawne, reputacyjne i operacyjne.
Wiele projektów AI nie zatrzymuje się dlatego, że model nie działa. Zatrzymuje się dlatego, że dział prawny, bezpieczeństwo albo compliance zbyt późno dowiadują się, gdzie trafiły dane i jak są przetwarzane.
Trzeci problem dotyczy decyzji regulowanych. Scoring kredytowy, ocena wniosków, wypowiedzenie umowy, decyzje windykacyjne czy rozstrzygnięcia reklamacyjne nie mogą zostać potraktowane jak prosta automatyzacja biurowa.
AI może wspierać analizę, klasyfikować dokumenty, wskazywać niezgodności, rekomendować ścieżkę albo przygotowywać podsumowanie. Ale przy decyzjach o istotnych skutkach dla klienta potrzebny jest człowiek w procesie.
Model human-in-the-loop w sektorze finansowym nie jest dodatkiem architektonicznym. Jest warunkiem odpowiedzialnego i możliwego do obrony wdrożenia.
Obserwacja z projektu: AI nie zaczęło działać lepiej, pojawiła się metoda
W jednej z organizacji z sektora usług finansowych pilotaż AI trwał ponad rok. Zespół był zaangażowany, rozwiązanie było regularnie omawiane, a kolejne przeglądy kończyły się podobnym wnioskiem: „wyniki są obiecujące”.
Problem polegał na tym, że nikt nie potrafił powiedzieć, co dokładnie oznacza „obiecujące”. Nie zmierzono punktu wyjścia. Nie było jasnego KPI. Nie ustalono, jaki wynik kończy test decyzją GO, a jaki oznacza NO-GO.
Zaangażowanie zespołu spadało, bo każde spotkanie wyglądało podobnie. Pojawiały się kolejne przykłady, kolejne obserwacje, kolejne hipotezy, ale nie było decyzji.
Po przeformułowaniu projektu na Proof of Value sytuacja zmieniła się radykalnie. Najpierw zdefiniowano proces, wskaźniki i punkt odniesienia. Następnie przygotowano test na realnych danych i ustalono twarde kryterium decyzji. Projekt zakończył się w ciągu trzech tygodni.
Co ważne, AI nie zaczęło nagle działać lepiej. Zmieniła się metoda oceny. Organizacja po raz pierwszy miała dane, żeby powiedzieć, czy rozwiązanie wnosi wartość, w jakim zakresie i pod jakimi warunkami można je skalować.
To dobrze pokazuje naturę problemu. W wielu projektach AI nie brakuje modeli. Brakuje struktury, która pozwala ocenić, czy model pomaga.
Trzy pytania, które szybko pokazują, gdzie jest projekt
Gdy organizacja zastanawia się nad projektem AI albo tkwi w pilotażu, nie trzeba zaczynać od dużego audytu gotowości. Często wystarczą trzy pytania, żeby zobaczyć, czy projekt ma szansę zakończyć się decyzją.
Pierwsze pytanie brzmi: co zmierzymy przed startem?
Jeśli odpowiedź brzmi: „mamy raporty, jakoś to ocenimy” albo „to się zobaczy w trakcie”, projekt prawdopodobnie nie ma jeszcze punktu odniesienia. A bez punktu odniesienia trudno mówić o ROI.
Drugie pytanie brzmi: kto podejmie decyzję GO/NO-GO?
Jeśli odpowiedź brzmi: „komitet sterujący”, „IT z biznesem”, „wspólnie zdecydujemy” albo „zobaczymy po wynikach”, to zwykle oznacza, że nikt nie ma jednoznacznego mandatu. Taki projekt prawdopodobnie skończy się kolejnym przeglądem, nie decyzją.
Trzecie pytanie brzmi: co zrobimy z wynikiem negatywnym?
Jeśli to pytanie wywołuje zakłopotanie, organizacja nie jest jeszcze gotowa na podejście oparte na danych. Oznacza to, że formalnie testuje, ale mentalnie oczekuje wyłącznie potwierdzenia wcześniejszej decyzji.
Trzy pytania, dziesięć minut rozmowy. Często dają więcej informacji o dojrzałości projektu niż rozbudowane prezentacje o strategii AI.
Co dzieje się po decyzji GO
Decyzja GO po Proof of Value nie oznacza jeszcze, że można natychmiast skalować AI na całą organizację. Oznacza, że w konkretnym procesie pojawił się mierzalny efekt uzasadniający kolejny etap.
To ważne rozróżnienie.
Po decyzji GO trzeba sprawdzić, czy fundamenty do skalowania są gotowe. Model powinien działać na realnych danych produkcyjnych, a nie tylko na eksportach z testu. KPI z fazy PoV powinny być monitorowane regularnie, najlepiej tygodniowo. Pracownicy powinni wiedzieć, kiedy korzystać z rekomendacji AI, kiedy ją eskalować i kto odpowiada za decyzję. Właściciel procesu powinien mieć bieżące dane, a nie prezentację raz na kwartał.
Skalowanie bez tych fundamentów jest tylko powielaniem pilotażu w większej skali. Problemy, które były małe przy stu sprawach miesięcznie, stają się duże przy tysiącu.
Organizacje, które to rozumieją, skalują stopniowo. Doprowadzają jeden proces do pełnej dojrzałości, zanim uruchomią kolejny. Dzięki temu budują wewnętrzne case study, wiarygodność i standard pracy z AI.
To ma duże znaczenie organizacyjne. Jeden projekt zakończony decyzją GO i poparty liczbami ułatwia kolejne inicjatywy bardziej niż dziesięć ogólnych prezentacji o potencjale AI.
Dlaczego to ma znaczenie właśnie teraz
Presja na wyniki AI w organizacjach rośnie. Zarządy pytają o ROI. Działy IT pytają, co dalej z zakupionymi licencjami. Konkurencja ogłasza kolejne wdrożenia. Pracownicy używają narzędzi AI prywatnie i oczekują, że firma też zacznie działać szybciej.
W takiej atmosferze pokusa pójścia na skróty jest duża. Pokazać demo zamiast wyników. Uruchomić kolejny pilotaż zamiast zamknąć poprzedni. Ogłosić „wdrożenie AI”, zanim ktokolwiek zmierzy, co się zmieniło w procesie.
To krótkoterminowo może wyglądać atrakcyjnie, ale długoterminowo niszczy wiarygodność AI w organizacji.
Firmy, które przez rok lub dwa ogłaszały kolejne inicjatywy AI bez mierzalnych efektów, zaczynają mieć problem innego rodzaju. Zarząd traci cierpliwość. Pracownicy przestają wierzyć w kolejne projekty. Działy operacyjne traktują AI jak modę, która generuje spotkania, ale nie rozwiązuje realnych problemów.
Ten cynizm jest trudniejszy do pokonania niż brak wiedzy technicznej.
Metodyczne podejście może wydawać się wolniejsze na początku. Trzeba wybrać proces, ustalić baseline, przygotować dane, zdefiniować kryteria decyzji i zaplanować adopcję. Ale właśnie to skraca drogę do realnego wdrożenia, bo ogranicza liczbę niejasności w trakcie.
Mały test, twardy punkt odniesienia i decyzja w kilka tygodni budują coś, czego nie zbuduje seria pilotaży: wiarygodność wewnętrzną.
Metoda zamiast kolejnego narzędzia
Różnica między organizacjami, które skalują AI, a tymi, które tkwią w pilotażach, rzadko jest różnicą budżetu. Rzadko jest też wyłącznie różnicą technologii.
Najczęściej jest różnicą metodyczną.
Projekty, które wychodzą poza pilotaż, zaczynają się od pytania: jak sprawdzimy, że to działa? Projekty, które utykają, zaczynają się od pytania: jakiego modelu użyjemy?
To pozornie drobna różnica, ale przesądza o całej logice projektu. W pierwszym przypadku technologia jest narzędziem poprawy procesu. W drugim staje się tematem samym w sobie.
Proof of Value pomaga utrzymać właściwą kolejność. Najpierw proces, baseline, KPI i decyzja. Dopiero potem narzędzie, model i integracja.
Dzięki temu organizacja nie musi zgadywać, czy AI ma sens. Może to sprawdzić w konkretnym procesie, na realnych danych i w krótkim czasie.
AI potrzebuje decyzji, nie kolejnego pilotażu
AI może realnie poprawiać procesy operacyjne, obsługowe, dokumentowe i technologiczne. Może skracać czas analizy, wspierać klasyfikację, poprawiać jakość danych, ograniczać ręczną pracę i pomagać zespołom podejmować lepsze decyzje.
Ale sama technologia nie wystarczy.
Jeśli projekt nie ma punktu odniesienia, właściciela decyzji, twardej daty zakończenia i planu adopcji, bardzo łatwo stanie się kolejnym pilotażem bez końca.
Dlatego warto zacząć od prostych pytań: co mierzymy, w którym procesie, na jakich danych, kto podejmuje decyzję i co zrobimy z wynikiem negatywnym.
Organizacje, które potrafią odpowiedzieć na te pytania, szybciej oddzielają dobre przypadki użycia od słabych. Nie wdrażają AI wszędzie. Wdrażają ją tam, gdzie potrafią pokazać efekt.
Jeżeli chcesz zobaczyć, jak takie podejście wygląda w praktyce dla konkretnego procesu w Twojej organizacji, przeczytaj artykuł „Jak ocenić, czy AI zadziała w Twoim procesie” albo „5 pytań przed projektem AI”.
