Dlaczego 73% projektów AI w firmach kończy się porażką – i jak NIE zostać w tej statystyce

Liczba 73% projektów AI „kończących się porażką” pochodzi z raportu BCG „How Companies Get Ahead of Tomorrow's AI Disruption” z 2024 roku. Definicja porażki jest tam konkretna: projekt po 12 miesiącach od startu nie osiągnął ŻADNEGO mierzalnego efektu biznesowego — ani redukcji kosztów, ani wzrostu przychodów, ani poprawy doświadczenia klienta, ani redukcji ryzyka.

Inne raporty podają zbliżone liczby. Gartner w 2024 mówił o 80% projektów AI, które „nigdy nie wychodzą z piaskownicy”. MIT Sloan podaje 60% jako wskaźnik projektów AI w firmach średnich, które są porzucane przed produkcją. McKinsey rozróżnia POC (75% nie skaluje się do produkcji) od deployment (40% wdrożeń produkcyjnych zostaje wycofane w ciągu 2 lat).

Te liczby brzmią dramatycznie, ale warto je rozłożyć. Większość porażek to nie spektakularne katastrofy. To projekty, które technicznie zadziałały, ale nie zmieniły niczego w sposobie pracy organizacji. Model działa, dashboardy są, ale po 6 miesiącach nikt już do nich nie zagląda i procesy wracają do starego trybu.

To najczęstsza przyczyna porażki w naszej praktyce i w raportach branżowych. Projekt AI ma kilka dni delivery z naszej strony, ale wymaga 2–4 godzin tygodniowo zaangażowania właściciela biznesowego ze strony klienta — kogoś, kto rozumie proces, ma decision authority i jest zmotywowany do tego, żeby projekt się udał.

Gdy właściciela nie ma, projekt utyka w przekazaniu wymagań, walce o priorytety i nieskończonych iteracjach „a jeszcze byśmy chcieli”. Po 6 miesiącach klient mówi „technologia jest świetna, ale nie pasuje do naszego procesu” — co tak naprawdę znaczy „nikt po naszej stronie nie miał czasu, żeby zmienić proces”.

Sygnał, że właściciela nie ma: na pierwszej rozmowie kickoff przychodzi tylko IT, a nie szef działu, dla którego projekt jest robiony. Drugi sygnał: na pytanie „kto będzie używał tego modelu codziennie?” odpowiedź to „cały zespół” (czyli nikt konkretny).

Druga najczęstsza przyczyna porażki. Firma kupuje Microsoft Copilot, wdraża agenta AI lub uruchamia chatbot, ale NIE zmienia sposobu, w jaki zespół pracuje. Model jest, ale workflow wokół niego wygląda jak przed wdrożeniem. Efekt: użytkownicy używają nowego narzędzia okazyjnie, wracają do starych nawyków, i po pół roku nikt już nie pamięta, że projekt był.

Przykład: wdrożenie OCR faktur w średniej firmie księgowej. Technologia działa — wyciąga dane z faktur z 95% accuracy. Ale workflow nie został zmieniony — księgowi nadal otwierają każdą fakturę, sprawdzają wszystko ręcznie, i ostatecznie używają OCR-a tylko do skopiowania kwoty. Czas obsługi faktury: identyczny jak przed wdrożeniem. Projekt formalnie żyje, ale wartości biznesowej nie ma.

Lekarstwo: każdy projekt AI musi mieć równolegle redesign workflow. Bez tego technologia nie ma jak zadziałać. To znaczy, że projekt AI to nigdy nie jest tylko projekt IT — to jest projekt operacyjny, w którym IT jest jednym ze składników.

AI działa na danych. Większość średnich firm ma dane w stanie, którego nie chce przyznać. Faktury są zeskanowane w różnych formatach, dane klienta są w 4 systemach z różnymi nazwami, historie transakcji mają luki, kategoryzacja jest niespójna. Projekt AI zaczyna się od „mamy dużo danych”, a po 2 miesiącach okazuje się, że 80% z nich nie nadaje się do trenowania ani do RAG bez czyszczenia.

Realny czas na data cleanup to często 40–60% budżetu projektu. Firmy, które nie planują tego od początku, kończą z wyborem: przekroczyć budżet o 50%, albo zaakceptować model z 60% accuracy zamiast 90%. Oba scenariusze prowadzą do porażki postrzegania projektu, nawet jeśli technicznie się udał.

Lekarstwo: audyt danych ZANIM zaczniecie projekt AI. To nie jest waste budget — to oszczędność większej kwoty później. W praktyce: spróbujcie zrobić projekt na próbce 100–500 rekordów ręcznie. Jeśli to jest trudne, AI też sobie nie poradzi.

Wybór pierwszego use case'a AI w firmie jest strategiczną decyzją, nie taktyczną. Większość firm wybiera „seksowny” use case — chatbot dla klientów, agent obsługujący e-maile, AI do raportów dla zarządu. To często okazuje się być właśnie tym najtrudniejszym projektem, który potem definiuje, czy firma w ogóle będzie kontynuować wdrażanie AI.

Dobry pierwszy use case ma trzy cechy: jest mierzalny w czasie i kosztach, ma realnego beneficjenta z autorytetem, i jest dostatecznie nudny, żeby nie wymagać przełomu technologicznego. Najczęściej wygrywają: OCR faktur, automatyzacja akceptacji wniosków pracowniczych, generowanie ofert na podstawie templatu.

Najgorsze pierwsze use case'y: customer service chatbot (bo dotyka brand reputation), AI w sprzedaży (bo sprzedaż zawsze ma wymówki, że to nie działa), AI w raportach zarządczych (bo zarząd nie chce „prawie dobrych” liczb).

Projekt AI bez frameworka governance kończy się jednym z trzech scenariuszy. Pierwszy: dział security/compliance zatrzymuje wdrożenie w fazie produkcyjnej, bo „nie wiemy, jak audytować decyzje modelu”. Drugi: AI Act lub RODO/GDPR wymaga zmian, których nie da się zrobić retrospektywnie. Trzeci: shadow AI eksploduje, bo pracownicy nie czekają na oficjalny projekt i zaczynają używać ChatGPT na prywatnych kontach.

Governance nie znaczy „bardzo dużo dokumentacji”. Governance znaczy: jasna polityka, kto może używać jakich narzędzi AI, jak są audytowane decyzje krytyczne, jak są dokumentowane modele i dane treningowe, jak reagujemy na incydent. Polityka AI w firmie powinna istnieć ZANIM zaczniecie pierwszy projekt.

Lekarstwo: framework governance to 5–10 stron dokumentu i 2 tygodnie pracy. Nie 200 stron i 6 miesięcy. Zaczynacie od dwóch dokumentów: AI Usage Policy (kto może czego używać) i AI Project Review (jak każdy projekt jest oceniany przed startem).

Wdrożenie AI w średniej firmie B2B wymaga seniora w trzech obszarach: solution architect (rozumie biznes i technologię), AI engineer (rozumie LLM-y, agentów i integracje) oraz delivery lead (zarządza projektem). Większość projektów wpada w pułapkę „jeden senior + dwóch juniorów” lub „body shop ze swojego kraju”. Oba scenariusze często kończą się porażką.

Sygnał ostrzegawczy: dostawca pokazuje wam wizyty członków zespołu na pitch'u, ale w umowie nie ma gwarancji, że to ci sami ludzie będą pracować nad projektem. Drugi sygnał: w przedstawionych CV brak konkretnych projektów AI w produkcji — tylko POC-i i case studies marketingowe.

Lekarstwo: zażądaj imiennej listy zespołu w umowie. Zapytaj o liczbę wdrożeń produkcyjnych każdego senior membera w ostatnich 24 miesiącach. Jeśli odpowiedź to mniej niż 3 — szukaj dalej.

Wdrożenie AI to projekt o horyzoncie 6–18 miesięcy z efektami widocznymi na końcu, nie na początku. Zarząd, który nie rozumie tej dynamiki, zaczyna pytać o ROI w 4. miesiącu — kiedy projekt jeszcze nie ma jak go pokazać. Wynik: presja na pokazanie „czegokolwiek”, zła decyzja techniczna pod tę presję, projekt traci spójność.

Realny buy-in zarządu znaczy: ktoś z C-level rozumie, dlaczego ten projekt ma sens biznesowy, i jest gotów go bronić przez pierwsze 6 miesięcy bez twardych liczb. Bez tej osoby projekt nie przeżyje pierwszej przeszkody.

Lekarstwo: na etapie pre-sale wymagajcie spotkania z C-levelem klienta. Jeśli on/ona nie potrafi po 30 minutach powtórzyć w swoich słowach, dlaczego ten projekt jest ważny biznesowo — projekt nie jest gotowy do startu.

Te osiem pytań to nasz wewnętrzny framework discovery, który stosujemy przed startem każdego projektu. Jeśli klient nie potrafi odpowiedzieć na 3 lub więcej z nich, rekomendujemy odłożenie projektu do czasu gotowości. To kosztuje nas pieniądze w krótkim terminie, ale chroni reputację i klienta przed dołączeniem do statystyki 73%.

Każde z tych pytań brzmi prosto, ale odpowiedź wymaga pracy — często 2–4 tygodni rozmów wewnętrznych po stronie klienta. To NIE jest zła wiadomość. Te 2–4 tygodnie ZAOSZCZĘDZĄ 6 miesięcy projektu, który by nie zadziałał.