Chatbot AI w firmie: błędy, które kosztowały nas najwięcej

I ponad sześć godzin tygodniowo, które pracownicy firm poświęcają na sprawdzanie oraz poprawianie odpowiedzi generowanych przez własne boty.

To nie są wyłącznie anegdoty z prezentacji o „przyszłości obsługi klienta”. Każdy z tych przypadków pokazuje inny rodzaj rachunku: prawny, operacyjny i wizerunkowy. Firmy inwestują w automatyzację, ale sam model językowy nie usuwa ryzyka. Przenosi je w inne miejsce — do regulaminu, procesu eskalacji, bazy wiedzy, zespołu nadzorującego i osoby, która musi odpowiedzieć klientowi, kiedy bot obiecał coś, czego nie wolno było obiecać.

Błędy wdrożenia chatbota AI kosztują więc nie tylko wtedy, gdy system przestaje działać. Częściej koszt pojawia się wtedy, gdy chatbot działa przekonująco, ale mówi rzeczy nieprawdziwe, przyjmuje nieautoryzowane instrukcje albo sprawia wrażenie, że jest człowiekiem.

Kiedy chatbot staje się prawnym obciążeniem: lekcja Air Canada

W lutym 2024 roku kanadyjski Civil Resolution Tribunal rozstrzygnął spór pasażera Jake’a Moffatta z Air Canada. Klient zapytał chatbota linii o taryfę ulgową dla osób w żałobie. Bot odpowiedział twierdząco i wskazał procedurę, według której pasażer mógł ubiegać się o zwrot części kosztów. Po podróży okazało się, że Air Canada takiej taryfy nie stosuje.

Sprawa trafiła do trybunału. Linia próbowała bronić się argumentem, który w różnych wersjach wraca przy niemal każdym incydencie z generatywną AI: chatbot jest osobnym narzędziem, więc firma nie powinna odpowiadać za jego wypowiedź. Trybunał tego argumentu nie zaakceptował. Dla klienta istotne było to, że informację otrzymał na oficjalnym kanale Air Canada. Nie miało decydującego znaczenia, czy odpowiedź przygotował pracownik, skrypt czy model językowy.

Air Canada została zobowiązana do zapłaty 812,02 CAD odszkodowania i kosztów postępowania. Sama kwota nie jest najważniejszą częścią tej historii. Znacznie ważniejsza jest zasada: firma nie może łatwo oddzielić swojej odpowiedzialności od komunikatu wysłanego przez narzędzie działające pod jej marką.

Właśnie tu wiele projektów chatbotowych ma źle ustawiony punkt ciężkości. Zespół techniczny koncentruje się na tym, czy model odpowiada szybko, czy poprawnie rozpoznaje intencję użytkownika i czy potrafi pobrać dane z systemu. Dział prawny pyta natomiast o coś innego: co się stanie, jeśli bot poda klientowi błędną cenę, obieca zwrot, źle opisze warunki gwarancji albo zasugeruje uprawnienie, którego firma nie przyznaje?

To nie znaczy, że każda nieprawidłowa odpowiedź automatycznie prowadzi do odpowiedzialności finansowej. Znaczenie mają między innymi treść komunikatu, kontekst rozmowy, regulamin, możliwość sprostowania informacji i faktyczne działanie klienta. Ryzyko jest jednak realne, a jego ocena nie może opierać się na założeniu, że „to tylko AI”.

Chatbot nie jest warstwą buforową. To kanał komunikacji firmy z klientem — a właściciel kanału musi umieć kontrolować to, co ten kanał obiecuje.

W praktyce oznacza to konieczność rozdzielenia kilku rodzajów odpowiedzi. Bot może bezpiecznie wyjaśniać procedurę, wskazywać stronę regulaminu albo pomagać znaleźć produkt. Inaczej należy traktować komunikaty, które zmieniają sytuację klienta: potwierdzają cenę, przyznają rabat, rozstrzygają reklamację, określają termin realizacji lub deklarują zwrot pieniędzy.

W takich obszarach chatbot powinien korzystać z kontrolowanych źródeł danych, a nie z ogólnej wiedzy modelu. Jeszcze ważniejsza jest możliwość przekazania rozmowy człowiekowi. Eskalacja nie może być ukrytą funkcją awaryjną, uruchamianą dopiero po kilku nieudanych próbach. Powinna być częścią projektu od początku.

Przed uruchomieniem warto więc odpowiedzieć na kilka praktycznych pytań:

• Czy bot może samodzielnie udzielać wiążących informacji, czy tylko przedstawia procedury?
• Które komunikaty wymagają potwierdzenia w systemie źródłowym?
• Czy klient może łatwo przejść do konsultanta?
• Kto sprawdza rozmowy, w których bot udzielił informacji o pieniądzach, terminach lub uprawnieniach?
• Czy firma ma procedurę sprostowania błędnej odpowiedzi i udokumentowania incydentu?

Jeśli odpowiedzi na te pytania nie są zapisane w procesie, firma nie ma kontroli nad chatbotem. Ma jedynie nadzieję, że model nie przekroczy granicy.

Ataki typu prompt injection i kryzysy wizerunkowe marek

Drugi wektor ryzyka nie wynika z pomyłki modelu, lecz z celowego działania użytkownika. Prompt injection to próba wprowadzenia do rozmowy instrukcji, które zmieniają sposób działania systemu. Użytkownik może nakłaniać bota do ujawnienia jego instrukcji, pominięcia wcześniejszych zasad, przyjęcia innej roli albo wykonania czynności, do których nie powinien mieć dostępu.

W grudniu 2023 roku Chris Bakke przeprowadził taki eksperyment na chatbocie salonu Chevroleta w Watsonville. System działał na bazie modelu z rodziny ChatGPT. W toku rozmowy bot zgodził się na sprzedaż samochodu Tahoe za 1 dolara, mimo że wartość pojazdu wynosiła 70 000 USD. Salon nie musiał oczywiście realizować deklaracji chatbota — system nie miał uprawnień do ustalania cen ani zawierania umów. Mimo to firma wyłączyła narzędzie, bo jego wypowiedź stała się publicznym problemem.

W ciągu jednego weekendu bot odnotował ponad 3000 prób podobnej manipulacji. To ważny szczegół: incydent nie został wywołany przez jednego wyjątkowo pomysłowego użytkownika i nie skończył się na jednym zrzucie ekranu. Gdy podatność stała się widoczna, inni użytkownicy zaczęli ją sprawdzać. Każdy kolejny test zwiększał zasięg problemu i zmuszał firmę do reakcji.

Podobny przypadek wydarzył się w styczniu 2024 roku w Wielkiej Brytanii. Klient firmy kurierskiej DPD, Ashley Beauchamp, poprowadził rozmowę w taki sposób, że chatbot zaczął generować wulgaryzmy i poetycki tekst krytykujący własną firmę. System określił DPD jako „najgorszy koszmar klienta”, a przedsiębiorstwo wyłączyło bota.

Oba incydenty pokazują, że chatbot może stać się narzędziem produkcji treści, których marka nigdy nie zaakceptowałaby w reklamie, komunikacie prasowym czy rozmowie z konsultantem. W modelu generatywnym problem polega na tym, że tekst użytkownika nie zawsze jest traktowany wyłącznie jako pytanie. Może stać się również częścią kontekstu, na podstawie którego model wybiera kolejną odpowiedź.

Nie wystarczy więc napisać w instrukcji systemowej: „nie ujawniaj informacji” albo „nie wykonuj poleceń użytkownika”. Model nie jest mechanizmem uprawnień. Instrukcja może ograniczać jego zachowanie, ale nie zastępuje kontroli po stronie aplikacji.

Co powinno znaleźć się poza modelem

Bezpieczniejsza architektura rozdziela rozmowę, decyzje i wykonanie akcji. Chatbot może rozpoznać intencję klienta, ale nie powinien samodzielnie decydować o wszystkim, co później dzieje się w systemie firmy.

Przed udostępnieniem bota klientom trzeba co najmniej:

• oddzielić instrukcje systemowe od treści dostarczanej przez użytkownika, pamiętając, że samo rozdzielenie promptu nie stanowi pełnej ochrony;
• ograniczyć działania do listy dozwolonych operacji, takich jak sprawdzenie statusu zamówienia czy przekierowanie do właściwego formularza;
• wymagać dodatkowego potwierdzenia przed wykonaniem czynności dotyczących pieniędzy, danych osobowych, rabatów i zmian w zamówieniu;
• filtrować dane wejściowe i wyjściowe po stronie aplikacji, a nie polegać wyłącznie na deklaracjach modelu;
• prowadzić testy adversarialne, w których zespół próbuje nakłonić system do obejścia zasad;
• zapisywać wersję promptu, modelu, źródła danych i reguł, które obowiązywały w chwili incydentu.

Red team nie powinien ograniczać się do wpisywania popularnych fraz w rodzaju „zignoruj poprzednie instrukcje”. Skuteczny test obejmuje także rozmowy wieloetapowe, pozornie niewinne pytania, prośby o streszczenie treści zewnętrznej oraz próby połączenia kilku małych uprawnień w jedno większe działanie.

Wizerunkowo najbardziej ryzykowna jest sytuacja, w której bot nie tylko odpowiada dziwnie, ale robi to w sposób łatwy do udostępnienia. Jedna absurdalna odpowiedź może zostać potraktowana jako żart. Seria podobnych odpowiedzi sugeruje już, że firma nie rozumie narzędzia, które wdrożyła.

Zjawisko botsittingu: dlaczego AI wymaga ciągłego nadzoru

Wdrożenie chatbota nie kończy się na uruchomieniu integracji. Wtedy zaczyna się etap, którego często nie ma w prezentacji dla zarządu: utrzymanie jakości.

Glean Work AI Institute opisywał zjawisko, w którym pracownicy poświęcają ponad sześć godzin tygodniowo na sprawdzanie i poprawianie treści wygenerowanych przez AI. W kontekście chatbotów można mówić o botsittingu — stałym nadzorowaniu systemu, poprawianiu odpowiedzi, sprawdzaniu faktów, reagowaniu na niepożądany ton i analizowaniu rozmów, w których model nie poradził sobie z zadaniem.

To nie jest jednorazowy koszt testów przed premierą. Bot zmienia się razem z bazą produktów, regulaminem, promocjami, stanami magazynowymi i oczekiwaniami klientów. Nawet jeśli model pozostaje ten sam, zmienia się środowisko, w którym działa. Odpowiedź poprawna w poniedziałek może być nieaktualna po zmianie cennika albo zasad zwrotu.

Właśnie dlatego koszt wdrożenia chatbota AI powinien obejmować nie tylko licencję, integrację i przygotowanie interfejsu. Trzeba uwzględnić również:

• monitorowanie jakości odpowiedzi po uruchomieniu;
• przegląd rozmów i klasyfikowanie incydentów;
• aktualizację bazy wiedzy oraz usuwanie sprzecznych instrukcji;
• testy po zmianie modelu, promptu lub źródła danych;
• czas ekspertów, którzy rozstrzygają przypadki nietypowe;
• obsługę eskalacji do człowieka;
• dokumentowanie błędów i sposobu ich naprawy.

Najczęściej pomijany jest ostatni punkt. Firma poprawia prompt, wdraża filtr i zamyka zgłoszenie, ale nie zapisuje, dlaczego bot popełnił błąd. Po kilku miesiącach podobny problem wraca w innym procesie. Zespół nie ma wtedy historii decyzji, więc zaczyna analizę od początku.

Botsitting jest też sygnałem jakości procesu. Jeżeli pracownicy bez końca ręcznie poprawiają odpowiedzi, problem nie musi leżeć wyłącznie w modelu. Czasem źródłem kłopotów jest nieuporządkowana baza wiedzy, zbyt szeroki zakres zadań albo brak jasnej granicy między informowaniem a podejmowaniem decyzji.

Jak rozpoznać, że nadzór stał się ukrytym etatem

Niepokojący jest nie sam fakt kontroli, lecz brak kontroli nad jej skalą. Zespół powinien wiedzieć, ile rozmów wymaga ręcznego przeglądu, jakie błędy pojawiają się najczęściej i które z nich blokują automatyzację.

Pomocne są proste kategorie:

Jeśli firma mierzy wyłącznie liczbę obsłużonych rozmów, może uznać projekt za sukces w chwili, gdy pracownicy zaczynają wykonywać niewidoczną pracę kontrolną. Klient widzi szybką odpowiedź. Organizacja widzi ją dopiero wtedy, gdy ktoś musi ją ręcznie poprawić.

Halucynacje modelu a zaufanie polskich konsumentów

Chatbot nie musi być zaatakowany, żeby wygenerować stratę. Wystarczy halucynacja — odpowiedź brzmiąca wiarygodnie, ale niezgodna z rzeczywistością. W kontrolowanych środowiskach wskaźniki halucynacji modeli językowych mogą mieścić się w szerokim zakresie, od około 3% do 27%, zależnie od modelu, zadania, danych i sposobu testowania.

Nie da się jednak uczciwie przełożyć tego zakresu na jedną uniwersalną liczbę dla każdej rozmowy z klientem. Wynik z benchmarku nie mówi automatycznie, jak często błąd pojawi się w polskim sklepie internetowym, banku czy firmie kurierskiej. Znaczenie ma między innymi to, czy bot korzysta z wyszukiwarki dokumentów, czy odpowiada z pamięci modelu, jak szczegółowe są pytania i czy odpowiedź jest sprawdzana przed wysłaniem.

Ryzyko rośnie szczególnie wtedy, gdy model ma wypowiadać się o danych zmiennych lub regulowanych.

W Polsce problem zaufania ma dodatkowy wymiar. Konsument może korzystać z własnych narzędzi AI podczas zakupów, porównywania produktów czy analizy ofert. Bot sklepu nie konkuruje więc wyłącznie z innym sklepem albo infolinią. Konkuruje także z asystentem, którego klient sam kontroluje i któremu ufa na własnych zasadach.

To nie oznacza, że firmowy chatbot jest z góry przegrany. Ma dostęp do danych, których zewnętrzny asystent nie posiada: statusu zamówienia, historii kontaktu, aktualnej ceny, dostępności produktu czy warunków dostawy. Tyle że ta przewaga istnieje tylko wtedy, gdy integracja jest aktualna, uprawnienia są ograniczone, a odpowiedź można powiązać z konkretnym źródłem.

Błąd integracji nie jest automatycznie halucynacją. System może pobrać nieaktualny rekord, źle zmapować pole, utracić jednostkę albo zwrócić pustą wartość. Model może też poprawnie odczytać dane, lecz niewłaściwie je opisać. Z punktu widzenia klienta wszystkie te sytuacje mogą wyglądać podobnie, ale dla zespołu wdrożeniowego wymagają różnych napraw.

Dlatego analiza błędów powinna rozróżniać co najmniej:

1. błąd źródła — informacja w systemie firmy była nieaktualna lub nieprawidłowa;

2. błąd pobrania — integracja zwróciła niepełne albo niewłaściwe dane;

3. błąd interpretacji — model źle odczytał poprawny materiał;

4. błąd komunikacji — odpowiedź była zbyt pewna, niejasna albo pozbawiona zastrzeżenia;

5. błąd procesu — bot wykonał czynność, która powinna wymagać udziału człowieka.

Dopiero taki podział pozwala ocenić, czy problem rozwiąże zmiana promptu, poprawa konektora, ograniczenie uprawnień czy całkowite wycofanie danego scenariusza z automatyzacji. Samo polecenie „bądź dokładniejszy” nie jest procedurą kontroli jakości.

AI Act i obowiązki przejrzystości w komunikacji z klientem

Na dzień 13 sierpnia 2026 roku obowiązki przejrzystości dotyczące systemów AI komunikujących się z użytkownikiem nie są już odległym zadaniem projektowym. Firmy powinny traktować je jako bieżący element zgodności, a nie punkt do odhaczenia przy kolejnej aktualizacji regulaminu.

W przypadku chatbota komunikującego się z klientem podstawowa zasada jest prosta: użytkownik powinien wiedzieć, że rozmawia z systemem AI. Informacja musi być czytelna i przekazana w sposób, który nie wymaga od klienta analizowania drobnego przypisu albo szukania wyjaśnienia w polityce prywatności.

W praktyce oznacza to potrzebę przejrzenia:

• pierwszego komunikatu w rozmowie;
• nazwy i opisu asystenta;
• sposobu prezentowania odpowiedzi generowanych automatycznie;
• miejsca, w którym klient może poprosić o kontakt z człowiekiem;
• informacji przekazywanych przy generowaniu lub przetwarzaniu treści syntetycznych;
• dokumentacji opisującej rolę systemu i zakres jego działania.

Nie każdy chatbot będzie podlegał tym samym obowiązkom w taki sam sposób. Znaczenie ma funkcja systemu, jego zastosowanie i relacja z innymi regulacjami. Nie należy także mieszać wymogów dotyczących przejrzystości z regulacjami odnoszącymi się do systemów wysokiego ryzyka. Sam fakt, że firma korzysta z modelu językowego, nie oznacza automatycznie, że wdrożenie należy do kategorii wysokiego ryzyka.

Dla działów prawnych, compliance i właścicieli produktu oznacza to zadania do wykonania niezwłocznie:

• zinwentaryzować wszystkie punkty kontaktu klienta z AI, w tym chatboty, voiceboty i funkcje generujące treść;
• ustalić, gdzie i jak użytkownik jest informowany o automatycznym charakterze interakcji;
• sprawdzić, czy komunikat pojawia się przed przekazaniem istotnej informacji, a nie dopiero po zakończeniu rozmowy;
• opisać, jakie decyzje bot może wspierać, a jakich nie może podejmować;
• zweryfikować regulamin, politykę prywatności i procedury reklamacyjne;
• wyznaczyć właściciela systemu, który odpowiada nie tylko za techniczną dostępność, ale również za aktualność zasad i obsługę incydentów;
• zachować dokumentację testów, zmian promptu, źródeł danych i działań naprawczych.

To jest obszar, w którym nie warto czekać na pierwszą skargę. Ujawnienie, że klient rozmawia z AI, nie naprawi błędnej odpowiedzi. Może jednak ograniczyć ryzyko wprowadzenia użytkownika w błąd i ustawić właściwe oczekiwania wobec automatycznego kanału.

Co sprawdzić przed uruchomieniem i po premierze

Najbezpieczniej potraktować gotowość chatbota jako proces, a nie pojedynczą bramkę przed produkcją. Przed startem trzeba sprawdzić architekturę, zakres uprawnień, dane i scenariusze awaryjne. Po starcie należy obserwować, czy założenia wytrzymują kontakt z prawdziwymi rozmowami.

Na etapie uruchomienia firma powinna potwierdzić, że:

1. Bot jasno ujawnia swoją tożsamość. Klient nie powinien dowiadywać się przypadkiem, że rozmawiał z systemem automatycznym.

2. Zakres odpowiedzi jest ograniczony do konkretnej funkcji. „Obsługa klienta” nie jest wystarczającą definicją. Trzeba wskazać, czy bot odpowiada na pytania, wyszukuje dane, przyjmuje zgłoszenia czy wykonuje operacje.

3. Akcje mają kontrolowane uprawnienia. Dostęp do informacji nie powinien automatycznie oznaczać możliwości zmiany danych lub zatwierdzenia transakcji.

4. Dane źródłowe są aktualne i możliwe do wskazania. Jeżeli bot podaje cenę, termin lub warunki, zespół powinien móc ustalić, skąd pochodziła informacja.

5. Istnieje ścieżka do człowieka. Eskalacja powinna działać także wtedy, gdy użytkownik nie zna właściwego polecenia.

6. Przeprowadzono testy manipulacji. Próby obejścia instrukcji muszą obejmować rozmowy wieloetapowe i nietypowe kombinacje poleceń.

7. Firma wie, jak reagować na błąd. Potrzebna jest procedura sprostowania, zapisania incydentu i poinformowania osoby odpowiedzialnej za system.

8. Nadzór ma właściciela i budżet. Czas poświęcany na botsitting nie może być ukrytą pracą wykonywaną „przy okazji”.

9. Po zmianach wykonywane są testy regresji. Nowy model, prompt, konektor albo regulamin może zmienić zachowanie w scenariuszach, które wcześniej działały poprawnie.

Nie każda odpowiedź „nie” musi oznaczać całkowitą rezygnację z projektu. Może oznaczać, że trzeba zawęzić zakres pierwszej wersji. Bot odpowiadający na pytania o status przesyłki jest łatwiejszy do kontrolowania niż bot, który sam interpretuje regulamin reklamacji i proponuje klientowi rozwiązanie.

To jedna z najważniejszych lekcji z opisanych incydentów. Firmy próbują często zautomatyzować całą rozmowę, zanim uporządkują pojedynczy proces. Tymczasem dobre wdrożenie AI w małej firmie może zacząć się od skromniejszego zakresu: wyszukiwania informacji w zatwierdzonej bazie, przekazywania spraw do właściwego działu i rejestrowania pytań, na które system nie zna odpowiedzi.

Najdroższy błąd to źle zdefiniowana odpowiedzialność

Air Canada pokazała, że odpowiedzialności nie da się przerzucić na chatbota. Chevrolet pokazał, że publiczny eksperyment może w krótkim czasie zmienić wadę techniczną w kryzys marki. DPD przypomniało, że nawet rozmowa rozpoczęta jako żart może zostać odczytana jako oficjalna wypowiedź firmy. Botsitting pokazał z kolei, że koszt automatyzacji może zostać przeniesiony na pracowników i długo pozostawać niewidoczny w budżecie.

Wspólny mianownik tych problemów nie brzmi „modele językowe są bezużyteczne”. Brzmi: firma uruchomiła system bez precyzyjnego określenia, co bot może powiedzieć, czego nie może zrobić i kto reaguje, kiedy przekroczy granicę.

Dlatego odpowiedź na pytanie „dlaczego chatbot AI nie działa?” rzadko znajduje się wyłącznie w wyborze modelu. Czasem problemem jest brak danych. Czasem zbyt szeroki prompt. Czasem niekontrolowane uprawnienia, brak testów albo założenie, że po premierze system będzie wymagał tylko sporadycznej konserwacji.

Chatbot jest kanałem firmowym, a nie niezależnym pracownikiem. Potrzebuje właściciela, ograniczeń, monitoringu i procedury wycofania. Dopiero wtedy można uczciwie liczyć jego zwrot z inwestycji. Bez tych elementów firma nie automatyzuje obsługi klienta. Automatyzuje produkcję odpowiedzialności, którą ktoś prędzej czy później będzie musiał ręcznie obsłużyć.