Tworzenie firmowych botów opartych na własnych dokumentach – jak zarabiać na chatbotach odpowiadających na podstawie instrukcji i procedur

Firmowy chatbot zaczyna mieć wartość dopiero wtedy, gdy potrafi odpowiedzieć na pytanie pracownika lub klienta na podstawie właściwej wersji instrukcji, regulaminu albo procedury — i potrafi odmówić odpowiedzi, gdy w dokumentach nie ma potrzebnej informacji. Sam dostęp do dużego modelu językowego nie rozwiązuje tego problemu.

To właśnie tutaj powstaje przestrzeń na usługę, którą można sprzedawać firmom. Nie chodzi o kolejną nakładkę na ChatGPT z logo klienta. Produktem jest kontrolowany system dostępu do firmowej wiedzy: dokumenty trafiają do indeksu, użytkownik zadaje pytanie naturalnym językiem, system wyszukuje odpowiednie fragmenty, a model formułuje odpowiedź wyłącznie na ich podstawie.

Dobrze zrobiony bot skraca czas szukania informacji w PDF-ach, SharePoint, Google Drive czy wewnętrznym intranecie. Źle zrobiony — z dużą pewnością siebie cytuje nieaktualną procedurę albo dopowiada brakujące zasady. I właśnie różnica między tymi dwoma rozwiązaniami decyduje, czy można pobierać za wdrożenie kilkanaście lub kilkadziesiąt tysięcy złotych, czy klient potraktuje projekt jak technologiczne demo.

Firmowy chatbot nie powinien „uczyć się PDF-ów”. Powinien umieć je wyszukiwać

W większości projektów opartych na instrukcjach, procedurach, regulaminach czy bazach wiedzy właściwym rozwiązaniem jest RAG — Retrieval-Augmented Generation, a nie trenowanie własnego modelu.

Mechanizm jest stosunkowo prosty:

1. Firma dostarcza dokumenty.
2. Dokumenty są dzielone na mniejsze fragmenty.
3. Fragmenty otrzymują reprezentacje wektorowe, czyli embeddingi.
4. Po zadaniu pytania system znajduje najbardziej pasujące fragmenty.
5. Dopiero te fragmenty są przekazywane do modelu językowego.
6. Model tworzy odpowiedź i — jeśli projekt tego wymaga — pokazuje nazwę dokumentu, rozdział albo wersję procedury.

To rozróżnienie ma znaczenie biznesowe. Fine-tuning nie jest dobrą metodą aktualizowania często zmieniającej się firmowej wiedzy. Jeżeli dział HR zmieni regulamin urlopowy w poniedziałek, nie chcesz trenować modelu ponownie. Chcesz podmienić dokument w bazie i przebudować indeks.

Sam proces techniczny też nie sprowadza się do wrzucenia katalogu PDF-ów do narzędzia typu „chat with documents”.

Pierwszy problem to jakość źródeł.

Jeśli firma ma pięć wersji tej samej instrukcji — „procedura_final.pdf”, „procedura_final2.pdf”, „procedura_NOWA.pdf”, „procedura_ostateczna.pdf” i dokument wysłany dwa lata temu mailem — chatbot odziedziczy ten bałagan. RAG nie naprawia zarządzania wiedzą. RAG bardzo szybko ujawnia, że firma nim nie zarządza.

Dlatego przed wdrożeniem trzeba ustalić co najmniej:

• kto jest właścicielem każdego dokumentu,
• która wersja jest aktualna,
• od kiedy obowiązuje,
• czy istnieje data wygaśnięcia,
• kto może zobaczyć dokument,
• czy dokument może być wykorzystywany przez wszystkich pracowników,
• które materiały są jedynie archiwalne.

W praktycznym wdrożeniu do każdego fragmentu dokumentu warto przypisać metadane takie jak nazwa źródła, numer wersji, data obowiązywania, właściciel dokumentu i grupa uprawnień. Dzięki temu wyszukiwarka nie tylko znajdzie podobny tekst, ale może również wykluczyć stare instrukcje i materiały, do których użytkownik nie ma prawa dostępu.

Drugim problemem jest dzielenie dokumentów.

Fragment zawierający dwa zdania bywa za krótki, ponieważ traci kontekst. Fragment obejmujący dziesięć stron instrukcji jest z kolei za duży i pogarsza trafność wyszukiwania. Dla typowych instrukcji tekstowych rozsądny punkt startowy to około 400–800 tokenów na fragment z niewielkim nakładaniem sąsiednich części, często rzędu 10–15%. Nie jest to uniwersalny parametr. Tabele techniczne, umowy, regulaminy i dokumentacja serwisowa wymagają innego podziału.

Jeszcze ważniejsze jest to, co dzieje się po wyszukiwaniu. Samo podobieństwo wektorowe nie daje gwarancji, że znaleziony fragment rzeczywiście odpowiada na pytanie. W bardziej wymagających systemach stosuje się więc wyszukiwanie hybrydowe, łączące embeddingi z wyszukiwaniem słów kluczowych, a następnie reranking wyników.

Praktyczny schemat może wyglądać tak:

pytanie → wyszukanie 10–20 kandydatów → reranking → wybór 4–8 najlepszych fragmentów → odpowiedź modelu.

Nie należy przy tym wciskać do promptu połowy firmowego archiwum tylko dlatego, że współczesny model ma duże okno kontekstowe. Więcej tekstu oznacza większy koszt, większe opóźnienie i więcej nieistotnych informacji, spośród których model musi wyłowić odpowiedź.

W system prompt warto natomiast wpisać twardą regułę:

jeżeli dostarczone materiały nie zawierają odpowiedzi, bot ma powiedzieć, że nie znalazł jej w firmowej bazie wiedzy — zamiast uzupełniać lukę wiedzą ogólną.

To jedna z najważniejszych różnic między chatbotem demonstracyjnym a produkcyjnym.

Przed uruchomieniem trzeba też zbudować zestaw testów. Nie pięć pytań zadanych przez właściciela projektu podczas prezentacji. Minimum to kilkadziesiąt realnych pytań z różnych działów; przy poważniejszym wdrożeniu sensownie jest przygotować 50–100 pytań referencyjnych razem z oczekiwaną odpowiedzią i właściwym dokumentem źródłowym.

Test powinien sprawdzać osobno:

• czy wyszukano właściwy dokument,
• czy odpowiedź jest zgodna ze źródłem,
• czy bot nie dodał informacji spoza źródła,
• czy poprawnie odmawia, gdy odpowiedzi nie ma,
• czy respektuje uprawnienia użytkownika,
• jak zachowuje się przy pytaniach niejednoznacznych.

Jeżeli system ma odpowiadać na pytania dotyczące bezpieczeństwa, finansów, HR lub procedur operacyjnych, sam wskaźnik „odpowiedź wygląda dobrze” jest bezwartościowy. Trzeba mierzyć zgodność ze źródłem.

Na czym faktycznie zarabia wykonawca takiego systemu

Koszt modelu językowego jest często najmniejszą częścią całego przedsięwzięcia. Klient płaci przede wszystkim za przygotowanie danych, integracje, kontrolę dostępu, testowanie, utrzymanie i odpowiedzialność za to, że system działa po zmianie dokumentów.

Dobrym przykładem są koszty API.

Przy aktualnej cenie GPT-5.4 mini wynoszącej 0,75 USD za milion tokenów wejściowych i 4,50 USD za milion tokenów wyjściowych obsłużenie 10 tys. pytań miesięcznie nie musi być drogie. Jeżeli pojedyncze zapytanie wraz z pobranymi fragmentami dokumentów zużywa średnio 2500 tokenów wejściowych i 300 tokenów odpowiedzi, otrzymujemy około:

• 25 mln tokenów wejściowych: 18,75 USD,
• 3 mln tokenów wyjściowych: 13,50 USD,
• łącznie: około 32,25 USD miesięcznie za samo przetwarzanie tekstu przez model.

Embeddingi są jeszcze tańsze. Dla przykładu text-embedding-3-small kosztuje obecnie 0,02 USD za milion tokenów. Jednorazowe przeliczenie nawet kilku milionów tokenów firmowych dokumentów nie jest więc pozycją, na której buduje się cenę wdrożenia.

Oczywiście rachunek produkcyjny obejmuje również bazę wektorową, hosting aplikacji, logowanie, monitoring, kopie zapasowe, ewentualny reranker, narzędzia administracyjne i integracje. Przy większym ruchu koszty rosną. Nadal jednak często okazuje się, że głównym kosztem nie jest AI, tylko stworzenie bezpiecznego produktu wokół AI.

Dlatego sprzedawanie usługi wyłącznie jako „podłączenie ChatGPT do dokumentów za 1500 zł” prowadzi do złego modelu biznesowego. Klient kupuje rozwiązanie tanio, a później przez miesiące zgłasza problemy z uprawnieniami, nowymi dokumentami i odpowiedziami, których wykonawca nie uwzględnił w wycenie.

Lepszy jest podział projektu na etapy.

Dla polskiej małej lub średniej firmy można przyjąć orientacyjne widełki:

• 8–20 tys. zł netto — ograniczony pilot: jeden przypadek użycia, kilkadziesiąt lub kilkaset dokumentów, prosty panel i jedna grupa użytkowników;
• 20–60 tys. zł netto — system produkcyjny z logowaniem, uprawnieniami, synchronizacją dokumentów, historią zapytań, monitoringiem i testami;
• 60–150 tys. zł netto i więcej — rozwiązanie obejmujące kilka działów, integracje z Microsoft 365, SharePoint, CRM lub systemami wewnętrznymi, rozbudowane role użytkowników, audyt oraz podwyższone wymagania bezpieczeństwa.

To nie jest cennik infrastruktury. To wycena usługi wdrożeniowej, dlatego projekt z 500 dobrze uporządkowanymi instrukcjami może być łatwiejszy niż projekt z 50 dokumentami pełnymi skanów, tabel, załączników i sprzecznych wersji.

Do tego dochodzi abonament.

Przy niewielkim wdrożeniu sensowny model utrzymania może wynosić około 1000–3000 zł netto miesięcznie. Przy systemach wymagających stałego monitoringu, aktualizacji integracji, obsługi kilku źródeł danych i raportowania częściej będzie to 3000–8000 zł miesięcznie albo więcej.

W abonamencie można zawrzeć między innymi:

• określoną liczbę użytkowników lub zapytań,
• koszty modeli do ustalonego limitu,
• automatyczną synchronizację dokumentów,
• monitoring błędnych odpowiedzi,
• miesięczny raport jakości,
• aktualizacje promptów i reguł,
• określoną liczbę godzin wsparcia.

Dzięki temu klient nie kupuje jednorazowego „bota”. Kupuje utrzymywany system firmowej wiedzy.

Najłatwiejszy do sprzedaży produkt jest zwykle branżowy. Zamiast oferować „chatbota AI dla każdej firmy”, lepiej zbudować rozwiązanie typu:

asystent procedur ISO dla zakładów produkcyjnych,
bot dla działu HR odpowiadający na podstawie regulaminów wewnętrznych,
asystent serwisanta korzystający z dokumentacji urządzeń,
wewnętrzna wyszukiwarka instrukcji dla sieci franczyzowej.

Powód jest prosty. Po kilku wdrożeniach w jednej branży powtarzają się integracje, struktury dokumentów, pytania użytkowników i mechanizmy testowania. Każdy kolejny projekt można wykonać szybciej, nie obniżając proporcjonalnie ceny.

Trzeba natomiast pilnować zakresu.

Jeżeli w umowie znajduje się zdanie „bot odpowiada na pytania dotyczące działalności firmy”, wykonawca praktycznie sam tworzy sobie nieograniczony backlog. Lepszy zakres brzmi: bot odpowiada na podstawie wskazanych repozytoriów i określonych kategorii dokumentów, dla konkretnych grup użytkowników oraz z jasno opisanymi sytuacjami, w których przekazuje pytanie człowiekowi.

Największą marżę daje standaryzacja. Największą stratę przynoszą nieograniczone wyjątki.

Bezpieczeństwo, RODO i AI Act mogą zabić projekt dopiero po udanym demo

Najbardziej irytujący moment w projektach firmowych przychodzi często po prezentacji. Bot działa świetnie. Zarząd jest zainteresowany. Dopiero wtedy ktoś pyta: „Czy pracownik magazynu będzie mógł zapytać go o dokumenty zarządu?”.

Jeżeli architektura nie została przygotowana pod kontrolę dostępu, odpowiedź może oznaczać przebudowę połowy rozwiązania.

Uprawnienia powinny działać przed wyszukiwaniem, a nie dopiero podczas generowania odpowiedzi. System nie powinien najpierw pobierać poufnych fragmentów, a później liczyć na to, że prompt zabroni modelowi ich ujawnienia.

Jeżeli użytkownik należy do grupy „Serwis”, wyszukiwarka powinna otrzymać wyłącznie dokumenty dostępne dla tej grupy. Informacja o uprawnieniach powinna znajdować się w metadanych indeksu albo wynikać bezpośrednio z systemu źródłowego.

To szczególnie istotne przy integracji z SharePoint czy Microsoft 365. Kopiowanie wszystkich plików do wspólnej bazy wektorowej bez zachowania istniejących ACL może stworzyć nową, niekontrolowaną drogę dostępu do informacji.

Drugi problem to dane osobowe.

Firmowa dokumentacja potrafi zawierać nazwiska pracowników, numery telefonów, adresy, informacje o absencjach, korespondencję, dane klientów czy treści umów. Sam fakt, że dokument znajduje się na firmowym dysku, nie oznacza automatycznie, że można bez dodatkowej analizy przesłać jego treść do dowolnego zewnętrznego API.

Przed uruchomieniem trzeba ustalić między innymi:

• jakie dane osobowe będą przetwarzane,
• w jakim celu,
• jaka jest podstawa prawna,
• kto jest administratorem, a kto podmiotem przetwarzającym,
• gdzie dane są przetwarzane,
• jak długo przechowywane są logi,
• czy dostawca wykorzystuje dane do trenowania modeli,
• jacy podwykonawcy uczestniczą w przetwarzaniu,
• czy potrzebna jest ocena skutków dla ochrony danych, czyli DPIA.

Uzasadniony interes może w określonych sytuacjach stanowić podstawę przetwarzania danych w systemach AI, ale nie działa jak automatyczna zgoda na wszystko. Trzeba wykazać cel, niezbędność przetwarzania oraz przeprowadzić test równowagi między interesem firmy a prawami osób, których dane dotyczą.

W systemie opartym na procedurach najrozsądniejszą zasadą pozostaje minimalizacja danych. Jeżeli do odpowiedzi na pytanie „jak zgłosić reklamację?” nie jest potrzebna tabela zawierająca nazwiska klientów, nie powinna trafiać do indeksu.

Trzeci temat to AI Act.

Od 2 sierpnia 2026 r. zasadnicza część unijnego AI Act jest już stosowana, a przepisy transparentności obejmują między innymi interaktywne systemy AI. Użytkownik chatbota powinien wiedzieć, że rozmawia z systemem AI, a nie z człowiekiem.

Najprostsze rozwiązanie nie wymaga długiej strony regulaminu przed pierwszym pytaniem. Interfejs może wyraźnie komunikować: „Odpowiedzi generuje system AI na podstawie firmowej bazy wiedzy” oraz pokazywać źródła wykorzystane do przygotowania odpowiedzi.

Firmy korzystające z AI mają również obowiązki związane z kompetencjami osób używających takich systemów. W praktyce oznacza to, że pracownikowi nie powinno się po prostu wysłać linku do bota z komunikatem „od jutra korzystamy”. Trzeba wyjaśnić przynajmniej jego przeznaczenie, ograniczenia, sposób zgłaszania błędów i sytuacje, w których odpowiedź wymaga potwierdzenia przez człowieka.

Szczególnie ostrożnie trzeba podchodzić do rozszerzania zwykłego bota wiedzy o funkcje decyzyjne.

Asystent HR odpowiadający na pytanie „ile dni wcześniej trzeba zgłosić urlop?” to zupełnie inny przypadek niż system, który ocenia kandydatów do pracy, klasyfikuje pracowników albo rekomenduje awanse. Wchodząc w takie zastosowania, wykonawca może wejść w obszar systemów wysokiego ryzyka i znacznie cięższych obowiązków regulacyjnych.

Dlatego na początku lepiej sprzedawać system, który odnajduje i wyjaśnia wiedzę, zamiast systemu, który podejmuje decyzje o ludziach.

Ostatnim zabezpieczeniem jest monitoring po wdrożeniu.

Trzeba zapisywać przynajmniej:

• pytanie użytkownika,
• dokumenty znalezione przez wyszukiwarkę,
• wersję dokumentu,
• odpowiedź systemu,
• informację o odmowie odpowiedzi,
• ocenę użytkownika,
• czas odpowiedzi i występujące błędy.

Nie chodzi o kolekcjonowanie logów bez końca. Okres przechowywania trzeba uzasadnić i ograniczyć. Bez historii interakcji nie da się jednak ustalić, dlaczego bot kilka dni wcześniej udzielił błędnej odpowiedzi.

Dobrze działa również mechanizm oznaczenia odpowiedzi jako „niepoprawna”, „niepełna” albo „nieaktualna”. Takie zgłoszenia powinny trafiać do właściciela bazy wiedzy, a nie tylko do programisty.

To ważna różnica. Programista może naprawić wyszukiwarkę. Nie może zdecydować, która z dwóch sprzecznych procedur jakości obowiązuje w fabryce.

FAQ

Czy do zbudowania firmowego chatbota trzeba trenować własny model?
Najczęściej nie. Przy procedurach, regulaminach i dokumentacji lepiej sprawdza się RAG, ponieważ pozwala aktualizować wiedzę przez zmianę dokumentów bez ponownego trenowania modelu.

Ile dokumentów potrzeba, żeby taki projekt miał sens?
Nie ma minimalnej liczby. Bot może mieć sens już przy kilkudziesięciu rozbudowanych instrukcjach, jeśli pracownicy regularnie tracą czas na ich przeszukiwanie. Tysiące źle opisanych dokumentów nie są przewagą — mogą wręcz pogorszyć wyniki.

Ile trwa wykonanie pierwszej działającej wersji?
Techniczny prototyp na uporządkowanych dokumentach można zbudować w kilka dni. Produkcyjne wdrożenie z analizą źródeł, testami, logowaniem, uprawnieniami i integracją zwykle wymaga kilku tygodni. Najczęściej opóźnia nie programowanie, lecz porządkowanie dokumentów i uzgadnianie dostępów.

Czy taki chatbot może odpowiadać bez błędów?
Nie. Żaden współczesny model generatywny nie daje gwarancji stuprocentowej poprawności. Można natomiast mocno ograniczyć ryzyko przez dobre wyszukiwanie, twarde reguły odpowiedzi, cytowanie dokumentów, testy oraz odmowę odpowiedzi przy niewystarczającym kontekście.

Czy klient musi płacić za każdy dokument dodany do systemu?
Nie ma takiej technicznej konieczności. Lepszym modelem biznesowym jest opłata za wdrożenie oraz utrzymanie systemu, a limity można wiązać z liczbą użytkowników, zapytań, repozytoriów albo zakresem integracji.

Czy można podłączyć bota bezpośrednio do SharePoint, Google Drive albo intranetu?
Tak, ale integracja powinna synchronizować nie tylko treść, lecz również status dokumentu i uprawnienia. Najgorszym skrótem jest skopiowanie całego repozytorium do jednej wspólnej bazy dostępnej dla każdego użytkownika chatbota.

Czy chatbot powinien korzystać również z internetu?
Jeżeli jego zadaniem jest odpowiadanie na podstawie procedur firmy — domyślnie nie. Włączenie wyszukiwania internetowego miesza kontrolowaną wiedzę wewnętrzną z materiałami zewnętrznymi i utrudnia ustalenie, dlaczego system udzielił konkretnej odpowiedzi. Dostęp do internetu warto dodawać jako osobną, jasno oznaczoną funkcję.

Co powinno być pierwszym płatnym produktem?
Nie „chatbot AI dla firm”. Znacznie łatwiej sprzedać wąskie rozwiązanie, na przykład asystenta procedur dla działu jakości, wyszukiwarkę dokumentacji dla serwisantów albo bota HR odpowiadającego na podstawie regulaminów. Zakres można później rozszerzyć.

Jeżeli masz rozpocząć taki biznes od jednej rzeczy, nie zaczynaj od wyboru modelu ani od budowania interfejsu. Weź od potencjalnego klienta 30–50 realnych pytań, na które jego pracownicy regularnie szukają odpowiedzi, oraz dokumenty zawierające prawidłowe odpowiedzi. Sprawdź, czy system potrafi odnaleźć właściwe źródło i poprawnie odmówić tam, gdzie odpowiedzi nie ma. Dopiero gdy ten test działa, wyceniaj integracje i miesięczne utrzymanie. Jeżeli test nie działa, popraw najpierw dokumenty i mechanizm wyszukiwania — droższy model językowy zwykle nie naprawi złej bazy wiedzy. Więcej informacji na: https://hd-biznes.com/blog