Jakie są poziomy ryzyka w EU AI Act?

Komisja Europejska przedstawia cztery poziomy: ryzyko niedopuszczalne, wysokie ryzyko, ryzyko związane z przejrzystością oraz ryzyko minimalne lub brak ryzyka. Obowiązki nie zawsze układają się w rozłączne szufladki — system wysokiego ryzyka może jednocześnie podlegać obowiązkom przejrzystości.

Kiedy system AI jest systemem wysokiego ryzyka?

Są dwie główne drogi: system jest produktem objętym reżimem z załącznika I lub elementem bezpieczeństwa takiego produktu wymagającego oceny zgodności przez stronę trzecią, albo realizuje konkretne zastosowanie z załącznika III (biometria, infrastruktura krytyczna, edukacja, zatrudnienie, dostęp do usług podstawowych, egzekwowanie prawa, migracja, wymiar sprawiedliwości).

Czym różni się provider od deployera?

Provider rozwija system lub zleca jego rozwój i wprowadza go na rynek albo uruchamia pod własną nazwą. Deployer używa systemu w ramach działalności zawodowej. Jeżeli klient oznacza system własną marką, istotnie go modyfikuje lub zmienia jego zamierzony cel, może przejąć obowiązki providera.

EU AI Act w praktyce — klasyfikacja ryzyka use case’u

Q: Czy klasyfikacja use case’u jest stała?

Nie. Use case może zmienić kategorię po pozornie niewielkiej zmianie procesu. Klasyfikację warto włączyć do zarządzania zmianą: przegląd po zmianie modelu, danych, integracji, grupy użytkowników, poziomu autonomii lub procesu biznesowego.

Nie klasyfikujesz modelu. Klasyfikujesz konkretny sposób jego użycia — razem z celem, danymi, osobami, na które wpływa, i rolą człowieka w procesie.

„Korzystamy z GPT, więc do której kategorii ryzyka trafiamy?” To jedno z najczęstszych, ale źle postawionych pytań o EU AI Act. Ten sam model językowy może pomagać pracownikowi znaleźć instrukcję w intranecie, filtrować CV kandydatów albo wspierać decyzję kredytową. Technologia bazowa może być identyczna, lecz konsekwencje prawne będą zupełnie inne.

Klasyfikacja wynika przede wszystkim z zamierzonego zastosowania systemu: jaką funkcję pełni, w jakim procesie działa, kogo dotyczy i czy jego wynik wpływa na zdrowie, bezpieczeństwo lub prawa podstawowe. Dlatego pierwszym artefaktem compliance nie powinien być opis modelu, ale precyzyjna karta use case’u.

Poniżej pokazujemy praktyczną ścieżkę, która pozwala przejść od pomysłu na automatyzację do wstępnej kwalifikacji ryzyka — bez zamieniania warsztatu biznesowego w kilkutygodniowy projekt prawny.

Ważne: artykuł ma charakter edukacyjny i nie stanowi porady prawnej. Ostateczna klasyfikacja wymaga analizy konkretnego systemu, sposobu użycia, roli organizacji oraz aktualnego tekstu przepisów i wytycznych.

Cztery poziomy ryzyka to dopiero początek

Komisja Europejska przedstawia cztery poziomy: ryzyko niedopuszczalne, wysokie ryzyko, ryzyko związane z przejrzystością oraz ryzyko minimalne lub brak ryzyka. Ta piramida jest użyteczna komunikacyjnie, ale w projekcie trzeba patrzeć szerzej.

Po pierwsze, obowiązki nie zawsze układają się w rozłączne szufladki. System wysokiego ryzyka może jednocześnie podlegać obowiązkom przejrzystości. Po drugie, regulacja modeli ogólnego przeznaczenia — GPAI — stanowi osobną oś. Po trzecie, nawet use case minimalnego ryzyka nadal może podlegać RODO, prawu konsumenckiemu, własności intelektualnej, cyberbezpieczeństwu lub regulacjom sektorowym.

Dlatego praktyczna klasyfikacja powinna odpowiadać nie na jedno, ale na kilka kolejnych pytań.

Krok 0. Czy rozwiązanie jest systemem AI w rozumieniu rozporządzenia?

Nie każda automatyzacja jest systemem AI. Zanim zespół zacznie wybierać kategorię ryzyka, powinien sprawdzić, czy rozwiązanie mieści się w definicji z art. 3 EU AI Act. Znaczenie mają m.in. zdolność systemu do wnioskowania na podstawie danych wejściowych i generowania wyników — takich jak predykcje, treści, rekomendacje lub decyzje — które mogą wpływać na środowisko fizyczne albo wirtualne.

Zwykły kalkulator oparty na stałych regułach czy klasyczny raport SQL nie staje się automatycznie AI tylko dlatego, że ma nowoczesny interfejs. Z kolei aplikacja wykorzystująca model uczenia maszynowego lub LLM może być systemem AI, nawet jeśli użytkownik widzi wyłącznie prosty formularz.

W praktyce zapisz dwie informacje: na czym polega wnioskowanie systemu oraz jaki wynik system generuje i co ten wynik zmienia. Jeśli odpowiedź pozostaje niejednoznaczna, warto sięgnąć do wytycznych Komisji dotyczących definicji systemu AI.

Krok 1. Czy use case wchodzi w obszar praktyk zakazanych?

To test, który należy przeprowadzić przed rozmową o kontrolach, dokumentacji i human oversight. Jeśli zamierzone zastosowanie jest zakazane, odpowiedzią nie jest „dodajmy akceptację człowieka”, lecz zatrzymanie lub przeprojektowanie rozwiązania.

Obecna lista obejmuje między innymi szkodliwą manipulację i wykorzystywanie podatności osób, social scoring, określone formy predykcji przestępstw, nieukierunkowane pozyskiwanie zdjęć twarzy z internetu lub CCTV do budowy baz rozpoznawania twarzy, a także rozpoznawanie emocji w miejscu pracy i placówkach edukacyjnych — z wąskimi wyjątkami medycznymi lub bezpieczeństwa. Zakazane są również określone formy kategoryzacji biometrycznej oraz, co do zasady, zdalna identyfikacja biometryczna w czasie rzeczywistym przez organy ścigania w przestrzeni publicznej, z bardzo ograniczonymi wyjątkami.

Od 2 grudnia 2026 r. zacznie obowiązywać także dodany przez AI Omnibus zakaz systemów generujących bez zgody treści seksualnie jednoznaczne lub intymne oraz materiały przedstawiające seksualne wykorzystywanie dzieci.

Przykład: narzędzie analizujące „poziom zaangażowania” pracownika na podstawie mimiki podczas wideokonferencji nie jest po prostu HR-tech o podwyższonym ryzyku. Jeżeli w rzeczywistości rozpoznaje emocje w miejscu pracy, może wpadać w obszar zakazany.

Krok 2. Czy system jest wysokiego ryzyka?

EU AI Act przewiduje dwie główne drogi do kategorii high-risk.

Droga A: AI jako produkt lub element bezpieczeństwa produktu

System będzie wysokiego ryzyka, jeżeli jest produktem objętym jednym z unijnych reżimów wymienionych w załączniku I albo elementem bezpieczeństwa takiego produktu, a produkt wymaga oceny zgodności przez stronę trzecią. Może chodzić na przykład o określone oprogramowanie medyczne, maszynę, urządzenie lub system bezpieczeństwa.

Tu pytanie brzmi nie tylko „czy używamy AI?”, lecz: czy wynik AI realizuje funkcję związaną z bezpieczeństwem regulowanego produktu? Asystent piszący instrukcję serwisową będzie zwykle oceniany inaczej niż model sterujący parametrem, którego błąd może spowodować uraz.

Droga B: use case z załącznika III

Druga droga obejmuje konkretne zastosowania w ośmiu wrażliwych obszarach:

biometria;
infrastruktura krytyczna;
edukacja i kształcenie zawodowe;
zatrudnienie, zarządzanie pracownikami i dostęp do samozatrudnienia;
dostęp do podstawowych usług prywatnych i publicznych oraz świadczeń;
egzekwowanie prawa;
migracja, azyl i kontrola granic;
wymiar sprawiedliwości i procesy demokratyczne.

Nie oznacza to, że każdy system użyty przez dział HR, bank, szkołę czy szpital automatycznie staje się high-risk. Liczy się dokładna funkcja wskazana w załączniku. Bot odpowiadający pracownikom na pytania o urlopy to inny use case niż system oceniający kandydatów. Asystent pomagający klientowi odnaleźć formularz kredytowy to co innego niż model oceniający jego zdolność kredytową.

Ważny wyjątek: obecność w załączniku III nie zawsze przesądza sprawy

System powiązany z obszarem załącznika III może nie zostać uznany za high-risk, jeżeli nie stwarza istotnego ryzyka szkody i nie wpływa materialnie na wynik decyzji. Rozporządzenie wskazuje przykładowo wąskie zadania proceduralne, poprawianie wyniku wcześniej zakończonej pracy człowieka, wykrywanie wzorców bez zastępowania wcześniejszej oceny człowieka oraz zadania przygotowawcze.

To jednak nie jest furtka typu „człowiek kliknie OK”. Trzeba wykazać rzeczywisty brak materialnego wpływu i udokumentować ocenę przed wdrożeniem. Dodatkowo system wykonujący profilowanie osób fizycznych w obszarze załącznika III pozostaje systemem wysokiego ryzyka.

Krok 3. Czy pojawiają się obowiązki przejrzystości?

Use case, który nie jest high-risk, nadal może podlegać art. 50. Od 2 sierpnia 2026 r. obowiązują wymogi przejrzystości dotyczące wybranych systemów interaktywnych i generatywnych.

W praktyce należy sprawdzić między innymi, czy:

użytkownik rozmawia bezpośrednio z chatbotem lub voicebotem i powinien wiedzieć, że kontaktuje się z AI;
system generuje lub manipuluje obrazem, dźwiękiem, wideo albo tekstem, a treść powinna być technicznie oznaczalna jako syntetyczna;
publikowany jest deepfake, który wymaga wyraźnego ujawnienia sztucznego pochodzenia;
AI tworzy tekst publikowany w celu informowania opinii publicznej o sprawach interesu publicznego;
system rozpoznaje emocje lub dokonuje dozwolonej kategoryzacji biometrycznej i osoby powinny zostać o tym poinformowane.

Przykład: wewnętrzny asystent wiedzy, który jedynie podpowiada pracownikowi treść odpowiedzi, może mieć niski profil ryzyka. Jeżeli jednak ten sam agent samodzielnie prowadzi rozmowę z klientem, dochodzi obowiązek poinformowania klienta, że ma do czynienia z systemem AI — chyba że jest to oczywiste z okoliczności.

Krok 4. Czy w łańcuchu występuje model GPAI?

ChatGPT, Claude, Gemini czy model open source wykorzystywany w wielu różnych zadaniach może być modelem ogólnego przeznaczenia. Obowiązki dotyczące GPAI spoczywają przede wszystkim na dostawcy takiego modelu i obowiązują od 2 sierpnia 2025 r. Bardziej zaawansowane modele mogą dodatkowo zostać uznane za modele o ryzyku systemowym.

Firma korzystająca z zewnętrznego API nie staje się automatycznie dostawcą modelu GPAI. Sytuacja może się jednak zmienić, gdy organizacja wprowadza model na rynek pod własną nazwą, dokonuje istotnej modyfikacji albo buduje na nim odrębny system i występuje jako jego dostawca. GPAI nie zastępuje klasyfikacji konkretnego systemu: model ogólnego przeznaczenia może zasilać zarówno prostego asystenta, jak i rozwiązanie wysokiego ryzyka.

Krok 5. Ustal rolę organizacji: provider czy deployer?

Ten sam system generuje inne obowiązki dla dostawcy i dla podmiotu, który go używa. Provider rozwija system lub zleca jego rozwój i wprowadza go na rynek albo uruchamia pod własną nazwą. Deployer używa systemu w ramach działalności zawodowej.

Zakup rozwiązania od dostawcy nie zawsze zamyka temat. Jeżeli klient oznacza system własną marką, istotnie go modyfikuje lub zmienia jego zamierzony cel w sposób powodujący wejście do kategorii high-risk, może przejąć obowiązki providera.

Dla dostawcy systemu wysokiego ryzyka oznacza to m.in. zarządzanie ryzykiem, governance danych, dokumentację techniczną i logi, odpowiednie instrukcje, human oversight, wymogi dokładności, odporności i cyberbezpieczeństwa, ocenę zgodności oraz monitoring po wdrożeniu. Deployer powinien używać systemu zgodnie z instrukcją, zapewnić kompetentny nadzór człowieka, monitorować działanie i reagować na ryzyka oraz incydenty. W części zastosowań dochodzą ocena wpływu na prawa podstawowe i obowiązki informacyjne wobec osób, których dotyczą decyzje.

Szybka klasyfikacja typowych use case’ów

Use case	Wstępna kwalifikacja	Co sprawdzić
Agent wykrywający rozbieżności na fakturach B2B	Zwykle minimalne ryzyko	Dane osobowe, uprawnienia, błędne blokady płatności, audyt działań
Chatbot obsługi klienta	Zwykle obowiązek przejrzystości	Jasna informacja o AI, eskalacja do człowieka, sektor usługi
Ranking CV kandydatów	Wysokie ryzyko — zatrudnienie	Provider/deployer, jakość danych, bias, human oversight, informowanie osób
Ocena zdolności kredytowej osoby	Wysokie ryzyko — podstawowe usługi	Profilowanie, prawo do wyjaśnienia, RODO, walidacja i monitoring
System rozpoznający emocje pracowników	Potencjalnie zakazany	Faktyczna funkcja, miejsce użycia, wąskie wyjątki medyczne/bezpieczeństwa
AI wspierające diagnozę w urządzeniu medycznym	Potencjalnie wysokie ryzyko — załącznik I	Klasa wyrobu, funkcja bezpieczeństwa, ocena zgodności sektorowej
Generator marketingowych obrazów	Obowiązki przejrzystości mogą mieć zastosowanie	Techniczne oznaczanie treści, deepfake, prawa autorskie i wizerunek
Wewnętrzny asystent procedur	Zwykle minimalne ryzyko	Halucynacje, poufność, jakość źródeł, zakres decyzji wykonywanych przez agenta

Słowo „wstępna” jest tu kluczowe. Dwa projekty o podobnej nazwie mogą różnić się tym, czy AI tylko porządkuje informacje, czy ocenia człowieka i wpływa na jego dostęp do pracy, kredytu, świadczenia lub usługi.

Karta klasyfikacji, którą da się zrobić w godzinę

Zamiast zaczynać od rozbudowanego kwestionariusza prawnego, zorganizuj 60-minutowy warsztat z właścicielem procesu, IT, security i osobą odpowiedzialną za compliance. Wypełnijcie jedną stronę:

nazwa systemu i wersja;
zamierzony cel oraz funkcje wyraźnie niedozwolone;
użytkownicy i osoby, na które system wpływa;
decyzja lub działanie, które powstaje po wyniku AI;
źródła danych, w tym dane osobowe i szczególne kategorie danych;
skala, częstotliwość i możliwość szkody;
rola człowieka, uprawnienie do odrzucenia wyniku i realny czas na reakcję;
dostawca, deployer oraz pozostałe podmioty w łańcuchu;
wynik testu: art. 5, załącznik I, załącznik III, art. 50 i GPAI;
uzasadnienie klasyfikacji, właściciel ryzyka i data ponownego przeglądu.

Taka karta nie zastępuje dokumentacji wymaganej dla high-risk, ale tworzy podstawę do decyzji: wdrażamy, wdrażamy po dodaniu zabezpieczeń, eskalujemy do analizy prawnej albo zatrzymujemy projekt.

Klasyfikacja nie jest etykietą na zawsze

Use case może zmienić kategorię po pozornie niewielkiej zmianie procesu. Asystent, który początkowo wyszukuje informacje, może później dostać możliwość priorytetyzowania kandydatów, blokowania transakcji albo automatycznego zamykania reklamacji. Wtedy nie wystarczy aktualizacja promptu. Trzeba ponownie ocenić zamierzony cel, wpływ na ludzi, rolę organizacji i skuteczność nadzoru.

Dlatego klasyfikację warto włączyć do zarządzania zmianą: przegląd po zmianie modelu, danych, integracji, grupy użytkowników, poziomu autonomii lub procesu biznesowego. Właściciel produktu AI powinien wiedzieć, które zmiany wymagają ponownej akceptacji compliance.

Najważniejsza zasada: klasyfikuj proces, nie nazwę technologii

EU AI Act nie mówi, że „LLM jest high-risk” albo „chatbot jest bezpieczny”. Ryzyko powstaje w konkretnym połączeniu celu, danych, decyzji, ludzi i kontroli. Dlatego dobre pytanie nie brzmi: „jakiego modelu używamy?”, lecz:

Co system robi, komu może zaszkodzić, jak jego wynik wpływa na decyzję i kto ma realną możliwość zatrzymania skutku?

Jeżeli organizacja potrafi odpowiedzieć na te cztery pytania, ma nie tylko lepszy punkt wyjścia do zgodności z EU AI Act. Ma też zwyczajnie lepiej zaprojektowany produkt AI — z jasno określoną odpowiedzialnością, mierzalnym ryzykiem i kontrolą adekwatną do konsekwencji.

Wymagania nadzoru i audytu opisujemy na stronie Bezpieczeństwo, granice autonomii agentów w AI Agents, a punkty decyzyjne projektu w trakcie wdrożenia.

EU AI Act w praktyce: do której kategorii ryzyka trafia Twój use case?