Krótka odpowiedź na pytanie z tytułu: prawo nie zakazuje wpuszczenia AI do SOC, ale zamienia jedną decyzję zakupową w dwie decyzje prawne naraz - komu powierzasz dane pod RODO i 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. Ten tekst sprawdza, co to realnie zmienia dla polskiej firmy, nie co mówi 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" (openai.com/business/solutions/cybersecurity, odczyt 12.08.2026). 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. napraw. Bez definicji, co liczy się jako "naprawa", i bez punktu odniesienia to liczby producenta o produkcie producenta, nie dowód skuteczności.
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łu. Nawet producent zakłada więc, że domyślny poziom autonomii modelu ma limit.
To rozróżnienie ma znaczenie przy realnym incydencie, nie tylko teoretyczne. Model, który podpowiada, gdzie szukać śladu ataku, przyspiesza pracę analityka i nie zmienia 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 - model, który uznaje realny incydent za nieistotny i nie eskaluje go dalej - jest poważniejsze, bo nikt świadomie nie zdecydował 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 nie jest wyłącznie zakupem narzędzia - to decyzja o powierzeniu danych, i to zwykle danych wrażliwych, bo logi z incydentu mogą zawierać dane osobowe, adresy IP, treść komunikacji.
Podstawą prawną takiego powierzenia jest art. 28 RODO. 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 RODO,
- 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.
Strona produktowa, którą tu analizujemy, tym tematem się nie zajmuje - nie ma na niej słowa o miejscu przetwarzania, retencji logów ani liście podwykonawców. To może być uregulowane gdzie indziej w dokumentacji OpenAI, ale nie tam, gdzie zwykle zapada decyzja zakupowa. Dla firmy przetwarzającej dane objęte RODO to nie jest szczegół do doczytania później, tylko punkt, który powinien trafić 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ółowy. 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ę - to ocena wagi zdarzenia, nie tylko fakt jego wystąpienia. Scenariusz, który dziś nie ma jeszcze utartej odpowiedzi w żadnej firmie: model klasyfikuje alert jako niegroźny, a analityk mu wierzy. Jeśli klasyfikacja była błędna, zegar 24 godzin i tak biegnie od momentu, w którym zespół realnie mógł się dowiedzieć o incydencie, nie od momentu, w którym ktoś ręcznie to potwierdził. Odpowiedzialność za dotrzymanie tego okna leży po stronie zespołu bezpieczeństwa, 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, więc kolejność pierwszeństwa obu reżimów trzeba ustalić 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 Fortinet. To nie przypadek doboru logotypów - to organizacje, które już mają 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, która nie ma jeszcze inwentaryzacji swoich zasobów IT, nie zyskuje na tym narzędziu tyle, ile sugeruje strona produktu, bo problem, który ma, leży o krok wcześniej niż ten, który to 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 czy jakimkolwiek 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 automatycznie zdyskwalifikowany - ale przenosi całe ryzyko z powrotem na kupującego, i to jest informacja, którą warto mieć przed podpisem umowy, nie po nim.
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", openai.com/business/solutions/cybersecurity (odczyt 12.08.2026)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 28 i art. 32
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), obowiązki zgłaszania incydentów
- Cyber Katalog, hasło NIS2
- Cyber Katalog, hasło RODO
- Cyber Katalog, hasło CSIRT
Powiązane pojęcia
- SOC - zespół, do którego pracy wchodzą dziś narzędzia takie jak Codex Security.
- NIS2 - dyrektywa nakładająca terminy zgłoszeniowe niezależne od użytego narzędzia.
- RODO - podstawa prawna każdego powierzenia danych zewnętrznemu dostawcy AI.
- CSIRT - zespół, do którego trafia zgłoszenie incydentu w oknie 24 i 72 godzin.
- Monitoring i SOC - polscy dostawcy usług SOC-as-a-Service, SIEM i MDR.
- GRC i Zgodność - firmy wdrażające zgodność z NIS2, RODO i ISO 27001.