Agent AI w SOC: kontrolowany triaż alertów bez oddawania reakcji modelowi

W SOC nie brakuje narzędzi. Brakuje czasu na spokojne przejście od alertu do decyzji: co się stało, jaki jest wpływ, czy mamy potwierdzenie z innych źródeł, kto powinien zatwierdzić reakcję i co trzeba zachować do audytu.

Agent AI może tu pomóc, ale tylko pod warunkiem, że nie jest traktowany jak zastępca SIEM, SOAR albo analityka L2. W 2026 sensowny wzorzec to kontrolowany workflow: agent czyta alert, pobiera kontekst z zatwierdzonych źródeł, tworzy uzasadnienie, proponuje akcję i zostawia ślad audytowy. Akcje destrukcyjne lub biznesowo ryzykowne przechodzą przez człowieka albo wcześniej zatwierdzony playbook.

To jest mniej widowiskowe niż hasło "autonomiczny SOC", ale znacznie bliższe temu, czego potrzebują polskie zespoły bezpieczeństwa: krótszy czas do sensownej decyzji, mniejszy szum w kolejce i lepsza dokumentacja działań.

Gdzie naprawdę boli SOC

Kolejka alertów nie jest jedynym problemem

Nie warto zaczynać od obietnicy, że "AI usunie 80% false positive". Taki wynik zależy od źródeł telemetrycznych, jakości reguł, dojrzałości CMDB, polityk IAM, konfiguracji EDR, higieny assetów i tego, czy zespół konsekwentnie zamyka alerty z powodem decyzji.

Praktyczny problem zwykle wygląda tak:

• jeden sygnał pojawia się w kilku narzędziach jako osobne alerty,
• alert nie ma kontekstu biznesowego: właściciela zasobu, krytyczności, okna serwisowego, wyjątków,
• analityk musi ręcznie przełączać się między SIEM, EDR, IAM, MDM, ticketingiem i threat intel,
• notatki z triażu są nierówne, więc trudno potem odtworzyć, dlaczego alert zamknięto,
• automatyzacja istnieje, ale jest krucha, bo playbook zakłada idealne dane wejściowe.

Agent AI jest użyteczny wtedy, gdy skraca właśnie ten odcinek pracy: zebranie kontekstu, porównanie sygnałów, przygotowanie uzasadnienia i skierowanie sprawy do właściwej ścieżki.

Czego agent nie powinien obiecywać

Zespół SOC powinien od razu odrzucić wdrożenie, które sprzedaje:

• samodzielne "wykrywanie wszystkich realnych zagrożeń" bez opisania źródeł danych i pokrycia detekcji,
• automatyczne blokowanie kont, izolację hostów albo kasowanie wiadomości bez progów ryzyka i zgód,
• uczenie na produkcyjnych logach bez polityki retencji, podstawy prawnej i separacji danych,
• ogólne zapewnienia o zgodności z RODO, NIS2 albo DORA bez mapy dowodów audytowych,
• brak możliwości odtworzenia wejść, wersji promptu, wersji modelu, wywołanych narzędzi i decyzji człowieka.

W SOC problemem nie jest tylko szybkość. Problemem jest też rozliczalność.

Co agent robi dobrze

1. Normalizacja i deduplikacja

Pierwsza warstwa nie wymaga żadnej "inteligencji" w marketingowym sensie. Agent może ujednolicić zdarzenia z SIEM, EDR, IAM, MDM, WAF, firewalli i chmury:

• połączyć alerty dotyczące tego samego użytkownika, hosta, procesu, IP albo mailboxa,
• zebrać timeline z kilku źródeł,
• oznaczyć duplikaty i zależności zamiast tworzyć kolejne tickety,
• wykryć brakujące pola, które blokują dalszą analizę.

To powinno być deterministyczne tam, gdzie się da. Model językowy nie powinien zgadywać, czy dwa alerty są tym samym incydentem, jeśli da się to ustalić regułą, identyfikatorem zdarzenia albo korelacją po czasie i encjach.

2. Wzbogacanie kontekstem

Największa oszczędność czasu pojawia się, gdy agent potrafi pobrać kontekst, który analityk i tak sprawdziłby ręcznie:

• krytyczność zasobu i właściciela z CMDB,
• typ konta, grupy, MFA, ostatnie zmiany uprawnień i ryzyko logowania z IAM,
• stan urządzenia z EDR/MDM: ostatni użytkownik, izolacja, wersja agenta, alerty procesu,
• okna serwisowe, deploymenty i wyjątki z change managementu,
• reputację domen, IP, hashy i wskaźników kompromitacji z zatwierdzonych źródeł,
• historię podobnych alertów i decyzji w ticketingu.

RAG ma tu sens, ale nie jako worek dokumentów. Baza wiedzy dla SOC powinna być wersjonowana i rozdzielona: procedury IR, wyjątki biznesowe, mapowanie systemów, standardy eskalacji, katalog playbooków i notatki z post-incident review. Agent musi podawać, z których fragmentów korzystał.

3. Uzasadnienie priorytetu

Dobry wynik agenta nie brzmi: "to jest high". Dobry wynik brzmi:

• jakie sygnały podniosły ryzyko,
• jakie sygnały obniżyły ryzyko,
• czego agent nie mógł sprawdzić,
• jaki playbook pasuje i na jakiej podstawie,
• jaka decyzja wymaga zatwierdzenia.

Przykład:

Alert: Nietypowe logowanie do konta finansowego
Źródła: SIEM, IAM, EDR, MDM, ticketing

Sygnały podnoszące ryzyko:
- nowe urządzenie, brak wcześniejszej historii dla użytkownika
- kraj bez historii logowań dla tego konta
- trzy nieudane próby przed poprawnym logowaniem
- konto ma dostęp do systemu płatności

Sygnały obniżające ryzyko:
- MFA potwierdzone metodą phishing-resistant
- host ma aktualny agent EDR i brak alertów procesu
- w kalendarzu jest zatwierdzona podróż służbowa, ale bez tej lokalizacji

Braki:
- brak potwierdzenia od przełożonego
- brak geolokalizacji z VPN firmowego
- brak danych z CASB dla sesji po logowaniu

Rekomendacja:
- priorytet P2 do weryfikacji L2
- nie blokować konta automatycznie
- przygotować akcję "revoke sessions" do zatwierdzenia przez analityka

Taki wynik jest mniej efektowny niż automatyczna blokada, ale dużo lepiej nadaje się do pracy operacyjnej.

Granice automatyzacji

Najpierw tylko odczyt

Pierwszy etap powinien mieć uprawnienia tylko do odczytu. Agent może pobierać alerty, enrichment, historię ticketów i procedury, ale nie powinien zmieniać stanu systemów.

To pozwala zmierzyć jakość bez ryzyka operacyjnego:

• ile alertów agent poprawnie zgrupował,
• ile razy znalazł brakujący kontekst,
• ile rekomendacji pokryło się z decyzją analityka,
• które integracje zwracały niepełne dane,
• w których klasach alertów agent był zbyt pewny siebie.

Write actions tylko przez bramki

Po pilotażu można dodać akcje zapisu, ale nie jako wolną autonomię. Każda akcja powinna mieć:

• jasno opisany skutek: blokada konta, wymuszenie resetu, izolacja hosta, usunięcie wiadomości, utworzenie reguły,
• warunki wejściowe, które można przetestować,
• limit blast radius, na przykład maksymalna liczba kont lub hostów na jedno uruchomienie,
• tryb dry-run,
• approval dla działań wysokiego wpływu,
• automatyczny rollback albo procedurę odwrócenia tam, gdzie to możliwe.

LangGraph daje praktyczny wzorzec dla takich bramek: interrupt() zatrzymuje wykonanie, zapisuje stan przez checkpointer i pozwala wznowić workflow po decyzji człowieka. Ten sam mechanizm można stosować przed wywołaniem narzędzia, na przykład przed revoke sessions albo izolacją hosta.

W n8n podobną ostrożność trzeba zbudować na poziomie workflow, ról, credentials, redakcji danych wykonania i log streamingu. n8n ma projekty, role i zakresy uprawnień, ale to zespół wdrożeniowy musi zaprojektować, kto może publikować workflow, kto może widzieć dane wykonania, kto może ujawniać zredagowane payloady i gdzie trafiają logi.

Narzędzia agentowe nie są kontrolą bezpieczeństwa same z siebie

OpenClaw, Hermes, LangGraph, n8n i podobne runtime'y trzeba traktować jako element warstwy wykonawczej, nie jako dowód bezpieczeństwa. Liczą się konkretne ustawienia:

• jakie narzędzia agent widzi,
• które narzędzia są read-only,
• które wymagają approval,
• jakie sekrety są dostępne w runtime,
• czy prompt może nakłonić agenta do użycia narzędzia poza intencją playbooka,
• czy każda akcja ma log z wejściem, wynikiem i osobą zatwierdzającą.

W praktyce prompt typu "nie rób nic ryzykownego" nie wystarcza. Uprawnienia muszą być wymuszone technicznie: osobne konta serwisowe, minimalne scope'y API, segmentacja sieciowa, lista dozwolonych narzędzi, bramki approval i monitoring wywołań.

Compliance: o co naprawdę pyta audytor

RODO

Logi bezpieczeństwa często zawierają dane osobowe: identyfikatory użytkowników, adresy IP, e-maile, nazwy urządzeń, lokalizacje, metadane sesji. RODO wymusza między innymi ograniczenie celu, minimalizację danych, ograniczenie przechowywania oraz odpowiednie zabezpieczenia przetwarzania.

Dla agenta SOC oznacza to konkretne decyzje projektowe:

• nie wysyłaj pełnych logów do zewnętrznego modelu, jeśli wystarczy zredagowany kontekst,
• oddziel dane potrzebne do triażu od danych potrzebnych do trenowania lub ewaluacji,
• ustal retencję promptów, odpowiedzi, trace'ów narzędzi i ticketów,
• maskuj lub pseudonimizuj dane w środowisku testowym,
• dokumentuj, kto może ujawnić zredagowane dane wykonania,
• w umowie z dostawcą określ role administratora, procesora, podprocesorów i transfery poza EOG.

Nie wystarczy napisać "hosting w UE". SOC musi wiedzieć, czy dane trafiają do modelu, do obserwowalności, do kolejek, do logów aplikacyjnych i do systemów debugowania.

NIS2

NIS2 stawia nacisk na zarządzanie ryzykiem cyberbezpieczeństwa i raportowanie istotnych incydentów. Dyrektywa przewiduje między innymi wczesne ostrzeżenie bez zbędnej zwłoki, co do zasady w ciągu 24 godzin od uzyskania wiedzy o istotnym incydencie, oraz zgłoszenie incydentu bez zbędnej zwłoki, co do zasady w ciągu 72 godzin. W praktyce workflow agenta powinien wspierać proces zgłoszeniowy, a nie go zastępować. Jeśli organizacja podlega NIS2, agent może pomóc zebrać timeline, wpływ, wstępne IOC i status działań, ale decyzja o kwalifikacji incydentu oraz komunikacja z CSIRT/właściwym organem muszą być zgodne z procedurą organizacji.

Warto zaprojektować osobny playbook "regulatory notification candidate", który nie wysyła zgłoszenia automatycznie. Tworzy paczkę dowodową i przypomina o terminach, ale wymaga zatwierdzenia przez właściciela procesu.

DORA

DORA obowiązuje sektor finansowy od 17 stycznia 2025 r. i wymaga dojrzałego zarządzania ryzykiem ICT, obsługi incydentów, testowania odporności i ryzyka stron trzecich. Agent w SOC może pomóc w klasyfikacji i dokumentowaniu zdarzeń ICT, ale nie powinien być obejściem procesu zatwierdzania, klasyfikacji wpływu albo kontroli nad dostawcami ICT.

Jeśli agent korzysta z zewnętrznych modeli, narzędzi SaaS albo managed workflow, trzeba ocenić również ryzyko dostawcy: dostęp do danych, lokalizację przetwarzania, audytowalność, odporność, SLA, wyjście z usługi i możliwość odtworzenia decyzji.

EU AI Act

EU AI Act wszedł w życie 1 sierpnia 2024 r., a obowiązki dotyczące kompetencji AI zaczęły mieć zastosowanie od 2 lutego 2025 r. W wielu scenariuszach agent SOC nie będzie automatycznie systemem wysokiego ryzyka tylko dlatego, że używa AI, ale nie zwalnia to z obowiązku zarządzania ryzykiem. Dla systemów wysokiego ryzyka akt przewiduje między innymi wymagania związane z nadzorem człowieka, dokumentacją, logowaniem, dokładnością, odpornością i cyberbezpieczeństwem.

Dla SOC dobrym minimum jest katalog systemów AI: gdzie działa agent, jakie dane przetwarza, jakie decyzje wspiera, kto jest właścicielem, gdzie są logi, jak wygląda human oversight i kiedy użycie modelu jest zabronione.

Architektura kontrolowanego agenta SOC

Najbezpieczniejszy projekt zaczyna się od podziału na warstwy.

Warstwa danych

• kolektor alertów z SIEM/SOAR/ticketingu,
• connector read-only do EDR, IAM, MDM, CMDB, threat intel,
• RAG z procedurami i playbookami, najlepiej z wersjonowaniem,
• redakcja danych wrażliwych przed wysłaniem do modelu,
• polityka retencji dla wejść, odpowiedzi i trace'ów.

Warstwa rozumowania

• klasyfikacja według jawnych kryteriów,
• wymuszony format odpowiedzi: fakty, braki, hipotezy, rekomendacja,
• zakaz uzupełniania braków zgadywaniem,
• ocena pewności oparta na sygnałach, nie na stylu odpowiedzi,
• testy regresji na historycznych alertach.

Warstwa narzędzi

• osobne konta serwisowe dla odczytu i zapisu,
• allowlist narzędzi,
• scope API dopasowany do konkretnego playbooka,
• approval przed akcjami wysokiego wpływu,
• limity liczby obiektów objętych akcją,
• pełny log wywołań narzędzi.

Warstwa operacyjna

• ticket z podsumowaniem i linkami do dowodów,
• kolejka zatwierdzeń dla L2/IR,
• dashboard jakości: zgodność rekomendacji z decyzją analityka, odsetek braków danych, błędy integracji,
• post-incident review obejmujący również zachowanie agenta,
• procedura wyłączenia agenta i powrotu do ręcznego procesu.

Jak mierzyć pilotaż

Nie mierz "ile alertów zamknęła AI". Na początku agent nie powinien sam zamykać alertów, jeśli nie masz bardzo dojrzałej klasy zdarzeń i jasnych kryteriów.

Lepsze metryki pilotażu:

• czas od alertu do kompletnego ticketu z kontekstem,
• liczba ręcznych przełączeń między narzędziami, których uniknął analityk,
• odsetek rekomendacji zaakceptowanych bez korekty,
• odsetek rekomendacji odrzuconych i powód odrzucenia,
• liczba przypadków, w których agent nie znalazł wymaganego źródła,
• liczba naruszeń polityki, na przykład próba użycia narzędzia poza allowlistą,
• jakość śladu audytowego oceniana przez SOC lead/compliance.

Pilot powinien obejmować historyczne alerty i tryb shadow na produkcyjnej kolejce. Dopiero po tej fazie warto dopuścić zamykanie niskiego ryzyka, a i wtedy z regułą próbkowania do ręcznej kontroli.

Przykładowe klasy alertów

Dobre na start

• podejrzane logowania z dobrze opisanym kontekstem IAM,
• phishing mailbox triage bez automatycznego kasowania,
• enrichment hashy, domen i IP,
• duplikaty alertów EDR/SIEM dla tego samego hosta,
• alerty cloud posture, gdzie agent tworzy ticket i wskazuje właściciela zasobu.

Ostrożnie

• insider threat,
• alerty dotyczące kadry zarządzającej,
• systemy płatności i produkcja krytyczna,
• automatyczne blokowanie kont,
• izolacja hostów,
• modyfikacja reguł detekcji,
• zgłoszenia regulacyjne.

W tych obszarach agent może przygotować rekomendację, ale decyzja powinna zostać przy człowieku lub formalnie zatwierdzonym playbooku.

Koszty i opłacalność

Koszt nie wynika z samego modelu. Najdroższe elementy to integracje, porządkowanie danych, uprawnienia, testy, obserwowalność i utrzymanie zmian w narzędziach bezpieczeństwa.

Przed budżetowaniem warto odpowiedzieć na pytania:

• ile klas alertów ma stabilne kryteria triażu,
• czy istnieje CMDB albo inny wiarygodny katalog zasobów,
• czy ticketing zawiera dobre powody zamknięcia,
• czy SOC ma playbooki w formie, którą da się zautomatyzować,
• czy dostawcy SIEM/EDR/IAM mają API potrzebne do odczytu i akcji,
• czy organizacja akceptuje przetwarzanie danych przez wybrany model,
• kto będzie utrzymywał prompty, testy i polityki narzędzi.

Agent ma sens ekonomiczny wtedy, gdy usuwa powtarzalną pracę analityków bez zwiększania ryzyka błędnej reakcji. Jeśli zespół nie ma podstawowych źródeł telemetrycznych, najpierw trzeba naprawić detekcję i procesy. Agent nie nadrobi braku EDR, złej jakości logów ani chaotycznego IAM.

Podsumowanie

Najlepszy agent AI w SOC nie udaje analityka z pełną autonomią. Działa jak kontrolowana warstwa operacyjna: zbiera kontekst, porządkuje zdarzenia, proponuje decyzję, wymusza approval i zostawia dowody.

Warto go wdrażać tam, gdzie:

• alerty mają powtarzalny schemat,
• źródła danych są dostępne przez API,
• playbooki są jawne,
• uprawnienia są ograniczone technicznie,
• każda decyzja jest odtwarzalna,
• działania wysokiego wpływu przechodzą przez człowieka.

To podejście nie obiecuje "SOC bez ludzi". Obiecuje coś bardziej praktycznego: mniej ręcznego zbierania danych, lepsze uzasadnienia, spokojniejszą eskalację i mniejsze ryzyko, że automatyzacja zrobi więcej szkody niż pożytku.

Źródła i punkty odniesienia

• RODO / GDPR - Regulation (EU) 2016/679, EUR-Lex
• NIS2 - Directive (EU) 2022/2555, EUR-Lex
• DORA - Regulation (EU) 2022/2554, EUR-Lex
• EU AI Act - Regulation (EU) 2024/1689, EUR-Lex
• European Commission - AI Act regulatory framework
• NIST SP 800-61 Rev. 2 - Computer Security Incident Handling Guide
• NIST Cybersecurity Framework 2.0
• CISA - Enabling Automation in Security Operations
• LangGraph - interrupts and human-in-the-loop workflows
• n8n - execution data redaction
• n8n - log streaming
• n8n - custom project roles

---

Chcesz sprawdzić, czy agent AI ma sens w Twoim SOC? Umów bezpłatny skan procesów. To 30 minut z inżynierem i pisemne podsumowanie w 2 dni robocze. Zaczynamy od mapy alertów, źródeł danych, uprawnień i ryzyk.

---

Powiązane artykuły:

• Syntalith
• Czym są agenci AI? Przewodnik dla biznesu
• Agent AI do monitorowania compliance w finansach