Dziewiętnaście kategorii i żadna nie pasuje…

Od kilku tygodni wraca w rozmowach to samo pytanie. Skoro Bruksela przesunęła terminy AI Act, to czy temat sztucznej inteligencji można zdjąć z tegorocznego planu?

27 lipca weszło w życie rozporządzenie (UE) 2026/1744, czyli Digital Omnibus on AI. Obowiązki dla systemów wysokiego ryzyka przesunięto. I tak, dla systemów samodzielnych z załącznika III na grudzień 2027 r., dla AI wbudowanej w produkty na sierpień 2028 r. Przekaz, który z tego został w obiegu, brzmiał po prostu – „mamy więcej czasu”.

Kłopot polega na tym, że przesunięto coś innego, niż większości się wydaje.

Sześć dni wcześniej UKNF skierował do podmiotów nadzorowanych pismo o modelach Frontier AI. Dziesięć dni później EBA, EIOPA i ESMA ogłosiły wspólne stanowisko w tym samym temacie. Ani jeden, ani drugi dokument nie opiera się na AI Act.

Oba opierają się na DORA.

Przesunięto obowiązek dokumentacyjny wynikający z prawa o sztucznej inteligencji. Nie przesunięto obowiązku inwentaryzacyjnego wynikającego z prawa o ICT.

Kogo właściwie dotyczyło to, co przesunięto

Odroczenie objęło obowiązki dostawcy systemu AI wysokiego ryzyka czyli dokumentację techniczną z art. 11 i załącznika IV, system zarządzania ryzykiem, ocenę zgodności. Dostawcy. Nie tego, kto z narzędzia korzysta.

Organizacja, która kupuje gotowe rozwiązanie i wpina je we własny proces, jest podmiotem stosującym, a nie dostawcą. Art. 11 nigdy nie był dla niej źródłem obowiązku. Przesunięto zatem termin, który jej nie dotyczył, i trudno o słabszą podstawę do decyzji o odłożeniu tematu.

Nie przesunięto przy tym obowiązków przejrzystości z art. 50, stosowanych od 2 sierpnia, ani niczego w rozporządzeniu DORA, obowiązującym od stycznia 2025 r., ani w ustawie o KSC, której nowelizacja weszła w życie 3 kwietnia.

Nadzorcy nie czekali

25 czerwca Europejska Rada ds. Ryzyka Systemowego przyjęła ostrzeżenie ESRB/2026/3 i podniosła klasyfikację systemowego ryzyka cybernetycznego z podwyższonego na poważny. Jako odrębny wektor wskazała koncentrację u ograniczonej liczby dostawców AI, dostawców chmury i komponentów open source.

21 lipca UKNF przesłał pismo DCB-DCBZAD.9400.11.2026. Wymieniono w nim wprost ocenę, czy dostawcy usług ICT mają odpowiednie mechanizmy zarządzania ryzykiem związanym z AI, z odesłaniem do art. 28–30 DORA. Wśród środków strukturalnych znalazło się ryzyko nadmiernego uzależnienia od pojedynczego dostawcy ICT i AI. Pismo zamyka zdanie, które w nadzorze zawsze warto przeczytać dwa razy: adekwatność i efektywność wdrożonych rozwiązań będzie przedmiotem weryfikacji zarówno w nadzorze bieżącym, jak i podczas czynności kontrolnych.

31 lipca ESA opublikowały wspólne stanowisko JC 2026 25. W części poświęconej prewencji napisano, że punktem wyjścia jest kompletny i na bieżąco aktualizowany wykaz wszystkich zasobów IT, obejmujący infrastrukturę, aplikacje, repozytoria danych, interfejsy API oraz komponenty AI i uczenia maszynowego. Dopiero on pozwala klasyfikować zasoby według krytyczności i ekspozycji.

Żaden z tych dokumentów nie tworzy nowego prawa. Wszystkie odczytują oczekiwania z przepisów, które obowiązują od dawna.

Gdzie kończy się dyskusja, a zaczyna arkusz

O tym, czy narzędzie AI jest usługą ICT, można rozmawiać długo i z przyjemnością. Ile by ta dyskusja nie trwała, nie da się ją rozstrzygnąć w kilka minut. Wystarczy spróbować wpisać takie narzędzie do rejestru informacji.

Wzory określa rozporządzenie wykonawcze (UE) 2024/2956. Dla każdej usługi ICT trzeba podać jej rodzaj, wybierając z zamkniętej listy z załącznika III, od S01 „Zarządzanie projektami ICT” do S19 „Usługi w chmurze: SaaS”. Dziewiętnaście pozycji. Kategorii dla modelu językowego wśród nich nie ma.

Trzeba więc wybrać. S06 „Analiza danych”? S08 „Zasoby obliczeniowe”? S05 „Przekazywanie danych”? A może po prostu S19?

Każdą z tych odpowiedzi da się obronić. Żadna nie jest oczywista. I to jest właśnie moment, w którym abstrakcyjny spór o to, czy przepisy nadążają za technologią, zamienia się w decyzję wymagającą uzasadnienia. Wzór B_99.01 służy dokładnie temu, żeby zapisać, jak rozumieją Państwo warianty z list zamkniętych.

Jeżeli usługa wspiera funkcję krytyczną lub istotną, dochodzą kolejne pola: państwo świadczenia usługi, lokalizacja przechowywania i przetwarzania danych, wrażliwość danych, poziom zależności, okresy wypowiedzenia. Wzór B_07.01 pyta o możliwość zastąpienia dostawcy, przyczynę jej braku, istnienie planu wyjścia i datę ostatniej kontroli. B_05.02 wymaga przypisania rangi każdemu podwykonawcy w łańcuchu, a model udostępniany przez warstwę SaaS to łańcuch co najmniej dwupoziomowy.

Subskrypcja opłacona kartą działu nie dostarcza żadnej z tych informacji. I nie jest to wina działu.

Poza sektorem finansowym mechanizm jest ten sam

Art. 8 ust. 1 pkt 1 ustawy o KSC wymaga polityki analizy ryzyka, a pkt 2 lit. e bezpieczeństwa łańcucha dostaw produktów, usług i procesów ICT. Dostawca modelu, do którego trafiają dane organizacji, jest dostawcą w tym rozumieniu niezależnie od tego, czy ktokolwiek zawarł z nim umowę.

Nowej procedury zarządzania incydentami tworzyć nie trzeba. Klasyfikacja według progów istotności wynika z art. 11 ust. 1 pkt 1 i 3, a same progi z rozporządzenia Rady Ministrów; do czasu wydania nowego obowiązuje to z 31 października 2018 r. (Pisaliśmy o tym tutaj). Wstrzyknięcie instrukcji do modelu albo nieautoryzowany transfer danych na zewnątrz to scenariusze do oceny pod istniejącymi progami. Nie odrębny reżim.

Warto pamiętać o kolejności. Obowiązek zgłaszania incydentów poważnych powstaje z chwilą objęcia podmiotu ustawą, niezależnie od okresu przejściowego na zbudowanie SZBI, który upływa 3 kwietnia 2027 r. Wniosek o wpis do wykazu składa się do 3 października.

Jeden dzień, nie projekt

Nie namawiam do budowania inwentarza AI. To brzmi jak inicjatywa, dla której trzeba znaleźć budżet i właściciela, a więc jak coś, co w tym kwartale się nie wydarzy.

Proponuję coś mniejszego. Przed najbliższą aktualizacją rejestru albo przed wnioskiem o wpis do wykazu KSC proszę wziąć zestawienie faktur i rozliczeń kart służbowych z ostatnich dwunastu miesięcy, wybrać z niego subskrypcje narzędzi opartych na AI i dla każdej spróbować wypełnić trzy pola: rodzaj usługi z załącznika III, identyfikator dostawcy oraz ocenę możliwości zastąpienia.

Liczba pozycji, przy których zabraknie odpowiedzi, jest rzeczywistą miarą ekspozycji. Można ją poznać w jeden dzień.

Jak w tym pomagamy

Prowadzimy ten temat w trzech zakresach. Pierwszy to przegląd rejestru informacji lub rejestru dostawców pod kątem komponentów AI: ustalenie, jakie narzędzia są faktycznie używane, klasyfikacja usług według załącznika III i uzupełnienie pól wymaganych dla funkcji krytycznych. Drugi to ocena umów z dostawcami narzędzi AI pod kątem art. 30 DORA oraz art. 8 ustawy o KSC, wraz ze ścieżką postępowania dla tych narzędzi, których warunków nie da się negocjować. Trzeci to aktualizacja procedury klasyfikacji i zgłaszania incydentów o scenariusze związane z AI, w ramach progów, które już Państwo stosują.

Pracujemy tak, żeby zaangażowanie Państwa zespołu ograniczyć do niezbędnego minimum.

Na koniec pytanie, które zostawiam bez własnej odpowiedzi. Czy w ostatnim rejestrze przekazanym do organu znalazła się choć jedna pozycja, przy której ktoś zatrzymał się nad słowem „model”? A jeżeli nie, to czy dlatego, że takich narzędzi u Państwa nie ma, czy dlatego, że nikt ich nie szukał?