Wiele zarządów w Polsce ma już politykę bezpieczeństwa IT i zakłada, że pokrywa ona również sztuczną inteligencję. Rozporządzenie (UE) 2024/1689, znane jako AI Act, weszło w życie 1 sierpnia 2024 roku. Nie dokłada systemów AI do listy oprogramowania chronionego hasłem i firewallem. Nakłada osobny zestaw obowiązków, rozłożonych w czasie, skierowanych do konkretnych ról w organizacji i wymagających innego rodzaju dokumentacji niż ta, którą dział IT prowadzi od lat.

Różnica nie jest kosmetyczna. Polityka bezpieczeństwa IT odpowiada na pytanie, kto ma dostęp do czego. Governance AI zadaje inne pytanie. Pyta, kto odpowiada za konkretną decyzję, którą podjął albo wspomógł system, i czy da się tę odpowiedzialność wykazać po fakcie. To dwa różne reżimy, nawet jeśli w praktyce często trafiają do tego samego segregatora.

Art. 9: zarządzanie ryzykiem jako proces ciągły

Dla systemów AI wysokiego ryzyka Rozporządzenie wymaga ustanowienia, wdrożenia, udokumentowania i utrzymywania systemu zarządzania ryzykiem. Obowiązek ten zacznie realnie wiązać systemy z Załącznika III, czyli samodzielne systemy wysokiego ryzyka, od 2 grudnia 2027 roku, a systemy wysokiego ryzyka wbudowane w produkty objęte Załącznikiem I sekcja A od 2 sierpnia 2028 roku, po przesunięciu obu terminów rozporządzeniem zmieniającym z pierwotnego 2 sierpnia 2026 roku.

Kluczowe słowo w samym przepisie to „utrzymywania". Przepis opisuje ten system wprost jako ciągły, iteracyjny proces obejmujący cały cykl życia systemu AI, wymagający regularnego, systematycznego przeglądu i aktualizacji.

Standardowa polityka IT zwykle powstaje raz, jest zatwierdzana przez zarząd i odświeżana przy okazji audytu albo incydentu. System zarządzania ryzykiem z art. 9 ma odwrotną logikę. Zakłada z góry, że ryzyko systemu AI zmienia się wraz z danymi, którymi jest karmiony, i wraz ze skalą jego użycia. Dokument, który nie ma wbudowanego harmonogramu przeglądu, nie spełnia tego wymogu, niezależnie od tego, jak dokładnie opisuje stan na dzień podpisania.

Art. 17: system zarządzania jakością, teraz proporcjonalny do wielkości firmy

Dostawcy systemów AI wysokiego ryzyka muszą wprowadzić udokumentowany, pisemny system zarządzania jakością. Ten obowiązek startuje w tym samym rytmie co art. 9, czyli od 2 grudnia 2027 roku dla systemów z Załącznika III i od 2 sierpnia 2028 roku dla systemów wbudowanych w produkty z Załącznika I sekcja A. Obejmuje on strategię zgodności regulacyjnej, techniki projektowania i weryfikacji, procedury testowania i walidacji, zarządzanie danymi, sam system zarządzania ryzykiem z art. 9, monitorowanie po wprowadzeniu do obrotu oraz procedurę zgłaszania incydentów.

To brzmi jak coś, co mają wyłącznie duzi dostawcy oprogramowania. Digital Omnibus, opublikowany w Dzienniku Urzędowym UE 24 lipca 2026 roku, który wszedł w życie 27 lipca 2026 roku, zmienił jednak ten przepis w jednym istotnym punkcie. Wdrożenie systemu zarządzania jakością ma być proporcjonalne do wielkości dostawcy, z wyraźnym uwzględnieniem MŚP, startupów i małych spółek o średniej kapitalizacji. Innymi słowy, obowiązek zostaje, ale jego zakres różni się w zależności od tego, czy mówimy o organizacji z jedną osobą odpowiedzialną za AI, czy o dziale liczącym kilkadziesiąt osób.

Art. 26: obowiązki podmiotu stosującego

Tu najczęściej pojawia się mylne założenie, że governance AI to problem wyłącznie firm, które budują lub sprzedają systemy AI. Art. 26 nakłada osobny zestaw obowiązków na podmiot stosujący, czyli każdą organizację, która używa systemu wysokiego ryzyka w swojej działalności. Ten sam podział dat obowiązuje i tutaj. Obowiązek zacznie wiązać systemy z Załącznika III od 2 grudnia 2027 roku, a systemy z Załącznika I sekcja A od 2 sierpnia 2028 roku. Cztery elementy tego obowiązku rzadko pokrywają się z tym, co zawiera zwykła polityka IT:

  • stosowanie systemu ściśle zgodnie z jego instrukcją obsługi,
  • powierzenie nadzoru osobom z niezbędnymi kompetencjami, przeszkoleniem, uprawnieniami i wsparciem,
  • monitorowanie działania systemu i informowanie dostawcy albo organu nadzoru w razie ryzyka, przy jednoczesnym obowiązku przechowywania rejestrów zdarzeń przez minimum sześć miesięcy,
  • informowanie pracowników przed uruchomieniem systemu w ich miejscu pracy.

Żaden z tych czterech punktów nie jest pokryty przez standardową politykę bezpieczeństwa danych. Wymagają wskazania konkretnych osób, konkretnych kompetencji i konkretnego terminu przechowywania śladu, znacznie więcej niż ogólna deklaracja, że „dostęp jest kontrolowany".

Zakup gotowego systemu niczego nie zdejmuje z organizacji

W praktyce oznacza to, że sam fakt zakupu systemu AI od renomowanego dostawcy niczego nie zdejmuje z organizacji. Podmiot stosujący pozostaje adresatem obowiązku nadzoru niezależnie od tego, kto system zbudował, i to on odpowiada za to, czy osoba wyznaczona do nadzoru rzeczywiście ma czas, wiedzę i uprawnienie, żeby zakwestionować wynik zamiast automatycznie go zaakceptować.

Podpisanie jednej polityki AI nie zamyka tematu governance, tak samo jak podpisanie jednej polityki bezpieczeństwa nie zamyka tematu cyberbezpieczeństwa. Art. 9, 17 i 26 opisują razem system z właścicielami, harmonogramem przeglądu i rejestrem zdarzeń. Pytanie, które warto zadać na najbliższym posiedzeniu zarządu, brzmi prosto. Kto konkretnie odpowiada za przegląd tego dokumentu za sześć miesięcy i skąd będzie wiedział, że coś się zmieniło.

Cztery terminy i co zaczyna obowiązywać kiedy

Harmonogram wejścia w życie

Rozporządzenie weszło w życie stopniowo. Zakaz praktyk uznanych za niedopuszczalne oraz obowiązek kompetencji AI zaczęły obowiązywać 2 lutego 2025 roku, obowiązki dla dostawców modeli ogólnego przeznaczenia od 2 sierpnia 2025 roku, przy czym reżim kar dla tych dostawców z art. 101 został wyłączony spod tej daty i jest stosowany dopiero od 2 sierpnia 2026 roku, a ogólna data stosowania obowiązków przejrzystości oraz aparatu nadzoru rynku przypadła na 2 sierpnia 2026 roku.

Obowiązki dla systemów wysokiego ryzyka z art. 9, 17 i 26, opisane w tym artykule, mają własny, odrębny harmonogram. Dla samodzielnych systemów z Załącznika III zaczynają wiązać od 2 grudnia 2027 roku, a dla systemów wbudowanych w produkty z Załącznika I sekcja A od 2 sierpnia 2028 roku, po przesunięciu obu dat z pierwotnego 2 sierpnia 2026 roku.

Po stronie polskiej ustawy kontrole, postępowania i kary zaczną obowiązywać dopiero 28 października 2026 roku. To data przyszła, nie taka, która już minęła, a organem uprawnionym do nakładania sankcji będzie Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji, złożona z przewodniczącego, dwóch zastępców i czterech członków wskazanych przez UOKiK, KNF, KRRiT i UKE.

Polska ustawa: daty i skład komisji

Sejm uchwalił polską ustawę 11 czerwca 2026 roku. Ostateczny akt, ustawa z dnia 3 lipca 2026 roku, został ogłoszony w Dzienniku Ustaw pod pozycją 1003 27 lipca 2026 roku. Weszła w życie 11 sierpnia 2026 roku. Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji uzyska uprawnienia kontrolne i sankcyjne 28 października 2026 roku. Po Omnibusie skonsolidowany tekst Rozporządzenia liczy 113 artykułów i 14 załączników.

Skala kar

Skala kar różni się w zależności od naruszonego obowiązku. Naruszenie zakazanych praktyk zagrożone jest karą do 35 mln euro albo 7% globalnego rocznego obrotu, w zależności od tego, która wartość jest wyższa. Naruszenie innych obowiązków materialnych zagrożone jest karą do 15 mln euro albo 3% obrotu.

Dla MŚP, w tym przedsiębiorstw typu start-up, reguła jest odwrócona na każdym progu: kara nie przekracza niższej z dwóch wartości. Dla małych spółek o średniej kapitalizacji to odwrócenie obejmuje progi z art. 99 ust. 4 i 5, bez progu za praktyki zakazane. Art. 9 i 17 są obowiązkami dostawcy, egzekwowanymi w tym katalogu zgodnie z art. 99 ust. 4 lit. a, a art. 26 jest w nim wymieniony bezpośrednio jako obowiązek podmiotu stosującego. Oba prowadzą do tego samego progu, do 15 mln euro albo 3% obrotu.

Punkt odniesienia poza Unią

Wymóg dedykowanego zarządzania ryzykiem AI nie jest europejskim wynalazkiem. Amerykański NIST opublikował własne AI Risk Management Framework (dokument NIST.AI.100-1) już 26 stycznia 2023 roku, z deklarowanym celem lepszego zarządzania ryzykiem dla osób, organizacji i społeczeństwa związanym z systemami AI oraz poprawy zdolności do uwzględniania wiarygodności tych systemów już na etapie projektowania. Ten fakt jest przydatny w rozmowie z zarządem sceptycznym wobec regulacji europejskiej. Dedykowane ramy zarządzania AI, odrębne od ogólnej polityki bezpieczeństwa IT, powstają równolegle po obu stronach Atlantyku, niezależnie od siebie.

Od czego zacząć

Metodyka takiego przeglądu opiera się bezpośrednio na pełnym tekście Rozporządzenia w wersji skonsolidowanej, obejmującej po Omnibusie 180 motywów i 14 załączników. W praktyce oznacza to jeden konkretny punkt startowy: sprawdzenie, czy istniejąca polityka IT w ogóle wymienia z nazwy art. 9, 17 i 26, czy tylko odsyła ogólnie do „zgodności z obowiązującymi przepisami". Jeśli odpowiedź brzmi to drugie, dokument prawdopodobnie nie przetrwa pierwszego pytania kontrolnego.

Bezpłatny audyt wstępny pod adresem novus-point.pl/audyt daje w kilka minut wstępną orientację, czy w organizacji w ogóle występują systemy podlegające tym obowiązkom. Dla organizacji, które już wiedzą, że mają systemy wysokiego ryzyka i chcą zbudować governance zgodny z art. 9, 17 i 26, właściwym krokiem jest rozmowa 30-minutowa przez formularz kontaktowy, prowadzona przez Google Meet, bez gwarancji wyniku regulacyjnego z góry.

Obie ścieżki pokazują, od którego z trzech artykułów warto zacząć w konkretnej organizacji. Samą pracę wewnętrzną, wskazanie konkretnych osób, ustalenie harmonogramu przeglądu i utrzymanie rejestru zdarzeń, organizacja wykonuje we własnym zakresie.