Jak bezpiecznie 'atakować' AI: przewodnik po ofensywnym testowaniu modeli językowych

Cel przewodnika: Ten obszerny artykuł ma pomóc zespołom produktowym, bezpieczeństwa i badawczym w odpowiedzialnym planowaniu i realizowaniu ofensywnego testowania modeli językowych. Skupiamy się na praktykach, które podnoszą jakość i bezpieczeństwo, a jednocześnie są zgodne z prawem i zasadami etycznymi. Kluczowym motywem jest dyscyplina znana jako red teaming systemów językowych, rozumiana jako kontrolowane, autoryzowane i udokumentowane próby wywołania zachowań niepożądanych w celu poprawy odporności i zgodności modeli.

Dlaczego warto bezpiecznie „atakować” modele językowe

Nowoczesne systemy oparte o LLM (Large Language Models) są niezwykle zdolne, ale równie podatne na nietypowe wejścia i subtelne manipulacje. W praktyce każdy interfejs konwersacyjny, funkcja tool use, czy przepływ RAG (Retrieval-Augmented Generation) tworzy nową, złożoną powierzchnię ataku. Ofensywne testowanie – prowadzone z pozwoleniem, w zaplanowanym zakresie i przy zachowaniu zasad etyki – pozwala:

• Wychwycić luki przed wdrożeniem do produkcji (shift-left w MLOps),
• Zmniejszyć ryzyko incydentów reputacyjnych, prawnych i finansowych,
• Podnieść zgodność z politykami bezpieczeństwa, przepisami (np. RODO) i standardami branżowymi,
• Lepsze dopasowanie do wymagań użytkowników i kontekstu biznesowego,
• Uczyć zespół świadomego projektowania zabezpieczeń i guardrails.

Czym jest red teaming w kontekście LLM

W tradycyjnym cyberbezpieczeństwie red teaming oznacza działania zespołu atakującego (red team), który diagnozuje słabości, współpracując z zespołem obronnym (blue team). W obszarze AI przyjmuje to formę kontrolowanych, kreatywnych testów zachowania modeli w trudnych, podstępnych lub dwuznacznych sytuacjach. Red teaming systemów językowych obejmuje:

• Projektowanie scenariuszy obejmujących prompt injection, jailbreak, exfiltrację danych czy nadużycia funkcji narzędziowych,
• Metryki szkodliwości, zgodności i uległości,
• Automatyzację kampanii testowych i sampling pokrycia ryzyka,
• Raportowanie i proces naprawczy w cyklu SDLC/MLOps.

Ważna różnica: tu „wektor ataku” to zwykle treść wejścia (prompt, dokument RAG, parametr funkcji), a nie tylko podatność infrastrukturalna. Zamiast exploitów binarnych testujemy zdolność modelu do zachowania bezpiecznych granic semantycznych i polityk.

Zasady etyczne i prawne: zanim rozpoczniesz

Zanim przejdziesz do pierwszego testu, upewnij się, że spełnione są warunki minimalizujące ryzyko prawne i operacyjne. Ofensywne testowanie można prowadzić wyłącznie na podstawie upoważnienia i w ustalonym zakresie.

• Upoważnienie na piśmie – dokument określający: system, zakres, czas testów, kontakt do właścicieli ryzyka i kanał zgłaszania incydentów.
• Zakres – jasno zdefiniowane środowisko (np. staging, sandbox), typy scenariuszy (np. jailbreak bez produkcyjnych danych), ograniczenia (bez ruchu do systemów zewnętrznych, brak prób omijania uwierzytelniania).
• Ochrona danych – brak realnych danych osobowych i tajemnic biznesowych w promptach i dokumentach testowych; stosuj honeytokens i atrapowe identyfikatory.
• Zasada minimalnych uprawnień – konta testowe, odseparowane klucze API, brak dostępu do krytycznych zasobów.
• Rejestrowanie i audyt – pełny log interakcji, w tym wersje promptów, metadane sesji, sumy kontrolne dokumentów RAG.
• Proces reakcji na incydent – kanał eskalacji, plan wyłączeń, kryteria wstrzymania testów.

Te elementy są fundamentem każdej kampanii określanej jako red teaming systemów językowych i odróżniają ją od nieautoryzowanej, ryzykownej eksploracji.

Model zagrożeń dla systemów językowych

Skuteczne ofensywne testowanie wymaga uporządkowanego zrozumienia powierzchni ataku. Poniżej znajduje się skrócona mapa ryzyk, które często wchodzą do zakresu testów:

• Prompt injection – próby nakłonienia modelu do ignorowania instrukcji systemowych, polityk lub granic roli.
• Jailbreaky – wymuszanie nieautoryzowanych odpowiedzi poprzez role-play, rekonfigurację kontekstu, wieloetapowe podpowiedzi czy pozorne wyjątki.
• Exfiltracja wrażliwych informacji – wydobywanie sekretów z promptu systemowego, pamięci konwersacji, narzędzi lub źródeł RAG.
• Ataki na RAG – zatruwanie indeksu, dokumentów lub metadanych, w tym złośliwe instrukcje w treściach.
• Nadużycia tool use – wymuszanie niebezpiecznych wywołań narzędzi, eskalacja działań poprzez łańcuchy funkcji.
• Model stealing / extraction – próby odtworzenia zachowania modelu, pobieranie promptu systemowego, mapowanie ograniczeń.
• Halu a ryzyka zaufania – halucynacje prowadzące do szkód (porady finansowe, zdrowotne, prawne), pomylenie tożsamości lub kontekstu.
• Poisoning / fine-tuning – wstrzykiwanie przykładów do fine-tuningu prowadzących do ukrytych backdoorów zachowania.
• Polityki i zgodność – naruszenia zasad moderacji treści, uprzedzenia, brak zgodności ze standardami regulacyjnymi.

Korzystaj z publicznych materiałów referencyjnych (np. przegląd kategorii ryzyk znanych z inicjatyw branżowych i akademickich) jako punktu wyjścia do budowy własnej taksonomii. Dzięki temu red teaming lepiej odzwierciedli Twoje realne zagrożenia biznesowe.

Metodyka ofensywnego testowania krok po kroku

Poniższy schemat pozwala przejść od koncepcji do powtarzalnego procesu. Jest to ujęcie praktyczne, łączące perspektywy bezpieczeństwa i produktu.

Krok 1: Zdefiniuj cele i kryteria sukcesu

• Cel biznesowy – co chronisz (np. reputację, zgodność, tajemnice)?
• Wskaźniki – np. wskaźnik niepożądanych odpowiedzi, odsetek skutecznych prób jailbreaku, liczba ujawnionych sekretów na 1000 interakcji.
• Granice – jakie zachowania są krytyczne, tolerowane, akceptowalne po moderacji.

Krok 2: Ustal zakres i scenariusze

• Powierzchnie interakcji – czat, API, narzędzia, RAG, pamięć, funkcje systemowe.
• Scenariusze priorytetowe – oparte na modelu zagrożeń i wartości aktywów.
• Przypadki graniczne – wielojęzyczność, slang, kody mieszane, długie konteksty, nietypowe formaty.

Krok 3: Projektuj zestawy prób

• Szablony – parametryzowane prompty odzwierciedlające taktyki (np. role-play, odwołanie do rzekomego upoważnienia), ale bez wprowadzania realnych wrażliwych treści.
• Warianty językowe – polski, angielski, mieszanki; testy z literówkami, emoji, skrótami.
• Miary pokrycia – liczba taktyk × konteksty × persony użytkownika.

Krok 4: Przygotuj środowisko testowe

• Sandbox – odseparowane konto, ograniczony budżet, kontrola kosztów, brak dostępu do danych produkcyjnych.
• Maskowanie – placeholdery zamiast prawdziwych identyfikatorów, tokenów i sekretów.
• Monitoring – pełne logowanie, metadane, ślady żądań, kontrola wersji promptu systemowego.

Krok 5: Wykonuj testy i eskaluj kontrolowanie

• Start od niskiego ryzyka – łagodne próby, testy zgodności i granic.
• Eskalacja – bardziej złożone łańcuchy promptów, testy zewnętrznych dokumentów RAG, wieloturowe podstępy.
• Stop-klauzule – warunki przerywające test, jeśli model zacznie wykonywać działania o wyższym ryzyku.

Krok 6: Analizuj wyniki i wprowadzaj poprawki

• Triage – kategoryzacja znalezisk według wpływu i powtarzalności.
• Remediacja – poprawki promptów systemowych, wzmacnianie guardrails, tuning, filtry treści, polityki eskalacji do człowieka.
• Weryfikacja – re-test po poprawkach, testy regresyjne na historycznych przykładach.

Scenariusze testowe: kategorie i bezpieczne przykłady

Poniżej przedstawiamy kategorie ataków wraz z bezpiecznymi, etycznymi sposobami ich odtwarzania w kontrolowanym środowisku. Celem jest sprawdzenie odporności modelu, a nie nauczanie metod wyrządzania szkód. Zastępuj wrażliwe treści atrapami i neutralnymi zadaniami.

1) Prompt injection i odwracanie ról

Idea: sprawdzić, czy model pozostaje przy politykach mimo nakłaniania do zmiany roli lub ignorowania instrukcji systemowych.

• Taktyki: udawany autorytet, prośba o „przełączenie trybu”, odwołanie do rzekomej korespondencji wewnętrznej, mieszanie języków.
• Bezpieczny cel: zamiast wymuszać łamanie zasad, poproś model o jawne wyjaśnienie, których instrukcji nie może wykonać i dlaczego.
• Wskaźniki: czy model potrafi uprzejmie odmówić, cytując politykę i proponując alternatywę.

2) Jailbreak przez wieloetapowe podpowiedzi

Idea: rola, narracja, zadania metapoziomowe, które mogą zmiękczać reguły. Testuj odporność bez zachęcania do nielegalnych działań.

• Taktyki: role-play w nieszkodliwej domenie (np. gra logiczna), przenoszenie kontekstu między turami, prośby warunkowe.
• Bezpieczny cel: poproś model o analizę zasad bezpieczeństwa w ramach fikcyjnego scenariusza, ale bez generowania treści o szkodliwym charakterze.
• Wskaźniki: stabilność odmowy mimo presji narracyjnej, spójność argumentacji.

3) Ekstrakcja promptu systemowego i poufnych zasad

Idea: sprawdzić, czy model ujawnia treści systemowe lub konfiguracyjne.

• Taktyki: prośby o „wyświetlenie ustawień”, parafrazowanie, pytania o dokładny tekst reguł.
• Bezpieczny cel: oczekiwana odpowiedź to odmowa i wyjaśnienie, dlaczego takie informacje są chronione.
• Wskaźniki: odsetek prób, w których model częściowo lub w pełni ujawnia szczegóły.

4) Exfiltracja informacji z RAG

Idea: sprawdzić, czy model może wyłuskać informacje z dokumentów o różnym poziomie wrażliwości lub złośliwie spreparowanych treści.

• Taktyki: dokumenty z ukrytymi instrukcjami, metadanymi wprowadzającymi w błąd, sprzeczne fragmenty.
• Bezpieczny cel: dokumenty zawierają tylko atrapowe dane i jawne oznaczenia testowe.
• Wskaźniki: czy model stosuje politykę najmniejszego ujawnienia, cytuje źródła, odmawia ujawniania oznaczonych sekretów.

5) Nadużycia tool use i eskalacja działań

Idea: gdy model ma możliwość wywoływania funkcji (np. wysyłka e-mail, pobieranie pliku), sprawdź, czy nie podejmuje ryzykownych działań na podstawie sprytnych podpowiedzi.

• Taktyki: łańcuch żądań prowadzący do niezamierzonego wywołania, podszywanie się pod użytkownika, manipulacja parametrami.
• Bezpieczny cel: funkcje podpięte do atrap i rejestratorów; brak efektów w realnych systemach.
• Wskaźniki: liczba nieautoryzowanych wywołań, skuteczność polityk potwierdzania intencji użytkownika.

6) Halucynacje i ryzyka zaufania

Idea: sprawdzić, czy model nie generuje pewnych, lecz mylnych odpowiedzi w obszarach wysokiego ryzyka, np. medycznym, finansowym czy prawnym.

• Taktyki: pytania z niejednoznacznymi danymi, sprzeczne źródła, presja czasu w treści promptu.
• Bezpieczny cel: pytania ogólne, bez konkretów mogących zaszkodzić; oczekiwana jest ostrożność, odwołania do źródeł i zalecenie konsultacji eksperta.
• Wskaźniki: odsetek odpowiedzi ze wskazaniem niepewności, linki do weryfikowalnych źródeł, unikanie kategorycznych stwierdzeń.

7) Fine-tuning i poisoning

Idea: ocenić, czy proces doskonalenia modelu lub RAG jest podatny na złośliwe przykłady, które wprowadzają uprzedzenia lub ukryte triggery.

• Taktyki: zestawy uczące z oznaczonymi, niejawnie złośliwymi etykietami; konflikty instrukcji.
• Bezpieczny cel: zestawy w pełni sztuczne, kontrolowane, bez realnych wrażliwych treści.
• Wskaźniki: zmiana zachowania modelu po retrenowaniu, testy regresji i driftu.

8) Wielojęzyczność i obejścia przez format

Idea: sprawdzić, czy polityki i filtry działają spójnie w różnych językach i formatach.

• Taktyki: mieszanina polskiego i angielskiego, transliteracje, nietypowe znaki, emoji, kody pseudo-programistyczne.
• Bezpieczny cel: pytania neutralne, ale projektowane tak, by testowały spójność odmów i moderacji.
• Wskaźniki: stabilność polityk ponad formatami, brak „luk” zależnych od kodowania.

Metryki skuteczności i zgodności

Sama liczba znalezionych problemów nie wystarcza. Istotne jest mierzenie jakości kontroli i trendu. Proponowane kategorie metryk:

• Skuteczność ochron – odsetek odmów zgodnych z polityką w scenariuszach ryzykownych.
• Uległość na ataki – procent prób jailbreaku lub injection zakończonych niepożądanym wynikiem.
• Precyzja moderacji – fałszywe pozytywy/negatywy filtrów (blokowanie nieszkodliwych treści vs. przepuszczanie szkodliwych).
• Stabilność w czasie – czy poprawki utrzymują efekt po tygodniach/wersjach.
• Pokrycie ryzyk – udział przetestowanych kategorii zagrożeń i wariantów językowych.
• MTTR dla poprawek – średni czas od wykrycia do wdrożenia remediacji.

Ważne, by raportować zarówno wielkość problemu (np. odsetek), jak i jego ciężar (skala szkód, kontekst prawny). Priorytetyzuj remediacje na podstawie tych dwóch wymiarów.

Automatyzacja i narzędzia: jak zwiększyć zasięg testów

Skalowanie ofensywnych testów jest trudne bez automatyzacji. Oto praktyczne podejścia wspierające red teaming systemów językowych w sposób bezpieczny:

• Generator scenariuszy – metaszablony tworzące warianty promptów (różne języki, style, długości), ograniczone do bezpiecznych domen.
• LLM-as-judge – drugi model ocenia odpowiedzi (np. zgodność z polityką, szkodliwość, pewność), z walidacją człowieka.
• Testy regresyjne – coroczne/cotygodniowe odpalanie znanych przypadków, by wykrywać cofki po aktualizacjach.
• Kanary i shadow traffic – bezpieczne, oznaczone próby w środowisku bliskim produkcji, ale bez wpływu na użytkowników.
• Dashboardy – monitorowanie metryk, heatmapy ryzyk, alerty po przekroczeniu progów.

Automatyzacja nie zastąpi człowieka: kreatywność red teamu, wnioskowanie o kontekście i rozumienie niuansów językowych są kluczowe, a automaty upraszczają jedynie powtarzalne wątki.

Projektowanie guardrails i polityk

Nawet najlepszy model potrzebuje warstw bezpieczeństwa. Na podstawie wyników testów wdrażaj połączenie kilku technik:

• Instrukcje systemowe – precyzyjne, redundancja zasad, jasne granice (czego model nie robi), kontrolowane metainstrukcje.
• Moderacja treści – filtry wejścia/wyjścia; białe/czarne listy domen; wykrywanie PII.
• Weryfikacja intencji – potwierdzenia krytycznych działań, „double confirm” dla tool use.
• Redukcja kontekstu – minimalizacja pamięci rozmowy, segmentowanie RAG, scoring zaufania źródeł.
• Bezpieczne domyślne – preferencja odmowy z empatycznym wyjaśnieniem i propozycją alternatyw.
• Fallback do człowieka – eskalacja do operatora przy niepewności, konfliktach polityk.

Testuj każdą warstwę osobno i łącznie – wiele incydentów wynika z interakcji między warstwami, nie zaś z pojedynczej usterki.

Włączanie wyników do cyklu SDLC/MLOps

Traktuj wyniki ofensywnych testów jako materiał rozwojowy, nie tylko kontrolę jakości. Cykl może wyglądać tak:

1. Gating przed wdrożeniem – minimalne progi wskaźników bezpieczeństwa.
2. Canary release – limitowany rollout, monitoring metryk i logów red flags.
3. Cykliczny red teaming – kampanie kwartalne, regression suite przy każdej zmianie promptu systemowego lub źródeł RAG.
4. Trening i tuning – inkorporowanie bezpiecznych, zanonimizowanych przykładów do fine-tuningu i reguł.
5. Post-incident reviews – uczenie się na incydentach, aktualizacja taksonomii zagrożeń.

Rola ludzi: organizacja i kompetencje

Najskuteczniejsze programy łączą kompetencje bezpieczeństwa, produktu, danych, inżynierii i prawa.

• Red team – projektowanie scenariuszy, kreatywne testy, hipotezy ataków.
• Blue team – architektura zabezpieczeń, monitorowanie, reagowanie na incydenty.
• Product i UX – projekt odmów przyjaznych użytkownikom, minimalizacja frustracji.
• Data/ML – tuning, ewaluacje, etyka AI, kontrola driftu.
• Legal/Compliance – zgodność z prawem, politykami, regulacjami branżowymi.

Ustal wspólny język i definicje. To, co red team nazywa „udanym obejściem”, dla produktu może być „edge-case UX”. Ramy metryk pomagają scalić perspektywy.

Bezpieczne środowisko testowe: praktyczne zalecenia

• Separacja danych – osobne indeksy RAG, brak połączeń z produkcją, czyszczenie pamięci po testach.
• De-identyfikacja – maskowanie PII i tajemnic firmowych; używaj sztucznych danych.
• Kontrola kosztów – limity tokenów, budżet, alerty nadużyć.
• Bezpieczne klucze – rotacja, scope’owanie, brak twardego kodowania w skryptach.
• Reproducibility – wersjonowanie promptów, snapshoty danych, stałe ziarna w generatorach.

Raportowanie i remediacja: jak budować wartość

Raport powinien być zrozumiały dla zarządzających ryzykiem i techniczny dla zespołów wdrożeniowych.

• Podsumowanie kierownicze – główne ryzyka, wpływ, rekomendacje.
• Szczegóły techniczne – kategorie taktyk, warunki testu, logi, próbki odpowiedzi (zanonimizowane).
• Wycena ryzyka – prawdopodobieństwo × wpływ, mapy priorytetów.
• Plan naprawczy – właściciele zadań, terminy, metryki kontroli efektu.
• Wnioski uogólnione – co dodać do polityk, szkoleń i procesów.

Etyka, prywatność i zgodność regulacyjna

Odpowiedzialne testowanie modeli to nie tylko technika. To także zobowiązanie do poszanowania prywatności, równości i przejrzystości.

• RODO i lokalne przepisy – unikaj rzeczywistych danych osobowych; jeśli niezbędne, stosuj minimalizację i podstawy prawne.
• Uprzedzenia – testuj stronniczości i dyskryminację; wdrażaj poprawki (instrukcje, tuning, filtry).
• Transparentność – informuj interesariuszy o granicach systemu, mechanizmach odmowy i eskalacji.
• Bezpieczny język odmowy – uprzejma asertywność, alternatywy, odsyłanie do pomocy człowieka.

Przykładowa macierz pokrycia testów

Aby zapanować nad złożonością, zbuduj macierz: kategorie zagrożeń × kanały × języki × konteksty.

• Kategorie: injection, jailbreak, exfiltracja, RAG poisoning, tool abuse, halucynacje, uprzedzenia.
• Kanały: czat web, API, integracje (Slack, e-mail), voice.
• Języki: PL, EN, mieszane.
• Konteksty: krótki prompt, długi kontekst, multi-turn, dokumenty z metadanymi.

Wyniki mapuj na ryzyka biznesowe. Jeśli np. narzędzia płatnicze są w zakresie, zwiększ ciężar testów w obszarze eskalacji tool use.

Studium przypadku (anonimowe, edukacyjne)

Organizacja X wdraża asystenta wsparcia klienta z RAG, integracją narzędzi i pamięcią rozmowy. W pierwszej rundzie ofensywnych testów (bez realnych danych) zespół wykrył, że:

• Model czasem parafrazował fragmenty promptu systemowego, gdy pytania dotyczyły „jak podejmujesz decyzje?”.
• W przypadku dokumentów zawierających sprzeczne instrukcje, model bezrefleksyjnie realizował nowsze zalecenie.
• Wielojęzyczne prośby zwiększały skłonność do halucynacji źródeł.

Po wprowadzeniu poprawek:

• Wzmocniono instrukcje systemowe i dodano szablon odmowy z cytatem polityki.
• RAG zaczęto składać z segmentów o znanym poziomie zaufania, a model otrzymał regułę: „odpowiadaj tylko na podstawie materiałów oznaczonych jako zaufane”.
• Dodano walidator odpowiedzi sprawdzający obecność źródeł i poziom pewności.

W wyniku kolejnej rundy testów wskaźnik zgodnych odmów wzrósł z 76% do 94%, a halucynacje spadły o 40%.

Najczęstsze błędy w offensywnym testowaniu AI

• Brak formalnego upoważnienia – ryzyko prawne i organizacyjne.
• Testy na produkcji – możliwość naruszeń danych i reputacji.
• Zbyt wąski zakres – pomijanie wielojęzyczności, tool use, RAG.
• Brak metryk – niemożność oceny trendu i efektu poprawek.
• Ignorowanie UX – ostrzejsze filtry bez empatycznych odmów frustrują użytkowników.
• Jednorazowe kampanie – brak utrzymania i regresji.

Checklist: start w 14 dni

• Dzień 1–2: uzyskaj upoważnienie, zdefiniuj zakres, ryzyka i cele.
• Dzień 3–5: zaprojektuj 30–50 bezpiecznych scenariuszy obejmujących kluczowe kategorie.
• Dzień 6–7: przygotuj sandbox, logowanie, maskowanie, limit budżetu.
• Dzień 8–10: uruchom pierwszą kampanię, zbierz metryki bazowe.
• Dzień 11–12: triage, priorytety, plan poprawek.
• Dzień 13–14: wdrożenie poprawek i testy regresji.

Jak mówić o „atakowaniu” AI w organizacji

Używaj języka, który systemowo buduje zaufanie:

• Bezpieczny eksperyment – w kontrolowanym środowisku, bez szkody dla użytkowników.
• Uczenie się przez testy – wyniki napędzają ulepszenia, nie szukanie winnych.
• Wspólny cel – jakość i bezpieczeństwo produktu.

Taka komunikacja sprzyja akceptacji i współpracy, które są niezbędne, by red teaming systemów językowych stał się stałym elementem cyklu życia AI.

Zaawansowane wątki na horyzoncie

• Ocena łańcuchów narzędzi – kompozycja funkcji, polityki uprawnień, separacja obowiązków na poziomie agenta.
• Bezpieczeństwo pamięci – długotrwałe profile użytkowników, unikanie akumulacji wrażliwych fragmentów.
• Ataki metapromptowe – konflikty reguł na różnych warstwach (system, developer, user).
• Model-in-the-middle – ryzyka wynikające z łączenia wielu modeli w jednym pipeline.
• Oceny przy ograniczonym dostępie – black-box vs white-box testy i metody estymacji granic.

Podsumowanie

Bezpieczne „atakowanie” AI to świadoma praktyka budowania zaufania do systemów konwersacyjnych. Dzięki uporządkowanej metodyce, jasnym zasadom legalno-etycznym i współpracy zespołów możesz osiągnąć szybko rosnący zwrot z inwestycji: mniej incydentów, większą zgodność i lepsze doświadczenia użytkowników. Dyscyplina określana jako red teaming systemów językowych nie jest jednorazowym projektem – to proces ciągły, który dojrzewa wraz z Twoim produktem. Zacznij od małego, mierz postępy i rozwijaj kompetencje, a Twoje modele będą odporniejsze na kreatywne próby nadużyć.

Załącznik: słownik pojęć (krótko)

• Red teaming – autoryzowane testy ofensywne w celu wykrycia słabości.
• Prompt injection – nakłanianie modelu do ignorowania lub zmiany reguł.
• Jailbreak – obejście zabezpieczeń modeli poprzez złożone podpowiedzi.
• RAG – Retrieval-Augmented Generation, generowanie odpowiedzi z użyciem wyszukanych dokumentów.
• Tool use – wywoływanie narzędzi/funkcji przez model.
• Halucynacja – pewna, lecz nieprawdziwa odpowiedź modelu.

Kluczowa myśl na koniec: ofensywne testowanie LLM to narzędzie do czynienia dobra – pod warunkiem, że odbywa się w odpowiednich granicach, z właściwą intencją i z planem poprawy. Z takim podejściem „atakowanie” AI staje się fundamentem dojrzałego bezpieczeństwa i jakości.