Semitora.

29 czerwca 2026 · Zaktualizowano: 25 sierpnia 2026

Klasyfikacja ryzyka AI Act — metoda krok po kroku

Klasyfikację ryzyka AI Act należy wykonać dla konkretnego systemu, przypadku użycia i roli organizacji — nie dla samego modelu ani dostawcy. Najpierw sprawdź, czy rozwiązanie mieści się w definicji systemu AI i czy realizuje praktykę zakazaną. Potem zbadaj obie ścieżki wysokiego ryzyka, obowiązki przejrzystości, pozostałe zastosowania oraz warstwę GPAI. Wynikiem powinien być zapis decyzji z ownerem, źródłem prawnym, uzasadnieniem i datą ponownego przeglądu, a nie tylko etykieta „high-risk” lub „minimalne”.

Punktem odniesienia jest AI Act — rozporządzenie (UE) 2024/1689. Ogólną datą stosowania jest 2 sierpnia 2026, ale część przepisów zaczęła działać wcześniej. Od 2 lutego 2025 stosuje się rozdziały I i II, obejmujące art. 4 oraz zakazy z art. 5. Od 2 sierpnia 2025 stosuje się obowiązki dotyczące GPAI. Zaktualizowany kalendarz high-risk opisujemy w analizie Digital Omnibus a terminy AI Act: 2 grudnia 2027 dla systemów z załącznika III i 2 sierpnia 2028 dla systemów z załącznika I. Każdą datę zapisuj razem z zakresem i rolą, której dotyczy.

Spis treści

Ścieżka decyzji prowadząca od definicji systemu AI przez praktyki zakazane, wysokie ryzyko i przejrzystość do wyniku klasyfikacji

Krok 1. Ustal zakres systemu AI

Odpowiedź na pierwsze pytanie brzmi: klasyfikuj działający układ, który generuje wyniki wpływające na proces, a nie nazwę produktu na fakturze. Opisz wejścia, model lub logikę, wyjścia, stopień autonomii, użytkowników, osoby objęte wynikiem oraz decyzję, którą wynik wspiera. Definicja z art. 3 AI Act wymaga analizy cech rozwiązania; samo użycie słowa „AI” w materiałach marketingowych niczego nie rozstrzyga.

Granica systemu powinna obejmować wszystkie elementy potrzebne do odtworzenia działania. W asystencie rekrutera będzie to nie tylko model językowy, lecz także źródła CV, prompt, reguły rankingu, integracja z ATS i sposób prezentacji rekomendacji człowiekowi. Ten sam model użyty do redagowania neutralnych notatek może należeć do innego przypadku użycia niż model wspierający selekcję kandydatów. Dlatego jeden dostawca może pojawić się w rejestrze kilka razy.

Zbierz minimum:

  1. zamierzony cel i faktyczne użycie;
  2. właściciela biznesowego i technicznego;
  3. kategorię użytkowników i osób, na które wpływa wynik;
  4. dane wejściowe, wyjściowe oraz integracje;
  5. wersję modelu, konfiguracji i polityk;
  6. rynki oraz jurysdykcje wdrożenia.

Jeżeli rozwiązanie nie jest systemem AI w rozumieniu rozporządzenia, zapisz podstawę tej decyzji i termin przeglądu. Zmiana funkcji, modelu lub sposobu użycia może zmienić wynik. Brak zastosowania AI Act nie wyłącza innych reżimów, takich jak ochrona danych, prawo pracy, ochrona konsumentów czy wymogi sektorowe.

Krok 2. Wyklucz praktyki zakazane

Jeżeli przypadek użycia realizuje praktykę zakazaną z art. 5, nie przechodź do łagodniejszej kategorii — zatrzymaj wdrożenie i skieruj sprawę do analizy prawnej. Kontrola ta ma pierwszeństwo przed oceną wysokiego ryzyka. Zakazów nie można „obsłużyć” dodatkową dokumentacją, lepszym monitoringiem ani zgodą ownera.

Art. 5 obejmuje określone praktyki i wyjątki, dlatego nie wystarcza wyszukanie słowa kluczowego. Trzeba opisać mechanizm, kontekst i osoby objęte działaniem. Szczególnej uwagi wymagają między innymi manipulacja lub wykorzystanie podatności, scoring społeczny, określone formy predykcji ryzyka przestępstwa, nieukierunkowane pozyskiwanie obrazów twarzy, rozpoznawanie emocji w miejscu pracy i edukacji oraz niektóre zastosowania biometrii. Nie traktuj tej listy jako samodzielnej opinii prawnej — pracuj na pełnym brzmieniu art. 5 i jego warunkach.

Praktyczny zapis decyzji powinien zawierać: testowaną praktykę, stan faktyczny, właściwy fragment przepisu, ocenione wyjątki, autora analizy i decyzję „stop / przeprojektuj / kontynuuj”. Gdy dział zakupów zmienia dostawcę albo zespół dodaje nowe źródło danych, test trzeba powtórzyć. Art. 4 i art. 5 stosuje się od 2 lutego 2025. Ten wcześniejszy kalendarz należy odróżnić od późniejszych terminów dla załączników I i III.

Krok 3. Sprawdź wysokie ryzyko

System jest kandydatem do kategorii wysokiego ryzyka, gdy prowadzi do niej załącznik I albo załącznik III; każdą ścieżkę sprawdź oddzielnie. Ścieżka z art. 6 ust. 1 wymaga spełnienia łącznie dwóch warunków: system AI jest elementem bezpieczeństwa produktu albo sam jest produktem objętym prawodawstwem harmonizacyjnym z załącznika I, a ten produkt musi przejść ocenę zgodności przez stronę trzecią na podstawie tego prawodawstwa. Załącznik III obejmuje wskazane zastosowania, między innymi w biometrii, infrastrukturze krytycznej, edukacji, zatrudnieniu, dostępie do podstawowych usług, egzekwowaniu prawa, migracji i wymiarze sprawiedliwości — z warunkami zapisanymi w rozporządzeniu.

Nie klasyfikuj całego działu HR albo całej platformy bankowej jednym ruchem. Narzędzie do poprawy języka ogłoszenia o pracę i moduł szeregujący kandydatów mogą mieć inny status. Dla zastosowań z załącznika III sprawdź także warunki z art. 6 ust. 3 i udokumentuj ocenę, zanim powołasz się na przewidziane tam wyłączenie. Zapisuj zamierzony cel, znaczenie wyniku dla decyzji, spełnione przesłanki i każde zastosowane wyłączenie. Jeśli kwalifikacja jest niepewna, oznacz ją jako wymagającą przeglądu prawnego zamiast automatycznie obniżać ryzyko.

Dla systemów wysokiego ryzyka rozporządzenie przewiduje rozbudowany reżim, zależny również od roli podmiotu: zarządzanie ryzykiem, wymagania dotyczące danych, dokumentację techniczną, logowanie, informacje dla podmiotu stosującego, nadzór człowieka, dokładność, odporność i cyberbezpieczeństwo, a także czynności oceny i nadzoru po wprowadzeniu do obrotu po stronie właściwych ról. Nie każda organizacja wykonuje każdy obowiązek. Provider, deployer, importer i dystrybutor mają różne zadania.

Terminy po zmianie opisujemy szerzej w analizie Digital Omnibus a terminy AI Act: pełne reguły stosuje się od 2 grudnia 2027 dla systemów z załącznika III, a od 2 sierpnia 2028 dla systemów z załącznika I. Odroczenie nie jest zgodą na pominięcie inwentaryzacji, wcześniejszych przepisów ani innych obowiązujących regulacji.

Krok 4. Oceń obowiązki przejrzystości

Brak wysokiego ryzyka nie kończy analizy: sprawdź art. 50 i obowiązki informacyjne właściwe dla sposobu interakcji lub rodzaju treści. W zależności od przypadku może chodzić o poinformowanie osoby, że wchodzi w interakcję z systemem AI, oznaczenie określonych syntetycznych treści albo ujawnienie manipulacji obrazem, dźwiękiem lub wideo. Zakres, wyjątki i odpowiedzialna rola wynikają z konkretnego ustępu, nie z ogólnej etykiety „ograniczone ryzyko”.

W praktyce mapuj obowiązek na punkt kontaktu z odbiorcą. Dla chatbota sprawdź pierwszą wiadomość i sytuację, w której kontekst czyni użycie AI oczywistym. Dla treści ustal, kto ją generuje, kto publikuje, w jakim celu i czy działa któryś wyjątek. Zachowaj tekst komunikatu, zrzut lub wersję interfejsu, wynik testu dostępności oraz ownera odpowiedzialnego za zmianę oznaczenia po zmianie kanału.

Sformułowania „ryzyko ograniczone” i „minimalne” są użytecznym skrótem operacyjnym, ale nie zastępują testu przepisów. System może nie być wysokiego ryzyka, a jednocześnie podlegać konkretnemu obowiązkowi przejrzystości, art. 4, przepisom o GPAI albo prawu spoza AI Act. Ogólną datą stosowania pozostaje 2 sierpnia 2026.

Krok 5. Udokumentuj pozostałe zastosowania

Jeśli system nie jest zakazany, nie kwalifikuje się jako wysokiego ryzyka i nie uruchamia badanego obowiązku przejrzystości, zapisz wynik jako niższy profil regulacyjny — nie jako „brak ryzyka”. Takie zastosowania często nazywa się minimalnym ryzykiem. Oznacza to jedynie, że analiza nie wykazała wskazanych obowiązków systemowych AI Act; nie potwierdza bezpieczeństwa, jakości ani zgodności z innymi przepisami.

Dla wewnętrznego podsumowania dokumentów praktyka proporcjonalna może obejmować testy jakości, ograniczenia dostępu i procedurę zgłaszania błędów. Dla narzędzia oddziałującego na klienta potrzeba może być większa. To decyzja governance i zarządzania ryzykiem, a nie automatycznie obowiązek prawny wynikający z etykiety.

Poniższa tabela świadomie oddziela prawo od sposobu wdrożenia. Kolumna „Obowiązki” opisuje możliwe obowiązki prawne, które trzeba potwierdzić dla roli i stanu faktycznego. Kolumna „Artefakt Semitory” pokazuje praktykę implementacyjną służącą zebraniu dowodów; sam artefakt nie jest obowiązkową formą narzuconą przez AI Act.

Materiał nie jest poradą prawną ani formalną oceną zgodności. Semitora wspiera analizę techniczną, governance i budowę dowodów, ale kwalifikację prawną oraz formalną ocenę zgodności należy powierzyć właściwym osobom i, gdy wymagane, jednostkom.

Poziom ryzyka Obowiązki Artefakt Semitory Owner
Niedopuszczalne / praktyka zakazana Zakaz określonej praktyki; sprawdzić zakres i wyjątki art. 5 Notatka decyzji „stop lub przeprojektuj” z wersją stanu faktycznego Legal / compliance oraz sponsor
Wysokie — provider Obowiązki providera obejmują m.in. zarządzanie ryzykiem, wymagania dla danych, dokumentację techniczną, logowanie i zaprojektowanie nadzoru człowieka Macierz wymagań do dowodów, backlog luk, protokół go/no-go Provider systemu AI oraz risk owner
Wysokie — deployer Obowiązki deployera obejmują m.in. użycie zgodne z instrukcją, kontrolę danych wejściowych, nadzór człowieka w eksploatacji, monitoring i przechowywanie logów w wymaganym zakresie Rejestr instrukcji, kontroli operacyjnych, incydentów i eskalacji Deployer oraz owner procesu biznesowego
Wysokie — ścieżka załącznika I Reżim AI Act trzeba połączyć z właściwą procedurą dla produktu regulowanego po spełnieniu obu warunków art. 6 ust. 1 Mapa wymagań AI do dokumentacji produktu i planu oceny Provider AI i producent lub product compliance; role mogą należeć do różnych podmiotów
Przejrzystość Obowiązek informacyjny lub oznaczenie, jeżeli spełnione są przesłanki art. 50 Rejestr komunikatów, test kanałów i wersja zaakceptowana Product owner / content owner
Pozostałe zastosowania Brak automatycznego zestawu obowiązków high-risk; nadal sprawdzić art. 4 i inne prawo Proporcjonalna karta kontroli, testy i termin przeglądu Business owner
GPAI — osobna warstwa Obowiązki zależne od roli dostawcy modelu i charakteru modelu Due diligence dostawcy, dokumentacja modelu i lista zależności Model provider / vendor owner

Mapa łącząca możliwe obowiązki prawne z praktycznymi artefaktami dowodowymi i właścicielami

Artefakt powinien być wersjonowany razem z systemem. Minimalny zapis zawiera identyfikator systemu, use case, rolę organizacji, wynik sześciu kroków, źródła, założenia, otwarte pytania, ownera i datę kolejnego przeglądu. Dzięki temu zmiana modelu albo celu nie nadpisuje historii decyzji.

Krok 6. Dodaj warstwę GPAI i role

Na końcu nałóż dwie osie: zależność od modelu GPAI oraz rolę każdego podmiotu w łańcuchu wartości. GPAI nie jest „piątym poziomem ryzyka”. To osobny reżim dla modeli ogólnego przeznaczenia, który może współistnieć z klasyfikacją systemu końcowego. Obowiązki GPAI stosuje się od 2 sierpnia 2025; ich zakres zależy między innymi od tego, kto jest dostawcą modelu i jakie cechy ma model. Dla modeli wprowadzonych na rynek przed tą datą obowiązują odrębne reguły przejściowe, dlatego termin wymagany od providera trzeba sprawdzić w art. 111 i 113 przed oznaczeniem dokumentacji jako spóźnionej.

Firma korzystająca z API nie staje się przez sam zakup dostawcą modelu GPAI, ale nadal powinna ustalić zależności, warunki użycia i dostępność dokumentacji. Równolegle trzeba określić rolę wobec systemu końcowego. Organizacja może być podmiotem stosującym gotowe narzędzie, dostawcą własnego systemu pod swoją nazwą, importerem albo dystrybutorem. Istotna zmiana systemu lub zmiana zamierzonego celu może wpłynąć na role i obowiązki, dlatego wymaga oceny na konkretnych faktach.

Dobre przekazanie wyniku ma formę krótkiego rekordu decyzyjnego:

Siedmioczęściowy sposób porządkowania dokumentacji opisujemy w Evidence Pack dla AI Act. Nie każdy element pakietu jest nazwanym wprost dokumentem ustawowym, ale razem tworzą czytelny ślad od zakresu i testów do decyzji oraz eksploatacji.

Siedem części Evidence Pack: inwentarz, klasyfikacja, golden set, ewaluacje, logi i monitoring, kontrola człowieka oraz decyzja

FAQ: klasyfikacja ryzyka AI Act

Czy cały model językowy ma jeden poziom ryzyka?

Nie. Klasyfikacja systemu końcowego zależy od zamierzonego celu, przypadku użycia, roli i kontekstu. Ten sam model może wspierać mało istotną redakcję tekstu oraz osobny proces rekrutacyjny wymagający analizy załącznika III. Model GPAI analizuje się dodatkowo jako odrębną warstwę.

Czy użycie człowieka w pętli automatycznie usuwa wysokie ryzyko?

Nie. Nadzór człowieka może być ważną kontrolą, lecz sama obecność osoby akceptującej wynik nie zmienia automatycznie zakresu załączników ani przesłanek przepisu. Trzeba zbadać realną możliwość zrozumienia, zakwestionowania i odrzucenia wyniku oraz kwalifikację całego use case’u.

Czy po odroczeniu high-risk można czekać z klasyfikacją?

Nie jest to rozsądna praktyka. Digital Omnibus przesunął pełne terminy dla wskazanych systemów, ale nie wyłączył przepisów działających wcześniej ani innych reżimów. Klasyfikacja jest potrzebna właśnie po to, by ustalić, który termin i obowiązek dotyczą danego systemu.

Kto powinien zatwierdzić wynik klasyfikacji?

Owner biznesowy powinien potwierdzić fakty i zamierzony cel, właściciel techniczny — architekturę oraz zachowanie systemu, a risk, compliance i legal — odpowiednie obszary kwalifikacji. Dla systemów regulowanych potrzebne są także role produktowe i osoby odpowiedzialne za formalną ścieżkę oceny.

Jak często powtarzać klasyfikację?

Nie ma jednego uniwersalnego rytmu dla każdego systemu. Ustal przegląd okresowy i triggery zdarzeniowe: nowy cel, model, dostawca, źródło danych, grupa użytkowników, kraj, integracja lub znacząca zmiana wydajności. Ważniejsze od samego kalendarza jest powiązanie przeglądu ze zmianą stanu faktycznego.

Źródła i dalsze kroki

Nadrzędnym źródłem metody klasyfikacji jest tekst rozporządzenia (UE) 2024/1689. Czytaj przepisy razem z załącznikami, definicjami, rolami i właściwymi wyjątkami; zaktualizowane terminy high-risk podsumowujemy w analizie Digital Omnibus a terminy AI Act. Ten materiał ma charakter informacyjny; nie zastępuje porady prawnej ani formalnej oceny zgodności konkretnego wdrożenia.

Na stronie AI Act w Semitora opisujemy zakres prac technicznych i governance. Do samodzielnego uporządkowania pracy służą checklista gotowości i szablon Evidence Pack. Jeśli potrzebujesz przejść od rejestru systemów przez klasyfikację do planu dowodowego, zobacz usługi Semitory. Dobrym pierwszym wynikiem warsztatu nie jest kolor w arkuszu, lecz uzgodniony rekord decyzji, owner oraz lista pytań, które wymagają formalnej interpretacji.