W poniedziałek zespół sprzedaży pokazuje zarządowi asystenta, który w kilka sekund odpowiada na pytania o warunki umów. We wtorek ktoś zauważa, że ten sam asystent cytuje fragment umowy z innym klientem, bo indeks dokumentów zbudowano z całego udziału sieciowego. W środę okazuje się, że klucz API do usługi modelu leży w publicznym repozytorium kodu od dwóch miesięcy. Żaden z tych incydentów nie wymagał ataku na sam model językowy.
Tak zwykle wygląda bezpieczeństwo AI w praktyce: ryzyko rzadko siedzi w samym modelu, a prawie zawsze w środowisku wokół niego — w tożsamościach, kluczach, danych, integracjach, dostawcach i lukach w monitoringu. Ten przewodnik pokazuje, jak zabezpieczyć AI w firmie domena po domenie, istniejącymi mechanizmami cyberbezpieczeństwa, i kończy się mapą ryzyk i kontroli z planem działań na pierwsze trzy miesiące.
Czym bezpieczeństwo środowisk AI różni się od ochrony samych modeli?
Bezpieczeństwo środowisk AI obejmuje wszystko, co otacza model: kto i czym się do niego uwierzytelnia, jakie dane do niego trafiają, z jakimi systemami jest połączony, kto go dostarcza i czy zespół bezpieczeństwa widzi, co się z nim dzieje. Ochrona samego modelu to węższy wycinek: integralność danych treningowych, odporność na ataki adversarial, kradzież modelu. Ten wycinek opisujemy osobno w artykule o tym, jak chronić modele AI i dane treningowe przed atakami.
Różnica ma znaczenie praktyczne. Większość firm nie trenuje własnych modeli. Kupuje dostęp do modelu przez API, włącza funkcje AI w aplikacjach SaaS albo buduje aplikację, która łączy gotowy model z własnymi dokumentami. W każdym z tych przypadków firma nie kontroluje wag modelu, ale kontroluje dostęp, dane i integracje. To tam leży większość decyzji, za które odpowiada CISO.
Hasło bezpieczeństwo AI ma więc dwa piętra. Pierwsze to bezpieczeństwo systemów AI jako aktywów firmy, czyli temat tego przewodnika. Drugie to użycie AI w obronie, na przykład w analizie zdarzeń w SOC, które jest osobnym zagadnieniem. Mieszanie obu pięter prowadzi do sytuacji, w której firma kupuje narzędzie z „AI” w nazwie, a jej własny asystent nadal ma dostęp do wszystkich plików.
Dobra wiadomość jest taka, że nie trzeba budować programu od zera. Rama NIST AI Risk Management Framework (AI RMF 1.0, opublikowana 26 stycznia 2023 r.) jest dobrowolna i opiera się na czterech funkcjach: GOVERN, MAP, MEASURE i MANAGE. Pierwsza warstwa trójwarstwowej ramy ENISA, Multilayer Framework for Good Cybersecurity Practices for AI z 7 czerwca 2023 r., to po prostu podstawy cyberbezpieczeństwa. Obie ramy mówią to samo: AI dziedziczy istniejące kontrole i dokłada do nich kilka własnych.
Jak zbudować inwentarz systemów i użyć AI w firmie?
Inwentarz AI to rejestr trzech kategorii: systemów AI, które firma buduje, usług AI, które kupuje, oraz funkcji i narzędzi AI, z których pracownicy korzystają — z wiedzą działu IT albo bez niej. Bez takiej listy każda kolejna kontrola jest częściowa, bo nie wiadomo, czego dotyczy.
Pierwsza kategoria jest najłatwiejsza do spisania: aplikacje z modelem językowym, chatboty dla klientów, asystenci wewnętrzni, automatyzacje z agentami. Każdy taki system ma repozytorium kodu, środowisko uruchomieniowe i zespół, więc wystarczy dopisać go do rejestru aplikacji i oznaczyć, że korzysta z modelu.
Druga kategoria to usługi kupowane: dostęp do modeli przez API, platformy do budowy aplikacji AI, a także funkcje AI dodane przez dostawców do aplikacji, których firma używa od lat. Ta ostatnia grupa umyka najczęściej. Dostawca CRM, systemu helpdesk albo pakietu biurowego włącza asystenta w ramach aktualizacji, a firma dowiaduje się o tym z newslettera. Dlatego inwentarz trzeba odświeżać przy każdym przeglądzie umów z dostawcami SaaS.
Trzecia kategoria to narzędzia używane przez pracowników na własną rękę: czatboty na prywatnych kontach, rozszerzenia przeglądarki, aplikacje do transkrypcji spotkań. Tę warstwę nazywa się shadow AI, a jej wykrywanie z logów DNS, proxy i CASB opisujemy szczegółowo w przewodniku o tym, jak wykryć i ograniczyć shadow AI.
Dla każdej pozycji inwentarza warto zapisać co najmniej: właściciela biznesowego, właściciela technicznego, dostawcę modelu, kategorie danych, które system przetwarza, sposób uwierzytelniania, integracje z innymi systemami i rolę firmy w rozumieniu AI Act. Ostatnie pole wróci przy wymaganiach prawnych. Rejestr może żyć w istniejącym CMDB — ważniejsze od narzędzia jest to, żeby był jeden i żeby ktoś odpowiadał za jego aktualność.
Inwentarz od razu podpowiada kolejność dalszej pracy. Najpierw warto zająć się systemami, które spełniają co najmniej dwa z trzech warunków: przetwarzają dane poufne albo osobowe, są dostępne dla klientów lub partnerów spoza firmy i mogą wykonywać operacje w innych systemach, a nie tylko odpowiadać. Asystent wewnętrzny bez dostępu do dokumentów to inna klasa ryzyka niż chatbot obsługi klienta połączony z CRM. Takie proste kryteria pozwalają uniknąć sytuacji, w której zespół bezpieczeństwa przez kwartał analizuje najbardziej widoczny projekt, a najbardziej ryzykowny działa bez nadzoru.
Jak kontrolować tożsamość, klucze API i uprawnienia w systemach AI?
Systemy AI trzeba objąć tym samym zarządzaniem tożsamością co pozostałe aplikacje, z dodatkową uwagą na trzy elementy: klucze API do usług modeli, konta usług używane przez integracje i uprawnienia, z jakimi model sięga po dane. To w tej domenie powstaje najwięcej incydentów, które z AI mają wspólną tylko nazwę.
Klucz API do usługi modelu działa jak hasło do konta z budżetem. Kto go ma, może wysyłać zapytania na koszt firmy, a czasem także czytać historię rozmów albo pliki wgrane do usługi. Klucze trzeba trzymać w sejfie na sekrety, nie w kodzie ani w plikach konfiguracyjnych, rotować według harmonogramu i natychmiast po odejściu osoby, która je znała, a repozytoria skanować pod kątem wycieku sekretów. Osobne klucze dla środowisk testowych i produkcyjnych ułatwiają też analizę, gdy coś pójdzie nie tak.
Konta usług to druga pułapka. Integracja, która pobiera dokumenty do indeksu wyszukiwania albo wykonuje operacje w systemie biletowym, zwykle działa na koncie technicznym. Takie konto często dostaje uprawnienia „na wszelki wypadek”, bo tak było szybciej przy pierwszym uruchomieniu. Zasada najmniejszych uprawnień obowiązuje tu bardziej niż gdziekolwiek, bo konto usługi jest używane automatycznie, przez całą dobę i bez człowieka, który zauważyłby nietypowe żądanie.
Trzeci element to uprawnienia, z jakimi model widzi dane. Asystent, który odpowiada na podstawie dokumentów, powinien widzieć tylko to, do czego ma dostęp pytający użytkownik — nie wszystko, co widzi konto techniczne. Jeżeli architektura aplikacji tego nie zapewnia, każdy użytkownik asystenta zyskuje pośrednio dostęp do całego indeksu. To samo dotyczy gotowych asystentów biurowych: dziedziczą uprawnienia użytkownika, więc nadmiarowe udostępnienia w repozytoriach plików stają się widoczne w ich odpowiedziach.
Uprawnienia kont usług i integracji AI warto przeglądać w tym samym cyklu co dostęp uprzywilejowany, a nie raz, przy uruchomieniu. Projekty AI szybko się rozrastają: integracja, która miała czytać jedną bibliotekę dokumentów, po kilku tygodniach obsługuje trzy kolejne, a konto techniczne zachowuje wszystkie nadane po drodze uprawnienia.
Na koniec tożsamość użytkowników. Dostęp do konsol administracyjnych usług AI, platform do budowy aplikacji i portali dostawców modeli wymaga uwierzytelniania wieloskładnikowego i logowania przez firmowego dostawcę tożsamości. Konto założone na prywatny adres e-mail w portalu dostawcy modelu to konto, którego firma nie wyłączy po odejściu pracownika.
Jak chronić dane, które trafiają do modeli i asystentów AI?
Dane chroni się w trzech punktach: na wejściu, czyli w promptach i wgrywanych plikach, w indeksach i bazach wiedzy, z których model korzysta, oraz tam, gdzie usługi AI przechowują historię rozmów i logi. W każdym z tych punktów działa ta sama podstawa: wiedza, które dane są wrażliwe, i reguły, dokąd wolno je wysyłać.
Punktem wyjścia jest klasyfikacja danych. Firma, która nie oznaczyła umów, danych osobowych i kodu źródłowego, nie skonfiguruje sensownych reguł dla AI, bo reguły nie mają się do czego odwołać. Etykiety poufności i kontrole przepływu danych, które działają już dla poczty i chmury, warto rozszerzyć na usługi AI: zablokować wysyłanie danych oznaczonych jako poufne do niezatwierdzonych narzędzi, ostrzegać przy wklejaniu dużych fragmentów kodu i rejestrować wyjątki. Szczegółowy przegląd takich kontroli opisuje artykuł o tym, jak zatrzymać wyciek danych do ChatGPT i asystentów AI.
Drugi punkt to indeksy i bazy wiedzy. Aplikacja RAG, czyli łącząca model z wyszukiwaniem w dokumentach firmy, jest tak bezpieczna, jak dokumenty, które do niej wpuszczono. Jeśli do indeksu trafiły dokumenty kadrowe albo umowy z jednym klientem, asystent może je zacytować komuś, kto nie powinien ich zobaczyć. Zakres indeksu trzeba więc ustalić świadomie, a uprawnienia do dokumentów przenieść do warstwy wyszukiwania.
Osobnym zagadnieniem jest integralność danych, z których korzystają modele. Złośliwie zmieniony dokument w bazie wiedzy albo zmanipulowany zbiór danych do dostrajania modelu to data poisoning, czyli zatruwanie danych. CISA, NSA, FBI i partnerzy międzynarodowi opisali ryzyka wynikające z problemów z bezpieczeństwem i integralnością danych w dokumencie AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems z 22 maja 2025 r. i podkreślają, że dotyczą one wszystkich faz cyklu życia AI. W praktyce oznacza to kontrolę, kto może dodawać i zmieniać dokumenty w źródłach RAG, oraz rejestrowanie tych zmian.
Trzeci punkt to retencja. Usługi AI przechowują historię rozmów, wgrane pliki i logi zapytań według własnych zasad. Firma powinna wiedzieć, gdzie te dane leżą, jak długo i kto ma do nich dostęp — zarówno po stronie dostawcy, jak i we własnych systemach, do których trafiają logi aplikacji.
Najważniejsze:
- Inwentarz AI obejmuje systemy budowane, usługi kupowane i narzędzia używane przez pracowników bez wiedzy IT.
- Klucze API do usług modeli wymagają sejfu na sekrety, rotacji i skanowania repozytoriów.
- Asystent ma widzieć dane z uprawnieniami pytającego użytkownika, nie konta technicznego.
- Bez klasyfikacji danych reguły dla AI nie mają się do czego odwołać.
Jakie ryzyka niosą aplikacje LLM i RAG i jak je testować?
Najlepiej udokumentowaną listą ryzyk aplikacji opartych na dużych modelach językowych jest OWASP Top 10 for LLM Applications 2025 — i to ją warto przyjąć jako wspólny język między zespołem bezpieczeństwa, deweloperami i dostawcą testów. Lista obejmuje dziesięć kategorii, od prompt injection po niekontrolowane zużycie zasobów.
Na pierwszym miejscu stoi prompt injection, czyli wstrzyknięcie instrukcji, które zmieniają zachowanie modelu wbrew intencji twórcy aplikacji. W wersji bezpośredniej robi to użytkownik w okienku czatu. W wersji pośredniej instrukcja jest ukryta w dokumencie, stronie internetowej albo e-mailu, który model przetwarza. Wersja pośrednia jest groźniejsza dla firm, bo atakujący nie musi mieć dostępu do aplikacji — wystarczy, że jego treść trafi do źródeł, które aplikacja czyta.
Pozostałe kategorie da się pogrupować według tego, czego dotyczą. Ujawnienie informacji wrażliwych (LLM02) i wyciek promptu systemowego (LLM07) to ryzyka poufności. Zatruwanie danych i modeli (LLM04) oraz słabości wektorów i osadzeń (LLM08) dotyczą integralności źródeł, z których korzysta RAG. Niewłaściwa obsługa wyjścia (LLM05) i nadmierna sprawczość (LLM06) to ryzyka, które ujawniają się wtedy, gdy odpowiedź modelu trafia dalej — do przeglądarki, do bazy danych albo do narzędzia, które wykonuje operacje.
| Kategoria OWASP 2025 | Pytanie testowe przed udostępnieniem | Typowa kontrola |
|---|---|---|
| LLM01 Prompt Injection | Czy treść dokumentu albo strony zmienia zachowanie asystenta? | separacja instrukcji od danych, filtry, ograniczenie narzędzi |
| LLM02 Sensitive Information Disclosure | Czy asystent zwraca dane spoza uprawnień użytkownika? | uprawnienia w warstwie wyszukiwania, kontrola zakresu indeksu |
| LLM04 Data and Model Poisoning | Kto może dodać lub zmienić dokument w źródłach RAG? | kontrola zmian i rejestr modyfikacji źródeł |
| LLM05 Improper Output Handling | Czy odpowiedź modelu trafia bez walidacji do HTML, SQL albo powłoki? | walidacja i kodowanie wyjścia jak dla danych od użytkownika |
| LLM06 Excessive Agency | Jakie operacje model może wykonać bez potwierdzenia człowieka? | lista dozwolonych narzędzi, potwierdzenia dla operacji zmieniających |
| LLM07 System Prompt Leakage | Czy prompt systemowy zawiera sekrety albo reguły dostępu? | sekrety poza promptem, autoryzacja poza modelem |
| LLM10 Unbounded Consumption | Czy jeden użytkownik może wygenerować dowolnie duży koszt? | limity zapytań i budżetów na klucz |
Takiej tabeli nie wypełnia się raz. Zachowanie aplikacji LLM zależy od modelu, promptu systemowego, zakresu danych i dostępnych narzędzi, więc każda zmiana któregoś z tych elementów zmienia też powierzchnię ataku. Dlatego testy trzeba powtarzać po zmianie modelu, dodaniu źródła danych albo nowego narzędzia, a nie tylko przed pierwszym uruchomieniem.
Same testy funkcjonalne nie wystarczą, bo sprawdzają, czy aplikacja robi to, co powinna, a nie czy da się ją zmusić do czegoś innego. Do tego służą testy penetracyjne aplikacji AI/LLM, w których tester próbuje prompt injection, wydobycia promptu systemowego, obejścia uprawnień do dokumentów i nadużycia narzędzi. Ramy oceny ryzyka LLM w ujęciu całego przedsiębiorstwa porządkuje osobny artykuł: bezpieczeństwo LLM — framework oceny ryzyka.
Jak zabezpieczyć agentów AI i ich integracje z narzędziami?
Agenta AI zabezpiecza się przede wszystkim przez ograniczenie tego, co może zrobić: listę narzędzi, z których korzysta, uprawnienia kont, na których działa, i operacje, które wymagają potwierdzenia człowieka. Agent różni się od asystenta tym, że nie tylko odpowiada, ale wykonuje działania — wysyła wiadomości, zmienia rekordy, uruchamia skrypty.
Ta różnica sprawia, że skutki prompt injection rosną. Asystent, któremu wstrzyknięto instrukcję, może najwyżej powiedzieć coś niewłaściwego. Agent z dostępem do poczty i systemu plików może tę instrukcję wykonać: przesłać dokument na zewnątrz albo usunąć dane. OWASP nazywa to ryzyko nadmierną sprawczością (Excessive Agency, LLM06) i wskazuje, że jego źródłem są zwykle zbyt szerokie funkcje, zbyt szerokie uprawnienia albo zbyt duża autonomia. Ten podział jest praktyczny, bo każdej przyczynie odpowiada inna kontrola: zbędne funkcje usuwa się z listy narzędzi, uprawnienia ogranicza na koncie, na którym agent działa, a autonomię — przez potwierdzenia człowieka przy wybranych operacjach.
Agenci łączą się z narzędziami przez integracje, coraz częściej przez serwery Model Context Protocol (MCP). Każdy taki serwer to nowy kod z dostępem do danych, często pobrany z publicznego repozytorium. Opis narzędzia, który agent czyta, może zawierać ukryte instrukcje, a serwer może po aktualizacji zmienić zachowanie. Te zagadnienia, razem z autoryzacją i izolacją serwerów, rozwija przewodnik o bezpieczeństwie agentów AI i serwerów MCP.
Z perspektywy CISO wystarczy kilka zasad, które da się sprawdzić w każdym projekcie z agentem. Agent działa na dedykowanym koncie z minimalnymi uprawnieniami, nie na koncie użytkownika z pełnym dostępem. Lista narzędzi i serwerów jest zatwierdzana tak jak każde inne oprogramowanie. Operacje nieodwracalne albo wychodzące poza firmę wymagają potwierdzenia człowieka. Każde wywołanie narzędzia jest logowane z informacją, który użytkownik i która rozmowa je zainicjowały.
Jak oceniać dostawców modeli i usług AI?
Dostawcę AI ocenia się jak każdego dostawcę przetwarzającego dane firmy, z dodatkowymi pytaniami o trenowanie modeli na danych klienta, retencję promptów i odpowiedzi, lokalizację przetwarzania i podwykonawców. Odpowiedzi na te pytania zmieniają się szybciej niż w przypadku klasycznych usług chmurowych, bo dostawcy często zmieniają modele i warunki.
Najważniejsze pytanie dotyczy trenowania. Czy dane z promptów, plików i rozmów mogą zostać użyte do trenowania lub ulepszania modeli dostawcy? Odpowiedź bywa różna dla wersji konsumenckiej i biznesowej tej samej usługi, a także dla różnych kanałów: interfejsu czatu i API. Dlatego deklaracja „nie trenujemy na danych klientów” powinna być zapisana w umowie albo w dokumentacji usługi, którą firma faktycznie kupiła, a nie w materiałach marketingowych.
Drugie pytanie dotyczy retencji i dostępu. Jak długo dostawca przechowuje prompty i odpowiedzi, czy jego pracownicy mogą je przeglądać, na przykład w ramach monitorowania nadużyć, i czy firma może tę retencję skrócić albo wyłączyć. Trzecie dotyczy lokalizacji: w jakich regionach dane są przetwarzane i czy dostawca korzysta z podwykonawców, w tym z dostawców modeli zewnętrznych.
Te pytania mają podstawę prawną. RODO w art. 28 wymaga, żeby administrator korzystał wyłącznie z podmiotów przetwarzających, które zapewniają wystarczające gwarancje ochrony danych. Dyrektywa NIS2 w art. 21 ust. 2 lit. d wymienia wśród środków zarządzania ryzykiem bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami i usługodawcami. Dla sektora finansowego DORA w art. 28 traktuje ryzyko ze strony zewnętrznych dostawców ICT jako integralną część ryzyka ICT, za które podmiot finansowy pozostaje w pełni odpowiedzialny.
W praktyce ocena dostawcy AI kończy się trzema dokumentami: kwestionariuszem bezpieczeństwa z pytaniami specyficznymi dla AI, umową powierzenia przetwarzania z zapisem o zakazie trenowania na danych i retencji oraz wpisem w rejestrze dostawców z datą kolejnego przeglądu. Bez tego ostatniego zmiana warunków dostawcy przejdzie niezauważona.
Warto też zapisać, co się stanie, gdy dostawca zmieni model, na którym działa usługa. Nowa wersja modelu może inaczej reagować na te same prompty, inaczej traktować instrukcje ukryte w dokumentach i mieć inne zasady przetwarzania danych. Umowa albo dokumentacja powinna przewidywać informowanie klienta o takich zmianach, a firma — traktować je jak każdą istotną zmianę w systemie produkcyjnym: z oceną ryzyka i ponownym testem aplikacji, które z modelu korzystają.
Jak włączyć systemy AI do monitoringu SOC i reagowania na incydenty?
Systemy AI trzeba podłączyć do SIEM tak jak każdą aplikację biznesową: z logami uwierzytelniania, działań administracyjnych, wywołań narzędzi i — tam, gdzie pozwala na to prawo i polityka prywatności — treści interakcji. Bez tych logów SOC nie odróżni prompt injection od zwykłego pytania i nie odtworzy, co agent zrobił w czyimś imieniu.
Wytyczne Guidelines for secure AI system development, opublikowane przez brytyjskie NCSC 27 listopada 2023 r. i ogłoszone wspólnie z amerykańską CISA, dzielą cykl życia systemu AI na cztery obszary: bezpieczne projektowanie, rozwój, wdrożenie oraz eksploatację i utrzymanie. W ostatnim obszarze wytyczne wskazują wprost logowanie i monitorowanie. To dobry argument w rozmowie z zespołem projektowym, który chce uruchomić asystenta przed podłączeniem logów.
Co warto monitorować? Nietypowe wolumeny zapytań na jeden klucz API, które mogą oznaczać wyciek klucza. Zapytania zawierające znane wzorce prompt injection albo próby wydobycia promptu systemowego. Wywołania narzędzi przez agenta poza godzinami pracy użytkownika, w którego imieniu działa. Masowe pobieranie dokumentów przez konto techniczne integracji. Dostęp do konsol dostawców modeli z nowych lokalizacji. Część tych scenariuszy to klasyczne reguły korelacji, które wystarczy rozszerzyć o nowe źródła logów.
Drugą połową tej domeny jest reagowanie na incydenty. Plan reagowania warto uzupełnić o scenariusze specyficzne dla AI: wyciek klucza API do usługi modelu, ujawnienie danych przez asystenta osobie nieuprawnionej, wykonanie przez agenta operacji, której nikt nie zlecił, i zatrucie źródeł RAG. Dla każdego scenariusza trzeba ustalić, kto może wyłączyć asystenta albo agenta, jak unieważnić klucze, jak zabezpieczyć logi rozmów jako dowód i kiedy incydent podlega zgłoszeniu na podstawie RODO albo NIS2.
Do analizy technik atakujących przyda się baza MITRE ATLAS (Adversarial Threat Landscape for AI Systems), czyli publiczna baza wiedzy o taktykach i technikach przeciwników wymierzonych w systemy AI. Zespół SOC może z niej czerpać scenariusze ćwiczeń i pomysły na reguły detekcji, zamiast wymyślać ataki na asystentów od zera.
Najważniejsze:
- Testy aplikacji LLM powtarza się po każdej zmianie modelu, źródła danych lub narzędzia.
- Agent działa na dedykowanym koncie, a operacje nieodwracalne wymagają potwierdzenia człowieka.
- Zakaz trenowania na danych i retencję zapisuje się w umowie, nie w materiałach marketingowych dostawcy.
- Bez logów wywołań narzędzi SOC nie odtworzy, co agent zrobił w czyimś imieniu.
Jakie wymagania prawne trzeba uwzględnić przy systemach AI?
Przy systemach AI w firmie trzeba uwzględnić jednocześnie AI Act, RODO oraz — zależnie od sektora — NIS2 i DORA; AI Act dokłada obowiązki zależne od roli firmy i kategorii ryzyka systemu, a pozostałe akty obowiązują niezależnie od tego, czy system jest „wysokiego ryzyka”. Stan prawny opisujemy na 10 listopada 2026 r.
AI Act, czyli rozporządzenie (UE) 2024/1689, zmienione rozporządzeniem (UE) 2026/1744, rozróżnia role. Dostawca rozwija system AI i wprowadza go do obrotu pod własną nazwą, a podmiot stosujący wykorzystuje system AI, nad którym sprawuje kontrolę. Większość firm, które kupują usługi AI, jest podmiotem stosującym, ale firma, która buduje własną aplikację i udostępnia ją klientom, może stać się dostawcą. Rolę trzeba ustalić dla każdej pozycji inwentarza.
Terminy (stan na 10 listopada 2026 r., AI Act w EUR-Lex): przepisy ogólne, w tym art. 4 o kompetencjach w zakresie AI, oraz zakazane praktyki z art. 5 stosuje się od 2 lutego 2025 r. Ogólna data stosowania rozporządzenia to 2 sierpnia 2026 r. Wymagania dla systemów wysokiego ryzyka po zmianie z 2026 r. stosuje się od 2 grudnia 2027 r. dla systemów z załącznika III i od 2 sierpnia 2028 r. dla systemów z załącznika I. Art. 4 w obecnym brzmieniu zobowiązuje dostawców i podmioty stosujące do podejmowania środków wspierających rozwój kompetencji personelu w zakresie AI, bez wymogu zapewnienia określonego poziomu. Pełny harmonogram obowiązków omawia osobny przewodnik po AI Act.
W Polsce obowiązuje ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), która ustanawia Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji organem nadzoru rynku. Za porządek ról, rejestr systemów i proces zatwierdzania odpowiada w firmie struktura opisana w artykule o tym, jak zorganizować AI governance w firmie.
Niezależnie od AI Act system AI, który przetwarza dane osobowe, podlega RODO. Art. 32 wymaga środków technicznych i organizacyjnych zapewniających bezpieczeństwo odpowiednie do ryzyka, a art. 35 — oceny skutków dla ochrony danych przed przetwarzaniem, które, w szczególności z użyciem nowych technologii, może powodować wysokie ryzyko. Asystent analizujący dane klientów albo pracowników jest typowym kandydatem do takiej oceny. NIS2 i DORA dokładają obowiązki zarządzania ryzykiem, łańcuchem dostaw i incydentami, które obejmują systemy AI tak samo jak każdy inny system teleinformatyczny.
Z tych aktów wynika praktyczny wniosek dla obszaru „Ład, ryzyko i zgodność”: wymagania prawne nie tworzą osobnego programu, tylko dopisują pola do inwentarza (rola, kategoria ryzyka, dane osobowe), dowody do mapy kontroli i scenariusze do planu reagowania. Uporządkowanie tego w jednym procesie to zakres gotowości na AI Act i governance AI.
Jak wygląda mapa ryzyk i kontroli oraz plan na 90 dni?
Mapa ryzyk i kontroli zestawia każdą domenę bezpieczeństwa AI z jej głównym ryzykiem, kontrolą, właścicielem i dowodem, który pokaże audytorowi, że kontrola działa. Tabela poniżej jest punktem startowym — w konkretnej firmie część wierszy się rozdzieli, a część połączy.
| Domena | Główne ryzyko | Kontrola | Właściciel | Dowód działania |
|---|---|---|---|---|
| Inwentarz | system AI poza wiedzą IT i bezpieczeństwa | rejestr systemów, usług i narzędzi AI z rolą wg AI Act | CISO z właścicielami biznesowymi | rejestr z datą przeglądu |
| Tożsamość i klucze | wyciek klucza API, nadmiarowe konto usługi | sejf na sekrety, rotacja, najmniejsze uprawnienia, MFA do konsol | właściciel techniczny systemu | raport rotacji, wynik skanowania repozytoriów |
| Dane | dane poufne w promptach i indeksach | klasyfikacja, etykiety, kontrole przepływu danych, zakres indeksu RAG | właściciel danych i zespół bezpieczeństwa | reguły i rejestr wyjątków |
| Aplikacje LLM i RAG | prompt injection, ujawnienie danych | testy wg OWASP Top 10 for LLM Applications 2025, walidacja wyjścia | zespół produktowy | raport z testu i retestu |
| Agenci | operacja wykonana bez zlecenia | lista narzędzi, dedykowane konto, potwierdzenia człowieka | właściciel techniczny agenta | konfiguracja i logi wywołań narzędzi |
| Dostawcy | trenowanie na danych, retencja, podwykonawcy | kwestionariusz AI, umowa powierzenia, przegląd okresowy | zakupy z CISO i IOD | umowa i wpis w rejestrze dostawców |
| Monitoring | brak widoczności nadużyć | logi w SIEM, reguły korelacji dla AI | SOC | reguły i przykładowe alerty |
| Reagowanie | chaos przy incydencie z asystentem lub agentem | scenariusze AI w planie reagowania, ćwiczenia | zespół reagowania | protokół z ćwiczenia |
| Zgodność | rola i obowiązki nieustalone | rola wg AI Act, DPIA wg RODO, mapowanie na NIS2 i DORA | IOD i dział prawny | ocena roli i DPIA |
Plan na 90 dni układa te wiersze w kolejności, która daje najszybciej widoczny efekt. Dni 1–30 to widoczność: inwentarz trzech kategorii, przypisanie właścicieli, ustalenie ról według AI Act i lista dostawców z umowami do przeglądu. Dni 31–60 to kontrole bazowe: przeniesienie kluczy API do sejfu, przegląd kont usług, rozszerzenie reguł ochrony danych na usługi AI, podłączenie logów najważniejszych systemów do SIEM. Dni 61–90 to weryfikacja: testy penetracyjne aplikacji LLM, które przetwarzają dane wrażliwe, ćwiczenie scenariusza incydentu z asystentem, uzupełnienie umów z dostawcami i pierwszy przegląd mapy z zarządem.
Kolejność nie jest przypadkowa. Testy przed inwentarzem dają raport o jednej aplikacji, podczas gdy ryzyko leży w pięciu innych, o których nikt nie wiedział. Monitoring przed porządkiem w kluczach i kontach usług generuje alerty, których nie ma kto obsłużyć. Dlatego pierwsze 30 dni poświęca się wyłącznie widoczności, nawet jeśli zespół projektowy naciska na szybsze testy.
Jak nFlo może pomóc w zabezpieczeniu środowisk AI?
nFlo wspiera ten program w trzech miejscach, w których firmom najczęściej brakuje niezależnej oceny: widoczności użycia AI, testów aplikacji i porządku regulacyjnego. Nie zastępujemy zespołów, które budują albo kupują systemy AI — dostarczamy dowody, na których te zespoły i CISO mogą oprzeć decyzje.
Pierwsza usługa to ocena shadow AI i polityka korzystania z AI: ustalenie, z jakich narzędzi AI korzystają pracownicy, jakie dane do nich trafiają i które kontrole ochrony danych działają, a na tej podstawie — polityka korzystania z AI. To bezpośrednio zasila inwentarz i domenę danych z mapy kontroli.
Druga to testy penetracyjne aplikacji AI/LLM, które sprawdzają prompt injection, wyciek promptu systemowego, granice uprawnień do dokumentów w RAG i nadużycie narzędzi, z raportem mapowanym na OWASP Top 10 for LLM Applications i retestem po poprawkach. Trzecia to gotowość na AI Act i governance AI: ustalenie ról, kategorii ryzyka i obowiązków oraz rejestr systemów AI. Wszystkie trzy obszary porządkuje strona bezpieczeństwo AI, a przegląd tekstów z tego klastra znajdziesz w bazie wiedzy o bezpieczeństwie AI. Jeśli chcesz ustalić, od której domeny zacząć w Twojej firmie, skontaktuj się z nami.
Co jeszcze warto wiedzieć o bezpieczeństwie AI w firmie?
Od czego zacząć zabezpieczanie AI w firmie?
Od inwentarza: listy systemów AI, które firma buduje lub kupuje, funkcji AI włączonych w używanych aplikacjach SaaS i narzędzi, z których pracownicy korzystają na własną rękę. Bez inwentarza nie da się przypisać właścicieli, ocenić ryzyka ani sprawdzić, czy kontrole w ogóle obejmują dany system.
Czy do bezpieczeństwa AI potrzebne są nowe narzędzia?
Najczęściej nie na początku. Większość kontroli to istniejące mechanizmy cyberbezpieczeństwa: zarządzanie tożsamością, sejfy na sekrety, klasyfikacja danych, kontrole przepływu danych, logowanie w SIEM i procedury reagowania. Nowe są zakres i scenariusze, które te mechanizmy muszą objąć, na przykład prompt injection albo nadmierna autonomia agenta.
Kto w firmie odpowiada za bezpieczeństwo systemów AI?
Każdy system AI powinien mieć właściciela biznesowego, który odpowiada za cel i dane, oraz właściciela technicznego, który odpowiada za konfigurację i zmiany. CISO odpowiada za ramę kontroli i nadzór nad ryzykiem, a inspektor ochrony danych — za zgodność przetwarzania danych osobowych z RODO.
Jak często testować aplikacje oparte na LLM?
Przed pierwszym udostępnieniem użytkownikom i po każdej istotnej zmianie: nowym modelu, nowym źródle danych w RAG, nowym narzędziu dla agenta albo zmianie promptu systemowego. Zachowanie modelu zależy od całej konfiguracji, więc wynik testu sprzed zmiany nie potwierdza bezpieczeństwa po zmianie.
Czy AI Act wymaga zabezpieczenia wszystkich systemów AI w firmie?
AI Act stawia najdalej idące wymagania systemom wysokiego ryzyka, a od części obowiązków zależy rola firmy: dostawcy albo podmiotu stosującego. Niezależnie od AI Act obowiązki bezpieczeństwa wynikają z RODO, NIS2 i DORA, dlatego kontrole z tego przewodnika dotyczą każdego systemu, który przetwarza dane firmy.
