Co roku Gartner, McKinsey i BCG publikują raport z tą samą liczbą — między 70 a 87 procent projektów AI nie dociera do produkcji. Liczba się powtarza tak dokładnie, że stała się statystycznym krajobrazem. Wszyscy ją znają, nikt nie reaguje.
Jest w tym coś niepokojącego. Jeśli cztery na pięć projektów kończy się w fazie proof-of-concept, to nie mówimy o pojedynczych błędach wykonania. Mówimy o strukturze porażki — powtarzalnej, przewidywalnej, możliwej do zidentyfikowania przed jej wystąpieniem.
Przez ostatnie dwie dekady pracowałam z zarządami banków, utilities i producentów na projektach, w których technologia była narzędziem, ale nigdy celem. Teraz patrzę na sektor AI z innego kąta — jako integrator, który łączy ambitne organizacje z zespołami technologicznymi. Ten artykuł jest próbą usystematyzowania tego, co widzę w rozmowach każdego tygodnia.
Zdefiniujmy porażkę, o której mówimy
Projekt AI nie „nie trafia do produkcji" na jeden sposób. Widzę cztery warianty tej samej historii:
- Pilot techniczny się udaje, ale projekt nigdy nie dostaje budżetu wdrożeniowego. Zespół pokazał, że model działa na 94% danych testowych. Zarząd kiwa głową, finansowanie na kolejny kwartał nie zostaje przyznane.
- Pilot wdraża się częściowo i umiera w utrzymaniu. System działa na dwóch oddziałach, nikt nie ma budżetu ani kompetencji, żeby go rozwijać. Rok później pracownicy wracają do poprzedniego procesu.
- Wdrożenie techniczne się udaje, ale nikt nie używa systemu. Model rekomenduje optymalne decyzje. Decydenci ignorują rekomendacje, bo nikt nie pracował nad tym, żeby im zaufali.
- System działa, ale nie generuje wartości, którą obiecano. Metryki techniczne są świetne. ROI jest nieobliczalny, bo przed startem nikt nie zdefiniował, czym jest ROI w tym projekcie.
We wszystkich czterech wariantach organizacja wydała pieniądze na technologię, która — z biznesowego punktu widzenia — nie zaistniała. To jest porażka, o której mówimy.
Siedem powodów, dla których pilot nie zostaje produktem
1. Projekt zaczął się od technologii, nie od problemu
„Potrzebujemy GenAI w bankowości." „Musimy wprowadzić agentów AI do obsługi klienta." „Nasza konkurencja ma computer vision, my też powinniśmy." To są zdania, które słyszę regularnie — i które prawie zawsze prowadzą do projektów kończących się w PoC.
Właściwe pytanie brzmi inaczej: jaki proces biznesowy w naszej organizacji jest dziś bolesny, kosztowny lub wadliwy — i czy AI jest najlepszym sposobem, żeby ten konkretny problem rozwiązać? Jeśli odpowiedź nie przychodzi w kilku zdaniach, projekt ma strukturalny problem, zanim się zacznie.
2. Brak właściciela biznesowego z realnym autorytetem
Projekty AI prowadzone z działu IT, bez silnego właściciela po stronie biznesu, mają szanse na sukces poniżej średniej. Nie dlatego, że IT nie rozumie technologii — często rozumie lepiej niż ktokolwiek w firmie. Dlatego, że wdrożenie produkcyjne wymaga zmiany procesów, a procesów nie zmienia się z roli IT.
Projekt potrzebuje właściciela, który może powiedzieć „tak, w moim pionie pracownicy będą używać tego systemu" — i wyegzekwować to bez proszenia o zgodę innych.
3. Metryki sukcesu zdefiniowane po fakcie
Pytanie zadawane w czwartym miesiącu pilota — „jak właściwie mierzymy, czy to działa?" — to znak, że projekt już przegrał. Metryki muszą być zdefiniowane przed pierwszą linijką kodu, i muszą być:
- Mierzalne obiektywnie, nie przez ankietę satysfakcji
- Powiązane z konkretną liczbą w P&L lub operacyjnym KPI
- Uzgodnione między właścicielem biznesowym a dostawcą
- Mierzone przed startem (baseline) i w trakcie (trajektoria)
4. Wybór dostawcy, który robi prototypy
Rynek dostawców AI dzieli się na trzy grupy. Agencje kreatywne robiące efektowne demo. Zespoły badawcze specjalizujące się w nowej nauce. Firmy, które wdrażają systemy produkcyjne. Te trzy grupy często wyglądają tak samo na stronie internetowej.
Różnica wychodzi dopiero, kiedy projekt przekracza fazę happy-path i trzeba obsłużyć corner cases, monitoring, wersjonowanie modeli, rolowanie aktualizacji bez przerwy serwisu. Agencje i zespoły badawcze nie mają tych kompetencji — nie dlatego że nie chcą, tylko dlatego że to inny zawód.
5. Brak planu utrzymania od początku
System AI w produkcji wymaga aktywnego utrzymania. Dane się zmieniają (data drift), modele tracą jakość, pojawiają się nowe przypadki brzegowe, regulacje się rozwijają. Projekty, które nie mają budżetu operacyjnego na 3–5 lat po wdrożeniu, są projektami na wymieranie.
To jest miejsce, w którym wiele organizacji się wykłada — budżet wdrożeniowy jest zaplanowany, budżet utrzymaniowy nie istnieje. Po roku system „nie działa", choć w rzeczywistości nikt go nie utrzymywał.
6. Niedopasowanie do istniejącego stosu technologicznego
Bank, który ma core system z lat 90. i warstwę aplikacyjną z lat 2000., nie wdroży w tygodnie rozwiązania AI projektowanego pod cloud-native. Nie dlatego, że technologia nie działa — dlatego że integracja zabiera sześć miesięcy, a pilot miał trzy.
Dobry partner technologiczny pyta o istniejący stack w pierwszej godzinie rozmowy, nie w piątym miesiącu. Zły dostawca przynosi demo i dziwi się później, że „wasze systemy są trudne".
7. Projekt nie ma szansy na „nie"
Największa pułapka — projekty, w których decyzja o wdrożeniu została podjęta przed rozpoczęciem pilota. Pilot wtedy nie jest walidacją hipotezy, tylko ceremonią. Nikt nie może powiedzieć „to nie działa", bo nie jest to opcja na stole.
Zdrowy projekt zaczyna się od pytania „czy to rozwiąże nasz problem" — i ma strukturę, w której odpowiedź może brzmieć „nie". Jeśli takiej opcji nie ma, projekt nie jest pilotem — jest budżetem szukającym uzasadnienia.
Trzy cechy projektów, które docierają do produkcji
Po tej liście można pomyśleć, że wdrożenie produkcyjne wymaga idealnej sekwencji zdarzeń. W rzeczywistości wystarczą trzy rzeczy zrobione porządnie.
1. Jeden właściciel biznesowy, jedna decyzja, jedno P&L
Projekt ma właściciela na poziomie pozwalającym podejmować decyzje o procesach w jego pionie. Właściciel widzi projekt w swoim P&L — jako koszt lub oszczędność — i jest gotów ponieść za niego odpowiedzialność na koniec roku. To automatycznie filtruje projekty, które nie mają realnego wnętrza.
2. Zdefiniowane metryki przed startem, mierzone od dnia pierwszego
Baseline wzięty przed rozpoczęciem prac. Trajektoria monitorowana w trakcie. Decyzja o rolloutie oparta na twardych liczbach, nie na wrażeniu z demo. To brzmi oczywiście — rzadko jest wdrażane.
3. Partner technologiczny z historią produkcyjnych wdrożeń w podobnym kontekście
Nie w podobnej branży — w podobnym kontekście technologicznym, regulacyjnym, operacyjnym. Zespół, który wdrażał systemy AI w dużym banku, rozumie DORA i AI Act w sposób, jakiego nie nauczy się w trzy miesiące ekipa dotąd pracująca dla startupów.
Ramy decyzyjne przed startem pilota
Zamiast zaczynać pilot, proponuję prostą listę kontrolną. Jeśli na któreś pytanie nie ma jasnej odpowiedzi, projekt wymaga dopracowania przed startem, nie po.
- Jaki konkretny problem biznesowy rozwiązujemy? (Nie: „chcemy wykorzystać AI". Tak: „czas obsługi reklamacji kredytowych wynosi 12 dni, celem jest zejść do 5".)
- Kto jest właścicielem tego problemu w organizacji? Musi mieć nazwisko i autorytet operacyjny.
- Jak zmierzymy sukces? Konkretna liczba, nie deklaratywna satysfakcja.
- Co jest baseline'em — stanem obecnym, przeciw któremu mierzymy zmianę?
- Jaki jest budżet pilota, wdrożenia i utrzymania w horyzoncie trzyletnim? Jeśli finansujemy tylko pilot, wiemy, że skończymy na pilocie.
- Jak wygląda decyzja o kontynuacji? Jakie warunki muszą być spełnione, żeby pojechać w rollout — i jakie warunki oznaczają, że kończymy.
- Jakie systemy musimy zintegrować, i czy mamy kompetencje do tej integracji?
Organizacja, która ma odpowiedzi na te siedem pytań przed rozpoczęciem pilota, statystycznie nie ma problemu „80% projektów nie dochodzi do produkcji". Ma inny problem — czasem pilot nie dochodzi do produkcji, bo dowiadujemy się, że nie powinien. I to jest dobry wynik.
Wniosek dla osób decydujących o budżetach AI
Liczba „80% pilotów nie trafia do produkcji" nie jest naturalnym prawem sektora. Jest funkcją sposobu, w jaki organizacje zaczynają projekty AI — i jest do poprawienia w pojedynczym projekcie, jeśli zaczyna się go świadomie.
Najbardziej kosztowna decyzja, jaką podejmuje zarząd w projekcie AI, nie jest decyzją o budżecie. Jest decyzją o tym, jak wygląda pierwsza godzina — czy zaczynamy od prezentacji dostawcy, czy od rozmowy o problemie biznesowym, który chcemy rozwiązać.
Te same dolary wydane w innej sekwencji dają projekt, który trafia do produkcji.