Rejestr i klasyfikacja systemów AI: ustawa z 3 lipca 2026 i kalendarz KRiBSI

Kto skorzysta z tego przewodnika.

• Firmy, które kupiły albo zbudowały narzędzia z funkcjami AI i nie mają jednej listy tych systemów
• Zespoły produktowe, których funkcja AI została właśnie zakwestionowana w ankiecie od klienta
• Software house'y i integratorzy, którzy muszą powiedzieć klientowi, w jakiej roli występują
• Urzędy i samorządy, w których urzędnicy korzystają z generatywnej AI szybciej, niż powstają zasady
• Compliance, CISO i CTO, którzy potrzebują artefaktu do podpisania, a nie prezentacji

Co weszło w życie i kiedy

Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji została ogłoszona 27 lipca 2026 (Dz.U. 2026 poz. 1003) i weszła w życie 11 sierpnia 2026. Art. 8-18 oraz rozdziały 3-5, 8 i 9 wchodzą w życie później, 28 października 2026. To rozróżnienie ma znaczenie praktyczne, bo właśnie w tej późniejszej grupie znajduje się tryb kontroli i przepisy o karach.

Art. 5 ust. 1-2 ustanawia Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji organem nadzoru rynku w rozumieniu art. 70 ust. 1 rozporządzenia (UE) 2024/1689 oraz pojedynczym punktem kontaktowym. Przewodniczącą Komisji powołał Sejm za zgodą Senatu, wyrażoną 24 września 2026. Komisja ma rozpocząć pracę w listopadzie 2026.

Ustawa przewiduje również piaskownice regulacyjne, a mikro, mali i średni przedsiębiorcy mogą w nich uczestniczyć nieodpłatnie.

Czy wasze narzędzie jest systemem AI

Nikt nie przyjdzie i nie powie wam, że dany system podlega przepisom. Każdy podmiot ocenia to samodzielnie, a ocena musi dać się odtworzyć, bo to od niej zaczyna się rozmowa przy kontroli, w ankiecie klienckiej i w badaniu due diligence.

Oceniamy cechy techniczne systemu, a nie to, jak nazywa go dostawca w materiałach handlowych. Znaczenie ma to, czy system wnioskuje z danych wejściowych i jak dużą ma autonomię. Liczy się też, czy jego wyniki, na przykład rekomendacje albo decyzje dotyczące ludzi, mogą wpływać na środowisko fizyczne lub wirtualne. Zdolność adaptacji po wdrożeniu definicja wymienia jako cechę możliwą, a nie konieczną.

Najwięcej sporów powstaje tam, gdzie łatwo powiedzieć, że to tylko automatyzacja: scoring i ranking, predykcja używana do typowania spraw do kontroli, klasyfikacja dokumentów, generowanie odpowiedzi w obsłudze klienta, sortowanie kandydatów. Publicznie opisywane spory o kwalifikację takich systemów pokazują, że rozstrzyga się to na faktach technicznych, więc te fakty trzeba mieć spisane, zanim ktoś zapyta.

• Reguły napisane ręcznie a model wytrenowany na danych to dwie różne odpowiedzi, więc trzeba wiedzieć, co naprawdę siedzi w produkcie
• System kupiony, w którym dostawca dołożył funkcję AI w aktualizacji, jest waszym systemem w rozumieniu obowiązków podmiotu stosującego
• Ta sama technologia w dwóch zastosowaniach może mieć dwie różne klasy ryzyka, bo decyduje przeznaczenie, nie algorytm
• Przypadek graniczny opisujemy jako graniczny i kierujemy do radcy, zamiast rozstrzygać go po cichu na korzyść wygodniejszej odpowiedzi

Jak zrobić inwentaryzację, która się obroni

Inwentaryzacja zrobiona przez wysłanie ankiety do zespołów kończy się listą tego, co ludzie pamiętają. Zbieramy z czterech źródeł naraz i porównujemy wyniki, bo dopiero rozbieżności między nimi pokazują, czego brakuje.

Poniżej pola, które musi mieć wpis, żeby dało się go obronić bez obecności osoby, która go tworzyła.

• Co zbudowaliście sami: repozytoria, wywołania API modeli, usługi z wbudowaną integracją modelu
• Co kupiliście świadomie jako narzędzie AI: umowy, faktury, aneksy do umów powierzenia
• Co dostaliście po cichu: funkcje AI dołożone przez dostawców w aktualizacjach istniejącego oprogramowania
• Czego ludzie używają sami: aplikacje widoczne w logowaniu SSO i w wydatkach na kartach służbowych

Dostawca czy podmiot stosujący

Rola decyduje o zestawie obowiązków i bywa częstszym źródłem nieporozumień niż sama klasa ryzyka. Firma, która wdraża kupiony system, występuje zwykle jako podmiot stosujący, ale może stać się dostawcą, jeżeli oznacza system własną nazwą lub znakiem towarowym, istotnie go modyfikuje albo zmienia jego przeznaczenie na takie, którego sam dostawca nie przewidział.

To rozróżnienie sprawdzamy dla każdego wpisu w rejestrze i zapisujemy razem z faktami, na których się opiera. Ostateczną kwalifikację prawną potwierdza radca, bo od niej zależy lista obowiązków, które trzeba potem wykonać.

Co może pójść nie tak i co z tym robimy.

1. 1
   Rejestr powstaje w arkuszu i umiera po kwartale

   Inwentaryzacja zrobiona jednorazowo pod audyt albo pod ankietę klienta trafia do arkusza i nie ma ani właściciela, ani punktu, w którym ktoś musi ją zaktualizować. Systemy zmieniają się szybciej niż arkusz: dostawca włącza funkcję AI w aktualizacji, zespół podmienia model na nowszy, ktoś kupuje narzędzie na kartę służbową. Po dwóch kwartałach rejestr opisuje stan, którego już nie ma. Jest wtedy gorszy niż jego brak, bo daje poczucie kontroli bez pokrycia.

   Co z tym robimy

   Wpinamy rejestr w procesy, które i tak się dzieją: zakup narzędzia, wdrożenie, zmiana dostawcy i zmiana modelu dostają pole obowiązkowe z odsyłaczem do wpisu. Każdy wpis ma właściciela z imienia i nazwiska. Do tego ustawiamy kwartalny przegląd, w którym rejestr porównuje się z listą aplikacji z logowania SSO i z wydatkami, a różnice trafiają na listę do wyjaśnienia.

   Co zostaje u was: rejestr z właścicielami, procedura aktualizacji wpięta w zakupy i wdrożenia oraz kwartalna lista różnic
2. 2
   Klasyfikacja bez uzasadnienia

   W kolumnie z klasą ryzyka stoi wartość, ale nie ma zapisu, na jakiej podstawie ją przyjęto. Osoba, która to rozstrzygnęła, zmieniła stanowisko albo firmę. Przy pierwszym pytaniu kontrolera, klienta albo kupującego w due diligence nikt nie odtworzy toku rozumowania, więc całą klasyfikację robi się od nowa, tym razem pod presją czasu.

   Co z tym robimy

   Każdy wpis dostaje uzasadnienie z powołaniem na przepis i na konkretne fakty o systemie: przeznaczenie, dane, autonomię i wpływ na osoby. Zapisujemy datę i osobę. Uzasadnienia przechodzimy razem z waszym radcą prawnym i utrwalamy wynik tego przeglądu obok wpisu, a nie w czyjejś skrzynce pocztowej.

   Co zostaje u was: uzasadnienie klasyfikacji dla każdego systemu, w formie gotowej do przeglądu i podpisu przez prawnika
3. 3
   AI wbudowana w kupione narzędzie zostaje poza rejestrem

   Inwentaryzacja pyta zespoły, co zbudowały, a nie pyta dostawców, co dołożyli. Funkcje AI wchodzą do systemu rekrutacyjnego, obsługi zgłoszeń i CRM przy zwykłej aktualizacji, bez żadnej decyzji po waszej stronie. To właśnie przy nich stoi zestaw obowiązków podmiotu stosującego, a w rejestrze ich nie ma, bo nikt nie uznał aktualizacji za wdrożenie AI.

   Co z tym robimy

   Wysyłamy dostawcom konkretne pytanie o funkcje AI w używanej przez was wersji i o to, co planują dołożyć; wzór pytania zostaje u was do ponownego użycia. Równolegle czytamy changelogi i aneksy do umów powierzenia oraz porównujemy listę aplikacji z SSO z rejestrem. Odpowiedzi i daty sprawdzenia zapisujemy przy wpisach, więc następnym razem widać, co jest świeże, a co wymaga ponowienia.

   Co zostaje u was: lista dostawców z odpowiedziami i datami oraz wzór pytania do ponownego użycia
4. 4
   Kwalifikacja rozstrzygana życzeniowo

   Uznanie systemu za zwykłą automatyzację jest tańsze i szybsze, więc opis produktu zaczyna dopasowywać się do pożądanego wyniku. Rzecz w tym, że kwalifikację ocenia się na faktach technicznych, a te są zapisane w kodzie, w umowie z dostawcą i w tym, co system realnie robi z danymi. Rozjazd między opisem a faktami wychodzi dokładnie wtedy, kiedy jest najdroższy.

   Co z tym robimy

   Kwalifikację prowadzimy na faktach: co jest w kodzie i w konfiguracji, jakie dane wchodzą, jak duża jest autonomia i co dzieje się z wynikiem. Fakty spisujemy przy wpisie razem ze źródłem. Przypadki, w których fakty nie rozstrzygają, oznaczamy jako sporne i przekazujemy radcy z gotowym pytaniem, zamiast rozstrzygać je samodzielnie.

   Co zostaje u was: lista przypadków granicznych z opisem faktów i pytaniem sformułowanym dla radcy prawnego
5. 5
   Kalendarz czytany jako jedna data

   Zdanie o tym, że ustawa weszła w życie 11 sierpnia, brzmi jak zamknięcie tematu, więc plan pracy powstaje pod tę jedną datę. Tymczasem przepisy o trybie kontroli i o karach wchodzą 28 października, a organ staje się operacyjny jeszcze później. Najtwardsza część harmonogramu zostaje na koniec, kiedy nie ma już miejsca na przesunięcie.

   Co z tym robimy

   Plan pracy układamy pod obie daty i pod moment, w którym organ zaczyna działać, z listą tego, co musi być gotowe przed każdą z nich. Harmonogram ma właścicieli i statusy, więc widać na nim, co jest zrobione, a co dopiero zaplanowane. Przechodzimy przez niego z wami raz w miesiącu do końca roku.

   Co zostaje u was: harmonogram z podziałem na obie daty wejścia w życie, z właścicielami i statusem

Co zostaje u was.

• Rejestr systemów AI z właścicielem, przeznaczeniem, danymi, modelem, dostawcą i wersją
• Uzasadnienie klasyfikacji dla każdego systemu, gotowe do przeglądu prawnego
• Ustalenie roli, dostawca albo podmiot stosujący, dla każdego wpisu, razem z faktami
• Procedura aktualizacji rejestru wpięta w zakupy, wdrożenia i zmiany dostawcy
• Lista dostawców z odpowiedziami na pytania o funkcje AI oraz wzór pytania do ponownego użycia
• Lista przypadków granicznych z pytaniami sformułowanymi dla radcy prawnego
• Harmonogram z podziałem na 11 sierpnia i 28 października 2026

Jak pracujemy.

1. 1
   1. Zbiórka z czterech źródeł

   Repozytoria i wywołania API, umowy i faktury, changelogi dostawców, logowanie SSO i wydatki. Porównujemy wyniki, a rozbieżności między nimi wyznaczają dalszą pracę.

   Tydzień 1
2. 2
   2. Rejestr i pierwsza klasyfikacja

   Opisujemy każdy system w pełnym zestawie pól, przypisujemy rolę i klasę ryzyka razem z uzasadnieniem opartym na faktach.

   Tydzień 1-2
3. 3
   3. Przypadki graniczne i przegląd prawny

   Oddzielamy to, co rozstrzygają fakty, od tego, co wymaga wykładni. Przygotowujemy pytania i przechodzimy przez nie z waszym radcą albo z naszym partnerem prawnym.

   Tydzień 2-3
4. 4
   4. Wpięcie w procesy i przekazanie

   Rejestr dostaje właścicieli i procedurę aktualizacji, a harmonogram terminów trafia do osób, które za nie odpowiadają. Przekazujemy komplet i omawiamy go z kierownictwem.

   Tydzień 3-4
5. 5
   5. Przegląd kwartalny

   Porównujemy rejestr z rzeczywistością: nowe aplikacje w SSO, aktualizacje dostawców, zmiany modeli. Różnice wyjaśniamy i dopisujemy.

   Co kwartał

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

Zakres przewodnika.

Jesteśmy zespołem inżynierskim, nie kancelarią. Budujemy rejestr, zbieramy fakty i przygotowujemy uzasadnienia w formie gotowej do przeglądu, ale kwalifikację prawną systemu i ocenę obowiązków podpisuje radca prawny: wasz albo nasz partner prawny. Przypadki, w których fakty nie rozstrzygają, oznaczamy jako sporne, zamiast rozstrzygać je po cichu.

Skąd pochodzą daty i liczby.

• Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), tekst aktu
• Ministerstwo Cyfryzacji: ustawa o systemach AI, bezpieczny rozwój sztucznej inteligencji w Polsce
• Rozporządzenie (UE) 2024/1689 (AI Act), tekst w EUR-Lex
• prawo.pl: AI Act wchodzi w życie, urzędy nie wiedzą, czy korzystają ze sztucznej inteligencji
• Przewodnik po sztucznej inteligencji dla administracji publicznej (Ministerstwo Cyfryzacji, marzec 2026)
• Senat RP: 65. posiedzenie Senatu, 24 września 2026, zgoda na powołanie przewodniczącej Komisji Rozwoju i Bezpieczeństwa Sztucznej Inteligencji
• Komisja Europejska: wytyczne w sprawie definicji systemu AI z rozporządzenia 2024/1689, C(2025) 5053 final