AI Act w produkcji: klasyfikacja high-risk i co to znaczy dla wdrożenia

Czas czytania: ok. 12 minut. Klaster: compliance. Autor: Fryderyk.

Odpowiedź najpierw

Większość systemów AI uruchamianych w zakładzie produkcyjnym nie jest wysokiego ryzyka w rozumieniu AI Act. Asystent po dokumentacji technicznej, kontrola jakości obrazem, predykcyjne utrzymanie ruchu czy generowanie oferty z rysunku zwykle nie wpadają w kategorię high-risk. System jest wysokiego ryzyka tylko dwiema drogami: jako komponent bezpieczeństwa produktu objętego unijnym prawem harmonizacyjnym (Annex I), na przykład maszyny, albo jako jedno z zastosowań wprost wymienionych w Annex III, w praktyce produkcyjnej najczęściej zarządzanie pracownikami. Reszta podlega co najwyżej obowiązkom przejrzystości z Art. 50. W lipcu 2026 doszła ważna zmiana: pakiet Digital Omnibus przesuwa terminy obowiązków high-risk (Annex III na 2 grudnia 2027, Annex I na 2 sierpnia 2028), ale obowiązki przejrzystości z Art. 50 zostają na 2 sierpnia 2026, a dopóki nowela nie jest opublikowana w Dzienniku Urzędowym, formalnie obowiązują dawne daty. Miejsce wdrożenia, on-prem czy chmura, nie zmienia klasyfikacji. Zmienia tylko to, jak łatwo udowodnisz spełnienie części obowiązków. Ta notatka pokazuje, jak sklasyfikować system i co z klasyfikacji wynika dla wdrożenia.

Spis treści

1. Stan na lipiec 2026: co właśnie się zmieniło
2. Dwie drogi do high-risk: Annex I i Annex III
3. Co to znaczy konkretnie dla zakładu produkcyjnego
4. Klasyfikacja krok po kroku
5. Obowiązki, jeśli system jest high-risk
6. Jak to wpływa na decyzję on-prem czy chmura
7. Trzy błędy w klasyfikacji
8. FAQ
9. Disclosure i biases
10. Czego tu nie pokrywam
11. Powiązane notatki

Stan na lipiec 2026: co właśnie się zmieniło

AI Act, czyli rozporządzenie (UE) 2024/1689, wszedł w życie 1 sierpnia 2024 i stosuje się etapami. Zakazane praktyki obowiązują od lutego 2025, obowiązki dla modeli ogólnego przeznaczenia od sierpnia 2025, a najcięższa warstwa, obowiązki dla systemów wysokiego ryzyka, miała ruszyć 2 sierpnia 2026 dla zastosowań z Annex III i 2 sierpnia 2027 dla systemów wbudowanych w produkty z Annex I.

Ten kalendarz właśnie się zmienił. Pakiet Digital Omnibus na AI został przyjęty przez Parlament Europejski 16 czerwca i formalnie zatwierdzony przez Radę 29 czerwca 2026. Przesuwa on obowiązki high-risk: dla Annex III na 2 grudnia 2027, dla Annex I na 2 sierpnia 2028. Ważne zastrzeżenie: nowela nie jest jeszcze w mocy. Wchodzi w życie trzeciego dnia po publikacji w Dzienniku Urzędowym, spodziewanej w drugiej połowie lipca 2026. Do tego momentu formalnie obowiązują pierwotne daty, więc planuj według kierunku zmiany, ale nie traktuj przesuniętych terminów jako pewnika, dopóki publikacja nie nastąpi.

Trzy elementy noweli mają realne znaczenie dla produkcji. Po pierwsze, Rozporządzenie Maszynowe przeniesiono do sekcji B Annex I, przez co pełne obowiązki AI Act nie stosują się wprost do maszyn. Zamiast tego Komisja ma do 2 sierpnia 2028 wprowadzić wymagania dla AI w maszynach aktami delegowanymi do samego Rozporządzenia Maszynowego. Po drugie, doprecyzowano definicję komponentu bezpieczeństwa: AI służące wyłącznie do wspomagania użytkownika, optymalizacji wydajności, automatyzacji czy kontroli jakości nie jest komponentem bezpieczeństwa, chyba że jego awaria mogłaby zagrozić zdrowiu lub bezpieczeństwu. Po trzecie, obowiązki przejrzystości z Art. 50 nie zostały przesunięte i stosują się od 2 sierpnia 2026, z krótkim okresem przejściowym do 2 grudnia 2026 dla znakowania treści w systemach już obecnych na rynku.

Sama architektura AI Act się nie zmieniła. Podejście oparte na ryzyku, kategorie z załączników i logika klasyfikacji zostają. Zmienił się głównie zegar.

Dwie drogi do high-risk: Annex I i Annex III

System AI jest wysokiego ryzyka na jeden z dwóch sposobów.

Droga pierwsza, Annex I. System jest produktem albo komponentem bezpieczeństwa produktu, który i tak podlega unijnemu prawu harmonizacyjnemu: maszyny, wyroby medyczne, zabawki, windy, sprzęt radiowy. W produkcji najczęściej chodzi o maszyny. Po zmianie z Digital Omnibus ta ścieżka dla maszyn biegnie jednak przez Rozporządzenie Maszynowe i akty delegowane, a nie przez bezpośrednie stosowanie AI Act.

Droga druga, Annex III. System, niezależnie od produktu, realizuje jedno z zastosowań wymienionych na liście: między innymi biometrię, zarządzanie infrastrukturą krytyczną, zatrudnienie i zarządzanie pracownikami, dostęp do usług podstawowych, egzekwowanie prawa. Dla zakładu produkcyjnego najbardziej realne są dwa obszary: zarządzanie pracownikami oraz, jeśli firma prowadzi infrastrukturę tego typu, zarządzanie infrastrukturą krytyczną.

Jeśli system nie wpada w żadną z tych dróg, nie jest wysokiego ryzyka. Może nadal podlegać obowiązkom przejrzystości albo być poza istotnym zakresem, ale nie dźwiga ciężaru obowiązków high-risk.

Co to znaczy konkretnie dla zakładu produkcyjnego

Przełóżmy to na typowe systemy, które faktycznie stawia się w fabryce.

Asystent AI po dokumentacji, instrukcjach i normach, oparty na RAG, jest narzędziem wspomagającym pracownika. Nie jest komponentem bezpieczeństwa maszyny ani zastosowaniem z Annex III, więc nie jest high-risk. Jeśli rozmawia z człowiekiem, podlega obowiązkowi przejrzystości: użytkownik ma wiedzieć, że ma do czynienia z systemem AI.

Kontrola jakości obrazem, wykrywająca wady na linii, to klasyczny przypadek, w którym doprecyzowana definicja komponentu bezpieczeństwa robi różnicę. Jeśli system tylko klasyfikuje jakość, a jego błąd nie zagraża zdrowiu ani bezpieczeństwu, nie jest komponentem bezpieczeństwa i nie jest high-risk. Jeśli natomiast wynik systemu bezpośrednio steruje zatrzymaniem maszyny w sytuacji groźnej dla operatora, ocena wygląda inaczej i trzeba ją przeprowadzić rzetelnie.

Predykcyjne utrzymanie ruchu i generowanie oferty z rysunku to również narzędzia wydajnościowe, nie komponenty bezpieczeństwa. Poza istotnym zakresem high-risk.

Inaczej jest z AI w zarządzaniu pracownikami. System, który selekcjonuje kandydatów, rozdziela zadania, monitoruje albo ocenia pracowników, wpada w Annex III jako zastosowanie związane z zatrudnieniem. To najczęstsze wysokie ryzyko w zakładzie, o którym łatwo zapomnieć, bo nie kojarzy się z produkcją, tylko z HR. Tu obowiązki high-risk stosują się realnie, według przesuniętego terminu 2 grudnia 2027.

Klasyfikacja krok po kroku

Prosta ścieżka, którą można przejść dla każdego systemu.

Krok pierwszy: czy system jest produktem lub komponentem bezpieczeństwa produktu z Annex I, i czy jego awaria mogłaby zagrozić zdrowiu lub bezpieczeństwu. Jeśli tak, to droga Annex I, przy maszynach obecnie przez Rozporządzenie Maszynowe.

Krok drugi: czy system realizuje któreś z zastosowań z Annex III, w produkcji przede wszystkim zarządzanie pracownikami lub infrastrukturą krytyczną. Jeśli tak, to high-risk drogą Annex III.

Krok trzeci: jeśli system trafia do Annex III, sprawdź wyłączenia z Art. 6 ust. 3, na przykład dla systemów wykonujących wąskie zadanie proceduralne albo poprawiających wynik wcześniejszej pracy człowieka. Uwaga: nawet przy wyłączeniu pozostaje uproszczony obowiązek rejestracji w bazie UE.

Krok czwarty: jeśli żadna droga nie prowadzi do high-risk, system jest ograniczonego lub minimalnego ryzyka. Sprawdź jeszcze, czy dotyczą go obowiązki przejrzystości z Art. 50, bo te stosują się niezależnie od klasyfikacji ryzyka.

Wynik każdego kroku zapisz. To ślad klasyfikacyjny, który pokażesz, gdy ktoś zapyta, dlaczego uznaliście system za taki, a nie inny.

Obowiązki, jeśli system jest high-risk

Najpierw ustal rolę. Dostawca to podmiot, który system opracowuje i wprowadza pod swoją nazwą. Podmiot stosujący, czyli deployer, to ten, kto go używa w działalności zawodowej. Większość zakładów produkcyjnych jest podmiotem stosującym, bo kupuje system od dostawcy. Uwaga na pułapkę: jeśli istotnie zmodyfikujesz system albo puścisz go pod własną marką, możesz zostać przekwalifikowany na dostawcę i przejąć jego cięższe obowiązki.

Po stronie dostawcy high-risk stoją: system zarządzania ryzykiem, ład danych, dokumentacja techniczna, rejestrowanie zdarzeń, przejrzystość wobec użytkownika, nadzór człowieka, dokładność, odporność i cyberbezpieczeństwo, ocena zgodności, oznakowanie CE, rejestracja w bazie UE oraz monitorowanie po wprowadzeniu na rynek.

Po stronie podmiotu stosującego stoją głównie: używanie systemu zgodnie z instrukcją, zapewnienie nadzoru człowieka, monitorowanie działania, przechowywanie logów przez co najmniej sześć miesięcy, poinformowanie pracowników i ich przedstawicieli, gdy system dotyczy zatrudnienia, oraz ocena skutków dla praw podstawowych tam, gdzie jest wymagana.

Jak to wpływa na decyzję on-prem czy chmura

Kluczowa rzecz: klasyfikacja zależy od zastosowania i celu, nie od miejsca wdrożenia. Postawienie modelu u siebie nie sprawia, że system przestaje być wysokiego ryzyka, tak samo jak chmura nie czyni go automatycznie ryzykownym. Klasyfikujesz to, co system robi, nie gdzie stoi.

Miejsce wdrożenia zmienia natomiast to, jak udowodnisz spełnienie części obowiązków high-risk. Ład danych, rejestrowanie zdarzeń, cyberbezpieczeństwo i nadzór człowieka łatwiej wykazać, gdy dane i model zostają wewnątrz organizacji, bo panujesz nad przepływem i nie musisz analizować łańcucha podprocesorów dostawcy chmury. Przy chmurze publicznej część dowodu przenosi się na dostawcę i jego umowy, co rozłożyłem w osobnej notatce o publicznym LLM a NIS2.

Warto też nie dublować pracy między reżimami. Obowiązki high-risk z AI Act, takie jak zarządzanie ryzykiem, logowanie czy cyberbezpieczeństwo, mocno pokrywają się z obszarami Art. 21 NIS2. Ten sam artefakt często zaspokaja oba reżimy. Mapowanie NIS2 na system AI opisałem w osobnej ściądze, a minimalną izolację sieciową w notatce o network isolation.

Trzy błędy w klasyfikacji

Pierwszy: uznanie, że każdy system AI jest wysokiego ryzyka, i budowanie pełnej machiny zgodności tam, gdzie wystarczy obowiązek przejrzystości. To marnuje zasoby i rozmywa uwagę na systemach, które naprawdę są high-risk.

Drugi: założenie, że skoro system działa wewnętrznie albo on-prem, jest poza zakresem AI Act. Obowiązki przejrzystości z Art. 50 oraz zastosowania z Annex III, zwłaszcza zarządzanie pracownikami, obowiązują niezależnie od tego, że nikt spoza firmy z systemu nie korzysta.

Trzeci: potraktowanie przesuniętych terminów jako pozwolenia, żeby nic nie robić. Inwentaryzacja systemów i ich klasyfikacja to praca, która i tak jest do zrobienia, a przesunięcie daje na nią czas, nie zwolnienie. W grudniu 2027 padnie dokładnie to samo pytanie, które padłoby w sierpniu 2026: czy potraficie wykazać, że system oceniliście, sklasyfikowaliście i objęliście nadzorem.

FAQ

Czy nasz wewnętrzny asystent AI po dokumentacji jest high-risk?

Zwykle nie. Asystent wspomagający pracownika nie jest komponentem bezpieczeństwa ani zastosowaniem z Annex III. Podlega obowiązkowi przejrzystości, jeśli użytkownik z nim rozmawia, ale nie dźwiga obowiązków wysokiego ryzyka.

Czy przesunięcie terminów oznacza, że mamy czas nic nie robić?

Nie. Przesunięcie dotyczy dat stosowania obowiązków high-risk, nie samej potrzeby klasyfikacji. Inwentaryzacja i klasyfikacja systemów są do zrobienia teraz, a dodatkowe miesiące służą na uporządkowanie, nie na zwłokę. Do tego obowiązki przejrzystości z Art. 50 stosują się od sierpnia 2026 i nie zostały przesunięte.

Czy on-prem zdejmuje z nas obowiązki AI Act?

Nie. Miejsce wdrożenia nie wpływa na klasyfikację. On-prem może ułatwić wykazanie części obowiązków, na przykład ładu danych czy logowania, ale nie wyprowadza systemu spoza zakresu regulacji.

Jesteśmy dostawcą czy podmiotem stosującym?

Jeśli kupujesz system od zewnętrznego dostawcy i używasz go zgodnie z przeznaczeniem, jesteś podmiotem stosującym. Jeśli budujesz system sam, wprowadzasz go pod własną marką albo istotnie modyfikujesz cudzy, możesz być dostawcą i przejąć jego cięższe obowiązki.

Co z Rozporządzeniem Maszynowym?

Po zmianie z Digital Omnibus AI wbudowane w maszyny nie podlega wprost pełnym obowiązkom AI Act. Wymagania dla AI w maszynach Komisja wprowadzi aktami delegowanymi do Rozporządzenia Maszynowego, z terminem do 2 sierpnia 2028.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc naturalnie akcentuję kontrolę przepływu danych i architekturę on-prem. Starałem się oddzielić treść regulacji od tej preferencji. Ten tekst nie jest opinią prawną. Stan prawny opisuję na połowę lipca 2026, gdy Digital Omnibus jest przyjęty, ale czeka na publikację w Dzienniku Urzędowym, więc daty mogą się jeszcze doprecyzować. Klasyfikacja konkretnego systemu zależy od stanu faktycznego i powinna być skonsultowana z prawnikiem.

// co tu nie pokrywamCzego tu nie pokrywam

Nie omawiam pełnej listy zastosowań z Annex III poza tymi realnymi dla produkcji. Nie wchodzę w szczegóły oceny zgodności, oznakowania CE ani procedury rejestracji w bazie UE, bo każde z nich zasługuje na osobną notatkę. Pomijam obowiązki dla modeli ogólnego przeznaczenia oraz nowe zakazy z Art. 5, które dotyczą innych zastosowań niż typowa produkcja. Skupiam się na klasyfikacji i jej konsekwencjach dla wdrożenia.

Powiązane notatki

• NIS2 plus AI: mapowanie Art. 21 na konkretne kontrole, jedna ściąga
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem
• Network isolation dla on-prem AI: minimalne wymagania NIS2
• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d