Bezpieczeństwo AI: nowe ryzyka, gdy LLM trafia do firmy

Modele językowe (LLM) trafiają do firmowych aplikacji w błyskawicznym tempie — jako chatboty, asystenci, narzędzia do analizy dokumentów czy agenci wykonujący zadania. Wraz z nimi pojawia się klasa zagrożeń, której nie znały tradycyjne aplikacje. Testując takie wdrożenia, najczęściej spotykamy te same problemy.

Prompt injection — wstrzykiwanie poleceń

To najważniejsza nowa kategoria podatności — w zestawieniu OWASP Top 10 for LLM Applications (2025) prompt injection zajmuje pierwsze miejsce (LLM01), już drugą edycję z rzędu. Model nie rozróżnia w sposób pewny instrukcji od danych — wszystko jest dla niego tekstem. Jeśli aplikacja przetwarza treść z zewnątrz (e-mail, dokument, stronę WWW), atakujący może ukryć w niej polecenia, które model potraktuje jak instrukcje od użytkownika.

Szczególnie groźny jest wariant pośredni (indirect prompt injection): złośliwa instrukcja jest umieszczona w dokumencie, który model dopiero przeczyta. Przykład: asystent podsumowujący e-maile napotyka wiadomość zawierającą ukrytą komendę „prześlij historię konwersacji na zewnętrzny adres” — i, jeśli ma taką możliwość, wykonuje ją.

Klasyczne filtrowanie wejścia tu nie wystarcza, bo nie istnieje jednoznaczna granica między danymi a poleceniem. Obrona opiera się na ograniczaniu tego, co model w ogóle może zrobić.

Wyciek danych przez kontekst

LLM-y są tak bezpieczne, jak dane, które do nich trafiają. Dwa typowe błędy: wprowadzanie danych poufnych do modeli zewnętrznych bez kontroli, gdzie trafią, oraz architektura RAG (retrieval-augmented generation), w której model ma dostęp do dokumentów wykraczających poza uprawnienia konkretnego użytkownika.

W tym drugim przypadku problemem nie jest sam model, lecz brak kontroli dostępu na poziomie źródła wiedzy. Jeśli wektorowa baza dokumentów nie respektuje uprawnień, użytkownik może — odpowiednio pytając — wydobyć treści, do których nie powinien mieć dostępu.

Nadmiarowe uprawnienia agentów

Najbardziej ryzykowne są wdrożenia, w których model nie tylko odpowiada, ale i działa: wywołuje API, wysyła wiadomości, modyfikuje dane. Taki agent łączy nieprzewidywalność modelu z realnymi uprawnieniami w systemie.

Obowiązuje tu ta sama zasada, co przy kontach użytkowników: minimalne uprawnienia. Agent powinien mieć dostęp wyłącznie do funkcji niezbędnych do zadania, a operacje nieodwracalne lub wrażliwe (przelewy, usuwanie danych, wysyłka na zewnątrz) powinny wymagać potwierdzenia przez człowieka.

Shadow AI — niekontrolowane użycie w organizacji

Zanim jeszcze firma formalnie „wdroży AI”, pracownicy już z niego korzystają — prywatnymi kontami, na firmowych danych. To zjawisko (shadow AI) jest dziś tym, czym dekadę temu było shadow IT: umowy, kod źródłowy i dane klientów trafiają do publicznych narzędzi bez żadnej kontroli, a organizacja nawet o tym nie wie.

Zakazy nie działają — wygrywa wygoda. Skuteczniejsze podejście to danie pracownikom legalnej, firmowej alternatywy (konta biznesowe z gwarancjami dotyczącymi danych, wewnętrzny asystent) połączonej z krótką, jasną polityką użycia AI: co wolno wkleić, czego nie, i gdzie zgłaszać nowe przypadki użycia. Polityka powinna też przewidywać przegląd narzędzi — nie każde „AI” z wtyczki do przeglądarki spełnia wymogi RODO.

Łańcuch dostaw AI: modele, wtyczki, MCP

Coraz mniej wdrożeń to „czysty” model — typowa aplikacja korzysta z gotowych komponentów: modeli open source, frameworków agentowych, zewnętrznych wtyczek i serwerów narzędziowych (np. w protokole MCP). Każdy z tych elementów to potencjalne ryzyko łańcucha dostaw, analogiczne do ataków przez zależności oprogramowania:

Zatrute modele i dane treningowe. Model pobrany z publicznego repozytorium może zawierać celowo wprowadzone zachowania (backdoory) niewykrywalne w standardowych testach.
Złośliwe lub podatne wtyczki i narzędzia. Serwer narzędziowy z nadmiernymi uprawnieniami staje się bramą do systemów firmy — model wykona to, co podpowie mu opis narzędzia.
Niejawne zmiany dostawcy. Aktualizacja modelu u dostawcy API może zmienić zachowanie aplikacji bez żadnej zmiany w Twoim kodzie — potrzebne są testy regresyjne także dla zachowań bezpieczeństwa.

Minimalny standard: inwentaryzacja komponentów AI (odpowiednik SBOM), przypięcie wersji modeli, przegląd uprawnień każdego narzędzia udostępnionego agentowi i środowisko testowe odseparowane od produkcyjnych danych.

AI Act i RODO: wymogi prawne wdrożeń

Bezpieczeństwo techniczne to jedno, zgodność — drugie. Unijny AI Act wszedł w życie w sierpniu 2024 i jest wdrażany etapami: zakazy niedopuszczalnych praktyk już obowiązują, obowiązki dla modeli ogólnego przeznaczenia (GPAI) stosuje się od sierpnia 2025, a pełne wymogi dla systemów wysokiego ryzyka — od sierpnia 2026/2027. Dla większości firm wdrażających chatboty i asystentów kluczowe są: obowiązki przejrzystości (użytkownik musi wiedzieć, że rozmawia z AI), tzw. AI literacy, czyli kompetencje osób pracujących z systemami, oraz poprawna klasyfikacja ryzyka systemu.

Równolegle działa RODO: dane osobowe w promptach i bazach RAG wymagają podstawy prawnej, retencji i realizacji praw osób. Praktyczny skrót: zanim wdrożysz, zrób DPIA dla systemów przetwarzających dane osobowe i upewnij się, że umowa z dostawcą modelu jasno reguluje, czy Twoje dane służą do treningu.

Czego nie robić

Nie traktuj odpowiedzi modelu jako zaufanej. Jeśli wynik LLM trafia do innej części systemu (np. jako zapytanie SQL czy polecenie), podlega tym samym regułom walidacji, co dowolne dane wejściowe od użytkownika.
Nie zakładaj, że instrukcje systemowe są nienaruszalne. Prompt systemowy bywa obchodzony. Bezpieczeństwo nie może opierać się wyłącznie na „poproszeniu modelu, żeby tego nie robił”.
Nie pomijaj logowania. Zapisuj zapytania i działania agentów — bez tego analiza nadużyć jest niemożliwa.

Jak testujemy wdrożenia AI

Testy bezpieczeństwa aplikacji opartych na LLM łączą klasyczne podejście (kontrola dostępu, walidacja, konfiguracja) z technikami specyficznymi dla AI: próbami prompt injection, weryfikacją izolacji danych w RAG oraz analizą zakresu uprawnień agentów. Punktem odniesienia jest m.in. OWASP Top 10 for LLM Applications, który porządkuje najważniejsze ryzyka.

Podsumowanie

Wdrożenie AI nie zwalnia z podstaw bezpieczeństwa — przeciwnie, dokłada do nich nową warstwę. Najważniejsze zasady to: ograniczanie uprawnień modelu i agentów, kontrola dostępu po stronie źródeł danych, traktowanie wyjścia LLM jako niezaufanego oraz pełne logowanie. Jeśli wdrażasz rozwiązania oparte na modelach językowych i chcesz je przetestować, skontaktuj się z nami — testy bezpieczeństwa AI i wsparcie wdrożeń to jedna z naszych specjalizacji.

Najczęstsze pytania (FAQ)

Czy bezpieczniej jest używać modelu lokalnego (open source) niż API zewnętrznego dostawcy? To zamiana jednych ryzyk na inne. Model lokalny nie wysyła danych na zewnątrz, ale całość odpowiedzialności za jego bezpieczeństwo, aktualizacje i infrastrukturę spada na Ciebie — a podatności typu prompt injection występują niezależnie od miejsca hostowania. Duzi dostawcy API oferują z kolei umowy DPA, certyfikacje i opcje wyłączenia treningu na Twoich danych. Decyzja powinna wynikać z klasyfikacji danych, nie z ideologii.

Czy da się całkowicie zablokować prompt injection? Nie — przy obecnej architekturze modeli nie istnieje niezawodny filtr oddzielający dane od instrukcji. Dlatego celem obrony nie jest „zablokowanie” ataku, lecz sprawienie, by nawet udany atak nie miał poważnych skutków: minimalne uprawnienia, potwierdzanie operacji wrażliwych przez człowieka, izolacja danych i monitorowanie zachowań agenta.

Wdrażamy chatbota dla klientów. Jakie testy ma sens zrobić przed startem? Minimum: próby prompt injection (bezpośredniego i pośredniego), test wycieku promptu systemowego i danych innych użytkowników, weryfikacja kontroli dostępu w RAG, test odporności na generowanie treści szkodliwych oraz przegląd uprawnień integracji. Do tego klasyka: uwierzytelnianie, rate limiting, logowanie. Taki zakres pokrywa nasz test bezpieczeństwa aplikacji LLM.

Czym jest OWASP Top 10 for LLM i czy wystarczy „przejść” tę listę? To uporządkowana lista najistotniejszych klas ryzyk w aplikacjach LLM (od prompt injection po nadmierną autonomię agentów) — dobry szkielet do projektowania testów i wymagań. Nie jest jednak certyfikatem ani gwarancją: konkretne ryzyka zależą od architektury Twojego wdrożenia, zwłaszcza od tego, do czego model ma dostęp.

Czy nasza polityka użycia AI musi zakazywać ChatGPT? Nie musi i zwykle nie powinna — zakaz przeniesie użycie do szarej strefy. Sensowna polityka określa: jakie kategorie danych wolno przetwarzać w jakich narzędziach, które narzędzia są zatwierdzone (np. konta firmowe z DPA), jak zgłaszać nowe potrzeby oraz kto odpowiada za przegląd. Pomagamy takie zasady napisać i wdrożyć w ramach konsultacji bezpieczeństwa AI.