Audyt bezpieczeństwa AI i LLM: kompletny przewodnik dla firm

Audyt bezpieczeństwa AI i LLM sprawdza nie tylko model, lecz cały system: dane, prompty, RAG, narzędzia, tożsamości, aplikację, dostawcę i proces reagowania. Model może poprawnie odmawiać szkodliwej instrukcji, a jednocześnie agent może wysłać poufny dokument do niewłaściwego odbiorcy, ponieważ konektor ma zbyt szerokie uprawnienia.

W skrócie: skuteczny audyt AI obejmuje inwentaryzację zastosowań, model zagrożeń, testy danych i prompt injection, kontrolę dostępu do RAG, uprawnienia narzędzi, izolację wykonania, prywatność, monitoring, odporność na awarie i retest. Sam chatbotowy jailbreak nie jest pełnym audytem.

Czym różni się audyt AI od zwykłego pentestu

Klasyczny pentest nadal jest potrzebny. Panel, API, OAuth, chmura i backend mogą zawierać zwykłe błędy autoryzacji lub injection. System AI dodaje jednak element probabilistyczny i nowe granice zaufania: treść dokumentu może wpłynąć na decyzję modelu, wynik narzędzia może zatruć kolejne kroki, a zmiana wersji modelu zmieni zachowanie bez zmiany kodu aplikacji.

Audyt musi więc odpowiedzieć na trzy poziomy pytań:

Czy aplikacja jest technicznie bezpieczna? Uwierzytelnianie, sesje, API, sekrety, chmura i zależności.
Czy pipeline AI chroni dane i instrukcje? Prompt systemowy, RAG, pamięć, filtry, klasyfikatory i logi.
Czy działania modelu mają bezpieczne granice? Tożsamość agenta, uprawnienia narzędzi, zatwierdzenia i odwracalność.

NIST AI RMF porządkuje zarządzanie ryzykiem w funkcjach Govern, Map, Measure i Manage. Profil NIST dla generatywnej AI rozszerza tę strukturę o ryzyka charakterystyczne dla GenAI. OWASP Top 10 for LLM Applications pomaga nazwać najważniejsze klasy techniczne, ale nie zastępuje modelu zagrożeń konkretnego produktu.

Co powinno wejść w zakres audytu

Sformułowanie „audyt chatbota” jest zbyt wąskie. W zakresie zapisz:

zastosowanie biznesowe i niedopuszczalne skutki;
wersję oraz dostawcę modelu;
prompt systemowy i warstwy orkiestracji;
źródła RAG, embeddingi, bazę wektorową i cache;
pamięć krótką i długą;
dostępne narzędzia, MCP, API i konektory;
tożsamości użytkowników, agentów i usług;
klasy danych, retencję i lokalizację przetwarzania;
proces ewaluacji, wdrożenia, monitoringu i wycofania;
zależności od usług zewnętrznych.

Jeżeli system generuje wyłącznie tekst marketingowy bez dostępu do danych wewnętrznych, ryzyko wygląda inaczej niż w agencie zatwierdzającym zwroty albo czytającym pocztę. Zakres powinien wynikać ze skutku, nie z nazwy modelu.

1. Inwentaryzacja i właścicielstwo

Pierwszym testem jest ustalenie, czy organizacja wie, gdzie używa AI. Rejestr powinien łączyć zastosowanie z właścicielem biznesowym, modelem, dostawcą, danymi, narzędziami, wersją i datą zatwierdzenia. Bez tego nie wiadomo, który proces zmienił się po aktualizacji API ani gdzie trafiły dane pracownika.

Audyt porównuje deklarowany rejestr z SSO, logami proxy, wydatkami SaaS, repozytoriami i integracjami. Shadow AI nie zawsze oznacza złą wolę — często pokazuje brak bezpiecznej, szybkiej ścieżki wdrożenia. Rozwinięcie procesu znajdziesz w artykule o rejestrze modeli AI i kontroli shadow AI.

2. Model zagrożeń i granice zaufania

Mapa przepływu powinna pokazać użytkownika, aplikację, model, RAG, narzędzia, magazyny danych oraz usługi zewnętrzne. Każda strzałka oznacza dane i decyzję o zaufaniu.

Warto zadać konkretne pytania:

Czy treść pobrana z Internetu może sterować agentem?
Czy dokument innego tenanta może wejść do kontekstu?
Czy model może samodzielnie wybrać odbiorcę operacji?
Czy narzędzie ponownie sprawdza autoryzację?
Czy wynik jednego agenta staje się instrukcją dla następnego?
Czy człowiek widzi prawdziwy skutek przed zatwierdzeniem?

Ryzyko prompt injection nie znika po dopisaniu do promptu „ignoruj złośliwe instrukcje”. Treść niezaufana i instrukcja sterująca nadal trafiają do mechanizmu interpretującego język. Kontrole muszą istnieć również poza modelem.

3. Prompt injection i odporność instrukcji

Testy obejmują bezpośrednie instrukcje użytkownika oraz pośrednie instrukcje ukryte w stronie, PDF, e-mailu, issue, obrazie lub wyniku narzędzia. Tester próbuje zmienić cel, ujawnić dane, wymusić użycie konektora lub ominąć wymóg zatwierdzenia.

Nie mierzy się wyłącznie tego, czy model wypowie zakazane zdanie. Ważniejsze jest, czy dochodzi do skutku: odczytu pliku, wysłania danych, zmiany rekordu lub wygenerowania niebezpiecznego polecenia. Wynik należy oceniać po wielu parafrazach i wersjach językowych, a przypadki regresyjne zachować w zestawie ewaluacyjnym.

Pełny proces ofensywny opisujemy w przewodniku AI red teaming i pentest LLM.

4. RAG, dane i izolacja tenantów

System retrieval powinien sprawdzać uprawnienia przed wyszukaniem i przed przekazaniem fragmentu do modelu. Filtr podany przez klienta nie może być jedyną kontrolą. Testy wykorzystują dokumenty dwóch tenantów, zasoby usunięte, treści z embargiem i pytania agregujące wiele fragmentów.

Sprawdzane są również poisoning indeksu, złośliwe metadane, usuwanie danych z cache, retencja embeddingów i cytowanie źródeł. Model może „nie pokazać dokumentu”, a mimo to ujawnić jego treść w podsumowaniu. Osobną checklistę zawiera przewodnik bezpieczeństwa RAG.

5. Narzędzia, agenci i uprawnienia

Agent nie powinien działać wspólnym kluczem administratora. Potrzebuje własnej tożsamości, krótkiego tokenu, ograniczonego audience i zakresu przypisanego do zadania. System docelowy musi autoryzować operację niezależnie od decyzji modelu.

Audyt sprawdza:

czy narzędzia odczytu i zapisu są rozdzielone;
czy argumenty mają typowany, mały schemat;
czy istnieją limity czasu, kosztu i liczby działań;
czy operacje nieodwracalne wymagają zatwierdzenia;
czy zatwierdzenie pokazuje obiekt, odbiorcę i skutek;
czy retry nie wykonuje płatności lub wysyłki dwukrotnie;
czy uprawnienia można szybko cofnąć;
czy agent jest izolowany od produkcyjnych sekretów.

Dla kodu i powłoki potrzebny jest sandbox z ograniczeniem systemu plików, sieci i procesów. Szczegóły opisuje architektura sandboxa agentów AI.

6. Prywatność, sekrety i dostawca

Audyt śledzi pełny cykl danych: wejście, logi, cache, trening, eksport, backup i usunięcie. Trzeba potwierdzić warunki dostawcy, region, podprocesorów, retencję i możliwość użycia treści do ulepszania usługi. Sama deklaracja „enterprise” nie opisuje konkretnej konfiguracji konta.

Prompty i odpowiedzi mogą zawierać dane osobowe, kod, umowy i tokeny. Logowanie wszystkiego ułatwia debugging, ale tworzy nowy magazyn wrażliwych danych. Maskowanie sekretów, minimalizacja, kontrola dostępu i retencja powinny być testowane, nie tylko zapisane w polityce.

7. Ewaluacja bezpieczeństwa i jakość

Zestaw testowy powinien obejmować normalne zadania, przypadki graniczne, nadużycia i awarie zależności. Wersjonuje się model, prompt, narzędzia, dane RAG, parametry i kryteria. Średnia skuteczność nie wystarcza, jeśli jeden krytyczny przypadek pozwala wysłać dane klienta.

Raportuj osobno false positive i false negative. Zbyt agresywna kontrola może zablokować prawidłową pracę, przez co użytkownicy znajdą obejście poza systemem. Bramka wdrożeniowa powinna określać niedopuszczalne klasy skutków, nie tylko docelową średnią ocen.

8. Monitoring i incident response

Do rekonstrukcji potrzebne są identyfikatory żądania, wersja modelu, decyzje polityki, źródła RAG, wywołania narzędzi i wynik operacji. Nie należy przy tym utrwalać sekretów ani pełnych danych ponad potrzebę.

Containment może oznaczać wyłączenie narzędzia, cofnięcie tokenu agenta, zamrożenie modelu, odłączenie indeksu lub przejście do trybu read-only. Playbook powinien określać, kto podejmuje te decyzje i jak zachować dowody. Zobacz również playbook reagowania na incydenty AI.

Jak wygląda raport z audytu AI

Raport powinien zawierać:

zakres, wersje i ograniczenia;
diagram architektury oraz przepływu danych;
model zagrożeń i niedopuszczalne skutki;
potwierdzone ścieżki ataku z minimalnym dowodem;
ocenę wpływu technicznego, biznesowego i prawnego;
rekomendacje dla aplikacji, modelu i procesu;
mapę pokrycia testów;
priorytety, właścicieli i kryteria retestu.

Znalezisko „prompt injection” bez skutku jest zbyt ogólne. Raport powinien wskazać, z którego źródła przyszła instrukcja, jaką granicę przekroczyła, jakie narzędzie uruchomiła i jaka kontrola powinna zatrzymać operację.

Checklista przed wdrożeniem

Kiedy zamówić audyt bezpieczeństwa AI

Najlepszy moment to przed produkcją, po dodaniu narzędzi lub RAG, po zmianie dostawcy i przed rozszerzeniem uprawnień. Audyt warto powtórzyć po istotnej zmianie modelu, promptu, indeksu albo architektury, ponieważ poprzedni wynik nie opisuje automatycznie nowej wersji.

Jeżeli system jest jeszcze na etapie projektu, model zagrożeń i review architektury dadzą więcej wartości niż późny jailbreak test. Jeżeli działa produkcyjnie, zakres powinien objąć także konfigurację, monitoring i rzeczywiste tożsamości.

Najczęstsze pytania o audyt AI

Czy audyt może objąć model zamknięty, którego firma nie kontroluje?

Tak. Nie oceni wtedy wewnętrznych wag ani procesu treningowego dostawcy, ale może sprawdzić zachowanie dostępnego API, konfigurację konta, przepływ danych, RAG, narzędzia, tożsamości i zabezpieczenia aplikacji. Raport musi jasno oddzielić elementy przetestowane od tych, które opierają się na dokumentacji lub zapewnieniu dostawcy.

Czy test jailbreak wystarczy dla chatbota bez narzędzi?

Nie. Nawet prosty chatbot może ujawniać dane z kontekstu, przechowywać poufne prompty w logach, błędnie izolować rozmowy albo korzystać z podatnego backendu. Test zachowania modelu jest jednym strumieniem obok klasycznego pentestu, prywatności, retencji i konfiguracji dostawcy.

Jak mierzyć wagę prompt injection?

Po rzeczywistym skutku i wymaganych warunkach. Instrukcja, która zmienia styl odpowiedzi, ma inne znaczenie niż ta, która odczytuje dokument innego klienta albo uruchamia przelew. Raport powinien opisać źródło niezaufanej treści, osiągniętą zdolność, uprawnienia, powtarzalność i kontrolę, która zawiodła.

Jak długo trwa audyt bezpieczeństwa LLM?

Zależy od liczby przepływów, źródeł RAG, narzędzi, ról i środowisk. Prosty chatbot może wymagać kilku dni technicznej pracy, a agent wielonarzędziowy — kilku tygodni. Do harmonogramu trzeba doliczyć model zagrożeń, przygotowanie danych testowych, raport, omówienie i retest.

Czy po zmianie modelu trzeba powtarzać cały audyt?

Nie zawsze. Najpierw wykonuje się analizę wpływu: czy zmienił się dostawca, kontekst, format wywołań narzędzi, filtry lub klasy danych. Zestaw regresyjny powinien zostać uruchomiony ponownie. Pełniejszy audyt jest uzasadniony, gdy nowy model otrzymuje dodatkowe zdolności, większy kontekst albo inne uprawnienia.

Czy audyt bezpieczeństwa sprawdza również halucynacje?

Sprawdza je wtedy, gdy błędna odpowiedź tworzy ryzyko: uruchamia operację, wprowadza klienta w błąd, generuje nieprawidłową poradę lub fałszywie przypisuje źródło. Ogólna jakość języka należy do szerszej ewaluacji produktu. Audyt bezpieczeństwa koncentruje się na scenariuszach nadużycia i szkodliwych skutkach.

Jak Breachroad prowadzi audyty AI

Breachroad łączy klasyczny pentest aplikacji z analizą LLM, RAG i agentów. Zaczynamy od skutków biznesowych, mapujemy przepływ danych i uprawnienia, następnie testujemy niezaufane treści, izolację danych, narzędzia i scenariusze awarii. Krytyczne ścieżki przekazujemy od razu, a raport zawiera dowody oraz rekomendacje możliwe do wdrożenia przez zespół.

Chcesz sprawdzić chatbota, RAG lub agenta przed produkcją? Zobacz usługi bezpieczeństwa AI i testy penetracyjne albo umów scoping call.

Źródła pierwotne: NIST AI RMF, NIST Generative AI Profile, OWASP Top 10 for LLM Applications, OWASP AI Agent Security Cheat Sheet, MITRE ATLAS.