Dlaczego projekty AI w firmach kończą się porażką i jak tego uniknąć

W internecie krąży wiele procentów o porażkach AI, często bez źródła albo z błędnym opisem. Te, które da się sprawdzić, mierzą różne rzeczy, więc nie należy ich porównywać wprost.

Wszystkie prowadzą jednak do tego samego wniosku. Sama technologia działa coraz lepiej, a większość firm wciąż nie umie zamienić jej na wymierny efekt. RAND, który rozmawiał z doświadczonymi inżynierami AI, na pierwszym miejscu wśród przyczyn wymienia źle postawiony problem biznesowy, a nie wybór modelu.

Dla Ciebie ważniejsza od procentu jest definicja porażki. Zanim zaczniesz, zapisz, co będzie sukcesem: krótszy czas obsługi, mniej błędów, mniej godzin pracy. Bez tego po roku nikt nie oceni, czy projekt się udał.

Dostawca może skonfigurować narzędzie, ale nie zmieni procesu w Twojej firmie. Potrzebna jest osoba, która zna proces, może podejmować decyzje i ma na projekt stały czas co tydzień. Zwykle jest to kierownik działu, dla którego projekt powstaje.

Bez takiej osoby projekt utyka na pytaniach o wyjątki i na sporach o priorytety. Po kilku miesiącach pada zdanie „technologia jest dobra, ale nie pasuje do naszego procesu”. Najczęściej znaczy ono, że nikt nie miał czasu, żeby ten proces zmienić.

Poniższe sygnały pokazują, że właściciela procesu brakuje. Jeśli widzisz dwa z nich, wstrzymaj start i najpierw wyznacz tę osobę.

Firma kupuje Microsoft Copilot albo uruchamia asystenta AI, ale zespół pracuje dokładnie tak samo jak wcześniej. Pracownicy korzystają z narzędzia od czasu do czasu, a po kilku tygodniach wracają do starych nawyków.

Weźmy hipotetyczną firmę, w której AI przygotowuje szkic oferty na podstawie zapytania klienta. Handlowcy nie ufają szkicom, więc piszą każdą ofertę od zera, a szkic tylko przeglądają. Narzędzie działa, ale czas przygotowania oferty się nie skrócił.

Rozwiązaniem jest zaprojektowanie nowego sposobu pracy razem z narzędziem. Ustal, które kroki znikają, które sprawdza człowiek i według jakich kryteriów. Właśnie tę część BCG opisuje jako 70% wysiłku w firmach, którym AI się opłaca.

Projekt często zaczyna się od zdania „mamy dużo danych”. Po kilku tygodniach okazuje się, że ten sam klient ma trzy nazwy w trzech systemach, cenniki istnieją w kilku wersjach, a kategorie w historii zamówień zmieniały się co rok.

Porządkowanie danych pochłania wtedy czas i budżet przeznaczone na właściwe wdrożenie. Firma staje przed wyborem: przekroczyć budżet albo zaakceptować rozwiązanie, które myli się częściej, niż obiecano.

Prosty test zrób, zanim podpiszesz umowę. Weź 100 typowych spraw, np. zapytań ofertowych, i niech doświadczony pracownik obsłuży je ręcznie, zapisując, skąd brał każdą informację. Jeśli jemu sprawia to trudność, AI też sobie nie poradzi.

Pierwszy projekt decyduje, czy firma będzie dalej inwestować w AI. Kuszą pomysły efektowne, np. chatbot dla wszystkich klientów albo AI, które samo przygotowuje raporty dla zarządu. To zwykle najtrudniejsze zadania, a ich błędy widać od razu.

Dobry pierwszy projekt jest nudny. Dotyczy powtarzalnej pracy, którą łatwo zmierzyć, a każdy wynik AI sprawdza człowiek, zanim trafi dalej. Tabela poniżej pomaga odróżnić dobry start od ryzykownego.

Projekt bez jasnych zasad potrafi zatrzymać się tuż przed uruchomieniem. Ktoś pyta, czy dane klientów mogą trafiać do modelu AI i kto odpowiada za błędną odpowiedź, a nikt nie zna odpowiedzi.

W tym czasie pracownicy często korzystają już z darmowych narzędzi na prywatnych kontach i wklejają do nich firmowe dokumenty. Zasady nie muszą być długie. Wystarczy kilka stron: jakie narzędzia są dozwolone, jakich danych nie wolno do nich wpisywać i kto zatwierdza nowe zastosowania.

AI Act nie nakłada na każdą firmę obowiązku spisania polityki AI. Od 2 lutego 2025 r. wymaga jednak (art. 4), by firma wspierała wiedzę pracowników o AI, a spisane zasady i szkolenie to najprostszy sposób, żeby to wykazać. Jeśli AI rozmawia z klientami, od 2 sierpnia 2026 r. musi informować, że rozmówca nie rozmawia z człowiekiem (art. 50).

Na spotkaniu sprzedażowym występują doświadczeni specjaliści, a projekt prowadzą potem osoby, które robią podobne wdrożenie po raz pierwszy. To częsty powód, dla którego dobrze zapowiadany projekt rozjeżdża się w trakcie.

Przed podpisaniem umowy zadaj dostawcy kilka prostych pytań. Odpowiedzi na piśmie mówią o nim więcej niż prezentacja.

Pierwsze tygodnie projektu to opis procesu, porządkowanie danych i testy. Jeśli zarząd pyta o zwrot z inwestycji, zanim rozwiązanie zacznie działać, zespół pod presją pokazuje „cokolwiek” i podejmuje pochopne decyzje.

Pomaga jeden członek zarządu, który rozumie, po co jest projekt, i broni go do pierwszego pomiaru. Dobry test jest prosty: po krótkiej rozmowie potrafi on własnymi słowami powiedzieć, jaki problem projekt rozwiązuje i po czym poznacie sukces.

Uzgodnij też z góry punkty kontrolne. Na przykład: po pilotażu w jednym zespole porównujecie wynik z miarą zapisaną przed startem i decydujecie, czy rozszerzyć projekt, poprawić go, czy zakończyć.

Poniższa lista zbiera wszystkie przyczyny w jednym miejscu. Jeśli na trzy lub więcej pytań nie masz dobrej odpowiedzi, lepiej przesunąć start i najpierw uzupełnić braki.

Odpowiedzi zwykle wymagają kilku tygodni rozmów wewnątrz firmy. To dobrze wykorzystany czas, bo pozwala uniknąć miesięcy pracy nad projektem, który nie miał szans.

Zanim zaczniesz drugi projekt, przeanalizuj pierwszy. Przejdź przez siedem przyczyn opisanych wyżej i przy każdej zapisz, czy wystąpiła. Do rozmowy zaproś osoby, które miały korzystać z rozwiązania, a nie tylko zespół projektowy.

Jeśli przyczyną był proces, właściciel albo dane, kolejny projekt może się udać nawet z tym samym dostawcą. Jeśli zawiodła jakość pracy dostawcy, zmień go, ale przenieś do nowego projektu to, czego się nauczyliście.