Budowa chatbota AI w 2026 roku: co trzeba zrobić, żeby chatbot naprawdę rozwiązywał sprawy klientów?

Dyrektorka obsługi klienta w sklepie internetowym ma budżet na chatbota i trzy prezentacje od dostawców. Wszystkie robią wrażenie: bot płynnie odpowiada na pytania o zwroty, dostawę i płatności, niezależnie od sformułowania. Sześć tygodni po uruchomieniu liczby wyglądają inaczej. Kontaktów z infolinią nie ubyło, bo klienci, którzy dostali pewną siebie, ale błędną odpowiedź o terminie zwrotu, i tak dzwonią — tyle że zirytowani. Jedna rozmowa, w której bot obiecał zwrot pieniędzy niezgodny z regulaminem, trafiła do mediów społecznościowych.

Problemem w tym projekcie nie był model. Problemem było wszystko wokół niego: na jakich dokumentach bot się opierał, co wolno mu było obiecać, kiedy miał przekazać rozmowę człowiekowi i skąd ktokolwiek miał wiedzieć, czy odpowiada poprawnie. Właśnie tam w 2026 roku odbywa się prawdziwa budowa chatbota — i tam powinna trafić większość budżetu.

Ten przewodnik jest dla CTO lub szefa obsługi klienta, który decyduje, czy i jak zbudować chatbota AI. Omawiamy typy chatbotów i to, kiedy każdy ma sens, architekturę produkcyjnego asystenta, wybór modelu, przeliczony przykład kosztu budowy i utrzymania, obowiązki regulacyjne, które w UE obowiązują od sierpnia 2026 roku, wskaźniki pokazujące, czy bot działa, oraz wybór partnera wdrożeniowego.

Co oznacza budowa chatbota w 2026 roku?

Słowo „chatbot” obejmuje dziś cztery różne rodzaje systemów. Mylenie ich to najczęstsze źródło rozjazdu oczekiwań między firmą a dostawcą.

Chatboty regułowe prowadzą użytkownika po drzewach decyzyjnych: przyciskach, menu i zaprojektowanych ścieżkach. Są przewidywalne, tanie w utrzymaniu i łatwe do audytu, ale obsługują tylko scenariusze, które ktoś wprost przewidział. Każde pytanie spoza drzewa kończy się komunikatem „Nie rozumiem”.

Chatboty oparte na intencjach (NLU) rozpoznają, czego chce użytkownik — „śledź zamówienie”, „zmień adres” — za pomocą klasyfikatora wytrenowanego na przykładowych wypowiedziach, a potem uruchamiają przygotowany scenariusz. To było dominujące podejście przed dużymi modelami językowymi, oparte na klasycznym przetwarzaniu języka naturalnego. Dobrze działa przy ograniczonym zestawie częstych spraw, ale każda nowa intencja wymaga danych treningowych i nowego scenariusza.

Chatboty LLM z wyszukiwaniem (RAG) rozumieją swobodny język i generują odpowiedzi na podstawie wiedzy firmy pobieranej w chwili pytania — regulaminów, danych produktowych, artykułów z centrum pomocy. Retrieval-augmented generation sprawia, że bot odpowiada na podstawie Twoich dokumentów, a nie tego, co model zapamiętał z treningu. To domyślna architektura asystentów dla klientów w 2026 roku.

Chatboty agentowe z narzędziami idą krok dalej: oprócz odpowiadania — działają. Sprawdzają status zamówienia w systemie OMS, zmieniają termin dostawy, otwierają zwrot, wydają kupon w ustalonych limitach. Technicznie oznacza to, że model może wywoływać funkcje lub API, coraz częściej przez standardy takie jak Model Context Protocol. To też miejsce, w którym najbardziej zmienia się profil ryzyka: bot, który tylko rozmawia, może wprowadzić w błąd; bot, który działa, może też popełnić kosztowny błąd.

Gartner przewidział w marcu 2025 roku, że do 2029 roku agentowa sztuczna inteligencja będzie samodzielnie rozwiązywać 80% typowych spraw w obsłudze klienta, obniżając koszty operacyjne o 30%. Niezależnie od tego, czy ta data się utrzyma, kierunek jest jasny: wartość chatbota coraz częściej wynika z tego, co potrafi zrobić, a nie tylko powiedzieć.

Jakiego typu chatbota potrzebuje Twój przypadek użycia?

Właściwy typ zależy od trzech pytań: jak zróżnicowane są pytania klientów, czy odpowiedzi da się wziąć z dokumentów i czy bot ma cokolwiek zmieniać w Twoich systemach.

Przypadek użycia	Rekomendowany typ	Dlaczego
Kilka stałych procesów (rezerwacja, prosty status)	Regułowy lub NLU	Przewidywalny, tani, łatwy do certyfikacji; LLM dodaje ryzyko bez wartości
Pytania o regulaminy i FAQ zadawane na wiele sposobów	LLM + RAG	Obsługuje różne sformułowania; odpowiedzi oparte na aktualnych dokumentach
Pytania wymagające danych klienta (zamówienie, faktura, umowa)	LLM + RAG + narzędzia tylko do odczytu	Potrzebny uwierzytelniony dostęp do danych, bez operacji zapisu
Działania: zwroty, zmiana terminu, anulowanie, drobne rekompensaty	Agentowy z narzędziami i limitami	Realna automatyzacja pracy; wymaga reguł autoryzacji, limitów i audytu
Asystent wewnętrzny (HR, helpdesk IT, wsparcie sprzedaży)	LLM + RAG, czasem agentowy	Mniejsze ryzyko wizerunkowe, większa tolerancja na niedoskonałe odpowiedzi
Doradztwo regulowane (kredyty, ubezpieczenia, zdrowie)	Hybryda: scenariusz regułowy, LLM tylko do języka	Decyzje muszą wynikać z reguł; model ma tłumaczyć, a nie decydować

Z projektów wynikają dwie praktyczne obserwacje. Po pierwsze, większość firm nie potrzebuje jednego typu, tylko połączenia kilku. Dobrze zaprojektowany asystent używa deterministycznych scenariuszy dla nielicznych procesów, w których pomyłka jest droga, i LLM dla długiego ogona pytań. Po drugie, opłaca się zacząć od dostępu tylko do odczytu. Bot, który sprawdza zamówienie, ale go nie modyfikuje, daje większość wartości w pierwszych miesiącach, a zespół w tym czasie uczy się, jak klienci naprawdę z nim rozmawiają.

Jak wygląda architektura produkcyjnego chatbota AI?

Chatbot na prezentacji to prompt, model i okno czatu. Produkcyjny asystent ma co najmniej osiem komponentów, a większość pracy inżynierskiej trafia do tych, których na prezentacji nie widać.

1. Kanały. Widżet na stronie, aplikacja mobilna, WhatsApp, Messenger, e-mail, głos. Każdy kanał ma własne ograniczenia długości wiadomości, formatowania i uwierzytelniania.
2. Warstwa orkiestracji. Logika decydująca, co dzieje się z każdą wiadomością: klasyfikacja, wybór ścieżki deterministycznej lub LLM, wywołanie narzędzi, zabezpieczenia i decyzja o eskalacji.
3. Model. Jeden lub kilka dużych modeli językowych, często tańszy do klasyfikacji i routingu, a mocniejszy do złożonych odpowiedzi.
4. Wiedza i wyszukiwanie. Wczytywanie dokumentów, dzielenie na fragmenty, embeddingi, indeks wektorowy lub hybrydowy i — najczęściej zaniedbywany element — proces utrzymywania treści w aktualności. Bot odpowiadający na podstawie zeszłorocznego regulaminu zwrotów jest gorszy niż brak bota.
5. Narzędzia i integracje. API systemów OMS, CRM, billingu czy zgłoszeń, z uwierzytelnianiem, uprawnieniami i limitami tego, co bot może zrobić.
6. Zabezpieczenia (guardrails). Filtrowanie wejścia (prompt injection, nadużycia, pytania spoza zakresu), kontrola wyjścia (odpowiedzi bez źródła, niedozwolone zobowiązania, wycieki danych osobowych) i granice tematyczne.
7. Przekazanie do człowieka. Eskalacja do konsultanta z pełną historią rozmowy i podsumowaniem, tak żeby klient nie musiał wszystkiego powtarzać.
8. Obserwowalność i ewaluacja. Logowanie rozmów, pobranych źródeł i wywołań narzędzi; automatyczna ocena na zestawie testowym; dashboardy jakości, kosztów i eskalacji.

Komponenty 4, 6, 7 i 8 decydują o tym, czy chatbotowi da się zaufać. Jeśli oferta dostawcy szczegółowo opisuje model, a utrzymaniu wiedzy i ewaluacji poświęca jedną linijkę, oferta jest niekompletna. Szerzej o kosztach utrzymania danych, na których opiera się każdy system AI, pisaliśmy w artykule prawdziwy koszt AI to utrzymanie jakości danych.

Jak wybrać model: komercyjne API czy model otwarty?

Wybór modelu ma dziś mniejsze znaczenie niż dwa lata temu, bo różnica między czołowymi modelami w typowych zadaniach obsługi klienta się zmniejszyła, a ceny mocno spadły. Nadal ma jednak trzy konsekwencje: koszt, kontrolę nad danymi i nakład pracy operacyjnej.

Komercyjne API (OpenAI, Anthropic, Google i inni) dają najmocniejsze modele bez utrzymywania infrastruktury. Rozliczenie następuje za milion tokenów, osobno za wejście i wyjście. Według zestawień cenników z września 2026 roku rynek dzieli się na trzy poziomy: modele flagowe za ok. 4–10 USD za milion tokenów wejściowych i 20–50 USD za milion wyjściowych, modele średniej klasy za ok. 2 USD i 10 USD oraz modele ekonomiczne od ok. 0,10–0,30 USD na wejściu i 0,40–2,50 USD na wyjściu. Ceny zmieniają się kilka razy w roku, więc traktuj je jako rząd wielkości i sprawdzaj aktualne cenniki przed budżetowaniem.

Modele otwarte (open-weight) działają na własnej infrastrukturze lub w prywatnej chmurze. Dają pełną kontrolę nad danymi i brak opłat za tokeny, ale płacisz za GPU, utrzymanie i zespół, który to obsługuje. Dla większości firm z kilkudziesięcioma tysiącami rozmów miesięcznie API wychodzi taniej w całkowitym koszcie. Własny hosting zaczyna mieć sens przy bardzo dużych wolumenach, ścisłych wymaganiach co do lokalizacji danych albo tam, gdzie model musi działać on-premise.

W Polsce warto wiedzieć o dwóch rodzimych rodzinach modeli otwartych. Bielik, rozwijany przez fundację SpeakLeash we współpracy z ACK Cyfronet AGH, ma wersje od 1,5 do 11 mld parametrów, a wersja 3 wprowadziła tokenizer zoptymalizowany pod język polski. PLLuM, rozwijany w ramach wspieranej przez państwo inicjatywy polskich instytucji naukowych, ma wersje od 4 do 70 mld parametrów. Dla asystentów wewnętrznych w instytucjach publicznych czy firmach, które nie mogą wysyłać danych do zewnętrznych API, to realna alternatywa. W zastosowaniach dla klientów przewaga dużych komercyjnych modeli w rozumowaniu i obsłudze narzędzi nadal jest zwykle odczuwalna — decyzję warto podjąć na podstawie własnego zestawu testowego, a nie deklaracji.

Trzy praktyczne zasady obowiązują niezależnie od dostawcy:

• Używaj więcej niż jednego modelu. Kierowanie prostych pytań i klasyfikacji do modelu ekonomicznego, a tylko złożonych odpowiedzi do mocniejszego, zwykle znacząco obniża koszt tokenów bez widocznego spadku jakości.
• Korzystaj z cache’owania promptów. Prompt systemowy i duża część pobranego kontekstu powtarzają się między rozmowami; dostawcy obsługujący cache pobierają za nie ułamek ceny.
• Zachowaj możliwość wymiany modelu. Warstwa abstrakcji i własny zestaw testowy pozwalają zmienić model, gdy pojawi się lepszy lub tańszy — a przy obecnym tempie dzieje się to co kilka miesięcy.

Szersze porównanie narzędzi AI dla biznesu znajdziesz w artykule o alternatywach dla ChatGPT.

Jak język polski i wielojęzyczność wpływają na projekt chatbota?

Większość materiałów o budowie chatbotów powstaje z perspektywy języka angielskiego. W polskim projekcie — a tym bardziej w firmie obsługującej klientów w kilku krajach — pojawia się kilka kwestii, które zmieniają zarówno koszt, jak i jakość.

Tokeny kosztują więcej w języku polskim. Ogólne tokenizery dzielą polskie słowa, z ich odmianą i znakami diakrytycznymi, na więcej tokenów niż angielskie. To właśnie ten problem rozwiązywał dedykowany polski tokenizer w trzeciej wersji Bielika. Przy komercyjnych API oznacza to, że ta sama rozmowa po polsku zużyje więcej tokenów niż po angielsku, a efektywne okno kontekstu jest krótsze. W budżecie warto to uwzględnić, mierząc zużycie na prawdziwych polskich rozmowach, a nie przenosząc założeń z anglojęzycznych przykładów.

Klienci piszą niedbale. W czatach dominują wiadomości bez polskich znaków, z literówkami, skrótami i mieszaniem języków. Wyszukiwanie oparte wyłącznie na dopasowaniu słów kluczowych radzi sobie z tym słabo; wyszukiwanie semantyczne z embeddingami wielojęzycznymi — znacznie lepiej. Zestaw ewaluacyjny powinien zawierać takie wiadomości, a nie tylko poprawnie sformułowane pytania przygotowane przez zespół projektowy.

Odmiana utrudnia reguły. Deterministyczne zabezpieczenia, które w języku angielskim sprawdzają obecność konkretnych fraz, po polsku muszą uwzględniać odmianę — „zwrot”, „zwrotu”, „zwrotem”, „zwróćcie”. Lepiej sprawdzają się kontrole oparte na klasyfikacji intencji i na tym, czy odpowiedź zawiera zobowiązanie potwierdzone przez narzędzie, niż listy zakazanych słów.

Jedna prawda w wielu językach. Firma obsługująca klientów w kilku krajach musi zdecydować, czy bot odpowiada na podstawie dokumentów w każdym języku osobno, czy na podstawie jednej wersji źródłowej z tłumaczeniem. Pierwsza opcja daje naturalniejsze odpowiedzi, ale grozi rozjazdem treści między krajami; druga zapewnia spójność kosztem jakości języka. W praktyce najlepiej działa jedna wersja źródłowa regulaminów i polityk plus lokalne artykuły pomocy, z automatycznym sprawdzaniem, czy odpowiedzi w różnych językach na to samo pytanie są zgodne co do faktów.

Każdy język to osobny zestaw testów. Model, który świetnie radzi sobie po angielsku, może gorzej działać po polsku, czesku czy rumuńsku. Wyniki ewaluacji trzeba raportować osobno dla każdego języka, a decyzję o uruchomieniu kolejnego kraju podejmować na podstawie jego własnych wyników.

Ile kosztuje budowa i utrzymanie chatbota AI?

Uczciwa odpowiedź zależy od zakresu, dlatego policzyliśmy jeden konkretny przykład z jawnymi założeniami. Projekt: asystent obsługi klienta LLM + RAG dla sklepu internetowego, z dostępem tylko do odczytu do statusu zamówień, integracją z systemem zgłoszeń do przekazywania rozmów, widżetem na stronie i procesem ewaluacji.

Budowa — 12 tygodni. Stawki seniorów są zgodne z naszym benchmarkiem stawek body leasingu na 2026 rok; stawki QA i analityka to nasze założenie.

Rola	Stawka (zł/h)	Zaangażowanie	Koszt
Senior AI/ML engineer	290	100%	139 200 zł
Senior backend developer	220	100%	105 600 zł
QA engineer (mid)	140	50%	33 600 zł
Analityk biznesowy / kierownik projektu	200	30%	28 800 zł
Razem budowa			307 200 zł

Utrzymanie — miesięcznie. Założenia: 20 000 rozmów miesięcznie, po sześć wymian każda, ok. 4000 tokenów wejściowych na wymianę (prompt systemowy, pobrany kontekst i historia) i 300 tokenów wyjściowych, model średniej klasy za 2 USD / 10 USD za milion tokenów, kurs 3,70 zł za dolara.

Pozycja	Koszt miesięczny
Tokeny modelu (480 mln wejściowych, 36 mln wyjściowych)	1320 USD ≈ 4884 zł
Infrastruktura: indeks wektorowy, hosting, logowanie (założenie)	800 USD ≈ 2960 zł
Utrzymanie i ewaluacja: 0,25 etatu po 250 zł/h	10 500 zł
Razem utrzymanie	ok. 18 344 zł

To ok. 0,92 zł za rozmowę. Warto zauważyć dwie rzeczy. Po pierwsze, tokeny to tylko ok. jedna czwarta kosztu utrzymania; największą pozycją są ludzie, którzy utrzymują aktualność wiedzy i mierzą jakość. Przy cache’owaniu 60% tokenów wejściowych rachunek za tokeny spada z 1320 do ok. 800 USD. Po drugie, wybór modelu zmienia sumę mniej, niż podpowiada intuicja: model ekonomiczny kosztowałby ok. 230 USD miesięcznie, flagowy ok. 6600 USD. Różnica jest realna, ale o ekonomice projektu decyduje to, czy bot rozwiązuje sprawy — o czym w kolejnej sekcji. Ścieżkę od prototypu do budżetu produkcyjnego opisaliśmy szerzej w artykule o koszcie wdrożenia AI od PoC do produkcji.

Kiedy chatbot się zwraca?

Chatbot zarabia na rozmowach, które rozwiązuje, a które inaczej wymagałyby człowieka. Żeby pokazać mechanikę, przyjmijmy pełny koszt 10 zł za czat obsłużony przez konsultanta (na przykład 60 zł za godzinę i sześć czatów na godzinę — podstaw własną liczbę).

Odsetek rozmów rozwiązanych przez bota	Uniknięty koszt konsultantów / mies.	Oszczędność netto / mies.	Zwrot kosztu budowy
30%	60 000 zł	41 656 zł	7,4 mies.
50%	100 000 zł	81 656 zł	3,8 mies.
70%	140 000 zł	121 656 zł	2,5 mies.

Na papierze uzasadnienie jest mocne już przy 30%. W praktyce cały ciężar spoczywa na słowie „rozwiązanych”. Rozmowa zamknięta przez bota błędną odpowiedzią nie jest oszczędnością: wraca jako telefon, reklamacja albo utracony klient.

Klarna to najlepiej udokumentowany przykład obu stron tego zjawiska. W lutym 2024 roku firma ogłosiła, że jej asystent AI obsłużył w pierwszym miesiącu 2,3 mln rozmów — dwie trzecie czatów obsługi klienta, równowartość pracy 700 konsultantów na pełny etat — przy satysfakcji porównywalnej z ludźmi. W maju 2025 roku prezes firmy przyznał, że koszt był „zbyt dominującym kryterium oceny”, a efektem była niższa jakość. Klarna zaczęła ponownie zatrudniać konsultantów i zagwarantowała klientom możliwość rozmowy z człowiekiem. Wniosek nie brzmi „chatboty nie działają” — Klarna nadal używa asystenta na dużą skalę — tylko: uzasadnienie biznesowe trzeba budować na jakości rozwiązania spraw, a nie na wolumenie.

Tę samą lekcję widać w szerszej skali w projektach agentowych, o których pisaliśmy w analizie strategii AI w przedsiębiorstwach i odsetka nieudanych projektów agentowych.

Jak sprawić, żeby chatbot nie zmyślał?

Modele językowe generują wiarygodnie brzmiący tekst; nie wiedzą, czy jest prawdziwy. W obsłudze klienta to nie jest ryzyko teoretyczne. W sprawie Moffatt przeciwko Air Canada (2024) chatbot linii lotniczej poinformował klienta, że może ubiegać się o taryfę żałobną wstecznie — wbrew stronie z zasadami tej samej firmy. Trybunał rozstrzygania sporów cywilnych Kolumbii Brytyjskiej uznał odpowiedzialność Air Canada za niedbałe wprowadzenie w błąd, zasądził 650,88 dolarów kanadyjskich odszkodowania wraz z odsetkami i opłatami i odrzucił argument, że chatbot jest odrębnym podmiotem odpowiadającym za własne działania. Kwota była niewielka; zasada — nie: firma odpowiada za to, co mówi jej bot.

Ograniczenie tego ryzyka wymaga kilku warstw, z których żadna nie wystarcza sama:

• Ugruntowanie w źródłach. Bot odpowiada tylko na podstawie pobranych źródeł i je wskazuje. Jeśli wyszukiwanie nie znajdzie nic trafnego, właściwa odpowiedź brzmi „Nie wiem — połączę Cię z konsultantem”, a nie improwizacja.
• Właściciele wiedzy. Każdy dokument źródłowy ma właściciela i datę przeglądu. Większość błędnych odpowiedzi, które widzimy na produkcji, wynika z nieaktualnych lub sprzecznych dokumentów, a nie z tego, że model coś wymyślił.
• Zabezpieczenia zobowiązań. Bot nie może obiecywać zwrotów, rabatów, terminów ani wyjątków, jeśli nie potwierdzi ich narzędzie. Sprawdza się to na wyjściu, regułami deterministycznymi, a nie wyłącznie instrukcją w prompcie.
• Granice zakresu. Pytania spoza zdefiniowanej dziedziny — porady prawne, medyczne, pytania o konkurencję — bot uprzejmie odrzuca albo przekazuje dalej.
• Obrona przed prompt injection. Użytkownicy będą próbowali skłonić bota do zignorowania instrukcji. Filtrowanie wejścia, oddzielenie instrukcji od pobranych treści i minimalne uprawnienia narzędzi ograniczają szkody, gdy im się uda.
• Ciągła ewaluacja. Zestaw testowy prawdziwych pytań z zatwierdzonymi odpowiedziami, uruchamiany przy każdej zmianie modelu, promptu lub bazy wiedzy, oraz cotygodniowy przegląd próbki rzeczywistych rozmów przez ludzi.

Dobry prompt engineering pomaga, ale prompt nie jest mechanizmem kontrolnym. Wszystko, co nie może się wydarzyć, wymaga sprawdzenia poza modelem.

Czego AI Act wymaga od chatbotów od sierpnia 2026 roku?

Unijny akt o sztucznej inteligencji (rozporządzenie (UE) 2024/1689) wchodzi w życie etapami. Dla chatbotów rozmawiających z klientami kluczową datą był 2 sierpnia 2026 roku, kiedy zaczęły być stosowane obowiązki przejrzystości z art. 50. Pakiet Digital Omnibus przesunął obowiązki dla systemów AI wysokiego ryzyka na grudzień 2027 roku, ale art. 50 nie został przesunięty.

W praktyce oznacza to:

• Informację o AI. Dostawcy muszą projektować systemy AI przeznaczone do bezpośredniej interakcji z ludźmi tak, żeby ci ludzie wiedzieli, że rozmawiają z AI, chyba że wynika to jasno z kontekstu. Dla chatbota standardowym rozwiązaniem jest wyraźny komunikat na początku rozmowy.
• Oznaczanie generowanych treści. Systemy generujące syntetyczny tekst, dźwięk, obraz lub wideo muszą oznaczać wyniki w formacie odczytywalnym maszynowo. Systemy generatywne wprowadzone na rynek przed 2 sierpnia 2026 roku dostały na ten wymóg czas do 2 grudnia 2026 roku.
• Kary. Naruszenie tych obowiązków może skutkować karą do 15 mln euro lub 3% światowego rocznego obrotu, zależnie od tego, która kwota jest wyższa.

Chatbot podlega znacznie cięższym obowiązkom, jeśli jest używany w obszarze wysokiego ryzyka wymienionym w rozporządzeniu — na przykład przy ocenie zdolności kredytowej lub dostępu do usług podstawowych. Jeśli Twój asystent podejmuje takie decyzje lub istotnie na nie wpływa, architekturę trzeba projektować pod reżim wysokiego ryzyka od początku, mimo późniejszego terminu.

Równolegle obowiązuje RODO. Zapisy rozmów to dane osobowe, często zawierające szczegóły zamówień, adresy czy reklamacje dotyczące zdrowia. Potrzebujesz podstawy prawnej i okresu przechowywania transkrypcji, umowy powierzenia przetwarzania z dostawcą modelu, weryfikacji, gdzie dane są przetwarzane (w tym transferów poza EOG), i decyzji, czy rozmowy mogą służyć do ulepszania modelu. W większości komercyjnych API plany biznesowe domyślnie nie trenują na danych klientów, ale trzeba to potwierdzić w umowie. Warto też uwzględnić rozmowy w rejestrze czynności przetwarzania i ocenić, czy nie jest potrzebna ocena skutków dla ochrony danych — zwłaszcza gdy bot ma dostęp do danych klientów w systemach firmy.

Kiedy chatbot powinien przekazać rozmowę człowiekowi?

Ograniczenie projektowe wyznaczają nastawienia klientów. W badaniu Gartnera przeprowadzonym na 5728 klientach i opublikowanym w lipcu 2024 roku 64% respondentów stwierdziło, że wolałoby, żeby firmy nie używały AI w obsłudze klienta, a główną obawą było to, że trudniej będzie dotrzeć do człowieka. Chatbot, który ukrywa możliwość rozmowy z konsultantem, nie tylko irytuje — potwierdza obawę, która odstrasza klientów od tego kanału.

Dobre zaprojektowanie przekazania rozmowy opiera się na kilku zasadach:

• Opcja kontaktu z człowiekiem jest zawsze widoczna. Nie jako nagroda za wytrwałość, tylko jako normalny element interfejsu.
• Wyzwalacze eskalacji są jawne. Niska pewność wyszukiwania, wielokrotne przeformułowywanie pytania przez klienta, negatywny wydźwięk, określone tematy (reklamacje, rezygnacje, klienci w trudnej sytuacji) i każda prośba, której bot nie jest upoważniony spełnić.
• Kontekst idzie razem z klientem. Konsultant dostaje transkrypcję, podsumowanie, pobrane źródła i tożsamość klienta, więc rozmowa jest kontynuowana, a nie zaczynana od nowa.
• Godziny pracy są komunikowane uczciwie. Poza godzinami pracy konsultantów bot informuje, kiedy odpowie człowiek, i tworzy zgłoszenie, zamiast udawać, że rozwiąże wszystko.
• Eskalacje są źródłem nauki. Każde przekazanie ma oznaczony powód. Najczęstsze powody pokazują, gdzie w następnej kolejności dodać wiedzę, narzędzia lub reguły.

Przekazanie rozmowy nie jest miarą porażki. Bot, który szybko i z pełnym kontekstem eskaluje właściwe 30% rozmów, często daje wyższą satysfakcję klientów i niższy koszt całkowity niż bot, który próbuje zatrzymać 80% i myli się w co czwartej.

Które wskaźniki pokazują, czy chatbot działa?

Jedna liczba nie opisze chatbota. Poniższe wskaźniki mają sens tylko razem, bo każdy z osobna da się „podkręcić”.

• Containment rate — odsetek rozmów zakończonych bez człowieka. Łatwy do zmierzenia i łatwy do zawyżenia: bot, który utrudnia eskalację, ma wysoki wynik.
• Odsetek rozwiązanych spraw — udział rozmów, w których sprawa klienta faktycznie została rozwiązana; mierzony potwierdzeniem, brakiem ponownego kontaktu w ustalonym czasie (np. siedmiu dni) lub przeglądem próbki.
• Odsetek ponownych kontaktów — ilu klientów wraca innym kanałem z tą samą sprawą. To wskaźnik, który ujawnia pozorny containment.
• Deflection — spadek liczby kontaktów w innych kanałach (telefon, e-mail) po uruchomieniu, w porównaniu z okresem bazowym. Pokazuje efekt biznesowy, ale wymaga ostrożnego uwzględnienia sezonowości.
• CSAT po rozmowach z botem — krótkie pytanie na końcu, porównane z CSAT rozmów z konsultantami na podobne tematy.
• Jakość eskalacji — ile czasu konsultant potrzebuje po przejęciu rozmowy i czy podsumowanie było wystarczające.
• Trafność odpowiedzi na zestawie testowym — odsetek poprawnych, ugruntowanych w źródłach odpowiedzi w automatycznej ewaluacji, śledzony przy każdym wydaniu.
• Koszt rozwiązanej rozmowy — całkowity koszt utrzymania podzielony przez rozwiązane rozmowy, a nie przez wszystkie.

Na potrzeby zespołu warto dodać czas odpowiedzi, odsetek błędów wywołań narzędzi i udział odpowiedzi bez źródła. Dla zarządu zwykle wystarczą trzy liczby: odsetek rozwiązanych spraw, koszt rozwiązanej rozmowy i CSAT w porównaniu z obsługą przez ludzi.

Jak krok po kroku wygląda proces budowy chatbota?

Projekty, które się udają, przechodzą przez podobną sekwencję, a najczęściej pomijane kroki to właśnie te, które decydują o sukcesie.

1. Discovery (2–3 tygodnie). Analiza prawdziwych rozmów z ostatnich miesięcy: najczęstsze intencje, ich udział w wolumenie, które wymagają danych lub działań, a które są ryzykowne. Zdefiniowanie, czego bot nie będzie robił. Ustalenie docelowych wskaźników.
2. Audyt wiedzy. Inwentaryzacja dokumentów, na których bot ma się opierać, przypisanie właścicieli, usunięcie sprzeczności i nieaktualnych wersji. Z naszego doświadczenia ten krok często trwa dłużej niż budowa samego mechanizmu wyszukiwania.
3. Zestaw ewaluacyjny. Zanim powstaną prompty — kilkaset prawdziwych pytań z zatwierdzonymi odpowiedziami i oczekiwanym zachowaniem, łącznie z pytaniami, które bot powinien odrzucić lub eskalować.
4. Prototyp. Budowa podstawowego przepływu RAG i pomiar na zestawie ewaluacyjnym. Iteracje nad wyszukiwaniem, promptami i wyborem modelu na podstawie liczb, a nie wrażeń.
5. Integracje i zabezpieczenia. Dodanie narzędzi tylko do odczytu, przekazywania do systemu zgłoszeń, kontroli wyjścia i testów bezpieczeństwa, w tym prób prompt injection.
6. Pilotaż. Uruchomienie dla ograniczonej części ruchu lub jednego kanału, z codziennym przeglądem rozmów i szybką ścieżką uzupełniania luk w wiedzy.
7. Wdrożenie. Zwiększanie ruchu w miarę stabilizacji wskaźników rozwiązanych spraw i ponownych kontaktów; operacje zapisu dopiero po tym, jak wersja tylko do odczytu okaże się niezawodna.
8. Utrzymanie. Cotygodniowy przegląd próbek i eskalacji, comiesięczne przebiegi ewaluacji, proces utrzymania wiedzy i pozycja w budżecie na zespół, który o to dba.

W naszym przykładzie kroki 1–6 mieszczą się w 12 tygodniach budowy, a krok 8 to 0,25 etatu w kosztach utrzymania. Budżetowanie wyłącznie budowy to najczęstszy powód, dla którego chatboty tracą jakość w ciągu roku.

Jak wybrać partnera do budowy chatbota?

Rynek usług budowy chatbotów jest zatłoczony: dostawcy platform, agencje, integratorzy i freelancerzy używają tych samych słów. Poniższe kryteria oddzielają partnerów, którzy prowadzili asystentów na produkcji, od tych, którzy budowali prezentacje.

Kryterium	Jak wygląda mocna odpowiedź	Sygnał ostrzegawczy
Ewaluacja	Pokazuje zestaw ewaluacyjny, wskaźniki i zmiany wyników między iteracjami w poprzednich projektach	„Testujemy ręcznie przed uruchomieniem”
Utrzymanie wiedzy	Proponuje proces, właścicieli i narzędzia do aktualizacji treści	Baza wiedzy jako jednorazowy import
Zabezpieczenia	Opisuje deterministyczne kontrole zobowiązań, danych osobowych i zakresu	„Prompt mówi modelowi, żeby tego nie robił”
Przekazanie do człowieka	Projektuje wyzwalacze eskalacji i przekazanie kontekstu do Twojego systemu zgłoszeń	Eskalacja „w kolejnej fazie”
Strategia modeli	Niezależność od modelu, routing i plan wymiany	Przywiązanie do jednego modelu lub własnej platformy
Bezpieczeństwo	Testuje prompt injection, minimalne uprawnienia narzędzi, logowanie	Brak wzmianki o prompt injection
Zgodność	Obejmuje informację z art. 50 AI Act, retencję zgodną z RODO i umowy powierzenia z dostawcami modeli	Zgodność w całości po stronie klienta
Przejrzystość kosztów	Oddziela w ofercie budowę, tokeny, infrastrukturę i utrzymanie	Jedna cena ryczałtowa bez szacunku kosztów utrzymania
Wskaźniki	Zobowiązuje się do odsetka rozwiązanych spraw i ponownych kontaktów, nie tylko containmentu	Sukces zdefiniowany jako „liczba rozmów”
Własność	Należą do Ciebie prompty, zestawy ewaluacyjne, integracje i dane	Wszystko zamknięte w zastrzeżonej platformie

Oceń każde kryterium w skali 0–2. Partner z wynikiem poniżej 12 na 20 prawdopodobnie dostarczy dobrą prezentację i trudny pierwszy rok.

Najważniejsze wnioski:

1. Dobieraj typ chatbota do przypadku użycia. Scenariusze deterministyczne tam, gdzie pomyłki są drogie, LLM + RAG dla długiego ogona pytań, działania agentowe dopiero po sprawdzeniu wersji tylko do odczytu.
2. Większość pracy dzieje się wokół modelu. Utrzymanie wiedzy, zabezpieczenia, przekazanie do człowieka i ewaluacja decydują o tym, czy bot budzi zaufanie.
3. Tokeny nie są główną pozycją kosztu utrzymania. W naszym przykładzie to ok. jedna czwarta miesięcznego rachunku; największą pozycją są ludzie dbający o jakość.
4. Mierz rozwiązane sprawy, nie containment. Zwrot Klarny pokazuje, co się dzieje, gdy w ocenie dominują wolumen i koszt.
5. Firma odpowiada za swojego bota. Sprawa Air Canada i obowiązki przejrzystości z AI Act od sierpnia 2026 roku mówią to wprost.

W ARDURA Consulting od ponad 10 lat budujemy oprogramowanie dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA, a dziś wiele z tych projektów obejmuje komponenty LLM — od wewnętrznych asystentów wiedzy po chatboty obsługi klienta zintegrowane z istniejącymi systemami. W ramach software developmentu budujemy chatboty, które zaczynają się od danych z prawdziwych rozmów, są oceniane na podstawie liczb i pozostają własnością klienta, niezależnie od modelu, na którym działają.

Jeśli planujesz chatbota i chcesz sprawdzić zakres, architekturę lub budżet przed wyborem dostawcy, porozmawiaj z naszym zespołem. Przeanalizujemy Twój przypadek użycia, oszacujemy koszt budowy i utrzymania i wskażemy, gdzie chatbot się zwróci — a gdzie nie.