Najczęstsze błędy przy wdrażaniu AI: 7 lekcji z polskich firm

Od kilku lat jestem zaangażowany w projekty związane ze sztuczną inteligencją (AI) w polskich firmach. Niektóre zakończyły się sukcesem, więcej jednak upadło. A porażki prawie nigdy nie wynikały z powodów, których ludzie się spodziewają.

Kiedy rozmawiam z menedżerami o wdrażaniu AI, ich obawy dotyczą złożoności technicznej, jakości danych i dokładności modeli. To rzeczywiste problemy, ale nie one zabijają większość projektów. Wzorce, które niszczą inicjatywy AI, mają charakter organizacyjny, polityczny i kulturowy. To rodzaj problemów, których nie widać podczas prezentacji demo dostawców czy pokazów proof-of-concept.

Na podstawie moich obserwacji wyodrębniłem siedem lekcji. Każda z nich pochodzi z rzeczywistego projektu w prawdziwej firmie. Zanonimizowałem szczegóły, ale wzorce są na tyle powszechne, że prawdopodobnie rozpoznasz w nich swoją organizację przynajmniej w trzech przypadkach.

Wzorce, które niszczą inicjatywy AI, rzadko są techniczne. To problemy organizacyjne, polityczne i kulturowe -- takie, których nie widać podczas prezentacji demo dostawców.

## Lekcja 1: Rozpoczynanie od technologii zamiast od problemu

W połowie 2024 roku średniej wielkości firma ubezpieczeniowa z Warszawy zakupiła platformę AI dla przedsiębiorstw. Decyzję o zakupie podjął prezes, który zobaczył przekonującą demonstrację na konferencji. Roczny koszt platformy wyniósł ponad 200 000 PLN. Osiemnaście miesięcy później z platformy korzystały dokładnie dwie osoby w organizacji, a obie wykonywały zadania, które mogłyby równie dobrze zrobić w arkuszu kalkulacyjnym.

To najczęstszy błąd przy wdrażaniu AI, z jakim się spotykam, i zdarza się on na każdą skalę. Organizacja zaczyna od zakupu technologii, zamiast najpierw zidentyfikować konkretny problem biznesowy wart rozwiązania. Logika jest następująca: „AI jest ważne, musimy je mieć, kupmy coś i później wymyślimy, jak to wykorzystać”.

Rozwiązanie jest proste, ale wymaga dyscypliny. Przed podjęciem jakiejkolwiek decyzji technologicznej odpowiedz na trzy pytania: Jaki konkretny wynik biznesowy chcemy poprawić? Jak zmierzymy, czy się poprawił? Jaki jest koszt nierozwiązania tego problemu? Jeśli nie potrafisz konkretnie odpowiedzieć na wszystkie trzy pytania, nie jesteś gotowy na projekt związany z AI. Jesteś gotowy na szkolenie odkrywcze.

Prowadzę szkolenia dla kadry zarządzającej, które zaczynają się dokładnie od tego ćwiczenia. Najczęstszym rezultatem jest to, że zespół identyfikuje trzy do pięciu konkretnych problemów, zdaje sobie sprawę, że dwa z nich w ogóle nie wymagają AI, i skupia swój budżet na jednym lub dwóch przypadkach, w których AI rzeczywiście daje przewagę. To skupienie jest warte więcej niż jakakolwiek licencja na platformę.

## Lekcja 2: Pomijanie oceny gotowości danych

Firma logistyczna z Katowic chciała przewidywać opóźnienia dostaw za pomocą uczenia maszynowego. Przypadek użycia był jasny, wartość biznesowa mierzalna, a sponsor wykonawczy zaangażowany. Na papierze był to dobrze ustrukturyzowany projekt AI.

Wszystko rozpadło się w trzecim tygodniu, gdy zespół danych odkrył, że znaczniki czasu dostaw były rejestrowane w czterech różnych formatach w trzech systemach, około 30% historycznych zapisów miało brakujące pola, a najbardziej predykcyjna zmienna -- dostępność kierowców - istniała tylko w papierowym systemie harmonogramów, który dyspozytor trzymał w szufladzie biurka.

Nikt nie sprawdził danych przed zatwierdzeniem projektu. To zdarza się częściej, niż ktokolwiek przyznaje. Badanie Gartnera z 2024 roku wykazało, że słaba jakość danych kosztuje organizacje średnio 12,9 miliona dolarów rocznie. W przypadku projektów AI koszt jest jeszcze większy: spędzasz miesiące na budowaniu na złych fundamentach, zanim odkryjesz problem.

Ocena gotowości danych nie jest efektowną pracą. Oznacza to siedzenie z ludźmi, którzy faktycznie wprowadzają dane, rozumienie ich przepływów pracy, odkrywanie obejść, które opracowali przez lata pracy z niedoskonałymi systemami. Ale jest to najbardziej wartościowa czynność, jaką możesz wykonać przed zaangażowaniem się w projekt AI.

Przed zatwierdzeniem jakiegokolwiek projektu AI, ktoś musi usiąść z ludźmi wprowadzającymi dane i zrozumieć ich przepływy pracy. Ta nieefektowna praca zapobiega najdroższym porażkom.

Zalecam dwutygodniowy audyt danych przed rozpoczęciem jakiegokolwiek projektu AI. Zmapuj każde źródło danych. Sprawdź kompletność, spójność i aktualność. Przeprowadź wywiady z ludźmi zaangażowanymi w proces. Dwa tygodnie spędzone tutaj zaoszczędzą sześć miesięcy budowania na ruchomych piaskach.

## Lekcja 3: Traktowanie sztucznej inteligencji jako projektu IT, a nie transformacji biznesowej

Firma produkcyjna z Poznania uruchomiła inicjatywę AI mającą na celu optymalizację planowania produkcji. Zespół został przygotowany jak w projekcie IT: kierownikiem był menedżer z działu IT, dwóch programistów oraz analityk danych specjalnie zatrudniony do tego celu, ale nikt nie reprezentował działów operacyjnych. Strona biznesowa miała być „konsultowana” poprzez kwartalne spotkania komitetu sterującego.

Wynik był imponujący technicznie, ale bezużyteczny operacyjnie. Model był dokładny w kontrolowanych warunkach, ale jego zalecenia stały w sprzeczności z ograniczeniami znanymi działom operacyjnym, a nieznanymi IT: harmonogramami konserwacji maszyn, umowami związkowymi dotyczącymi zmian pracy czy oknami dostaw od dostawców, które sezonowo się zmieniały.

Wdrożenie AI to nie jest projekt IT – to transformacja biznesowa z wykorzystaniem technologii. Ta różnica ma znaczenie, bo determinuje kto jest w pokoju (zespole), czyje słowo się liczy i jak jest definiowany sukces. Jeśli AI to projekt IT, „sukces” oznacza: „model działa”. Gdy AI to transformacja biznesowa, sukces oznacza: „wyniki firmy się poprawiły”.

Praktyczna implikacja: każdy projekt AI potrzebuje właściciela biznesowego, który odpowiada za wyniki finansowe obszaru podlegającego zmianie (P&L accountability). Nie sponsora z IT. Ani „oficera ds. transformacji cyfrowej”. Osoby, która odczuje skutki projektu na własnych metrykach wydajności.

Widziałem, jak takie podejście radykalnie zmienia efekty. W jednym z wdrożeń na poziomie zespołu, gdy przekazano własność projektu z działu IT do dyrektora operacyjnego – ten sam projekt, ta sama ekipa, ta sama technologia! – udało się wprowadzić rozwiązanie do produkcji w cztery miesiące zamiast dwunastu, które przewidywała wcześniejsza struktura.



## Lekcja 4: Niedocenianie zarządzania zmianą

Firma świadcząca usługi finansowe w Gdańsku wprowadziła system klasyfikacji dokumentów, który pod względem technicznym był doskonały. Mógł klasyfikować nadchodzące dokumenty z 94% dokładnością, co było lepsze niż proces ręczny. Plan wdrożenia był prosty: włączyć go, wysłać e-mail szkoleniowy i gotowe.

Sześć miesięcy po wdrożeniu tylko 40% pracowników korzystało z systemu. Reszta znalazła obejścia. Niektórzy przesyłali dokumenty kolegom, którzy klasyfikowali je ręcznie. Inni zapisywali dokumenty na wspólnym dysku, którego system nie monitorował. Kilka osób po prostu całkowicie ignorowało nowy proces.

Problemem nie była technologia. Problemem był fakt, że nikt nie rozmawiał z ludźmi, których praca się zmieniała. Nikt nie wyjaśnił, dlaczego zachodzi zmiana, co oznacza dla ich codziennej pracy lub co stanie się z czasem, który wcześniej poświęcali na klasyfikację. Ludzie wypełnili tę lukę informacyjną swoimi najgorszymi obawami.

Zarządzanie zmianą w przypadku sztucznej inteligencji jest trudniejsze niż w przypadku innych projektów technologicznych, ponieważ sztuczna inteligencja wprowadza niepewność. Nowy system CRM jest przewidywalny - robi to samo za każdym razem. Sztuczna inteligencja podejmuje decyzje, które czasami wydają się arbitralne. Ludzie muszą zrozumieć nie tylko to, co system robi, ale także dlaczego czasami się myli i co zrobić, gdy tak się stanie.

Sztuczna inteligencja wprowadza niepewność, której nie ma w innych technologiach. Ludzie muszą zrozumieć nie tylko to, co system robi, ale także dlaczego czasami się myli i co zrobić, gdy tak się stanie.

Co działa: rozpocznij zarządzanie zmianą, zanim technologia będzie gotowa. Zaangażuj końcowych użytkowników już na etapie projektowania. Pozwól im zobaczyć brudną rzeczywistość rozwoju, a nie tylko wypolerowaną wersję demonstracyjną. Ludzie opierają się temu, czego nie rozumieją. Adaptują to, w czym pomagali tworzyć.

        

## Lekcja 5: Brak jasnych metryk sukcesu od pierwszego dnia

Firma handlowa we Wrocławiu uruchomiła model predykcji odpływu klientów. Zespół data science zbudował go, przetestował i ogłosił sukces, ponieważ model miał AUC na poziomie 0,87 - silny wynik predykcyjny w kontekście uczenia maszynowego. Zaprezentowali to biznesowi.

Biznes nie miał pojęcia, co oznacza AUC. Chcieli wiedzieć: czy mniej klientów odeszło? Odpowiedź brzmiała: nie wiemy. Nikt nie ustawił ram pomiarowych, aby śledzić, czy przewidywania faktycznie zmieniły wyniki retencji. Model predykował odpływ klientów dokładnie, ale nie istniał żaden proces, aby działać na podstawie tych przewidywań. Był to silnik predykcyjny bez załączonego planu działania.

Tak się dzieje, gdy zespół data science definiuje sukces w metrykach technicznych, a biznes definiuje sukces w wynikach biznesowych, i nikt nie zauważa, że mierzą różne rzeczy, aż do miesięcy w projekcie.

Rozwiązaniem jest uzgodnienie metryk sukcesu przed rozpoczęciem projektu i uczynienie ich metrykami biznesowymi, a nie metrykami modelu. „Zmniejszenie odpływu klientów o 5% w docelowym segmencie w ciągu sześciu miesięcy” to metryka sukcesu. „Osiągnięcie AUC na poziomie 0,85 na zbiorze testowym” to kamień milowy data science, który może (ale nie musi) przyczynić się do metryki sukcesu.

Proszę zespoły, aby na starcie projektu zdefiniowały trzy rzeczy: główną metrykę biznesową, docelową poprawę i metodę pomiaru. Jeśli zespół nie może się zgodzić co do tych kwestii, projekt nie jest gotowy. Lepiej spędzić dwa tygodnie na uzgadnianiu metryk, niż sześć miesięcy na budowaniu czegoś, czego nikt nie wie, jak ocenić.

## Lekcja 6: Budowanie niestandardowych rozwiązań, gdy gotowe byłyby wystarczające

Firma świadcząca usługi profesjonalne w Krakowie poświęciła dziewięć miesięcy i około 400 000 PLN na stworzenie niestandardowego systemu do podsumowywania dokumentów. System wykorzystywał dostrojony model językowy, niestandardowy potok przetwarzania wstępnego i spersonalizowany interfejs użytkownika. Działał dobrze.

Trzy miesiące po wdrożeniu udostępniono GPT-4 poprzez usługę Azure OpenAI, z którą firma miała już umowę korporacyjną. Pojedyncze wywołanie API z odpowiednim monitem generowało podsumowania o porównywalnej jakości. Koszt był znikomy. Z perspektywy czasu dziewięć miesięcy pracy nad niestandardowym rozwiązaniem okazało się niepotrzebne.

Nie twierdzę, że niestandardowe rozwiązania AI nigdy nie są uzasadnione. Istnieją uzasadnione powody do budowania niestandardowych systemów: przewaga wynikająca z własnych danych, wymogi regulacyjne, ograniczenia wydajnościowe lub rzeczywista przewaga konkurencyjna. Jednak wiele organizacji domyślnie wybiera rozwój niestandardowych rozwiązań, ponieważ wydaje się to poważniejsze, bardziej innowacyjne i, szczerze mówiąc, bardziej imponujące dla zarządu.

Zanim zbudujesz niestandardowe rozwiązanie, przeprowadź ustrukturyzowaną ocenę istniejących narzędzi. Daj im dwa tygodnie i uczciwy test z rzeczywistymi danymi. Obserwowałem, jak zespoły odrzucały komercyjne narzędzia po 30-minutowej prezentacji z użyciem danych testowych, a następnie spędzały miesiące na odtwarzaniu funkcjonalności, która była już dostępna. Koszt dwutygodniowej oceny jest niemal zerowy w porównaniu z ryzykiem niepotrzebnego rozwoju niestandardowych rozwiązań.

Wiele organizacji domyślnie wybiera rozwój niestandardowych rozwiązań AI, ponieważ wydaje się to bardziej innowacyjne. Jednak dwutygodniowa ocena istniejących narzędzi nic nie kosztuje w porównaniu z miesiącami niepotrzebnej pracy nad niestandardowymi rozwiązaniami.

Ramy decyzyjne, których używam: buduj niestandardowe rozwiązanie tylko wtedy, gdy możesz wyraźnie określić, co Twoje niestandardowe rozwiązanie robi lepiej niż jakiekolwiek istniejące narzędzie, a ta różnica jest związana z konkretną przewagą konkurencyjną. „Chcemy pełnej kontroli” nie jest przewagą konkurencyjną. „Nasza własna logika przetwarzania roszczeń wymaga wyodrębniania encji specyficznych dla domeny, czego żadne komercyjne narzędzie nie wspiera” - już tak.

## Lekcja 7: Ignorowanie zarządzania do czasu, aż coś pójdzie nie tak

Firma związana z opieką zdrowotną w Łodzi wdrożyła system AI do wstępnej oceny formularzy pacjentów. System działał dobrze podczas testów. Działał dobrze w produkcji. Przez około osiem miesięcy. Następnie zaczął generować oceny, które były subtelnie tendencyjne wobec starszych pacjentów. Nikt tego nie zauważył przez trzy miesiące, ponieważ nie było monitoringu.

Główną przyczyną był problem dryfu danych - charakterystyka nadchodzących formularzy pacjentów zmieniła się po kampanii marketingowej, która przyniosła inną mieszankę demograficzną, a model nie został ponownie przeszkolony. Ale głębszą przyczyną było to, że nikt nie ustanowił zarządzania wokół systemu AI. Nie było monitoringu dryfu modelu. Brak testów sprawiedliwości. Brak zdefiniowanego procesu, gdy model wymagał ponownego przeszkolenia. Brak jasnej odpowiedzialności za system po wdrożeniu.

Zarządzanie AI to nie biurokracja. To infrastruktura organizacyjna, która utrzymuje systemy AI niezawodnymi po tym, jak zespół deweloperski przejdzie do kolejnego projektu. Bez tego każde wdrożenie AI to tykający zegar. System będzie dryfował, świat się zmieni, i nikt tego nie zauważy, dopóki konsekwencje nie będą widoczne - a wtedy szkody już się staną.

Minimalne ramy nadzoru, które rekomenduję dla każdego systemu AI w produkcji, ma cztery komponenty. Po pierwsze, monitoring: automatyczne śledzenie wydajności modelu, dryfu danych i rozkładu wyjść, z alertami dla anomalii. Po drugie, odpowiedzialność: wyznaczona osoba odpowiedzialna za system po wdrożeniu, z jasnym upoważnieniem do jego wyłączenia, jeśli to konieczne. Po trzecie, częstotliwość przeglądów: zaplanowane ponowne szkolenia i oceny w określonych odstępach czasu, nie tylko gdy ktoś zauważy problem. Po czwarte, dokumentacja: zapis tego, co model robi, na jakich danych był trenowany, jakie są jego znane ograniczenia i kto zatwierdził jego wdrożenie.

Te ramy dodają kosztów. Ale koszt ich braku jest wyższy. Firma medyczna, o której wspomniałem, wydała ponad 500 000 PLN na naprawę, przegląd prawny i przeprojektowanie procesów. Ramy nadzoru kosztowałyby ułamek tej kwoty.

Szczegółowo omawiam ramy nadzoru na moich szkoleniach dla kadry zarządzającej. Akt UE o sztucznej inteligencji, który w pełni wejdzie w życie w sierpniu 2026 roku, uczyni wiele z tych praktyk zarządzania prawnie obowiązkowymi dla systemów AI wysokiego ryzyka. Rozpoczęcie teraz to nie tylko dobra praktyka - to przygotowanie regulacyjne.

    

## Wspólny wątek

Przyglądając się tym siedmiu błędom, dostrzegamy pewien wzorzec. Każdy z nich jest błędem organizacyjnym, a nie technicznym. W każdym przypadku technologia działała lub mogła zostać dostosowana tak, aby działać. Zawiódł system ludzki wokół technologii: podejmowanie decyzji, komunikacja, pomiar, zarządzanie.

Dlatego uważam, że doradztwo we wdrażaniu sztucznej inteligencji fundamentalnie różni się od doradztwa technologicznego. Najtrudniejsze problemy nie dotyczą algorytmów czy infrastruktury. Chodzi o to, jak organizacje podejmują decyzje, zarządzają zmianą i uczą się na błędach. Firmy, którym udaje się z powodzeniem wdrożyć sztuczną inteligencję, traktują ją jako dyscyplinę biznesową, a nie zakup technologii.

Jeśli te wzorce wydają się znajome, to normalne. Większość organizacji popełnia co najmniej trzy z tych siedmiu błędów w swoim pierwszym dużym projekcie związanym ze sztuczną inteligencją. Celem nie jest uniknięcie każdego błędu, ale rozpoznanie ich wystarczająco wcześnie, aby skorygować kurs, zanim koszty staną się nie do odzyskania.

Większość organizacji popełnia co najmniej trzy z tych siedmiu błędów w swoim pierwszym dużym projekcie związanym ze sztuczną inteligencją. Celem nie jest perfekcja, ale rozpoznanie wzorca wystarczająco wcześnie, aby skorygować kurs.

Dla zespołów rozpoczynających swoją przygodę z AI oferuję praktyczne szkolenia, które adresują każdy z tych trybów awaryjnych za pomocą ćwiczeń praktycznych. Dla kadry zarządzającej prowadzę sesje strategiczne skupione na budowaniu infrastruktury organizacyjnej - zarządzania, metryk, zarządzania zmianą - która zapobiega powtarzaniu się tych błędów. Jeśli chcesz porozmawiać o tym, gdzie Twoja organizacja znajduje się w tym krajobrazie, skontaktuj się ze mną pod adresem hello@33coders.com.