Jak zadbać o aktualność, wiarygodność i bezpieczeństwo wiedzy wykorzystywanej przez agentów AI?

Czym jest governance wiedzy dla agentów AI i dlaczego jest krytyczne?

Agent AI może poprawnie odczytać dokument, trafnie odnaleźć potrzebny fragment i mimo to podjąć błędną decyzję — jeśli korzysta z nieaktualnej procedury, niepotwierdzonej informacji albo treści, której nie powinien użyć w danym kontekście. Sam dostęp do firmowej bazy wiedzy nie oznacza więc dostępu do wiedzy właściwej. Governance wiedzy to ramy zarządzania, które określają, jakie informacje mogą stanowić podstawę odpowiedzi i działań agenta, w jakich warunkach oraz na czyją odpowiedzialność.

Obejmuje ono zasady dotyczące źródeł, jakości i dopuszczalnego wykorzystania informacji. Dotyczy nie tylko dokumentów w repozytorium, lecz także treści pobieranych z wyszukiwarki, danych zwracanych przez narzędzia i systemy biznesowe oraz informacji zachowywanych w pamięci agenta. Jego zadaniem jest stworzenie warunków, w których można ustalić, na jakiej podstawie agent działał i czy miał prawo z tej podstawy skorzystać.

Governance to więcej niż uporządkowana baza wiedzy

Zarządzanie wiedzą pomaga organizacji gromadzić, porządkować i udostępniać informacje. Governance wyznacza natomiast reguły uznawania ich za odpowiednie do konkretnego zastosowania. Dokument może być łatwy do znalezienia i dobrze opisany, a jednocześnie nie nadawać się do obsługi bieżącej sprawy — na przykład dlatego, że dotyczy innego rynku, produktu lub okresu.

Podobne rozróżnienie dotyczy technologii. Mechanizm RAG, czyli generowanie odpowiedzi z wykorzystaniem wyszukanych materiałów, pomaga dostarczyć modelowi kontekst spoza jego wiedzy treningowej. Nie gwarantuje jednak, że odnalezione treści są obowiązujące, prawdziwe ani dozwolone dla danego użytkownika. Trafność wyszukiwania i dopuszczalność wykorzystania wyniku to dwa odrębne zagadnienia. Governance określa wymagania wobec wiedzy; rozwiązania techniczne pomagają je egzekwować.

Trzy niezależne warunki: aktualność, wiarygodność i bezpieczeństwo

Wiedza przydatna agentowi musi spełniać trzy warunki jednocześnie. Żaden z nich nie zastępuje pozostałych:

• Aktualność oznacza zgodność z sytuacją i momentem, których dotyczy zadanie. Najnowszy dokument nie zawsze jest właściwy: przy analizie historycznej umowy potrzebne mogą być zasady obowiązujące w dniu jej zawarcia. Liczy się właściwy okres obowiązywania informacji, nie sama data pliku.
• Wiarygodność oznacza, że istnieją uzasadnione podstawy, by zaufać informacji w danym zastosowaniu. Znaczenie mają jej pochodzenie, status oraz zgodność z uznanym źródłem. Robocza notatka i zatwierdzona procedura mogą dotyczyć tego samego tematu, ale nie powinny mieć takiej samej mocy rozstrzygającej.
• Bezpieczeństwo oznacza, że użycie informacji nie prowadzi do niedozwolonego ujawnienia, wykorzystania ani zmanipulowania działania agenta. Nawet prawdziwa i aktualna treść może być nieodpowiednia dla konkretnego odbiorcy lub celu. Materiał zewnętrzny może też zawierać instrukcje próbujące zmienić zachowanie agenta — nie należy traktować ich jak uprawnionych poleceń.

Dlaczego w przypadku agentów AI stawka jest wyższa?

W zależności od przyznanych możliwości agent nie tylko odpowiada na pytania, ale również planuje kolejne kroki i wykonuje operacje w systemach. Błąd w wiedzy może więc przejść z poziomu nietrafnej odpowiedzi na poziom działania: zmiany danych, wysłania wiadomości czy uruchomienia niewłaściwego procesu. Przykładowo nieaktualna zasada zwrotów może skutkować błędną informacją dla klienta, a u agenta uprawnionego do obsługi zwrotów — także nieuzasadnioną decyzją finansową.

Ryzyko zwiększa płynny, przekonujący język odpowiedzi, który nie ujawnia automatycznie słabości źródła. Również cytowanie dokumentu nie dowodzi jeszcze, że dokument był właściwy dla sprawy. Governance pomaga rozdzielić to, co agent potrafi odnaleźć i przedstawić, od tego, co organizacja dopuszcza jako podstawę decyzji.

Ma to znaczenie zarówno w wewnętrznym asystencie pracowników, jak i w obsłudze klienta czy automatyzacji procesów. Zakres zabezpieczeń powinien odpowiadać skutkom pomyłki: inne ryzyko wiąże się z wyszukaniem instrukcji korzystania z biura, a inne z interpretacją warunków umowy. Governance wiedzy nie eliminuje wszystkich błędów modelu, ale ogranicza ryzyko, że agent oprze odpowiedź lub działanie na informacji niewłaściwej, nieuprawnionej albo pozbawionej wiarygodnej podstawy.

Role i odpowiedzialności: właściciele treści, stewardzi danych, bezpieczeństwo, użytkownicy i RACI

Gdy agent AI udzieli odpowiedzi na podstawie błędnej instrukcji, musi być jasne, kto odpowiada za jej poprawność, kto ma ją skorygować i kto ocenia ryzyko jej wykorzystania. Samo przypisanie bazy wiedzy do działu IT nie rozwiązuje tego problemu. Zespół techniczny może zapewnić działanie wyszukiwarki czy integracji, ale nie powinien rozstrzygać, czy interpretacja warunków umowy albo procedura obsługi klienta jest merytorycznie właściwa.

W Cognity często słyszymy pytania, jak praktycznie podzielić odpowiedzialność za wiedzę wykorzystywaną przez agentów AI — odpowiadamy na nie także na blogu. Podstawą jest rozdzielenie decyzji merytorycznych, opieki operacyjnej nad wiedzą, oceny bezpieczeństwa i informacji zwrotnej od użytkowników. Role mogą być łączone, zwłaszcza w małych zespołach, lecz ich zakresy powinny pozostać jednoznaczne.

Kto odpowiada za poszczególne obszary?

• Właściciel treści odpowiada za poprawność merytoryczną i przydatność wiedzy w określonym obszarze biznesowym. Rozstrzyga, które źródło jest miarodajne, wyjaśnia sprzeczności i ustala, do jakich zastosowań dana treść jest właściwa. Powinien mieć kompetencje oraz uprawnienia decyzyjne w swojej dziedzinie. Nie musi być autorem każdego dokumentu, ale musi wiedzieć, za jaki zakres wiedzy odpowiada.
• Steward danych lub wiedzy sprawuje bieżącą opiekę operacyjną nad powierzonym zasobem. Dba o jego uporządkowanie, opis, powiązanie ze źródłem i przypisanie do właściwego właściciela. Identyfikuje braki oraz niespójności i kieruje pytania do odpowiednich ekspertów. W odróżnieniu od właściciela nie rozstrzyga samodzielnie kwestii merytorycznych wykraczających poza jego mandat.
• Zespół bezpieczeństwa określa wymagania i ograniczenia dotyczące bezpiecznego wykorzystania informacji przez agenta. Ocenia ryzyka, których ekspert dziedzinowy może nie dostrzec, na przykład możliwość ujawnienia poufnej wiedzy w odpowiedzi. Nie zastępuje jednak właściciela treści w ocenie jej poprawności. To, czy pełni funkcję doradczą, czy ma prawo wstrzymać określone zastosowanie, powinno wynikać z przyjętego podziału kompetencji.
• Użytkownicy dostarczają informacji o tym, jak wiedza sprawdza się w rzeczywistych zadaniach. Zgłaszają błędne odpowiedzi, niejasności, brakujący kontekst i rozbieżności z praktyką. Ich obserwacje są ważnym sygnałem, ale samo zgłoszenie ani pozytywna ocena odpowiedzi nie stanowią potwierdzenia wiarygodności źródła.

Jak wykorzystać RACI bez rozbudowanej biurokracji?

RACI porządkuje odpowiedzialność za konkretne zadania i decyzje, a nie tylko opisuje stanowiska. R — Responsible oznacza wykonawcę zadania, A — Accountable osobę ostatecznie odpowiedzialną za jego rezultat, C — Consulted osoby konsultowane, a I — Informed osoby, które należy poinformować. Dla jednego zadania warto wskazać jedną rolę A: kilku równorzędnych decydentów łatwo prowadzi do sytuacji, w której nikt nie podejmuje decyzji.

Przykładowo przy wyjaśnianiu sprzeczności między dwiema instrukcjami steward może zebrać źródła i opisać problem jako R, a właściciel treści rozstrzygnąć go jako A. Bezpieczeństwo występuje jako C, jeśli sprawa dotyczy dopuszczalnego wykorzystania informacji, natomiast użytkownicy korzystający z instrukcji mogą być I. W innym zadaniu przypisania będą inne — zespół bezpieczeństwa nie jest automatycznie konsultantem przy każdej decyzji.

Przypisuj role do zakresów wiedzy i konkretnych decyzji, nie do ogólnego hasła „odpowiedzialność za AI”. Każde przypisanie powinno wskazywać osobę lub funkcję z realnym mandatem, a także zastępstwo na czas nieobecności. Dzięki temu pytanie o treść trafia do eksperta dziedzinowego, problem organizacyjny do stewarda, a wątpliwość dotycząca ryzyka do właściwego zespołu — bez przerzucania odpowiedzialności między działami.

Cykl życia wiedzy: pozyskanie, walidacja, publikacja, wersjonowanie i wycofywanie

Dokument zapisany w firmowym repozytorium nie powinien automatycznie stawać się źródłem odpowiedzi agenta AI. Najpierw trzeba ustalić jego pochodzenie, sprawdzić przydatność i przygotować go do udostępnienia. Później konieczne jest zachowanie historii zmian oraz skuteczne wyłączenie treści, które przestały obowiązywać. Cykl życia wiedzy porządkuje przejście od materiału źródłowego do informacji dopuszczonej do użycia — i określa, kiedy agent powinien przestać z niej korzystać.

Pozyskanie: zebranie treści wraz z kontekstem

Wiedza może pochodzić z procedur, dokumentacji produktowej, baz zgłoszeń czy systemów biznesowych. Na etapie pozyskania nie wystarczy skopiować tekstu. Trzeba zachować informacje pozwalające ustalić, czego dotyczy materiał i skąd pochodzi: identyfikator źródła, datę obowiązywania, zakres zastosowania oraz powiązania z innymi dokumentami.

Istotne jest także rozróżnienie charakteru treści. Rozwiązanie opisane w pojedynczym zgłoszeniu może pomóc w podobnym przypadku, ale nie staje się przez to ogólną procedurą. Z kolei dokument dotyczący jednego produktu lub rynku nie powinien być przedstawiany jako zasada obowiązująca w całej organizacji. Zachowanie tego kontekstu ogranicza ryzyko nieuprawnionych uogólnień.

Walidacja: sprawdzenie znaczenia i jakości technicznej

Walidacja odpowiada na pytanie, czy pozyskany materiał nadaje się do wykorzystania przez agenta. Obejmuje zgodność ze źródłem, kompletność, spójność oraz wykrywanie sprzeczności i duplikatów. Jeżeli dwie instrukcje opisują tę samą czynność inaczej, rozbieżność należy rozstrzygnąć przed publikacją, zamiast pozostawiać agentowi wybór przypadkowo znalezionego wariantu.

Osobnego sprawdzenia wymaga sposób przetworzenia dokumentu. Błędy rozpoznawania tekstu, utracone nagłówki tabel czy oddzielenie wyjątku od reguły mogą zmienić sens informacji. W systemach RAG, które wyszukują fragmenty wiedzy na potrzeby odpowiedzi, warto sprawdzić, czy podział treści zachowuje warunki, ograniczenia i odniesienia niezbędne do jej poprawnego zrozumienia.

Publikacja: świadome udostępnienie wiedzy agentowi

Publikacja oznacza przejście materiału do stanu, w którym może być wykorzystywany w odpowiedziach lub działaniach agenta. Jest czymś innym niż samo zapisanie pliku. W rozwiązaniu korzystającym z wyszukiwania może wymagać aktualizacji indeksu, przygotowania reprezentacji wektorowych i powiązania fragmentów z dokumentem źródłowym.

Wiedza jest skutecznie opublikowana dopiero wtedy, gdy agent potrafi odnaleźć właściwą treść i wskazać jej źródło. Krótki test na reprezentatywnych pytaniach pozwala wykryć sytuację, w której dokument znajduje się w repozytorium, lecz nie jest dostępny w rzeczywistej ścieżce wyszukiwania.

Wersjonowanie: rozróżnienie historii od stanu obowiązującego

Każda opublikowana wersja powinna mieć jednoznaczny identyfikator i informację o okresie obowiązywania. Data dodania do systemu nie musi być datą wejścia treści w życie: nowa instrukcja może zostać przygotowana wcześniej, a dokument historyczny zaimportowany dopiero dziś.

Wersjonowanie pozwala odtworzyć, na jakiej wiedzy opierała się konkretna odpowiedź. Wymaga to powiązania wykorzystanych fragmentów z odpowiednimi wersjami źródeł. Historia może służyć analizie wcześniejszych decyzji, ale nie powinna konkurować z obowiązującą treścią przy pytaniach o bieżące zasady.

Wycofywanie: usunięcie treści z aktywnego użycia

Wycofanie dotyczy materiałów zastąpionych, błędnych lub nieadekwatnych do obecnego zakresu działania agenta. Samo oznaczenie dokumentu jako archiwalnego może nie wystarczyć. Z aktywnego wyszukiwania trzeba wyłączyć także jego fragmenty i nieaktualne kopie, a w razie potrzeby unieważnić powiązane wpisy w pamięci podręcznej.

Archiwizacja zachowuje historię; wycofanie blokuje bieżące wykorzystanie. To dwa odrębne cele. Jeśli treść posłużyła do trenowania lub dostrajania modelu, usunięcie jej z repozytorium nie oznacza usunięcia jej wpływu z modelu — taki przypadek wymaga osobnego postępowania.

Harmonogram przeglądów i zarządzanie aktualnością: SLA, progi ryzyka, sygnały do rewizji

Dokument może być poprawny językowo i pochodzić z zaufanego źródła, a mimo to prowadzić agenta AI do błędnej odpowiedzi — wystarczy, że opisuje nieobowiązującą cenę, procedurę lub wersję produktu. Dlatego aktualnością wiedzy nie należy zarządzać wyłącznie przez cykliczne przypomnienia. Potrzebne są jednocześnie przeglądy okresowe, mierzalne terminy reakcji na zmiany oraz sygnały uruchamiające wcześniejszą rewizję.

W Cognity omawiamy zarządzanie aktualnością wiedzy agentów AI zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników szkoleń. W takim podejściu równie ważne jak sprawna synchronizacja danych są jasne zasady określające, kiedy treść wymaga weryfikacji i kiedy agent powinien wstrzymać działanie.

Częstotliwość przeglądów powinna wynikać z ryzyka

Jeden termin przeglądu dla całej bazy wiedzy rzadko jest uzasadniony. Częstotliwość warto uzależnić od tempa zmian, konsekwencji wykorzystania nieaktualnej informacji oraz sposobu działania agenta. Ta sama treść wymaga większej ostrożności, gdy agent na jej podstawie wykonuje operację, niż wtedy, gdy jedynie wskazuje użytkownikowi materiał do przeczytania.

Poniższe przedziały są przykładem sposobu planowania, a nie uniwersalnym standardem. Należy dopasować je do konkretnego procesu i akceptowalnego ryzyka.

Próg ryzyka powinien zmieniać sposób korzystania z wiedzy, nie tylko termin jej przeglądu. Jeżeli niepotwierdzona aktualność może spowodować istotną szkodę, agent nie powinien traktować materiału jako wystarczającej podstawy do wykonania działania. Przy treściach o małych konsekwencjach dopuszczalne może być ostrzeżenie o dacie ostatniej weryfikacji.

SLA: rozdziel przegląd, reakcję i dostępność aktualizacji

SLA dotyczące aktualności powinno określać, co dokładnie jest mierzone i od którego momentu biegnie czas. Warto rozdzielić trzy zobowiązania:

• Termin przeglądu — maksymalny odstęp między potwierdzeniami, że treść nadal odpowiada stanowi faktycznemu.
• Czas reakcji na sygnał — okres od wykrycia potencjalnej nieaktualności do oceny jej wpływu i ustalenia dalszego postępowania.
• Czas udostępnienia zmiany agentowi — okres od określonego zdarzenia, np. opublikowania obowiązującej zmiany w źródle, do dostępności poprawnej informacji w systemie, z którego korzysta agent.

Ostatnia miara jest szczególnie ważna: zmiana dokumentu źródłowego nie oznacza jeszcze aktualizacji indeksu wyszukiwania ani pamięci podręcznej. SLA powinno obejmować faktyczną dostępność właściwej wersji dla agenta. Trzeba też odróżniać datę publikacji od daty wejścia zmiany w życie — nowsza informacja nie zawsze jest już obowiązująca.

Sygnały do rewizji poza harmonogramem

Zaplanowany przegląd nie może być powodem do odkładania reakcji na znany problem. Wcześniejszą rewizję powinny uruchamiać przede wszystkim zmiany przepisów, cenników, produktów i procedur, ale również rozbieżności między źródłami, zgłoszenia użytkowników oraz powtarzające się błędne odpowiedzi agenta. Osobną kategorią są sygnały techniczne: nieudana synchronizacja, niedostępność źródła lub przekroczenie dopuszczalnego opóźnienia aktualizacji.

Do kontroli harmonogramu wystarczą początkowo trzy wskaźniki: udział materiałów po terminie przeglądu, liczba przekroczeń SLA oraz opóźnienie między zmianą źródła a jej dostępnością dla agenta. Warto analizować je osobno dla poziomów ryzyka. Wysoki odsetek aktualnych dokumentów w całej bazie może bowiem ukrywać zaległości dotyczące kilku informacji, od których zależą najważniejsze decyzje.

Proces akceptacji zmian: workflow, kontrola jakości, ścieżki eskalacji i ślad audytowy

Zmiana jednego zdania w bazie wiedzy może zmienić odpowiedź agenta, jego rekomendację lub sposób wykonania zadania. Dlatego akceptacja nie powinna ograniczać się do sprawdzenia poprawności dokumentu. Trzeba ocenić również wpływ zmiany na zachowanie agenta: czy odnajdzie właściwą informację, poprawnie ją zinterpretuje i zastosuje w odpowiednim kontekście.

Proces powinien być proporcjonalny do ryzyka. Korekta literówki zwykle nie wymaga takiej samej weryfikacji jak zmiana warunków reklamacji, instrukcji operacyjnej czy zasad podejmowania decyzji finansowych. Ważne jednak, aby uproszczona ścieżka wynikała z ustalonych kryteriów, a nie z uznania osoby wprowadzającej zmianę.

Workflow: od zgłoszenia do potwierdzenia wdrożenia

Przejrzysty obieg akceptacji rozdziela przygotowanie zmiany, jej ocenę i dopuszczenie do użycia przez agenta. Każdy etap powinien mieć określony wynik oraz warunek przejścia dalej.

• Zgłoszenie zmiany: opis tego, co ma zostać zmienione, dlaczego oraz na podstawie jakiego źródła. Zgłoszenie powinno wskazywać także agentów lub zastosowania, których może dotyczyć modyfikacja.
• Ocena wpływu: ustalenie, czy zmiana jest wyłącznie redakcyjna, czy wpływa na znaczenie treści, odpowiedzi lub działania agenta. Od tego zależy zakres testów i wymaganych akceptacji.
• Weryfikacja i testy: sprawdzenie treści oraz zachowania agenta w środowisku testowym. Wykryte problemy wracają do poprawy, zamiast pozostawać nieformalnym zastrzeżeniem w korespondencji.
• Decyzja: akceptacja, odrzucenie albo skierowanie do uzupełnienia, wraz z uzasadnieniem. Niespełnione warunki blokujące powinny uniemożliwiać wdrożenie.
• Potwierdzenie wdrożenia: sprawdzenie, czy agent rzeczywiście korzysta z zatwierdzonej treści, a nie ze starego indeksu lub pamięci podręcznej. W razie niepowodzenia należy mieć możliwość przywrócenia poprzedniego, sprawdzonego stanu.

Zatwierdzenie dokumentu nie jest równoznaczne z poprawnym udostępnieniem wiedzy agentowi. W systemach korzystających z wyszukiwania i generowania odpowiedzi, na przykład RAG, między tymi zdarzeniami mogą wystąpić błędy przetwarzania lub indeksowania.

Kontrola jakości: treść i zachowanie agenta

Weryfikacja merytoryczna odpowiada na pytanie, czy zmiana jest poprawna, jednoznaczna i zgodna z materiałem źródłowym. Testy działania sprawdzają natomiast, czy agent potrafi tę wiedzę wykorzystać. Obie oceny są potrzebne: poprawna instrukcja nie pomoże, jeśli system wyszuka niewłaściwy fragment albo pominie opisany w niej wyjątek.

Warto utrzymywać zestaw pytań i scenariuszy kontrolnych obejmujący typowe przypadki, sytuacje graniczne oraz przypadki, w których agent powinien powstrzymać się od rozstrzygnięcia. Po zmianie należy sprawdzić nie tylko oczekiwaną nową odpowiedź, lecz także to, czy nie pogorszyły się odpowiedzi w powiązanych obszarach. To istota testów regresji.

Kryteria akceptacji trzeba ustalić przed oceną wyników. Przykładowo: agent podaje warunki wynikające z zatwierdzonego źródła, nie pomija istotnych wyjątków i nie przedstawia niepewnej interpretacji jako obowiązującej zasady. Automatyczne testy mogą wspierać tę ocenę, ale przy zmianach o wysokich konsekwencjach nie powinny być jedyną podstawą decyzji.

Eskalacja: co zrobić, gdy nie ma podstaw do akceptacji

Eskalację powinny uruchamiać konkretne przesłanki: sprzeczne źródła, brak potwierdzenia nowej zasady, niezaliczone testy krytyczne lub spór dotyczący skutków zmiany. Problem merytoryczny wymaga rozstrzygnięcia przez właściwego eksperta, błąd wyszukiwania — analizy technicznej, a wątpliwość prawna lub bezpieczeństwa — oceny odpowiedniej funkcji kontrolnej.

Do czasu rozstrzygnięcia zmiana powinna pozostać zablokowana. Jeżeli problem dotyczy wiedzy już używanej, decyzja może obejmować czasowe wstrzymanie jej wykorzystania lub ograniczenie danego zastosowania agenta. Ścieżka pilna może skracać czas reakcji, ale nie powinna usuwać wymaganej akceptacji ani obowiązku udokumentowania decyzji.

Ślad audytowy: możliwość odtworzenia decyzji

Rejestr zmian powinien łączyć zgłoszenie, porównanie treści przed i po zmianie, podstawę merytoryczną, wyniki testów, decyzje akceptacyjne oraz potwierdzenie wdrożenia. Potrzebne są identyfikatory wersji, daty i informacje o osobach podejmujących decyzje. Sam wpis „zaakceptowano” nie wyjaśnia, co oceniono ani na jakiej podstawie.

Dobry ślad audytowy pozwala ustalić, dlaczego konkretna wersja wiedzy została dopuszczona do użycia. Powiązanie go z wersją faktycznie dostępną agentowi ułatwia analizę błędnych odpowiedzi i odróżnienie problemu treści od problemu wdrożenia.

Kontrola dostępu i audyt: uprawnienia, przeglądy dostępów, zasada najmniejszych uprawnień, SoD

Agent AI nie powinien stawać się drogą na skróty do informacji, których użytkownik nie może odczytać w systemie źródłowym. Jeśli pracownik nie ma dostępu do dokumentacji kadrowej, nie powinien otrzymać jej treści ani streszczenia za pośrednictwem asystenta. Kontrola dostępu musi obejmować cały przepływ wiedzy: od źródła, przez wyszukiwanie i kontekst przekazywany modelowi, aż po odpowiedź. Same instrukcje w prompcie nie zastępują mechanizmów autoryzacji.

Uprawnienia użytkownika i agenta to dwie różne granice

Użytkownik ma określone prawa do informacji, a agent — techniczne możliwości korzystania z repozytoriów i narzędzi. Gdy agent działa w imieniu użytkownika, dostęp powinien wynikać z przecięcia tych uprawnień, a nie z ich sumy. Szeroki dostęp konta technicznego nie może automatycznie rozszerzać praw osoby zadającej pytanie. Dla zadań wykonywanych autonomicznie potrzebna jest natomiast odrębna tożsamość i jawnie określony zakres działania.

Podstawowym rozwiązaniem jest RBAC, czyli nadawanie uprawnień według ról, na przykład pracownika, redaktora lub administratora. Sprawdza się tam, gdzie obowiązki i grupy odbiorców są stabilne. ABAC uzupełnia ten model o warunki oparte na atrybutach, takich jak przynależność do projektu, organizacja użytkownika czy status dokumentu. Jest przydatny, gdy sama rola nie wystarcza do podjęcia decyzji. Oba podejścia można łączyć, zachowując zasadę domyślnej odmowy dostępu.

Najmniejsze uprawnienia w praktyce

Zasada najmniejszych uprawnień oznacza przyznawanie wyłącznie takiego dostępu, jaki jest niezbędny do konkretnego zadania, i tylko na potrzebny czas. Agent odpowiadający na pytania zwykle potrzebuje odczytu, ale nie prawa do edycji dokumentów, zmiany uprawnień czy usuwania zasobów. Warto oddzielać tożsamości i poświadczenia agentów o różnych zadaniach, zamiast obsługiwać je jednym kontem z szerokimi uprawnieniami.

W systemach RAG, które wyszukują materiały przed wygenerowaniem odpowiedzi, autoryzacja powinna następować przed przekazaniem treści do modelu. Ograniczenia ze źródła muszą być respektowane także przez indeks wyszukiwania i fragmenty dokumentów. Nie wystarczy ukryć niedozwolonych cytatów w gotowej odpowiedzi, jeśli model wcześniej otrzymał chronione materiały. Podobnej kontroli wymagają pamięć rozmowy i pamięć podręczna: wynik dostępny dla jednej osoby nie może zostać bezwarunkowo wykorzystany w odpowiedzi dla innej.

Przeglądy dostępów i skuteczne odbieranie uprawnień

Przegląd dostępu powinien potwierdzać rzeczywistą potrzebę biznesową, a nie jedynie zgodność z istniejącą listą uprawnień. Jego częstotliwość należy dostosować do wrażliwości zasobów i zakresu dostępu. Niezależnie od przeglądów okresowych potrzebna jest reakcja na zmianę stanowiska, zakończenie projektu, odejście pracownika lub wyłączenie agenta.

• Sprawdzaj dostęp efektywny: uwzględniaj grupy, role dziedziczone, konta techniczne i delegowane uprawnienia.
• Usuwaj dostępy zbędne i osierocone: weryfikuj zwłaszcza konta bez właściciela oraz uprawnienia tymczasowe, które nie wygasły.
• Testuj odebranie dostępu: sprawdzaj, czy zmiana działa również w indeksach, aktywnych sesjach i wynikach zapisanych w pamięci podręcznej.

Rozdział obowiązków i audyt

SoD, czyli rozdział obowiązków, ogranicza ryzyko skupienia sprzecznych kompetencji w jednej osobie lub tożsamości technicznej. Osoba wnioskująca o rozszerzenie własnych uprawnień nie powinna samodzielnie go zatwierdzać. Administrator nadający dostęp nie powinien mieć niekontrolowanej możliwości usuwania śladów tej operacji. Przy dostępie awaryjnym warto stosować ograniczenie czasowe i niezależną weryfikację po użyciu.

Ślad audytowy powinien pozwalać ustalić, kto lub jaki agent korzystał z wiedzy, w czyim imieniu działał, jakiego zasobu dotyczyło żądanie i jaka była decyzja autoryzacyjna. Należy rejestrować również zmiany uprawnień, odmowy dostępu i użycie dostępu awaryjnego. Identyfikatory żądań pomagają połączyć zdarzenia między systemami. Nie oznacza to konieczności zapisywania pełnej treści dokumentów czy rozmów — same logi również wymagają ograniczonego dostępu i ochrony przed modyfikacją. Ich wartość rośnie, gdy służą nie tylko analizie incydentów, lecz także wykrywaniu nietypowych prób dostępu.

7. Klasyfikacja informacji i bezpieczeństwo: kategorie danych, zasady użycia, redakcja i DLP

Agent AI nie powinien wykorzystywać każdej informacji, którą potrafi odnaleźć. Dokument może być poprawny i aktualny, a mimo to zawierać dane niedopuszczone do przetwarzania w danym środowisku lub ujawnienia odbiorcy odpowiedzi. Klasyfikacja informacji musi więc określać nie tylko wrażliwość treści, lecz także dozwolony sposób jej wykorzystania przez agenta.

Kategorie danych i ich zastosowanie

Punktem wyjścia może być podział na cztery poziomy ochrony. Nazwy kategorii warto dopasować do istniejącej polityki organizacji, zamiast tworzyć osobną klasyfikację wyłącznie na potrzeby AI:

• Publiczne — materiały zatwierdzone do powszechnego udostępniania, np. opublikowane instrukcje produktów. Mogą służyć do przygotowywania odpowiedzi dla klientów, z uwzględnieniem warunków ich wykorzystania.
• Wewnętrzne — informacje przeznaczone do pracy wewnątrz organizacji. Agent wspierający pracowników może z nich korzystać w zatwierdzonym środowisku, ale nie powinien automatycznie przenosić ich do komunikacji zewnętrznej.
• Poufne — np. niepubliczne warunki umów, marże lub plany biznesowe. Ich użycie wymaga jasno określonego celu, ograniczonego zakresu danych i odpowiednio zabezpieczonego środowiska przetwarzania.
• Ściśle chronione — informacje, których ujawnienie może spowodować szczególnie poważne szkody. Hasła, klucze API i inne sekrety uwierzytelniające należy wykluczyć z bazy wiedzy oraz kontekstu modelu; narzędzia powinny pobierać je przez dedykowane mechanizmy zarządzania sekretami.

Poziom poufności nie zastępuje oznaczeń wynikających z charakteru danych. Dane osobowe, szczególne kategorie danych osobowych czy informacje objęte tajemnicą zawodową wymagają odrębnej oceny. Sam fakt publicznej dostępności danych osobowych nie oznacza dowolności ich dalszego przetwarzania.

Zasady użycia obejmują cały przepływ informacji

Dla każdej kategorii trzeba ustalić, czy dane wolno indeksować, przekazywać do modelu, umieszczać w odpowiedzi, zapisywać w historii rozmowy oraz przesyłać do narzędzi zewnętrznych. Są to różne operacje: zgoda na wyszukanie dokumentu nie jest równoznaczna ze zgodą na wysłanie jego pełnej treści do zewnętrznego API.

Reguły powinny uwzględniać miejsce przetwarzania, retencję oraz warunki wykorzystania danych przez dostawcę usługi. Ochroną należy objąć również fragmenty dokumentów, indeksy wektorowe, pamięć agenta i logi. Streszczenie poufnego materiału nie staje się automatycznie informacją publiczną — może nadal ujawniać chronione fakty.

Redakcja, anonimizacja i pseudonimizacja — różne cele

Redakcja danych polega na usunięciu lub zamaskowaniu wybranych elementów, np. numeru rachunku w dokumencie potrzebnym do analizy reklamacji. Należy ją wykonywać przed przekazaniem materiału do modelu, jeżeli model nie powinien otrzymać tych informacji. Usunięcie danych dopiero z odpowiedzi nie cofa ich wcześniejszego ujawnienia.

Anonimizacja ma uniemożliwić identyfikację osoby z uwzględnieniem środków, których użycia można rozsądnie oczekiwać. Samo usunięcie nazwiska zwykle nie wystarcza: stanowisko, miejscowość i opis zdarzenia mogą pozwolić rozpoznać konkretną osobę. Pseudonimizacja, np. zastąpienie nazwiska identyfikatorem powiązanym z oddzielnym rejestrem, ogranicza bezpośrednią identyfikowalność, lecz dane nadal pozostają osobowe. Dobór metody zależy od tego, jakie informacje są rzeczywiście niezbędne do zadania.

DLP jako dodatkowa warstwa ochrony

Mechanizmy DLP (Data Loss Prevention) pomagają wykrywać i ograniczać niedozwolony przepływ informacji. W rozwiązaniu agentowym warto stosować je przy zasilaniu bazy wiedzy, przekazywaniu kontekstu do modelu, wywoływaniu narzędzi oraz udostępnianiu odpowiedzi. Reakcją może być blokada, usunięcie wrażliwego fragmentu albo skierowanie przypadku do oceny.

DLP nie daje jednak pełnej gwarancji: łatwiej wykryć charakterystyczny format numeru niż poufną informację opisaną własnymi słowami. Dlatego reguły wymagają testowania także na streszczeniach i połączeniach danych z kilku źródeł. Polecenia zapisane w dokumentach nie mogą znosić tych zabezpieczeń — treść źródłowa jest materiałem do analizy, a nie upoważnieniem do ujawnienia informacji.

8. Logowanie zapytań i obserwowalność: rejestrowanie promptów i odpowiedzi, metryki, detekcja nadużyć oraz checklisty i polityki

Gdy agent AI udzieli błędnej odpowiedzi, sama historia rozmowy może nie wystarczyć do ustalenia przyczyny. Trzeba wiedzieć, jakie materiały odnalazł, które fragmenty otrzymał jako kontekst i czy jego odpowiedź rzeczywiście z nich wynikała. Logowanie zapisuje zdarzenia, a obserwowalność pozwala powiązać je i zrozumieć zachowanie systemu. To różnica między przechowywaniem śladów działania a możliwością wykrycia, dlaczego agent korzysta z wiedzy w niewłaściwy sposób.

Co rejestrować, aby odtworzyć przebieg odpowiedzi

Rejestr powinien łączyć zapytanie użytkownika, wyszukanie materiałów, wywołania narzędzi i odpowiedź agenta za pomocą wspólnego identyfikatora przebiegu. Przydatne są znaczniki czasu, identyfikatory i wersje wykorzystanych źródeł, wersja konfiguracji agenta oraz informacje o błędach i zadziałaniu zabezpieczeń. Pozwala to odróżnić problem z wyszukiwaniem od sytuacji, w której agent znalazł właściwy dokument, ale błędnie go zinterpretował.

Rejestrowanie promptów i odpowiedzi nie powinno oznaczać bezwarunkowego zapisywania ich pełnej treści. Rozmowy mogą zawierać dane osobowe, poufne informacje lub sekrety techniczne. Zakres zapisu należy ograniczyć do celu diagnostycznego: tam, gdzie wystarczą metadane, nie trzeba przechowywać całej rozmowy. Jeżeli analiza wymaga treści, warto usuwać z niej dane wrażliwe przed utrwaleniem. Trzeba też pamiętać, że prompt użytkownika i kontekst przekazany modelowi to różne elementy — do diagnozy często potrzebne są informacje o obu.

Metryki jakości i sygnały nadużyć

Czas odpowiedzi i liczba błędów technicznych pokazują sprawność usługi, ale nie wiarygodność wykorzystywanej wiedzy. Warto mierzyć również odsetek zapytań bez trafnych wyników, udział odpowiedzi z poprawnym wskazaniem źródeł, częstotliwość zgłaszanych błędów oraz udział twierdzeń znajdujących potwierdzenie w pobranych materiałach. Ostatni wskaźnik wymaga oceny jakościowej, na przykład na regularnie sprawdzanej próbce odpowiedzi; sama obecność przypisu nie dowodzi poprawności.

W detekcji nadużyć istotne są powtarzające się próby wydobycia poufnych informacji, masowe odpytywanie o zawartość bazy oraz instrukcje nakłaniające agenta do ignorowania zasad. Takie instrukcje mogą znajdować się także w pobranych dokumentach, nie tylko w wiadomości użytkownika. Pojedynczy sygnał nie przesądza jednak o nadużyciu. Alert powinien uwzględniać kontekst, częstotliwość i skutki zachowania, aby nie traktować zwykłych pytań diagnostycznych jak ataku.

Polityka odpowiedzi i krótka checklista kontroli

Polityka korzystania z wiedzy powinna opisywać zachowania, które da się sprawdzić w zapisach działania agenta. Ogólne polecenie „odpowiadaj rzetelnie” nie wystarczy. Potrzebne są jasne granice dotyczące korzystania ze źródeł, niepewności i odmowy odpowiedzi.

• Dozwolone: streszczanie dostępnych materiałów, porównywanie ich treści oraz wyraźne zaznaczanie braków lub sprzeczności.
• Niedozwolone: wymyślanie źródeł, przedstawianie przypuszczeń jako ustaleń i wykonywanie instrukcji z dokumentów, które próbują zmienić zasady działania agenta.
• Cytowanie: wskazanie źródła powinno umożliwiać weryfikację konkretnego twierdzenia, a nie jedynie prowadzić do ogólnie powiązanego dokumentu. Cytat ani opis źródła nie mogą ujawniać informacji niedostępnych dla odbiorcy.
• Brak podstaw: gdy materiały nie pozwalają udzielić odpowiedzi, agent powinien powiedzieć to wprost, zamiast uzupełniać lukę pozornie wiarygodną treścią.

Przy kontroli próbki rozmów warto sprawdzić trzy rzeczy: czy można odtworzyć podstawę odpowiedzi, czy przywołane materiały potwierdzają jej kluczowe twierdzenia i czy agent zastosował właściwą regułę przy braku wiedzy. Taka checklista łączy logi z oceną rzeczywistej jakości — bez sprowadzania nadzoru do samego gromadzenia danych. W Cognity łączymy teorię z praktyką — dlatego zagadnienia kontroli jakości odpowiedzi agentów AI rozwijamy także w formie ćwiczeń na szkoleniach.

DOE w Six Sigma – jak planowanie eksperymentów wspiera doskonalenie procesów? 24 października 2026

Metodyka DMAIC – pięć etapów doskonalenia procesów krok po kroku 22 października 2026