Dlaczego projekty AI zawodzą i jak tego uniknąć

W ciągu ostatnich dwóch lat pattern powtarzał się regularnie: firma inwestuje kilka miesięcy i budżet w projekt AI, uruchamia pilot, a po ośmiu tygodniach wdraża się stagnacja. Model „działa", ale wyniki biznesowe nie przyrastają. Zespół nie wie, co poprawić. Projekt ląduje w szufladzie.

Przyczyną prawie nigdy nie był model. Był proces dookoła niego.

Projekty AI, które zaczynają od „sprawdźmy, co można zrobić z AI", mają jeden nieodłączny problem: nie ma kryterium sukcesu. Bez niego każda demonstracja modelu wygląda dobrze, a każdy błąd jest „do dopracowania".

Mierzalny cel to konkretne zdanie: „czas obsługi jednego zgłoszenia spada z 8 do 3 minut na 80% przypadków" albo „klasyfikator kieruje 70% zapytań do właściwej kolejki bez interwencji człowieka". Takie zdanie wyznacza też kiedy projekt jest gotowy do przejścia z pilota do produkcji.

Praktyczna konsekwencja: zdefiniuj cel przed doborem modelu, nie po nim. Model dobiera się pod cel, nie odwrotnie. Jeśli nie potrafisz zapisać celu w jednym zdaniu z liczbą i horyzontem czasowym, projekt jest za mało dookreślony, żeby startować. Narzędzie do wstępnej oceny gotowości procesu to finder automatyzacji.

Model jest tak dobry jak dane, na których pracuje. Najczęstszy scenariusz: firma przygotowuje bazę wiedzy z dokumentacji, która nie była aktualizowana od roku. Albo trenuje model na danych historycznych, które nie zawierają przypadków wyjątkowych, ponieważ te były obsługiwane ręcznie poza systemem.

Trzy symptomy złych danych wejściowych:

• Model dobrze odpowiada na pytania z dokumentacji, a słabo na pytania, które klienci faktycznie zadają.
• Wyniki na zbiorze testowym są dobre, a na produkcyjnych danych regularnie pojawiają się halucynacje lub błędne klasyfikacje.
• Model używa terminologii, której nikt w firmie już nie stosuje, bo pochodzi z dokumentów sprzed reorganizacji.

Zanim zaczniesz budować RAG lub fine-tuning, przeprowadź audyt danych: które dokumenty są aktualne, które są sierotami, które zawierają sprzeczności. Artykuł o przygotowaniu danych firmowych pod AI opisuje ten audyt krok po kroku.

Model językowy bez guardrails jest jak pracownik bez zakresu obowiązków: robi wszystko, o co go poprosisz, w tym rzeczy poza kompetencją. W środowisku firmowym oznacza to odpowiedzi na pytania, na które model nie powinien odpowiadać, lub konfabulowanie odpowiedzi, gdy nie ma wiedzy w bazie.

Dwa mechanizmy, które są obowiązkowe w każdym systemie produkcyjnym:

Odpowiedź „nie wiem" z eskalacją. Model, który nie znajdzie wystarczająco pewnej odpowiedzi w bazie wiedzy, nie powinien zgadywać. Powinien powiedzieć wprost: „Nie mam pewnych informacji na ten temat" i zaproponować kontakt z człowiekiem. Projektowanie tej ścieżki opisuje artykuł o monitoringu i jakości agenta AI.

Guardrails tematyczne. System działający w obszarze obsługi klienta sklepu internetowego nie odpowiada na pytania prawne, nie podaje konkretnych cen ubezpieczeń, nie diagnozuje problemów medycznych. Guardrails definiuje się jako listę dozwolonych intencji lub zablokowanych kategorii zapytań. Każda próba wyjścia poza zakres jest logowana i eskalowana.

Brak tych mechanizmów skutkuje nie tylko złą jakością odpowiedzi, ale też odpowiedzialnością prawną za treści, które system wyprodukował.

Projekty AI regularnie wpadają w pułapkę: dane są podłączone, model odpowiada, nikt nie sprawdził, co właściwie trafia do modelu i gdzie jest przetwarzane. Szczególnie dotkliwe scenariusze:

• Dane osobowe klientów (imiona, numery zamówień, adresy) trafiają w promptach do zewnętrznych API bez pseudonimizacji.
• Logi konwersacji zawierają PII w formie jawnej i są przechowywane bez podstawy prawnej.
• Firma korzysta z chmurowego API do modelu, a umowa z dostawcą nie spełnia wymogów art. 28 RODO (procesor danych).

Minimalne wymagania bezpieczeństwa dla każdego projektu AI przetwarzającego dane osobowe:

1. Maskowanie PII przed podaniem modelowi (w routerze, nie w aplikacji klienckiej).
2. Umowa powierzenia przetwarzania z dostawcą modelu lub self-hosting w infrastrukturze własnej.
3. Retencja danych z konwersacji ograniczona do minimum niezbędnego celu, z automatycznym usuwaniem.
4. Ścieżka realizacji prawa do usunięcia danych (RODO art. 17), szczególnie istotna przy embeddingach i bazach wektorowych.

Dla procesów wysokiego ryzyka (dane zdrowotne, finansowe, kadrowe) wymagana jest DPIA przed uruchomieniem. Szczegóły obowiązków firm w 2026 roku opisuje artykuł AI Act i RODO 2026.

Systemy AI podejmujące działania w imieniu firmy (wysyłanie maili, aktualizacja rekordów, zatwierdzanie transakcji) wymagają mechanizmu zatwierdzania dla kroków nieodwracalnych. Projekt, który tego nie ma, prędzej czy później wyśle wiadomość do złego adresata, nadpisze ważny rekord lub zatwierdzi akcję na podstawie błędnej klasyfikacji.

Human-gate to nie pełne wyłączenie automatyzacji. To zatrzymanie agenta przed krokiem nieodwracalnym i oczekiwanie na jawną akceptację operatora. Akceptacja jest logowana: kto, kiedy, w kontekście jakiego zadania. W praktyce sprawdza się model pięciu pytań przed każdą akcją wysokiego ryzyka:

1. Czy akcja zmienia stan systemu w sposób trudny do odwrócenia?
2. Czy błąd w tej akcji ma bezpośrednie skutki dla klienta lub finansowe?
3. Czy model miał dostęp do pełnych danych niezbędnych do tej decyzji?
4. Czy wynik kroku poprzedniego jest pewny (nie szacowany)?
5. Czy ta akcja była już wykonywana w analogicznym kontekście z sukcesem?

Odpowiedź „nie" na którekolwiek z tych pytań to sygnał do zatrzymania i eskalacji. Szczegółową architekturę tego mechanizmu opisuje artykuł o roli człowieka w pętli agenta.

Projekt AI uruchamia się, działa przez dwa tygodnie dobrze, potem jakość stopniowo spada. Nikt tego nie zauważa, bo nie ma metryk. Model nadal odpowiada, ale odpowiedzi są coraz mniej trafne, coraz więcej klientów trafia do człowieka nie z powodu trudnych pytań, ale z powodu błędnych odpowiedzi systemu.

Dryft jakości to zjawisko systematyczne: dane w firmie się zmieniają (nowe produkty, zmienione procedury, nowe regulacje), a baza wiedzy modelu nie nadąża. System, który nie monitoruje własnej jakości, nie ma jak wykryć momentu, w którym stał się problemem.

Minimum monitoringowe dla systemu produkcyjnego:

Architekturę kompletnego monitoringu opisuje artykuł o monitoringu i KPI agenta AI. Ocenę jakości odpowiedzi RAG metodą golden set opisuje artykuł o ewaluacji RAG.

Nie każdy proces nadaje się na pierwszy projekt AI. Najczęstszy błąd: firma wybiera albo zbyt trywialny proces (FAQ, którego obsługa zajmowała 10 minut dziennie), albo zbyt złożony (obsługa reklamacji wymagająca oceny eksperckiej i negocjacji). Pierwszy nie zwraca inwestycji. Drugi zawodzi, bo model nie jest w stanie wiarygodnie zastąpić eksperta.

Cechy procesu właściwego na start:

• Powtarzalność: minimum 50 podobnych przypadków miesięcznie.
• Definiowalność: każdy krok da się opisać regułą lub schematem decyzji.
• Weryfikowalność: wynik da się sprawdzić programistycznie lub przez prostą kontrolę.
• Ograniczony zakres decyzji: nie wymaga wiedzy kontekstowej spoza dostępnych danych.
• Nie jest procesem wysokiego ryzyka w rozumieniu AI Act Załącznik III (lub firma jest gotowa na pełen compliance).

Przed wyborem procesu warto przejść przez finder automatyzacji, który ocenia dopasowanie procesu do automatyzacji AI według tych kryteriów. Metodologię wyboru pierwszego procesu opisuje też artykuł od czego zacząć wdrożenie AI.

Spośród projektów, które kończą się wdrożeniem produkcyjnym, zdecydowana większość przeszła przez etap shadow mode. Agent działa równolegle z człowiekiem przez 2-4 tygodnie: przetwarza te same dane, generuje te same odpowiedzi, ale wyniki nie są stosowane. Zamiast tego są porównywane z decyzjami człowieka.

Shadow mode ujawnia luki, których żadne testy jednostkowe nie znajdą: przypadki brzegowe specyficzne dla branży, terminologia używana przez klientów, która nie pasuje do terminologii dokumentacji, sytuacje, w których dane w bazie są sprzeczne.

Dopiero po shadow mode z rozbieżnością poniżej ustalonego progu (typowo 5-10% decyzji różnych od człowieka) system wchodzi w etap pilota z human-gate. Pełny harmonogram i plan wdrożenia krok po kroku opisuje artykuł plan wdrożenia AI.

Opisz projekt AI, który planujesz lub który utknął. Model wskaże, który z siedmiu błędów najbardziej pasuje do Twojego przypadku i zaproponuje konkretne kroki naprawcze. (playground: PII maskowane, zero retencji):

Nie. RAG (wyszukiwanie na bazie wiedzy) działa dobrze przy kilkuset do kilku tysięcy dokumentach, jeśli są aktualne i spójne. Fine-tuning wymaga dużych zbiorów, ale większość projektów pierwszej fazy go nie potrzebuje. Kluczowy jest jakość i aktualność danych, nie ich ilość. Firma z 200 dobrymi dokumentami wyprodukuje lepszy system niż firma z 20 000 dokumentami, z których połowa jest nieaktualna lub sprzeczna. Audyt danych przed projektem opisuje artykuł o przygotowaniu danych firmowych pod AI.

Dla jednego, dobrze wybranego procesu: 6-10 tygodni od podpisania umowy do decyzji o przejściu do produkcji. Tydzień 1-2: audyt danych i projektu guardrails. Tygodnie 3-5: shadow mode. Tygodnie 6-8: pilot z human-gate i monitoring. Tygodnie 9-10: decyzja i ewentualne korekty. Projekty skracają się, gdy firma ma już przygotowane dane i zdefiniowany cel. Wydłużają się przy integracji z wieloma systemami lub braku dostępu do danych historycznych. Orientacyjny koszt pilota wylicza kalkulator ROI.

Sprawdź, czy proces kwalifikuje się jako system wysokiego ryzyka w rozumieniu AI Act Załącznik III. Dotyczy to obszarów: zatrudnienie (selekcja kandydatów, ocena pracowników), usługi finansowe (scoring kredytowy), edukacja, opieka zdrowotna i kilku innych. Dla takich systemów wymagane są: DPIA, dokumentacja techniczna, rejestr systemu w bazie UE, mechanizm nadzoru ludzkiego i przejrzystość wobec użytkowników. Szczegółowy opis obowiązków w 2026 roku zawiera artykuł AI Act i RODO 2026.

Cztery pytania kontrolne przed przejściem z pilota na produkcję: (1) Wskaźnik błędów na golden secie poniżej ustalonego progu? (2) Guardrails przetestowane na rzeczywistych przypadkach brzegowych, nie tylko syntetycznych? (3) Ścieżka eskalacji do człowieka działa i jest monitorowana? (4) Dane w bazie wiedzy aktualne i spójne z bieżącą ofertą lub procedurami? Dopiero gdy wszystkie cztery punkty są zielone, wdrożenie produkcyjne ma sens. Ocenę gotowości wspiera narzędzie ocena gotowości.

Tak, ale wymaga to diagnozy przyczyny, nie doklejania kolejnych funkcji. Najczęstsze naprawy: odświeżenie bazy wiedzy (gdy problem to dryft danych), dodanie warstwy guardrails i ścieżki „nie wiem" (gdy problem to niekontrolowane odpowiedzi), wdrożenie monitoringu golden set (gdy problem to brak widoczności). Projekty, które utknęły z powodu złego wyboru procesu, wymagają cofnięcia się do kroku wyboru i ewentualnego pilota na innym procesie. Pierwszym krokiem jest zawsze diagnoza, nie przepisywanie od zera. Napisz do nas przez kontakt z opisem sytuacji. Przeanalizujemy i zaproponujemy ścieżkę naprawczą.