Tworzenie chatbotów i systemów AI – szkolenia RAG dla firm w Cognity z dofinansowaniem KFS

1. Chatbot firmowy vs system RAG: co naprawdę budujemy

W projektach AI w organizacjach słowo „chatbot” bywa używane jako skrót myślowy na bardzo różne rozwiązania: od prostego asystenta odpowiadającego według z góry ustalonego scenariusza, po system, który potrafi syntetyzować odpowiedzi na podstawie aktualnych dokumentów i wiedzy rozproszonej w wielu repozytoriach. Dla świadomego startu kluczowe jest precyzyjne nazwanie celu: czy budujemy interfejs konwersacyjny (kanał kontaktu i obsługi), czy budujemy system dostępu do wiedzy i jej uwiarygodnionego użycia w odpowiedziach.

Chatbot firmowy w klasycznym ujęciu to warstwa dialogu z logiką biznesową: prowadzi użytkownika przez proces, zbiera dane, uruchamia akcje (np. zgłoszenie, rezerwację, status zamówienia) i często korzysta z ograniczonego, kontrolowanego zestawu odpowiedzi. Może wspierać pracowników i klientów, ale jego „inteligencja” bywa w praktyce pochodną dobrze zaprojektowanych reguł, intencji, formularzy i integracji. W takich wdrożeniach ryzyko halucynacji modelu językowego jest wtórne wobec ryzyk procesowych: błędów w przepływach, niejednoznacznych polityk odpowiedzi czy braku spójności w kanałach.

System RAG (Retrieval-Augmented Generation) to z kolei architektura, w której model językowy generuje odpowiedź, ale najpierw pobiera (retrieval) najbardziej pasujące fragmenty wiedzy z wybranych źródeł, a dopiero potem na ich podstawie tworzy wynik. W efekcie „produktem” nie jest sam czat, lecz powtarzalny mechanizm pracy z wiedzą organizacji: wyszukiwanie semantyczne, selekcja kontekstu i generowanie odpowiedzi z odwołaniem do źródeł. To podejście jest szczególnie istotne tam, gdzie treści szybko się zmieniają (procedury, oferty, polityki), a odpowiedzi muszą być możliwe do uzasadnienia i weryfikacji.

W praktyce rynkowej obserwujemy, że najczęstsze rozczarowania wynikają nie z jakości modelu językowego, lecz z niedoprecyzowania tego, „co ma umieć” rozwiązanie i na jakiej wiedzy ma się opierać. Jeżeli celem jest rzetelna obsługa pytań o polityki, regulaminy, instrukcje, umowy czy bazę produktową, wtedy samo „podpięcie czatu do LLM” jest niewystarczające. Potrzebna jest architektura RAG, która w kontrolowany sposób podaje modelowi właściwy kontekst i ogranicza odpowiedzi do tego, co wynika z zatwierdzonych materiałów.

Różnicę warto zrozumieć jako rozdzielenie dwóch warstw: doświadczenia użytkownika (rozmowa) i mechanizmu wiarygodnej odpowiedzi (dostęp do wiedzy). Często najlepszym rozwiązaniem jest ich połączenie: chatbot jako kanał i interfejs, a RAG jako „silnik wiedzy”. Jednak już na etapie planowania należy zdecydować, które elementy są kluczowe biznesowo, ponieważ determinują one zarówno zakres prac, jak i kryteria sukcesu.

• Chatbot firmowy odpowiada przede wszystkim za prowadzenie dialogu i realizację procesów (nawigacja po usługach, zgłoszenia, integracje), a wiedza bywa ograniczona lub upraszczana dla przewidywalności.
• System RAG odpowiada za wyszukiwanie i podawanie modelowi właściwej, aktualnej wiedzy z dokumentów i repozytoriów, aby generowanie było oparte na źródłach, a nie na „pamięci” modelu.
• Chatbot z RAG łączy obie perspektywy: ma ergonomiczny interfejs konwersacyjny, ale jakość odpowiedzi zależy od zaprojektowanego mechanizmu dostępu do wiedzy.

W kontekście szkoleń wdrożeniowych szczególnie ważne jest właściwe ustawienie oczekiwań interesariuszy: RAG nie jest „magiczną funkcją”, lecz podejściem inżynierskim, które wymaga dyscypliny w pracy z wiedzą firmową oraz zrozumienia, jak model językowy wykorzystuje kontekst. Na tym etapie rekomendujemy traktować definicję rozwiązania jako decyzję architektoniczną i organizacyjną: określa ona, czy inwestujemy w automatyzację rozmowy, czy w systemowe uporządkowanie i bezpieczne udostępnienie wiedzy w formie odpowiedzi generowanych przez AI.

2. Przypadki użycia i wymagania: zakres wiedzy, kanały, SLA

W praktyce projektowej najczęstszym źródłem niepowodzeń wdrożeń chatbotów i systemów RAG nie jest dobór modelu, lecz nieprecyzyjne zdefiniowanie przypadku użycia i wymagań operacyjnych. RAG wymaga jasnej odpowiedzi na trzy pytania: jaka wiedza ma być obsługiwana, w jakich kanałach użytkownicy będą zadawać pytania oraz jaki poziom dostępności i czasu reakcji jest wymagany (SLA). Dopiero te ustalenia pozwalają realnie oszacować nakład pracy, ryzyka oraz kryteria akceptacji rozwiązania.

Przypadki użycia warto formułować jako konkretne „job stories” lub scenariusze z mierzalnym efektem: skrócenie czasu odnalezienia procedury, odciążenie helpdesku, ujednolicenie odpowiedzi w obszarze HR czy przyspieszenie pracy sprzedaży na bazie aktualnych ofert i warunków handlowych. Rekomendujemy zaczynać od obszarów o wysokiej powtarzalności pytań, stabilnych dokumentach i jednoznacznych regułach odpowiedzi. Natomiast obszary silnie sporne, uznaniowe lub wymagające interpretacji prawnej mogą wymagać dodatkowych zabezpieczeń (np. obowiązkowej eskalacji do człowieka), co powinno wynikać z definicji zastosowania, a nie być „dopisywane” na końcu.

Zakres wiedzy jest decyzją biznesowo-techniczną, ponieważ determinuje zarówno jakość odpowiedzi, jak i koszty utrzymania. W RAG kluczowe jest ustalenie, czy asystent ma działać na wiedzy „zamkniętej” (np. polityki, procedury, instrukcje), czy również na treściach dynamicznych (np. oferty, cenniki, statusy spraw). Równie istotne jest rozdzielenie wiedzy globalnej (wspólnej dla całej organizacji) od wiedzy zespołowej i wrażliwej, która musi podlegać kontroli dostępu. W naszej ocenie już na etapie planowania należy jednoznacznie zdefiniować: właścicieli treści, częstotliwość zmian oraz granice odpowiedzialności systemu (kiedy odpowiada, a kiedy odmawia lub eskaluje).

Kanały dostępu wpływają na projekt interakcji i wymagania niefunkcjonalne. Inne oczekiwania będą wobec asystenta w intranecie czy w narzędziu komunikacyjnym, a inne w systemie zgłoszeń lub na stronie publicznej. Kanał determinuje m.in. sposób uwierzytelniania, kontekst użytkownika, długość wypowiedzi, konieczność zachowania historii rozmowy oraz to, czy odpowiedź ma mieć formę krótkiej porady, czy cytatu z dokumentu z odnośnikiem do źródła. Warto też z góry założyć obsługę mechanizmów „handoff” do konsultanta lub tworzenia zgłoszenia, jeżeli proces biznesowy wymaga ścieżki formalnej.

SLA dla asystenta opartego o RAG należy definiować praktycznie, z rozróżnieniem na wymagania użytkownika i wymagania operacyjne IT. Najczęściej dotyczy to dostępności usługi, czasu odpowiedzi dla typowego zapytania, limitów obciążenia, okien serwisowych oraz procedur reagowania na incydenty. Dla zastosowań wewnętrznych SLA bywa mniej rygorystyczne, ale w krytycznych procesach (np. obsługa zgłoszeń lub wsparcie operacyjne) nawet kilkusekundowe opóźnienia czy niedostępność mogą generować koszty. Rekomendujemy również zdefiniowanie SLA „jakościowego” jako zestawu minimalnych wymagań: obowiązek podawania źródeł, zasady odpowiedzi przy braku pewności oraz sposób postępowania przy treściach nieaktualnych.

Aby uporządkować wymagania na etapie przygotowania, w organizacjach najczęściej sprawdza się podział na cztery obszary:

• Zakres i granice wiedzy: tematy wspierane, typy dokumentów, języki, właściciele treści, częstotliwość zmian, zasady „nie odpowiadamy/eskalujemy”.
• Kanały i kontekst użytkownika: miejsce użycia, uwierzytelnianie, personalizacja odpowiedzi, integracje z narzędziami pracy oraz sposób przekazywania spraw do człowieka.
• Wymagania wydajnościowe i SLA: dostępność, czasy odpowiedzi, obciążenie, monitoring oraz procedury obsługi awarii.
• Kryteria akceptacji: mierzalny efekt biznesowy, minimalna jakość odpowiedzi, wymagany poziom cytowania źródeł i zgodność z zasadami komunikacji w firmie.

Na tym etapie warto także rozróżnić rozwiązania „asystenckie” od „decyzyjnych”. W wielu firmach celem jest przyspieszenie dostępu do wiedzy i standaryzacja informacji, a nie automatyczne podejmowanie decyzji procesowych. Takie rozgraniczenie ogranicza ryzyka operacyjne i przyspiesza wdrożenie, ponieważ system RAG może dostarczać odpowiedzi z uzasadnieniem i odwołaniem do źródeł, pozostawiając decyzję użytkownikowi lub procesowi zatwierdzania.

W projektach szkoleniowych realizowanych przez Cognity te ustalenia traktujemy jako fundament prac warsztatowych: doprecyzowanie przypadków użycia, granic odpowiedzialności i wymagań SLA pozwala zespołom wejść w budowę rozwiązań RAG w sposób kontrolowany, z czytelnymi kryteriami „co oznacza, że to działa” i bez kosztownych zmian kierunku w późniejszym etapie.

3. Pipeline danych: źródła, czyszczenie, chunking, metadane, aktualizacja

W podejściu RAG jakość odpowiedzi jest wprost pochodną jakości pipeline’u danych. W praktyce nie „dokładamy dokumentów do chatbota”, tylko projektujemy powtarzalny proces: od identyfikacji źródeł, przez standaryzację i oczyszczenie treści, po podział na fragmenty (chunking), opis metadanymi oraz regularną aktualizację indeksu. Ten etap przesądza o tym, czy system będzie wyszukiwał właściwe konteksty, czy też będzie produkował odpowiedzi oparte na przypadkowych, niepełnych lub nieaktualnych fragmentach.

Źródła danych w firmie rzadko są jednorodne. Najczęściej obejmują instrukcje i procedury (np. PDF/DOCX), bazy wiedzy i wiki, artykuły intranetowe, zgłoszenia i odpowiedzi z systemów helpdesk, treści z CRM/ERP, a także zasoby udostępniane w SharePoint lub dyskach sieciowych. Z perspektywy RAG kluczowe jest nie tylko „skąd”, ale również „kto jest właścicielem treści” oraz „jak wygląda cykl życia dokumentu” (wersjonowanie, zatwierdzanie, daty obowiązywania). Bez tego retrieval może zwracać poprawne, ale nieobowiązujące już informacje.

Czyszczenie i normalizacja danych to etap, na którym usuwa się szum i wprowadza spójność. W praktyce obserwujemy problemy wynikające z artefaktów OCR, nagłówków i stopek powielanych na każdej stronie, tabel „posypanych” w ekstrakcji, mieszanego kodowania znaków, a także zduplikowanych wersji dokumentów krążących w organizacji. Czyszczenie powinno obejmować także ujednolicenie języka i nazewnictwa (np. skróty, identyfikatory produktów, nazwy formularzy), aby te same pojęcia były wyszukiwalne w przewidywalny sposób. Istotnym elementem jest również wyodrębnienie części, które nie powinny zasilać bazy RAG (np. treści archiwalne lub fragmenty bez wartości informacyjnej, jak stopki prawne, jeśli utrudniają trafność).

Chunking, czyli dzielenie treści na fragmenty indeksowane w wyszukiwarce, wymaga kompromisu między „kontekstem” a „precyzją”. Zbyt duże fragmenty zwiększają ryzyko, że system dobierze kontekst zawierający wątki poboczne i trudniej będzie z niego wygenerować jednoznaczną odpowiedź. Zbyt małe fragmenty powodują utratę zależności (np. definicja bez warunków, procedura bez wyjątków) i obniżają trafność. W podejściu specjalistycznym rekomendujemy projektować chunking pod typ dokumentu: inaczej dla instrukcji krok po kroku, inaczej dla polityk i regulaminów, a inaczej dla FAQ. Niezależnie od strategii, spójność podziału oraz możliwość odtworzenia fragmentu w oryginalnym kontekście (np. numer rozdziału, sekcja, strona) ma krytyczne znaczenie dla jakości odpowiedzi i dla późniejszego audytu.

Metadane są warstwą sterującą wyszukiwaniem i kontrolą dostępu oraz podstawą do filtrowania wyników. Dobrze zaprojektowane metadane pozwalają ograniczyć retrieval do właściwego obszaru wiedzy (np. dział, produkt, rynek, język), ułatwiają obsługę wersji (data publikacji, status obowiązywania, numer wersji) oraz wspierają wyjaśnialność (źródło, ścieżka do dokumentu, sekcja). W pipeline warto od początku zdefiniować minimalny standard metadanych oraz reguły jego nadawania, ponieważ późniejsze „dopisywanie” metadanych do już zindeksowanej bazy jest kosztowne i zazwyczaj wymaga reindeksacji.

• Metadane biznesowe: obszar merytoryczny, właściciel treści, proces, produkt/usługa, jednostka organizacyjna, rynek/język.

• Metadane jakości i wersjonowania: data publikacji i ważności, status (roboczy/obowiązujący/archiwalny), wersja, źródło prawdy (system nadrzędny).

• Metadane techniczne i śledzenie pochodzenia: typ pliku, identyfikator dokumentu, lokalizacja, identyfikator fragmentu (chunk id), sekcja/strona, sygnatura ekstrakcji.

Aktualizacja bazy RAG nie powinna być traktowana jako jednorazowa czynność „na wdrożeniu”. W organizacjach, gdzie procedury i oferty zmieniają się dynamicznie, brak odświeżania indeksu szybko prowadzi do spadku użyteczności systemu i utraty zaufania użytkowników. Dlatego pipeline powinien obejmować harmonogram aktualizacji (np. cykliczny lub zdarzeniowy), mechanizmy wykrywania zmian i duplikatów oraz reguły postępowania z dokumentami wycofanymi. Krytyczne jest również zarządzanie wersjami tak, aby system preferował treści aktualne i obowiązujące, a jednocześnie zachował możliwość audytu historycznych źródeł, jeśli jest to wymagane przez procesy firmy.

W praktyce szkoleniowej Cognity ten etap realizujemy warsztatowo: uczestnicy pracują na reprezentatywnych zbiorach dokumentów, definiują standard metadanych i zasady chunkingu, a następnie weryfikują, czy wynikowy zasób jest „retrieval-ready”, czyli nadaje się do przewidywalnego wyszukiwania i bezpiecznego użycia w środowisku firmowym. Dzięki temu organizacja zyskuje nie tylko koncepcję, ale także uzgodnione reguły operacyjne, które można utrzymać w dłuższym horyzoncie.

4. Retrieval i generowanie: indeksy wektorowe, reranking, prompt templates

W architekturze RAG kluczowy moment „spotkania” wiedzy organizacji z modelem językowym zachodzi w dwóch krokach: retrieval (wyszukiwanie kontekstu) oraz generation (wygenerowanie odpowiedzi w oparciu o kontekst). W praktyce jakość systemu zależy nie tyle od samego LLM, ile od tego, czy właściwe fragmenty dokumentów zostaną odnalezione, uporządkowane i przekazane do modelu w czytelnej, kontrolowanej formie.

Indeksy wektorowe służą do semantycznego wyszukiwania treści. Dokumenty (a dokładniej: ich fragmenty) są zamieniane na wektory osadzeń (embeddings), które reprezentują znaczenie tekstu. Zapytanie użytkownika również jest osadzane w tej samej przestrzeni, a wyszukiwarka zwraca fragmenty „najbliższe” znaczeniowo. Taki mechanizm jest odporny na parafrazy i różne sformułowania tego samego problemu, co ma bezpośrednie znaczenie w środowiskach firmowych, gdzie pytania rzadko są zadawane w sposób zgodny z językiem procedur.

Dobór indeksu i konfiguracji retrieval to nie tylko wybór technologii, ale przede wszystkim decyzje o parametrach, które wpływają na precyzję i kompletność wyników. W praktyce obserwujemy typowe napięcie między recall (czy system „złapie” właściwy kontekst) a precision (czy nie dostarczy zbyt wielu nieistotnych fragmentów). Na tym etapie ważne jest też, czy system ma wspierać wyszukiwanie hybrydowe (łączące semantykę z klasycznym dopasowaniem leksykalnym), oraz jak wykorzystuje metadane do zawężania wyników do właściwych źródeł i zakresów.

Reranking jest warstwą poprawiającą trafność zestawu kontekstu dostarczanego do LLM. Pierwszy etap wyszukiwania wektorowego jest zwykle zoptymalizowany pod szybkość i zwraca kandydatów (np. top-k fragmentów). Reranker (często model typu cross-encoder lub wyspecjalizowany komponent rankingowy) dokonuje ponownej oceny par zapytanie–fragment i układa wyniki w kolejności najbardziej użytecznej do odpowiedzi. Dzięki temu system rzadziej „karmi” model przypadkowo podobnym, lecz nieadekwatnym kontekstem, co redukuje halucynacje i poprawia spójność odpowiedzi w zastosowaniach operacyjnych.

W implementacjach firmowych reranking jest szczególnie istotny, gdy baza wiedzy zawiera dokumenty o zbliżonej terminologii (np. procedury w kilku wersjach, polityki dla różnych jednostek organizacyjnych, podobne instrukcje dla wielu produktów). W takich warunkach samo podobieństwo semantyczne bywa niewystarczające, a o jakości decyduje umiejętność poprawnego rozróżnienia „który fragment jest właściwy w tym kontekście biznesowym”.

Prompt templates porządkują sposób, w jaki model ma korzystać z dostarczonego kontekstu oraz jaką formę ma przyjąć odpowiedź. W RAG prompt nie jest jednorazowym poleceniem, tylko kontrolowaną „ramą” obejmującą instrukcje, ograniczenia, format wyjścia i zasady cytowania źródeł. Dobrze zaprojektowany szablon minimalizuje przypadkowość generacji i ujednolica zachowanie chatbota w różnych scenariuszach, co jest krytyczne w środowiskach, gdzie liczą się przewidywalność i zgodność z politykami organizacji.

W praktyce prompt templates powinny jasno rozstrzygać, czy model ma odpowiadać wyłącznie na podstawie dostarczonych fragmentów, jak ma postępować przy braku danych (np. poprosić o doprecyzowanie lub wskazać brak podstaw w źródłach), oraz w jakiej strukturze ma zwracać wynik (np. instrukcja krok po kroku, odpowiedź krótka + uzasadnienie, sekcja „Źródła”). Istotnym elementem jest także sposób wstawiania kontekstu: jego kolejność, delimitery i limity długości wpływają na to, czy model poprawnie odczyta priorytety i nie pominie kluczowego fragmentu.

W naszej ocenie warto traktować retrieval, reranking i prompt jako spójny mechanizm sterowania jakością, a nie trzy niezależne elementy. Najczęstsze problemy w działaniu RAG wynikają z „niedopasowania” tych warstw: poprawne wyniki wyszukiwania mogą zostać osłabione przez nieprecyzyjny szablon promptu, a dobry prompt nie zrekompensuje słabego rankingu kontekstu. Dlatego w szkoleniach i warsztatach RAG nacisk kładziemy na praktyczne strojenie całego przepływu, z naciskiem na to, aby model otrzymywał możliwie najbardziej relewantne, jednoznaczne i użyteczne fragmenty.

• Wektorowy retrieval odpowiada za znalezienie semantycznie pasujących fragmentów wiedzy, nawet gdy zapytanie jest parafrazą lub zawiera skróty branżowe.
• Reranking porządkuje i „doczyszcza” zestaw kandydatów tak, aby do modelu trafiał kontekst najbardziej adekwatny do pytania i sytuacji.
• Prompt templates nadają reguły korzystania z kontekstu i stabilizują format odpowiedzi, ograniczając niepożądane „dopowiadanie” poza źródłami.

5. Ewaluacja jakości: testy, zestawy pytań, metryki, human review

W systemach RAG jakość nie jest cechą „ustawioną raz na zawsze” – wynika z interakcji danych, wyszukiwania i generowania. Dlatego ewaluację warto zaprojektować jako stały proces, w którym mierzymy zarówno to, czy model odpowiada, jak i na jakiej podstawie odpowiada (pokrycie źródeł, zgodność z dokumentami, styl zgodny z polityką komunikacji). W praktyce obserwujemy, że organizacje, które wcześnie wdrażają testy i cykliczny przegląd jakości, znacząco szybciej osiągają stabilne wyniki oraz ograniczają ryzyko „pozornie dobrych” odpowiedzi bez oparcia w wiedzy firmowej.

Punktem wyjścia są zestawy pytań testowych (tzw. eval set) zbudowane na rzeczywistych potrzebach użytkowników i przypadkach brzegowych. Taki zbiór powinien zawierać pytania o wysokiej wartości biznesowej (procedury, produkty, zasady, SLA), ale również pytania „trudne”: wieloznaczne, przekrojowe, z wymaganiem doprecyzowania, oraz takie, na które system powinien odmówić odpowiedzi lub przekierować użytkownika. Istotne jest też wersjonowanie: wraz ze zmianami w dokumentach i konfiguracji retrieval zestaw pytań powinien być aktualizowany, aby testy nadal odzwierciedlały bieżący stan wiedzy i ryzyk.

Rekomendujemy rozdzielenie ewaluacji na dwa poziomy: ocenę jakości wyszukiwania (retrieval) oraz ocenę jakości odpowiedzi (generation). To rozdzielenie pozwala trafnie diagnozować źródło problemów: czy system nie znajduje właściwych fragmentów, czy znajduje, ale nie potrafi ich poprawnie wykorzystać. Dodatkowo w środowiskach firmowych kluczowe bywa mierzenie zachowania polityk: odpowiedzi w dozwolonym zakresie, zgodność tonu, unikanie spekulacji i właściwe informowanie o brakach w danych.

• Metryki retrieval: odsetek przypadków, w których właściwy fragment znalazł się w TOP-k wyników; jakość rankingowania (czy trafne źródła są wysoko); pokrycie zapytań (ile pytań kończy się „pustym” lub nietrafnym kontekstem).
• Metryki odpowiedzi: poprawność merytoryczna względem źródeł, kompletność (czy odpowiedź uwzględnia wszystkie istotne warunki), spójność i zrozumiałość, oraz groundedness (czy twierdzenia mają oparcie w dostarczonym kontekście).
• Metryki ryzyka: częstość halucynacji, skłonność do nadmiernej pewności, poprawność odmowy odpowiedzi (gdy brak podstaw), oraz podatność na pytania sugerujące lub wprowadzające w błąd.
• Metryki operacyjne: czas odpowiedzi end-to-end, stabilność wyników między wersjami, oraz wpływ zmian w danych/indeksie na jakość (porównania A/B w kontrolowanych warunkach).

Niezależnie od tego, jak zaawansowane metryki ilościowe zostaną wdrożone, w obszarze RAG konieczny jest human review – szczególnie w tematach regulowanych, technicznych i wrażliwych na interpretację. Przegląd ekspercki powinien oceniać: zgodność odpowiedzi z polityką firmy, adekwatność cytowanych źródeł, bezpieczeństwo treści (np. ujawnianie nieuprawnionych informacji) oraz to, czy system właściwie prosi o doprecyzowanie, gdy pytanie jest niejednoznaczne. W praktyce dobrym standardem jest stosowanie prostych kart oceny (rubryk) z jednoznacznymi kryteriami i przykładami – tak, aby oceny były porównywalne między recenzentami i możliwe do wykorzystania w usprawnieniach.

Kluczową częścią procesu jest też analiza błędów i pętla ulepszeń: każda niepoprawna odpowiedź powinna zostać sklasyfikowana (np. problem danych, retrieval, prompt, polityki odmowy), a następnie przełożyć się na konkretną zmianę i ponowny test na tym samym zestawie pytań. Taka dyscyplina ewaluacyjna jest fundamentem wdrożeń, w których system ma działać przewidywalnie, a jego jakość ma być komunikowalna wewnętrznie (IT, właściciele procesów, compliance) w sposób audytowalny i odporny na subiektywne wrażenia użytkowników.

6. Bezpieczeństwo: uprawnienia, separacja danych, PII, logowanie i audyt

W podejściu RAG bezpieczeństwo nie sprowadza się do „ochrony modelu”. Kluczowe jest zabezpieczenie całego łańcucha: od źródeł wiedzy i procesu indeksowania, przez warstwę wyszukiwania, aż po generowanie odpowiedzi i ekspozycję w kanałach (np. intranet, Teams, portal klienta). W praktyce oznacza to projektowanie kontroli dostępu i ścieżek audytowych tak, aby użytkownik mógł uzyskać wyłącznie te informacje, do których ma formalne uprawnienia, a organizacja potrafiła udowodnić „kto, kiedy i na jakiej podstawie” uzyskał dostęp do treści.

Najczęstszym ryzykiem w RAG jest nieautoryzowane ujawnienie danych w odpowiedzi, wynikające z błędnego powiązania dokumentów z uprawnieniami lub zbyt szerokiego zakresu retrieval. Dlatego rekomendujemy traktować warstwę wyszukiwania jako komponent bezpieczeństwa: ograniczenie przestrzeni wyszukiwania do dozwolonych zasobów powinno następować przed zwróceniem kontekstu do modelu, a nie dopiero na etapie „filtrowania odpowiedzi”. W naszej ocenie jest to krytyczne, bo model nie powinien w ogóle „widzieć” treści, do których użytkownik nie ma dostępu.

Separacja danych to drugi filar: inne wymagania ma asystent wewnętrzny (działy, role, projekty), a inne rozwiązanie obsługujące wielu klientów (multi-tenant). Minimalny standard to logiczna separacja indeksów i metadanych oraz jednoznaczne przypisanie dokumentów do jednostek organizacyjnych, tenantów lub przestrzeni projektowych. W środowiskach o podwyższonych wymaganiach stosuje się również separację na poziomie zasobów (osobne magazyny/indeksy, a czasem osobne środowiska), aby ograniczyć skutki błędów konfiguracji oraz uprościć audyt i rozliczalność.

Istotnym obszarem jest PII i dane wrażliwe. W RAG PII może pojawić się w trzech miejscach: w dokumentach źródłowych (np. umowy, zgłoszenia), w logach/telemetrii (np. treść zapytań użytkowników) oraz w samych odpowiedziach. Z perspektywy zgodności (np. RODO) i ryzyka operacyjnego należy przyjąć zasadę minimalizacji: nie indeksować i nie udostępniać tego, co nie jest potrzebne do realizacji celu. Tam, gdzie PII jest niezbędne, rekomendujemy jawnie określić podstawę przetwarzania, zakres retencji, sposób anonimizacji/pseudonimizacji oraz kontrolę dostępu do danych szkoleniowych i operacyjnych (w tym do promptów i historii rozmów).

W bezpieczeństwie generatywnym równie ważna jest odporność na nadużycia, takie jak prompt injection czy próby wymuszenia ujawnienia polityk i danych wewnętrznych. Na poziomie wprowadzenia warto przyjąć, że skuteczna ochrona jest warstwowa: polityki i instrukcje systemowe są potrzebne, ale nie zastąpią kontroli dostępu do kontekstu, walidacji wejścia i monitorowania nietypowych wzorców użycia. W praktyce obserwujemy, że organizacje, które wdrażają RAG bez jasnych reguł dotyczących tego, co może być źródłem wiedzy oraz jak klasyfikowane są dokumenty, najszybciej napotykają problemy z incydentami lub blokadami po stronie compliance.

Warstwa logowania i audytu powinna być zaprojektowana tak, aby wspierała zarówno bezpieczeństwo, jak i rozliczalność procesów. Minimalny zestaw, który zwykle jest wymagany w organizacjach, obejmuje:

• logi uwierzytelnienia i autoryzacji (kto uzyskał dostęp, z jaką rolą i w jakim kanale),
• ślad zapytania i przebiegu retrieval (jakie źródła/ID dokumentów zostały użyte jako kontekst, z jakimi filtrami uprawnień),
• rejestr działań administracyjnych (zmiany konfiguracji, polityk, indeksów, konektorów, uprawnień),
• politykę retencji i dostęp do logów zgodny z zasadą najmniejszych uprawnień.

Logowanie wymaga równowagi: z jednej strony musi umożliwiać audyt i analizę incydentów, z drugiej nie powinno utrwalać nadmiarowo treści zawierających PII lub tajemnice przedsiębiorstwa. Dlatego już na etapie projektowania przyjmuje się zasady maskowania/anonimizacji, rozdzielenia logów technicznych od treściowych oraz ograniczenia dostępu do danych obserwowalności wyłącznie do ról, które tego realnie potrzebują (np. bezpieczeństwo, administratorzy platformy).

W projektach szkoleniowych realizowanych przez Cognity temat bezpieczeństwa traktujemy jako nieodłączny element przygotowania organizacji do wdrożenia RAG: od uporządkowania modelu uprawnień i klasyfikacji danych, po zdefiniowanie wymagań audytowych i zasad pracy na danych wrażliwych. W razie potrzeby działamy w reżimie poufności i podpisujemy NDA, aby omawiane scenariusze i materiały mogły bezpiecznie odzwierciedlać realne procesy oraz ryzyka w organizacji.

7. Jak wygląda szkolenie RAG w Cognity i efekty warsztatowe

Szkolenie RAG w Cognity projektujemy jako warsztat inżynierski, w którym uczestnicy przechodzą od krótkiego uporządkowania pojęć (RAG, embeddingi, wyszukiwanie semantyczne, kontekst, halucynacje, grounding) do pracy na realnych artefaktach typowych dla wdrożeń firmowych. W naszej praktyce skuteczne przygotowanie organizacji do startu projektu RAG wymaga połączenia perspektywy technicznej (architektura i jakość odpowiedzi) z operacyjną (utrzymanie, aktualizacja i odpowiedzialności), dlatego nacisk kładziemy na decyzje projektowe i ich konsekwencje, a nie na „demo w próżni”.

W wariancie zamkniętym szkolenie jest przygotowywane wspólnie z klientem i dopasowane do środowiska oraz procesów pracy zespołów. Przed startem realizujemy krótką diagnozę potrzeb: jakie zespoły będą korzystać z rozwiązania, jakie typy dokumentów i źródeł wiedzy dominują, jakie kanały obsługi są planowane oraz jakie ryzyka organizacja chce ograniczyć (np. spójność odpowiedzi, kontrola uprawnień, obsługa zmian w dokumentacji). Na tej podstawie budujemy scenariusze ćwiczeń i dobieramy poziom techniczny tak, aby szkolenie było użyteczne zarówno dla osób projektujących rozwiązanie, jak i dla interesariuszy odpowiedzialnych za jego późniejsze utrzymanie.

Realizacja ma formę „learning by doing”: teoria jest ograniczona do niezbędnego minimum, a większość czasu zajmują ćwiczenia prowadzące do zbudowania i krytycznej oceny działającego prototypu RAG. Zajęcia prowadzą trenerzy–praktycy, którzy pracują w projektach technologicznych i na bieżąco odnoszą omawiane wzorce do realiów wdrożeń w organizacjach (np. typowe problemy z jakością danych, rozjazd oczekiwań między IT i biznesem, trudność w definiowaniu kryteriów akceptacji). Pracujemy w małych grupach, co pozwala na bieżące korygowanie założeń i doprecyzowanie decyzji, które zwykle przesądzają o efektywności rozwiązania.

• Efekt 1: wspólny język i model działania RAG – uczestnicy wychodzą z uporządkowanym rozumieniem, co odpowiada za jakość odpowiedzi (a co nie), jakie elementy są niezbędne w architekturze oraz gdzie najczęściej powstają błędy interpretacyjne na styku „chatbot” vs „system oparty o wiedzę”.
• Efekt 2: działający prototyp i zestaw decyzji projektowych – w wyniku ćwiczeń powstaje prototyp przepływu RAG oraz lista kluczowych ustawień i kompromisów (np. zakres kontekstu, podejście do obsługi źródeł, zasady aktualizacji), które organizacja może bezpośrednio przenieść do planu wdrożenia.
• Efekt 3: checklisty wdrożeniowe i kryteria „gotowości” – uczestnicy tworzą praktyczne checklisty do oceny materiałów wejściowych, doboru scenariuszy testowych i weryfikacji działania rozwiązania w typowych przypadkach użycia, co ułatwia późniejszą kontrolę jakości i komunikację z interesariuszami.
• Efekt 4: przygotowanie zespołu do ról i odpowiedzialności – warsztat porządkuje, kto odpowiada za co w cyklu życia rozwiązania (w tym za utrzymanie wiedzy i zmiany w treściach), dzięki czemu projekt startuje z realnym podziałem zadań, a nie z nieformalnym „AI zrobi resztę”.

Ważnym elementem jest również proces szkoleniowy i organizacyjny. W razie potrzeby pracujemy w reżimie poufności (NDA) i dbamy o to, aby ćwiczenia nie wymuszały ujawniania wrażliwych informacji. Szkolenia realizujemy online lub stacjonarnie (m.in. w naszych salach w Krakowie i Warszawie), a po zakończeniu uczestnicy otrzymują imienny certyfikat (PL/ENG), materiały oraz dostęp do opieki poszkoleniowej, która pozwala domknąć otwarte kwestie już po powrocie do codziennych zadań.

Jako organizacja szkoleniowa działamy nieprzerwanie od 2011 roku i konsekwentnie utrzymujemy podejście oparte na praktyce i jakości procesu edukacyjnego. Wysoką ocenę uczestników potwierdzają opinie o Cognity w Google, a wnioski z feedbacku wykorzystujemy do dalszego doskonalenia programów – tak, aby warsztat przekładał się na mierzalny postęp kompetencji i gotowość organizacji do świadomego startu projektu RAG.

8. KFS: jak opisać cele i korzyści szkolenia dla firmy

W projektach dofinansowanych z Krajowego Funduszu Szkoleniowego kluczowe jest precyzyjne opisanie, po co organizacja rozwija kompetencje i jakie mierzalne efekty biznesowe przyniesie szkolenie. W przypadku szkoleń z budowy chatbotów i systemów AI w podejściu RAG (Retrieval-Augmented Generation) rekomendujemy unikać ogólnych deklaracji typu „poznanie AI” i zamiast tego odnieść cele do konkretnych zadań: przygotowania zespołu do zaprojektowania i uruchomienia rozwiązania, które odpowiada na pytania na bazie firmowej wiedzy, z kontrolą jakości i zgodnością z wymaganiami organizacji.

Opis celów warto formułować w języku kompetencji i wdrożenia. Przykładowo: rozwój umiejętności analizy wymagań dla asystentów AI, przygotowania danych źródłowych do wykorzystania w RAG, projektowania logiki wyszukiwania kontekstu oraz budowy standardów oceny odpowiedzi. Taki zapis pokazuje, że szkolenie nie jest „inspiracyjne”, tylko służy wytworzeniu zdolności organizacyjnej do realizacji projektów AI w sposób przewidywalny i powtarzalny.

W części „korzyści dla firmy” najlepiej wskazać efekty operacyjne, które mają znaczenie dla działów biznesowych i IT. Z perspektywy KFS istotne jest, aby korzyści wynikały bezpośrednio z nabytych kompetencji i były możliwe do zweryfikowania w pracy. W praktyce dobrze działają następujące kategorie opisu:

• Efektywność procesów i obsługi: skrócenie czasu wyszukiwania informacji w dokumentacji i procedurach, odciążenie ekspertów merytorycznych, szybsza odpowiedź dla pracowników/klientów w typowych zapytaniach (z wyraźnym wskazaniem, że mowa o wykorzystaniu firmowej bazy wiedzy, a nie generowaniu „z pamięci”).
• Redukcja ryzyka projektowego: ujednolicenie podejścia do projektowania i oceny rozwiązań RAG, ograniczenie ryzyka błędnych odpowiedzi poprzez wdrożenie zasad pracy z kontekstem i testowania, lepsze przygotowanie do współpracy między IT, biznesem i właścicielami treści.
• Wzrost samodzielności organizacji: budowa kompetencji pozwalających rozwijać i utrzymywać rozwiązania wewnętrznie (np. aktualizować bazę wiedzy, definiować wymagania i kryteria jakości), a tym samym krótszy czas od pomysłu do pilotażu i mniejsze uzależnienie od podmiotów zewnętrznych w podstawowych pracach.
• Uporządkowanie standardów pracy z AI: stworzenie wspólnego języka i zasad dla zespołów (wymagania, rola danych, zasady testów), co przekłada się na spójność kolejnych inicjatyw AI i łatwiejsze skalowanie rozwiązań w organizacji.

W opisie KFS warto doprecyzować również, kogo obejmuje szkolenie i jak wiedza będzie wykorzystywana. Dobrą praktyką jest wskazanie grup docelowych (np. analitycy danych, osoby odpowiedzialne za automatyzację, zespoły IT, właściciele procesów, osoby zarządzające bazą wiedzy) oraz oczekiwanego rezultatu po stronie organizacji, np. przygotowanie koncepcji pilotażu chatbota/RAG dla wybranego procesu, ustandaryzowanie sposobu opisu wymagań lub opracowanie kryteriów jakości odpowiedzi. Tak sformułowany wniosek jasno łączy rozwój kompetencji z realnymi zadaniami, które firma planuje wykonać po szkoleniu.

Od strony formalnej istotne jest, aby szkolenie było możliwe do realizacji w modelu zgodnym z wymaganiami finansowania. Cognity posiada aktywny wpis do Bazy Usług Rozwojowych (BUR), co ułatwia korzystanie z dofinansowań ze środków publicznych, a dodatkowo wspieramy klientów w precyzowaniu celu i zakresu szkolenia tak, aby były spójne z potrzebami organizacji i jednocześnie „broniły się” w logice wniosku KFS. W naszej ocenie najlepiej działają opisy, które łączą język kompetencyjny (co uczestnicy potrafią) z językiem rezultatu (co firma dzięki temu wdroży lub usprawni).

Jak uzyskać dofinansowanie z KFS na szkolenia z AI, SQL i Power BI w Cognity w 2026 roku? 25 marca 2026

Jak uzyskać dofinansowanie z KFS na szkolenia z AI, SQL i Power BI w Cognity w 2026 roku? 25 marca 2026