Prawo nie zakazuje wpuszczenia AI do SOC. Zamienia za to jedną decyzję zakupową w dwie decyzje prawne. Pierwsza to komu powierzasz dane pod RODO. Druga to kto odpowiada za zegar zgłoszeniowy NIS2, gdy w pętli stoi model.
OpenAI właśnie dołożył do tej układanki własny produkt. Sprawdzamy, co on realnie zmienia dla polskiej firmy, a nie co obiecuje o sobie strona sprzedażowa.
Co OpenAI oferuje zespołom bezpieczeństwa
OpenAI ma osobną stronę produktową dla zespołów bezpieczeństwa, z hasłem "Frontier intelligence for cybersecurity"1. Produkt ma dwie warstwy. Codex Security to skaner - wtyczka, wersja chmurowa spięta z GitHubem albo CLI odpalane lokalnie. Pod spodem stoją modele rodziny Daybreak: Daybreak Blue do pracy obronnej (wykrywanie i walidacja podatności, modelowanie zagrożeń, analiza zagrożeń), Daybreak Red do pentestów i kontrolowanego red teamingu, dostępny dopiero po osobnej kwalifikacji zespołu.
Strona podaje własne liczby - ponad 30 mln przeanalizowanych commitów, 30 tys. przeskanowanych repozytoriów, 500 tys. napraw1. Bez definicji, co liczy się jako "naprawa", i bez punktu odniesienia to liczby producenta o produkcie producenta, nie dowód skuteczności.
Anthropic poszedł tą samą drogą. Firma pozycjonuje Claude Mythos 5 jako model do cyberbezpieczeństwa, na razie dla "niewielkiego grona początkowych partnerów testowych", z badaniami biologicznymi zapowiedzianymi jako kolejny obszar2. Warunkiem dostępu jest 30-dniowa retencja danych na potrzeby monitoringu bezpieczeństwa2. Szerzej dostępny jest osobny wariant, Claude Fable 5. Wedle producenta to ten sam model bazowy z dodatkowymi zabezpieczeniami, w którym część zapytań z tych domen trafia automatycznie do modeli Opus. Podział jest więc dwustopniowy: pełne możliwości za bramką partnerską, a poza nią wersja, która sama odsyła najtrudniejsze zapytania gdzie indziej.
To znowu deklaracje producenta o własnym produkcie, a nie niezależny audyt. Wzorzec zaczyna się jednak powtarzać. Najmocniejsze modele w tej domenie trafiają najpierw do wąskiego kręgu partnerów po bramce kwalifikacyjnej. Pytanie z tytułu, komu powierzasz dane i kto odpowiada za zegar zgłoszeniowy, dotyczy więc całej kategorii produktów, która dopiero się formuje. Rozwijamy je w tekście o agentach AI w audycie bezpieczeństwa chmury.
Gdzie kończy się asystent, a zaczyna decyzja człowieka
Sama strona rysuje tę granicę, choć nie nazywa jej wprost. W FAQ pada zdanie, że Codex Security obsługuje typowe scenariusze obronne, a dostęp do bardziej uprawnionych trybów pracy (Daybreak Access) wymaga osobnej kwalifikacji zespołu1. Nawet producent zakłada więc, że domyślny poziom autonomii modelu ma limit.
Przy realnym incydencie to rozróżnienie przestaje być teoretyczne. Model, który podpowiada, gdzie szukać śladu ataku, przyspiesza pracę analityka i nie rusza struktury odpowiedzialności. Decyzja i tak zapada po stronie człowieka. Model, który sam klasyfikuje alert jako fałszywy albo sam wysyła patch na produkcję, przenosi tę odpowiedzialność gdzie indziej. Marketing chętnie miesza oba przypadki pod jednym hasłem "przyspieszenia", bo to brzmi lepiej niż pytanie o to, kto podpisuje się pod decyzją.
Konsekwencje błędu są przy tym asymetryczne. Fałszywy alarm, który model bez potrzeby eskaluje do człowieka, kosztuje czas analityka. Fałszywe uspokojenie jest poważniejsze. Model uznaje realny incydent za nieistotny i nie eskaluje go dalej, więc nikt świadomie nie decyduje o zignorowaniu zagrożenia.
RODO - co realnie oznacza wysłanie logów do AI
Żeby model cokolwiek zwalidował, musi dostać materiał: fragmenty kodu, logi, artefakty incydentu, czasem próbki złośliwego oprogramowania do analizy. Wysłanie tego do zewnętrznego dostawcy jest decyzją o powierzeniu danych, i to zwykle danych wrażliwych. Logi z incydentu potrafią zawierać dane osobowe, adresy IP i treść komunikacji.
Ten sam materiał niesie drugie ryzyko. Log albo artefakt incydentu, wklejony do modelu jako dowód, może zawierać treść spreparowaną tak, by wstrzyknąć modelowi fałszywą instrukcję. Pytanie brzmi wtedy inaczej: czy dane, które wysyłasz, dają się obrócić przeciwko Tobie.
Podstawą prawną takiego powierzenia jest art. 28 RODO3. Administrator, czyli Twoja firma, może korzystać wyłącznie z podmiotu przetwarzającego dającego wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, a samo przetwarzanie musi być objęte umową wiążącą obie strony. Taka umowa powierzenia, z którą zwykle zaczyna się wdrożenie zgodności z NIS2 i RODO, ma określać:
- przedmiot, czas trwania, charakter i cel przetwarzania oraz rodzaj danych i kategorie osób, których dotyczą,
- że procesor przetwarza dane wyłącznie na udokumentowane polecenie administratora,
- środki bezpieczeństwa odpowiadające ryzyku, zgodnie z art. 32 RODO3,
- warunki korzystania z dalszych podwykonawców - wyłącznie za uprzednią zgodą administratora,
- prawo administratora do audytu i inspekcji oraz obowiązek usunięcia lub zwrotu danych po zakończeniu współpracy.
Analizowana strona produktowa tym tematem się nie zajmuje. Nie ma na niej słowa o miejscu przetwarzania, retencji logów ani liście podwykonawców. Może to być uregulowane gdzie indziej w dokumentacji OpenAI, tyle że nie tam, gdzie zapada decyzja zakupowa. Dla firmy przetwarzającej dane objęte RODO ten punkt trafia do umowy, zanim pierwszy log opuści firmę.
Osobna warstwa problemu to sam transfer danych poza Europejski Obszar Gospodarczy. OpenAI to firma amerykańska, więc RODO wymaga dla takiego przekazania dodatkowego mechanizmu prawnego - decyzji Komisji Europejskiej o odpowiednim stopniu ochrony albo standardowych klauzul umownych wpiętych w umowę powierzenia. Który z tych mechanizmów stosuje konkretny dostawca i dla którego regionu przetwarzania, strona produktowa nie precyzuje. To pytanie do umowy, nie do materiałów marketingowych.
NIS2 - kto odpowiada za 24 i 72 godziny, gdy w pętli jest AI
NIS2, czyli dyrektywa (UE) 2022/2555, nakłada twarde terminy zgłaszania incydentów do CSIRT - 24 godziny na wstępne zgłoszenie od powzięcia wiedzy o incydencie, 72 godziny na raport szczegółowy4. Te terminy nie przesuwają się w zależności od tego, jakie narzędzie stoi w pętli detekcji.
Sam próg, od którego incydent w ogóle wymaga zgłoszenia, to osobna decyzja. NIS2 nakłada obowiązek zgłoszenia, gdy incydent wywołuje poważne zakłócenie usługi albo naraża jej odbiorców na istotną szkodę4. To ocena wagi zdarzenia, a nie sam fakt jego wystąpienia.
Jest scenariusz, na który żadna firma nie ma jeszcze utartej odpowiedzi: model klasyfikuje alert jako niegroźny, a analityk mu wierzy. Przy błędnej klasyfikacji zegar 24 godzin4 i tak biegnie od momentu, w którym zespół realnie mógł się dowiedzieć o incydencie. Nie od chwili, w której ktoś ręcznie to potwierdził. Odpowiedzialność za dotrzymanie tego okna zostaje po stronie zespołu bezpieczeństwa, a nie dostawcy modelu, niezależnie od tego, czy błąd popełnił człowiek, czy algorytm.
Firma z sektora finansowego ma dodatkowo osobny reżim. DORA reguluje zgłaszanie incydentów ICT równolegle do NIS2, z własną logiką klasyfikacji. Kolejność pierwszeństwa obu reżimów ustala się przed audytem, nie w jego trakcie.
Dla kogo to naprawdę jest
Wśród firm powoływanych na stronie jako referencje są Cloudflare, Cisco, CrowdStrike, Palo Alto Networks, Oracle, Salesforce, Zscaler, Akamai i Fortinet1. Dobór logotypów nie jest przypadkowy. To organizacje, które mają już dojrzały SOC, własne repozytoria kodu i procesy inżynierskie, do których można podłączyć skaner.
Masz z tego realną korzyść, jeśli:
- wiesz, jakie zasoby i repozytoria w ogóle chronisz - inwentaryzacja jest zrobiona, nie planowana,
- masz zespół, który przegląda wyniki skanera, a nie tylko go włącza,
- Twoja umowa z dotychczasowymi dostawcami narzędzi już przewiduje powierzenie danych, więc dodanie kolejnego dostawcy rozszerza istniejący proces, zamiast budować go od zera.
Firma bez inwentaryzacji zasobów IT nie zyska na tym narzędziu tyle, ile sugeruje strona produktu. Jej problem leży o krok wcześniej niż ten, który narzędzie rozwiązuje. AI przyspiesza pracę zespołu, który już wie, co chroni. Nie tworzy tej wiedzy za niego.
Jak ocenić taki produkt, zanim go wdrożysz
Przed podpisaniem umowy z dostawcą AI dla SOC (OpenAI albo dowolnym innym) karta produktu i pytanie kupującego wyglądają tak:
| Obszar | Co mówi (lub przemilcza) strona produktowa | Pytanie do dostawcy |
|---|---|---|
| Skuteczność | Zbiorcze liczby producenta bez definicji i punktu odniesienia | Jaka jest metodyka liczenia "naprawy" i czy jest porównywalna z innym narzędziem? |
| Autonomia | Ogólne hasło "przyspieszenia" bez rozróżnienia sugestii od decyzji | Które akcje model wykonuje sam, a które tylko proponuje człowiekowi? |
| Miejsce przetwarzania | Nieokreślone na stronie sprzedażowej | Gdzie fizycznie trafiają logi i kod i czy opuszczają EOG? |
| Retencja danych | Nieokreślona na stronie sprzedażowej | Jak długo dane pozostają u dostawcy po zakończeniu analizy? |
| Podwykonawcy | Niewspomniani | Kto poza dostawcą ma dostęp do przesłanych danych? |
| Zgodność z terminami NIS2 | Nie dotyczy dostawcy narzędzia | Czy dostawca gwarantuje czas odpowiedzi zgodny z oknem 24/72h zgłoszenia? |
| Prawo audytu | Nie dotyczy karty produktowej | Czy umowa daje prawo do audytu i inspekcji u dostawcy? |
| Błędna klasyfikacja modelu | Nie adresowane na stronie | Kto ponosi konsekwencje, jeśli model błędnie oceni wagę incydentu? |
Dostawca, który nie potrafi odpowiedzieć na te pytania wprost, nie jest przez to zdyskwalifikowany. Przenosi za to całe ryzyko z powrotem na kupującego. Tę informację lepiej mieć przed podpisem umowy.
Firma, która dziś nie ma jeszcze własnego SOC, nie musi zaczynać od narzędzia AI. Alternatywą jest outsourcing tej funkcji do wyspecjalizowanego dostawcy, zanim w ogóle pojawi się pytanie, które narzędzie AI podłączyć.
Źródła
- OpenAI, "AI for Cybersecurity Teams" (odczyt 12.08.2026)
- Anthropic, "Claude Mythos" - strona produktowa (odczyt 13.08.2026)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 28 i art. 32 (odczyt 27.08.2026)
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), obowiązki zgłaszania incydentów (odczyt 27.08.2026)