Slajd „95% wdrożeń AI kończy się porażką” trafił do każdej prezentacji sprzedażowej. Pokazuję, skąd naprawdę pochodzi ta liczba i podaję pięć wskaźników, które policzysz we własnej firmie w tydzień.
Przemysław Zagórski7 min czytaniaakt. 31 lipca 2026
Jeśli w ostatnim roku siedziałeś na jakiejkolwiek prezentacji o wdrożeniu AI, widziałeś ten slajd: 95% pilotaży generatywnej AI nie przynosi zwrotu. Zwykle z logo MIT w rogu, żeby nie było wątpliwości co do powagi źródła.
Nie używam tej liczby. Nie dlatego, że uważam ją za fałszywą, tylko dlatego, że nie unosi ciężaru, który się na niej stawia. Opowieści o adopcji AI to dziś w dużej mierze handel cudzymi statystykami. Przejdźmy więc przez to porządnie: skąd ta liczba pochodzi, co naprawdę wiemy o adopcji i jak zmierzyć własną sytuację.
Liczba pochodzi z raportu The GenAI Divide: State of AI in Business 2025, wydanego latem 2025 przez Project NANDA w MIT Media Lab. Podstawa: 150 wywiadów z menedżerami, ankieta wśród 350 pracowników i analiza 300 publicznych wdrożeń.
Cztery rzeczy, które trzeba wiedzieć, zanim wstawi się ten slajd do własnej prezentacji.
Sam raport zawiera zresztą wniosek ciekawszy niż nagłówek. Przyczyna niepowodzeń jest organizacyjna, nie technologiczna. Autorzy nazywają ją luką w uczeniu się, czyli niezdolnością firm do wpięcia modeli w istniejące procesy i sposób pracy. Ten fragment jest zgodny z wszystkim, co widzę w praktyce. Szkoda, że nie on poszedł w świat.
Dwa duże, powtarzalne badania z 2025 roku dają obraz mniej efektowny i bardziej użyteczny.
To zestawienie mówi coś bardzo konkretnego. Problemem nie jest adopcja narzędzia, bo narzędzie zaadaptowali prawie wszyscy. Problemem jest przechwycenie wartości. Ludzie używają, nie ufają i weryfikują ręcznie, a firma płaci jednocześnie za licencje i za czas weryfikacji.
Dochodzi do tego wynik, który powinien zdyskwalifikować połowę firmowych ankiet o AI. W randomizowanym badaniu METR z 2025 roku doświadczeni programiści z narzędziami AI pracowali 19% wolniej, a po fakcie oszacowali, że byli 20% szybsi.
Sam efekt spowolnienia się zdezaktualizował: w aktualizacji z lutego 2026, na nowszych narzędziach, estymata odwróciła znak. Ale przepaść między pomiarem a odczuciem to osobny wniosek i on się nie zestarzał. Ludzie pomylili się co do własnej wydajności o blisko czterdzieści punktów procentowych i nie mieli o tym pojęcia. Deklaracja użytkownika nie jest pomiarem produktywności. Mierząc adopcję ankietą „czy AI Ci pomaga?”, mierzysz nastrój.
Mechanizm porzucania narzędzia jest przewidywalny i widziałem go w każdej firmie, w której prowadziłem warsztaty.
Pierwszy kontakt wygląda tak. Ktoś dostaje dostęp, zadaje jednozdaniowe pytanie bez kontekstu i dostaje kod, który się nie kompiluje albo łamie konwencję projektu. W środowisku o wysokim rygorze, czyli w banku, telco czy systemach płatniczych, koszt naprawienia złej odpowiedzi przewyższa koszt napisania tego samemu. Osoba wyciąga rozsądny wniosek, że narzędzie jest do niczego, i wraca do starego sposobu pracy. Licencja zostaje w rozliczeniu.
Trzy rzeczy tę pętlę utrwalają.
Brak wspólnego standardu. Każdy formułuje własne, nieoptymalne zapytania do tych samych powtarzalnych zadań. To złamanie zasady DRY na poziomie organizacji, tylko że nikt tego tak nie nazywa.
Brak budżetu czasu na naukę. Nikt nie dostał w sprincie dnia na opanowanie nowego narzędzia. Nauka odbywa się „przy okazji”, czyli pod presją terminu, czyli nie odbywa się.
Brak informacji zwrotnej. Osoba, która trafiła na dobry sposób pracy, nie ma gdzie go zapisać. Za tydzień odkrywa go ktoś inny od zera.
Poniższe da się zebrać bez kupowania czegokolwiek i bez projektu wdrożeniowego. Zastrzeżenie, żeby było uczciwie: progi w trzeciej kolumnie to moje reguły kciuka, wypracowane na warsztatach, a nie wartości z badań. Żadne źródło nie mówi, że 50% aktywnych albo 20 interakcji tygodniowo to granica sensu. Traktuj je jak punkt startowy, który skalibrujesz po pierwszym pomiarze.
| Wskaźnik | Skąd go weźmiesz | Kiedy jest źle |
|---|---|---|
| Aktywni tygodniowo do wykupionych stanowisk | Konsola administracyjna dostawcy | Poniżej 50% po trzech miesiącach od zakupu |
| Głębokość użycia, czyli odsetek aktywnych z ponad 20 interakcjami w tygodniu | Ta sama konsola | Gdy „aktywni” to głównie ludzie z dwoma, trzema interakcjami; to zaglądanie, nie praca |
| Czas na zestawie kontrolnym: 10 typowych zadań mierzonych z AI i bez | Stoper i dwie osoby, jeden dzień pracy | Brak różnicy albo różnica na niekorzyść AI w zadaniach na istniejącym kodzie |
| Sygnały z repozytorium: code churn w 14 dni, przyrost zduplikowanych bloków | Historia gita plus dowolny detektor duplikatów | Gdy churn rośnie szybciej niż liczba zmian |
| Trzy pytania jakościowe (patrz niżej) | Rozmowa, nie formularz | Gdy nikt nie potrafi podać konkretnego zadania z ostatniego tygodnia |
Zestaw kontrolny jest najważniejszy i najczęściej pomijany. Wybierasz dziesięć zadań, które Twój zespół faktycznie wykonuje, a nie zadania demonstracyjne. Dwie osoby o podobnym doświadczeniu robią po pięć każda, raz z AI, raz bez, z pomiarem czasu i oceną wyniku przez trzecią osobę.
Nie udawajmy, że to eksperyment naukowy: próba jest za mała, zadania nierówne, a osoby różnią się doświadczeniem. Przy dziesięciu zadaniach wychwycisz różnicę rzędu dziesiątek procent, nie kilku. To i tak nieporównanie więcej niż ankieta, bo zmusza do zapisania oczekiwanego wyniku przed pomiarem. Jeśli chcesz mocniejszych danych, powtórz to kwartalnie i patrz na trend, nie na pojedynczy pomiar.
Trzy pytania jakościowe, które faktycznie coś dają. Żadne z nich nie brzmi „czy AI Ci pomaga”.
Trzy wskaźniki, które wyglądają dobrze na slajdzie i nie znaczą nic.
Trzy typowe układy i sensowna reakcja na każdy z nich.
Niskie użycie, niezależnie od reszty. Nie dokupuj licencji i nie rób kolejnego webinaru o możliwościach AI. Problem leży w pierwszym kontakcie: ludzie nie wiedzą, jak sformułować zadanie dla własnej roboty. To problem umiejętności i rozwiązuje się go warsztatem na ich własnych zadaniach, nie prezentacją.
Wysokie użycie, brak efektu w repozytorium. Najczęstszy i najdroższy przypadek. Zespół pracuje szybko, a churn i duplikacja rosną. Potrzebne są bramki jakości i standardy pracy, nie więcej treningu z promptowania. Opisałem to w tekście o paradoksie produktywności.
Wysokie użycie i dobre wskaźniki. Zdarza się częściej, niż sugerują nagłówki. Wtedy jedyne sensowne działanie to spisać, co ci ludzie robią inaczej, i przenieść to do reszty organizacji jako standard. Zwykle okazuje się, że mają swoje prywatne, dopracowane prompty, o które nikt ich nigdy nie poprosił.
Statystyka 95% jest wygodna, bo zwalnia z myślenia. Skoro prawie wszystkim nie wychodzi, to nam też nie musi. Statystyka z własnej konsoli administracyjnej jest niewygodna, bo trzeba coś z nią zrobić.
Wszystkie potrzebne dane masz u siebie: konsolę dostawcy, historię gita i dwadzieścia osób, którym można zadać trzy sensowne pytania. Tydzień pracy jednej osoby daje obraz, którego nie zastąpi żaden cudzy raport. I to on powinien decydować o kolejnej fakturze za licencje.
Programista i architekt, 14+ lat w telco i enterprise IT. Prowadzi warsztaty z inżynierii kontekstu, GitHub Copilota, Google ADK oraz ekosystemu Gemini dla zespołów, które muszą dowozić produkcyjnie.
Jeśli opisane tu problemy brzmią znajomo, zwykle da się je rozbroić w kilka dni roboczych — nie kolejnym narzędziem, tylko zmianą sposobu pracy zespołu. Chętnie omówię Wasz przypadek.
Cache promptu wygląda na darmową optymalizację, a jest zakładem: zapis kosztuje więcej niż jego brak. Rozbieram mechanizm u Anthropic i OpenAI, liczby i to, co realnie zrobić z pięciominutowym oknem.
W randomizowanym badaniu programiści z AI pracowali 19% wolniej, a byli przekonani, że 20% szybciej. METR zaktualizował ten wynik. Pokazuję, co z niego zostało i co mówią dane GitClear oraz DORA.