Temat wpływu najbardziej zaawansowanych modeli sztucznej inteligencji na cyberbezpieczeństwo sektora finansowego po raz kolejny powraca w materiałach publikowanych przez organy nadzoru. Najpierw 25 czerwca 2026 r. Europejska Rada ds. Ryzyka Systemowego wydała ostrzeżenie dotyczące systemowych ryzyk cybernetycznych związanych z modelami Frontier AI. Następnie 7 lipca 2026 r. Komisja Europejska przedstawiła plan działania dotyczący cyberbezpieczeństwa i sztucznej inteligencji, a Europejski Bank Centralny zwrócił się do największych instytucji z oczekiwaniem podjęcia konkretnych działań w obszarze ryzyka ICT. 22 lipca 2026 r. własne rekomendacje opublikował Urząd Komisji Nadzoru Finansowego, zaś 31 lipca 2026 r. wspólne stanowisko przedstawiły EBA, EIOPA i ESMA. Publikacja kolejnego dokumentu nadzorczego pokazuje, że mamy do czynienia z wyraźnie kształtującym się kierunkiem nadzorczym.

Kolejne dokumenty nadzorców różnią się zakresem i poziomem szczegółowości, ale ich główne przesłanie pozostaje bardzo podobne i sprowadza się do uznania, że Modele Frontier AI mogą znacząco przyspieszać identyfikowanie podatności, przygotowywanie sposobu ich wykorzystania oraz prowadzenie kolejnych etapów ataku. Znaczenie tych modeli nie polega przy tym wyłącznie na tworzeniu nowych rodzajów zagrożeń. Istotniejsze nawet może okazać się zwiększenie skali i szybkości działań ofensywnych. Z punktu widzenia podmiotów finansowych oznacza to przede wszystkim ograniczenie czasu dostępnego na ocenę zagrożenia i podjęcie odpowiednich działań.

Z przedstawionych stanowisk wyraźnie wynika, że organy nadzoru oczekują, by przyjęte rozwiązania rzeczywiście pozwalały na szybką ocenę zagrożenia, podjęcie decyzji i reakcję na incydent. UKNF zapowiedział przy tym, że adekwatność i efektywność wdrożonych mechanizmów będzie przedmiotem weryfikacji nadzorczej. Powstaje zatem pytanie, jak wymagania DORA przełożyć na rozwiązania, które z jednej strony pozwolą spełnić oczekiwania organów nadzoru, a z drugiej faktycznie przygotują organizację na zagrożenia związane z Frontier AI.

Frontier AI a obowiązki wynikające z DORA

Rekomendacje UKNF i stanowisko Europejskich Urzędów Nadzoru nie tworzą odrębnego systemu regulacyjnego dotyczącego ryzyka Frontier AI. Wszystkie te organy odwołują się przede wszystkim do obowiązków już wynikających z DORA, w tym wymagań dotyczących zarządzania ryzykiem ICT, wykrywania i obsługi incydentów, testowania operacyjnej odporności cyfrowej oraz zarządzania ryzykiem dostawców usług ICT. W praktyce nie ma zatem potrzeby tworzenia całkowicie nowego systemu zarządzania ryzykiem. Konieczne jest natomiast położenie większego nacisku na te elementy DORA, na które wpływa wzrost szybkości i skali zagrożeń.

Należy przy tym pamiętać, że DORA wskazuje przede wszystkim, jakie procesy i mechanizmy powinny funkcjonować w organizacji. Nie zawsze odpowiada natomiast szczegółowo na pytanie, w jaki sposób powinny zostać technicznie i organizacyjnie wdrożone. W tym zakresie znaczenie mają standardy z zakresu cyberbezpieczeństwa, w tym normy ISO, a także dobre praktyki wypracowane przez ekspertów i organy nadzoru.

Przy doborze konkretnych rozwiązań, prowadzeniu ocen ryzyka oraz okresowym przeglądzie funkcjonujących procesów należy zatem uwzględnić także rozwój modeli Frontier AI. Jeżeli modele te skracają czas potrzebny na identyfikację i wykorzystanie podatności, odpowiedniej oceny wymagają między innymi rejestry aktywów, sposób priorytetyzacji podatności, częstotliwość monitorowania, proces wdrażania poprawek oraz procedury eskalacji i reagowania na incydenty.

Zarządzanie podatnościami wymaga wiedzy o własnym środowisku

Jednym z obszarów wymagających szczególnej uwagi jest zarządzanie podatnościami. UKNF wskazuje, że ich priorytetyzacja nie powinna opierać się wyłącznie na wskaźnikach technicznych, takich jak CVSS (Common Vulnerability Scoring System). Należy uwzględniać również informacje o aktywnym wykorzystywaniu luki, ekspozycji zasobu, znaczeniu wspieranego procesu oraz zależnościach pomiędzy aktywami i dostawcami.

Takie podejście wymaga jednak możliwości szybkiego ustalenia, gdzie podatny komponent jest wykorzystywany i jakie procesy od niego zależą. Sam rejestr aplikacji i serwerów może być w tym zakresie niewystarczający, jeżeli nie pozwala powiązać konkretnej biblioteki lub komponentu z systemem ICT, procesem biznesowym oraz funkcją krytyczną lub istotną.

Jednym z rozwiązań, które może ułatwić spełnienie tych wymagań, jest SBOM (Software Bill of Materials). Pozwala on określić, z jakich komponentów składa się dane oprogramowanie, i szybciej zidentyfikować systemy, które mogą być dotknięte nowo ujawnioną podatnością. W połączeniu z aktualnym rejestrem aktywów, informacjami o konfiguracji i zależnościach może istotnie skrócić czas potrzebny na ocenę rzeczywistej ekspozycji.

Sama identyfikacja podatnego komponentu nie przesądza jeszcze o kolejności reakcji. Ocena powinna uwzględniać nie tylko wynik CVSS, ale także informacje o aktywnym wykorzystywaniu luki, dane KEV (Known Exploited Vulnerabilities) i EPSS (Exploit Prediction Scoring System), komunikaty producentów oraz własną telemetrię. Dopiero ich zestawienie z ekspozycją zasobu i znaczeniem wspieranego procesu pozwala właściwie określić priorytet.

Podobnie należy podejść do terminów wdrażania poprawek. Podatność o niższym wyniku CVSS, która jest aktywnie wykorzystywana i dotyczy systemu dostępnego z Internetu, może wymagać szybszej reakcji niż podatność formalnie krytyczna występująca w środowisku odizolowanym. Procedury powinny zatem przewidywać tryb przyspieszony, a gdy poprawka nie jest dostępna albo wymaga testów, możliwość zastosowania środków tymczasowych, takich jak ograniczenie dostępu, segmentacja, wyłączenie podatnej funkcji, virtual patching lub zwiększenie monitorowania.

Proces ten powinien obejmować również środowiska zapasowe. W przeciwnym razie odtworzenie działalności może oznaczać ponowne uruchomienie systemu zawierającego tę samą podatność.

Monitorowanie powinno pozwalać na szybkie wykrycie próby wykorzystania podatności

Skrócenie czasu pomiędzy ujawnieniem podatności a jej wykorzystaniem wpływa również na sposób monitorowania środowiska ICT. Organy nadzoru wskazują w tym zakresie na potrzebę przechodzenia od kontroli okresowych do monitorowania ciągłego lub zbliżonego do ciągłego, w szczególności w odniesieniu do systemów dostępnych z Internetu, API oraz infrastruktury chmurowej. Realizacja tego postulatu nie powinna jednak sprowadzać się do gromadzenia większej liczby logów. Istotna jest możliwość szybkiego powiązania informacji o podatności ze zdarzeniami występującymi w konkretnych systemach.

Jednym z rozwiązań może być odpowiednie wykorzystanie systemów klasy SIEM (Security Information and Event Management), które korelują dane pochodzące z różnych systemów oraz narzędzi skanujących podatności. Odpowiednio skonfigurowany SIEM, zasilany właściwą telemetrią i informacjami o podatnościach, może pomóc ustalić nie tylko, które zasoby są potencjalnie zagrożone, ale również czy w środowisku występują zdarzenia wskazujące na próbę wykorzystania danej podatności.

W tym zakresie kluczowe jest także mapowanie mechanizmów detekcyjnych do taktyk i technik opisanych w MITRE ATT&CK (Adversarial Tactics, Techniques & Common Knowledge), które pozwala ocenić, wobec jakich zachowań przeciwnika organizacja posiada odpowiednie zdolności detekcyjne, a gdzie nadal występują istotne luki w widoczności. Sama liczba zebranych logów nie daje odpowiedzi na pytanie, czy podmiot jest w stanie rozpoznać konkretny scenariusz ataku.

Procedury reagowania powinny ograniczać czas potrzebny na podjęcie decyzji

Należy także zauważyć, że szybkie wykrycie zagrożenia nie będzie wystarczające, jeżeli dalsze działania wymagają każdorazowo ustalenia, kto może zdecydować o izolacji systemu, zastosowaniu kontroli kompensującej albo czasowym ograniczeniu świadczenia usługi. W tym zakresie odpowiednio przygotowane procedury powinny określać nie tylko ogólne zasady postępowania, ale również odpowiedzialności, tryb eskalacji oraz uprawnienia decyzyjne. Pomocne mogą być playbooki opracowane dla konkretnych scenariuszy, takich jak ujawnienie krytycznej podatności, brak dostępnej poprawki albo równoczesne zagrożenie kilku powiązanych systemów.

Sam zakres odpowiedzialności poszczególnych podmiotów, może zostać uporządkowany przykładowo przy wykorzystaniu matrycy RACI (Responsible, Accountable, Consulted, Informed). Pozwala ona z góry określić, kto podejmuje decyzję, kto realizuje działania techniczne, kto powinien zostać skonsultowany, a kto jedynie poinformowany. Ma to szczególne znaczenie, gdy wdrożenie poprawki albo odłączenie systemu może wpływać na ciągłość świadczenia usług.

Warto także podkreślić, że przyjęte rozwiązania powinny następnie zostać zweryfikowane w ramach testów odporności cyfrowej. Organy nadzoru wskazują, że scenariusze testowe powinny uwzględniać ataki wspierane przez AI, awarie wielosystemowe oraz możliwość kaskadowego zakłócenia powiązanych elementów infrastruktury.

Zarządzanie ryzykiem dostawców wymaga dostępu do informacji technicznych

Zagrożenie może wynikać nie tylko z podatności występującej bezpośrednio w systemach podmiotu finansowego. Może ono dotyczyć także oprogramowania dostawcy, komponentu open source albo usługi świadczonej przez poddostawcę. Organy nadzoru podkreślają zatem potrzebę objęcia odpowiednimi standardami całego łańcucha dostaw ICT.
W praktyce sama informacja o posiadanym przez dostawcę certyfikacie lub standardzie bezpieczeństwa może być niewystarczająca. Podmiot powinien mieć możliwość ustalenia, jak dostawca identyfikuje podatności, w jakim czasie informuje o ich wystąpieniu oraz jakie działania podejmuje, jeżeli poprawka nie jest jeszcze dostępna.

W przypadku usług wspierających funkcje krytyczne lub istotne warto odpowiednio uregulować dostęp do komunikatów bezpieczeństwa, informacji o wykorzystywanych wersjach i zależnościach, aktualnych kontaktów eskalacyjnych. Takie rozwiązania pozwalają skrócić czas potrzebny na ustalenie, czy podatność dotycząca dostawcy wpływa również na działalność podmiotu finansowego.

Podobnej oceny wymagają zewnętrzne rozwiązania AI oferowane w modelu chmurowym lub SaaS. W tym przypadku znaczenie ma nie tylko bezpieczeństwo bieżącego korzystania z usługi, ale również rzeczywista możliwość jej zastąpienia. Plan wyjścia powinien zatem uwzględniać odzyskanie danych, zmianę integracji, wybór rozwiązania zastępczego oraz utrzymanie ciągłości działania w okresie przejściowym.

Ryzyko Frontier AI powinno zostać uwzględnione w decyzjach zarządczych

Organy nadzoru oczekują również odpowiedniego zaangażowania organu zarządzającego. W tym zakresie w szczególności zwracają uwagę na potrzebę aktualizacji ram apetytu na ryzyko (RAF – Risk Appetite Framework), w tym stosowanych mierników, progów tolerancji oraz mechanizmów kontrolnych. Co oczywiste, nie oznacza to zaangażowania zarządu w analizę każdej podatności technicznej. Zarząd powinien jednak otrzymywać informacje pozwalające ocenić wpływ zagrożenia na funkcje krytyczne, ciągłość działania, klientów oraz zależności od dostawców.

Znaczenie ma również jasne przypisanie odpowiedzialności za akceptację ryzyka. Jeżeli poprawka nie może zostać wdrożona, kontrola kompensująca jest niewystarczająca albo ograniczenie ryzyka wymaga dodatkowych nakładów, decyzja nie powinna pozostawać wyłącznie na poziomie zespołu technicznego.

W praktyce konieczna może być zatem aktualizacja zasad raportowania do zarządu. Okresowe przedstawianie liczby otwartych podatności może być niewystarczające. Istotniejsze są informacje o podatnościach aktywnie wykorzystywanych, ekspozycji systemów krytycznych, przekroczeniu terminów naprawczych oraz zależnościach, które mogą prowadzić do awarii wielu systemów jednocześnie.

Podsumowanie

Rozwój modeli Frontier AI nie prowadzi do powstania odrębnego systemu obowiązków regulacyjnych. Co więcej nie zmienia się też zasadniczo katalog procesów wymaganych przez DORA. Zmieniają się natomiast warunki, w których procesy te muszą działać i przede wszystkim dostępny czas reakcji, skala analizowanych zdarzeń oraz ryzyko równoczesnego oddziaływania na wiele powiązanych systemów. Zagrożenia te skutkują zatem koniecznością ponownej oceny sposobu wdrożenia wymagań wynikających z DORA. W tym kontekście w praktyce kluczowe stają się rozwiązania pozwalające skrócić czas pomiędzy uzyskaniem informacji o zagrożeniu a podjęciem skutecznego działania.

To właśnie skuteczność tych rozwiązań i ich odpowiednie ujęcie w ramach zarządzania ryzykiem zgodnie z DORA, będzie przesądzać o tym, czy podmiot jest rzeczywiście przygotowany na zmianę tempa i skali cyberzagrożeń. Nie można też pominąć, że UKNF zapowiedział weryfikację adekwatności i skuteczności wdrożonych rozwiązań. Należy zatem założyć, że sposób uwzględnienia tych ryzyk będzie badany, w szczególności przy okazji oceny zgodności z DORA. Biorąc pod uwagę skalę zainteresowania tym zagadnieniem po stronie organów nadzoru, mogą to być działania o wysokim priorytecie nadzorczym. Odpowiednie przygotowanie ma zatem znaczenie nie tylko dla ograniczenia ryzyka incydentu, ale również z perspektywy ochrony regulacyjnej podmiotu na wypadek kontroli lub działań nadzorczych.