Obowiązki providerów systemów AI wysokiego ryzyka w AI Act UE

czy jesteś providerem i czy Twój system jest wysokiego ryzyka

O tym, czy ten przewodnik Cię dotyczy, decydują dwa pytania progowe.

Po pierwsze, czy jesteś providerem. Artykuł 3(3) definiuje providera jako osobę fizyczną lub prawną, która opracowuje system AI lub model AI ogólnego przeznaczenia, albo zleca jego opracowanie, i wprowadza go na rynek lub oddaje do użytku pod własną nazwą lub znakiem towarowym, odpłatnie lub nieodpłatnie. Zbudowanie systemu i wypuszczenie go pod własną marką czyni Cię providerem.

Ta granica ma znaczenie, bo może się przesuwać. Na podstawie Artykułu 25 organizacja, która zaczynała jako deployer, może stać się providerem i przejąć obowiązki providera w kilku sytuacjach: umieszczając własną nazwę lub znak towarowy na systemie wysokiego ryzyka już obecnym na rynku, dokonując istotnej modyfikacji systemu wysokiego ryzyka, albo zmieniając przeznaczenie systemu w sposób, który czyni go systemem wysokiego ryzyka. Firma, która mocno dostosowuje model firmy trzeciej i wypuszcza go jako własny produkt, powinna sprawdzić Artykuł 25, zanim założy, że jest tylko deployerem.

Po drugie, czy system jest wysokiego ryzyka. Obowiązki providera opisane w tym przewodniku dotyczą systemów AI wysokiego ryzyka sklasyfikowanych na podstawie Artykułu 6. Do statusu wysokiego ryzyka prowadzą dwie ścieżki: systemy, które są elementami bezpieczeństwa produktów objętych unijnym prawodawstwem harmonizacyjnym z Załącznika I (wyroby medyczne, maszyny, pojazdy i podobne) albo które są takimi produktami same w sobie, oraz samodzielne systemy używane w obszarach wymienionych w Załączniku III (biometria, infrastruktura krytyczna, edukacja, zatrudnienie, dostęp do podstawowych usług, ściganie przestępstw, migracja i wymiar sprawiedliwości). Jeśli Twój system nie pasuje do żadnej z tych kategorii, poniższe ciężkie obowiązki providera zasadniczo się nie stosują, choć obowiązki transparentności z Artykułu 50 i inne zasady wciąż mogą mieć zastosowanie.

pełny zestaw obowiązków providera: Artykuł 16

Artykuł 16 to indeks obowiązków providera. Wymaga od providerów systemów AI wysokiego ryzyka, aby:

• zapewnili zgodność systemu z wymogami z Sekcji 2 (Artykuły 9-15);
• umieścili swoją nazwę, zarejestrowaną nazwę handlową lub znak towarowy oraz adres kontaktowy na systemie, jego opakowaniu lub w dokumentacji;
• posiadali system zarządzania jakością (Artykuł 17);
• przechowywali dokumentację (Artykuł 18);
• przechowywali logi generowane automatycznie przez system, jeśli są pod ich kontrolą (Artykuł 19);
• zapewnili, że system przejdzie odpowiednią ocenę zgodności przed wprowadzeniem na rynek lub oddaniem do użytku (Artykuł 43);
• sporządzili unijną deklarację zgodności (Artykuł 47);
• umieścili oznakowanie CE (Artykuł 48);
• spełnili obowiązki rejestracyjne (Artykuł 49);
• podejmowali działania naprawcze i przekazywali informacje, gdy jest to potrzebne (Artykuł 20);
• na uzasadniony wniosek krajowego właściwego organu wykazali zgodność;
• zapewnili, że system spełnia wymogi dostępności na podstawie Dyrektyw (UE) 2016/2102 i (UE) 2019/882.

Reszta tego przewodnika rozkłada na czynniki pierwsze najważniejsze pozycje z tej listy.

Artykuł 9: system zarządzania ryzykiem

Artykuł 9 wymaga systemu zarządzania ryzykiem, który działa jako ciągły, iteracyjny proces przez cały cykl życia systemu wysokiego ryzyka: zaplanowany, prowadzony oraz regularnie przeglądany i aktualizowany. To nie jest jednorazowy dokument.

System musi identyfikować i analizować znane oraz racjonalnie przewidywalne ryzyka, jakie system AI może stwarzać dla zdrowia, bezpieczeństwa lub praw podstawowych przy zamierzonym użyciu oraz w warunkach racjonalnie przewidywalnego niewłaściwego użycia. Następnie szacuje i ocenia te ryzyka, uwzględnia ryzyka wynikające z danych z monitorowania po wprowadzeniu do obrotu i przyjmuje ukierunkowane środki, aby zarządzać nimi tak, by wszelkie ryzyko szczątkowe zostało uznane za akceptowalne.

Artykuł 9 wymaga też testowania, które potwierdza, że system działa spójnie zgodnie ze swoim przeznaczeniem i spełnia wymogi, z testami wobec wcześniej zdefiniowanych metryk i progów. Nakazuje też providerom rozważenie, czy system może niekorzystnie wpływać na osoby poniżej 18 roku życia lub inne grupy wrażliwe. System zarządzania ryzykiem jest silnikiem, który zasila większość reszty: jego wyniki stają się treścią dokumentacji technicznej i danymi wejściowymi do oceny zgodności.

Artykuł 10: dane i zarządzanie danymi

Artykuł 10 ma zastosowanie tam, gdzie system wysokiego ryzyka jest trenowany na danych. Zbiory danych treningowych, walidacyjnych i testowych muszą podlegać praktykom zarządzania danymi odpowiednim do zamierzonego przeznaczenia.

Kluczowym wymogiem jest jakość danych. Zbiory danych muszą być odpowiednie, wystarczająco reprezentatywne oraz w możliwie największym stopniu wolne od błędów i kompletne z perspektywy zamierzonego przeznaczenia. Praktyki zarządzania obejmują wybory projektowe, zbieranie danych i ich pochodzenie, operacje przygotowawcze takie jak etykietowanie i czyszczenie, założenia dotyczące tego, co dane mierzą, ocenę dostępności i przydatności oraz badanie pod kątem możliwych błędów systematycznych, które mogłyby wpłynąć na zdrowie, bezpieczeństwo lub prawa podstawowe albo prowadzić do zakazanej dyskryminacji.

Jedna rzecz warta podkreślenia dla zespołów inżynieryjnych: te obowiązki dotyczące zarządzania danymi są specyficzne dla AI i mają zastosowanie niezależnie od tego, czy dane są danymi osobowymi. RODO reguluje dane osobowe osobno i dodatkowo. Artykuł 10 nie jest spełniony tylko dlatego, że istnieje program RODO.

Załącznik IV: dokumentacja techniczna

Załącznik IV to plik dowodowy, który wykazuje, że system spełnia wymogi. Artykuł 11 wymaga jego sporządzenia przed wejściem systemu na rynek i utrzymywania go w aktualności. Musi być na tyle szczegółowy, by organy i jednostki notyfikowane mogły ocenić zgodność. Załącznik IV określa jego zawartość w dziewięciu obszarach:

1. Ogólny opis systemu: przeznaczenie, provider, wersje, sposób interakcji ze sprzętem lub oprogramowaniem oraz formy, w jakich jest wprowadzany na rynek.
2. Szczegółowy opis elementów systemu i jego rozwoju: specyfikacje projektowe, architekturę systemu, pod kątem czego system jest zoptymalizowany, kluczowe wybory projektowe oraz wykorzystane zasoby obliczeniowe.
3. Szczegółowe informacje o monitorowaniu, działaniu i kontroli systemu, w tym jego możliwości i ograniczenia, oczekiwaną dokładność oraz przewidywalne ryzyka.
4. Opis adekwatności metryk skuteczności dla danego systemu.
5. Szczegółowy opis systemu zarządzania ryzykiem na podstawie Artykułu 9.
6. Opis istotnych zmian dokonanych w trakcie cyklu życia systemu.
7. Listę zastosowanych norm zharmonizowanych albo opis innych rozwiązań użytych do spełnienia wymogów.
8. Kopię unijnej deklaracji zgodności.
9. Szczegółowy opis systemu służącego do oceny skuteczności systemu w fazie po wprowadzeniu na rynek, w tym planu monitorowania po wprowadzeniu na rynek, o którym mowa w Artykule 72.

Dokumentacja techniczna nie jest osobnym strumieniem pracy oderwanym od Artykułów 9, 10 i pozostałych. To miejsce, w którym ich wyniki są spisywane i zbierane w jeden spójny plik.

Artykuł 17: system zarządzania jakością

Artykuł 17 wymaga od providerów wdrożenia udokumentowanego systemu zarządzania jakością (QMS), który zapewnia zgodność z rozporządzeniem. To organizacyjny kręgosłup: procesy, odpowiedzialności i zapisy, które czynią zgodność powtarzalną, a nie jednorazowym wysiłkiem dla pojedynczego produktu.

QMS musi obejmować między innymi: strategię zgodności regulacyjnej; procedury projektowania, rozwoju i kontroli jakości; procedury testowania i walidacji; zastosowane specyfikacje techniczne i normy; systemy i procedury zarządzania danymi; system zarządzania ryzykiem z Artykułu 9; system monitorowania po wprowadzeniu na rynek; procedury zgłaszania poważnych incydentów na podstawie Artykułu 73; komunikację z organami i jednostkami notyfikowanymi; prowadzenie dokumentacji; zarządzanie zasobami; oraz ramy odpowiedzialności.

Artykuł 17 wbudowuje w siebie proporcjonalność: wdrożenie QMS musi być proporcjonalne do wielkości organizacji providera. Może też zostać zintegrowane z istniejącym QMS, który provider już prowadzi na podstawie innego sektorowego prawa unijnego, co ma znaczenie dla producentów produktów regulowanych, takich jak wyroby medyczne, którzy już prowadzą system jakości.

Artykuł 43: ocena zgodności

Ocena zgodności to formalna procedura, dzięki której provider wykazuje, że system wysokiego ryzyka spełnia wymogi z Sekcji 2, zanim zostanie wprowadzony na rynek lub oddany do użytku. Artykuł 43 określa dwie ścieżki.

Ścieżka pierwsza: kontrola wewnętrzna (Załącznik VI). Samoocena. Provider weryfikuje, na własną odpowiedzialność, że jego system zarządzania jakością i dokumentacja techniczna spełniają wymogi, bez udziału jednostki notyfikowanej. To ścieżka, z której korzysta większość systemów wysokiego ryzyka z Załącznika III.

Ścieżka druga: ocena przez stronę trzecią (Załącznik VII). Udział jednostki notyfikowanej, która ocenia system zarządzania jakością i dokumentację techniczną. Jest wymagana w konkretnych sytuacjach, a nie uniwersalnie.

To, która ścieżka ma zastosowanie, zależy od typu systemu i od norm:

• Dla systemów biometrycznych z punktu 1 Załącznika III provider wybiera między kontrolą wewnętrzną (Załącznik VI), gdy zastosowano normy zharmonizowane lub wspólne specyfikacje, a ścieżką z jednostką notyfikowaną (Załącznik VII) w pozostałych przypadkach.
• Dla pozostałych obszarów wysokiego ryzyka z Załącznika III (punkty 2-8) domyślną ścieżką jest kontrola wewnętrzna na podstawie Załącznika VI.
• Ścieżka strony trzeciej z Załącznika VII staje się obowiązkowa, gdy normy zharmonizowane nie istnieją i wspólne specyfikacje nie są dostępne, gdy provider nie zastosował danej normy zharmonizowanej lub zastosował ją tylko częściowo, gdy istnieją wspólne specyfikacje, ale provider ich nie zastosował, albo gdy właściwa norma zharmonizowana została opublikowana z ograniczeniem.

Dla systemów wysokiego ryzyka, które są produktami lub elementami bezpieczeństwa objętymi prawodawstwem harmonizacyjnym z Załącznika I, ocena zgodności zasadniczo przebiega według procedury już wymaganej na podstawie tego prawodawstwa produktowego, z wbudowanymi wymogami AI Act. Gdy system wysokiego ryzyka zostaje istotnie zmodyfikowany, musi przejść nową ocenę zgodności, nawet jeśli był wcześniej oceniany.

Artykuły 47 i 48: deklaracja zgodności i oznakowanie CE

Gdy ocena zgodności zostanie zaliczona, dwa formalne akty czynią jej wynik widocznym.

Unijna deklaracja zgodności (Artykuł 47). Provider sporządza pisemną, czytelną maszynowo, podpisaną fizycznie lub elektronicznie deklarację dla każdego systemu wysokiego ryzyka, stwierdzającą, że system spełnia wymogi z Sekcji 2. Musi zawierać informacje określone w Załączniku V, być przetłumaczona na język zrozumiały dla właściwych organów krajowych i pozostawać dostępna dla krajowych właściwych organów przez 10 lat od wprowadzenia systemu na rynek lub oddania go do użytku. Podpisując ją, provider bierze na siebie odpowiedzialność za zgodność.

Oznakowanie CE (Artykuł 48). Provider umieszcza oznakowanie CE na systemie wysokiego ryzyka w sposób widoczny, czytelny i trwały, a tam, gdzie nie jest to możliwe, na opakowaniu lub w dołączonej dokumentacji. Dla systemów dostarczanych cyfrowo stosuje się cyfrowe oznakowanie CE, które musi być łatwo dostępne. Jeśli w ocenie zgodności brała udział jednostka notyfikowana, po oznakowaniu CE następuje numer identyfikacyjny tej jednostki. Oznakowanie CE to sygnał dla rynku i organów, że provider deklaruje zgodność z rozporządzeniem.

Rejestracja (Artykuł 49). Przed wprowadzeniem większości systemów wysokiego ryzyka z Załącznika III na rynek lub oddaniem ich do użytku, provider rejestruje też system i samego siebie w unijnej bazie danych, podając informacje określone w Załączniku VIII. To zamyka sekwencję przedrynkową: ocenić, zadeklarować, oznakować, zarejestrować.

gdzie obowiązki providera mieszczą się w harmonogramie

Opisane tu obowiązki providera systemów wysokiego ryzyka mają bazową datę rozpoczęcia stosowania 2 sierpnia 2026 na podstawie Artykułu 113 AI Act, i to jest data obecnie obowiązująca. Wejście w życie samego Artykułu 16 przypada na 2 sierpnia 2026 zgodnie z Artykułem 113.

Digital Omnibus, przyjęty przez Parlament 16 czerwca 2026 i przez Radę 29 czerwca 2026, przesuwa samodzielne obowiązki wysokiego ryzyka z Załącznika III na 2 grudnia 2027, a z Załącznika I na 2 sierpnia 2028. Na lipiec 2026 nie został jeszcze opublikowany w Dzienniku Urzędowym, więc na razie niczego nie zmienia. Traktuj 2 sierpnia 2026 jako datę obowiązującą do czasu publikacji. Praca budowlana stojąca za tymi obowiązkami, QMS, system zarządzania ryzykiem, plik techniczny z Załącznika IV, zajmuje wiele miesięcy, więc provider, który czeka na ostateczną datę, ryzykuje, że zabraknie mu czasu, niezależnie od tego, która data ostatecznie obowiąże.

Źródła

• Article 16: Obligations of Providers of High-Risk AI Systems, EU Artificial Intelligence Act (Regulation (EU) 2024/1689), full text and entry-into-force date · https://artificialintelligenceact.eu/article/16/ (pełna lista obowiązków providera i data 2 sierpnia 2026)
• Article 9: Risk Management System, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/9/ (wymogi zarządzania ryzykiem w cyklu życia)
• Article 10: Data and Data Governance, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/10/ (jakość i zarządzanie danymi, także dla danych innych niż osobowe)
• Annex IV: Technical Documentation Referred to in Article 11(1), EU Artificial Intelligence Act · https://artificialintelligenceact.eu/annex/4/ (dziewięć obszarów pliku technicznego)
• Article 17: Quality Management System, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/17/ (elementy QMS i proporcjonalność)
• Article 43: Conformity Assessment, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/43/ (ścieżki kontroli wewnętrznej i jednostki notyfikowanej oraz kiedy każda ma zastosowanie)
• Annex VI: Conformity Assessment Procedure Based on Internal Control, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/annex/6/ (ścieżka samooceny)
• Annex VII: Conformity Based on Assessment of the Quality Management System and the Technical Documentation, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/annex/7/ (ścieżka z jednostką notyfikowaną)
• Article 47: EU Declaration of Conformity, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/47/ (zawartość zgodnie z Załącznikiem V, przechowywanie przez 10 lat)
• Article 48: CE Marking, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/48/ (jak umieszcza się oznakowanie CE, w tym oznakowanie cyfrowe)
• Article 25: Responsibilities Along the AI Value Chain, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/25/ (kiedy deployer staje się providerem)
• EU AI Act: what are the obligations for high-risk AI systems, A&O Shearman · https://www.aoshearman.com/en/insights/ao-shearman-on-tech/zooming-in-on-ai-10-eu-ai-act-what-are-the-obligations-for-high-risk-ai-systems (przegląd zestawu obowiązków providera od kancelarii prawnej)