AI Act — provider vs deployer. Kto za co odpowiada w łańcuchu dostaw AI

Łańcuch dostaw AI ma wiele ról — i każda ma inny pakiet obowiązków

Polskie MŚP w większości nie są dostawcami modeli AI. Są ich klientami — kupują Copilota, używają Salesforce’a z modułami AI, wdrażają narzędzia HR-tech z funkcją screeningu CV. W terminologii AI Act ta rola nazywa się deployer — i ma węższy, ale konkretny pakiet obowiązków, którego nie da się przerzucić na dostawcę kontraktem.

Druga strona — provider — to podmiot, który system AI rozwija lub powierza rozwinięcie i wprowadza pod własną marką na rynek UE. Pakiet providera jest cięższy, ale to nie znaczy, że deployer może spać spokojnie. W szczególności art. 25 opisuje sytuacje, w których deployer staje się providerem — i ta zmiana statusu jest jednym z największych ryzyk operacyjnych przy modyfikacji AI third-party.

W tym artykule rozkładamy łańcuch dostaw na pięć ról z art. 3, pokazujemy obowiązki per rola i kończymy pięcioma scenariuszami typowymi dla polskiego MŚP.

Pięć ról z art. 3

Art. 3 rozporządzenia 2024/1689 definiuje:

• Provider (pkt 3): osoba fizyczna lub prawna, organ publiczny, agencja lub inny podmiot, który rozwija system AI lub model GPAI albo zleca jego rozwój, a następnie wprowadza go na rynek lub do użytkowania pod własną nazwą lub znakiem towarowym, odpłatnie lub bezpłatnie.
• Deployer (pkt 4): osoba fizyczna lub prawna, organ publiczny, agencja lub inny podmiot wykorzystujący system AI pod swoją odpowiedzialnością — z wyjątkiem użytku osobistego pozazawodowego.
• Authorised representative (pkt 5): podmiot z siedzibą w UE, który otrzymał pisemne upoważnienie od providera spoza UE do działania w jego imieniu w zakresie obowiązków AI Act.
• Importer (pkt 6): podmiot z siedzibą w UE, który wprowadza na rynek system AI noszący nazwę lub znak towarowy podmiotu spoza UE.
• Distributor (pkt 7): podmiot w łańcuchu dostaw, inny niż provider i importer, który udostępnia system AI na rynku UE.

Najczęstsze role w polskim MŚP to provider (jeśli budujesz produkt AI) lub deployer (jeśli kupujesz i używasz AI). Importer i distributor są istotne dla dystrybutorów oprogramowania amerykańskiego lub azjatyckiego w UE.

Obowiązki providera high-risk — art. 16-21

Art. 16 rozporządzenia jest listą kontrolną. Provider systemu wysokiego ryzyka musi:

• zapewnić zgodność systemu z wymogami z rozdziału III sekcja 2 (art. 8-15);
• wskazać na systemie swoją nazwę, zarejestrowaną nazwę handlową lub znak towarowy oraz adres;
• mieć wdrożony system zarządzania jakością (art. 17);
• przechowywać dokumentację (art. 18) i logi (art. 19);
• przeprowadzić conformity assessment (art. 43) przed wprowadzeniem na rynek;
• sporządzić deklarację zgodności UE (art. 47);
• nadać CE marking (art. 48);
• zarejestrować system w bazie danych UE (art. 49, 71);
• podjąć działania korygujące i powiadomić organy o niezgodnościach (art. 20);
• współpracować z organami nadzorczymi (art. 21).

To pakiet, którego nie da się zbudować w tydzień. Realistyczny czas dla MŚP-providera to sześć do dwunastu miesięcy pierwszego cyklu, z istotnym udziałem prawnego i technicznego konsultingu.

Obowiązki deployera high-risk — art. 26

Art. 26 nakłada na deployera następujące obowiązki:

• używać systemu zgodnie z instrukcjami providera (ust. 1);
• powierzyć nadzór człowieka osobom z odpowiednimi kompetencjami, szkoleniem i wsparciem (ust. 2);
• w zakresie, w jakim deployer kontroluje dane wejściowe — zapewnić, że są one istotne i wystarczająco reprezentatywne (ust. 4);
• monitorować działanie systemu i powiadamiać providera oraz organ nadzorczy o ryzykach lub poważnych incydentach (ust. 5);
• przechowywać logi generowane automatycznie przez system — przez okres co najmniej sześciu miesięcy, chyba że prawo unijne lub krajowe wymaga inaczej (ust. 6);
• przed wdrożeniem high-risk w miejscu pracy poinformować przedstawicieli pracowników i pracowników dotkniętych systemem (ust. 7);
• zarejestrować się w bazie danych UE, jeśli deployer jest organem publicznym lub działa w ich imieniu (ust. 8);
• w przypadku, gdy decyzja systemu dotyczy osoby fizycznej — poinformować ją, że podlega działaniu systemu high-risk (ust. 11);
• współpracować z organami nadzorczymi (ust. 12).

Dla niektórych deployerów dochodzi obowiązek FRIA (Fundamental Rights Impact Assessment) per art. 27 — patrz dalej.

Kiedy deployer staje się providerem — art. 25

Art. 25 ust. 1 mówi jednoznacznie: dystrybutor, importer, deployer lub inna strona trzecia są uznawani za providera systemu wysokiego ryzyka — i przejmują wszystkie jego obowiązki z art. 16 — w trzech sytuacjach:

• umieszczają swoją nazwę lub znak towarowy na systemie high-risk już wprowadzonym na rynek (rebranding, white-label);
• dokonują istotnej modyfikacji systemu (substantial modification w rozumieniu art. 3 pkt 23);
• zmieniają przeznaczenie systemu AI tak, że po zmianie wpada on w kategorię high-risk.

To jest pułapka, w którą MŚP wpada najczęściej nieświadomie. Klasyczny scenariusz: kupujesz model GPT od dostawcy zewnętrznego, dotrenowujesz go na własnym datasetcie do screeningu CV, sprzedajesz pod własną marką jako „MyHR AI”. Z punktu widzenia AI Act stałeś się providerem high-risk — z całym pakietem art. 16-21, art. 43, art. 71.

Po stronie operacyjnej oznacza to jedną zasadę: każdy projekt, który modyfikuje, rebranduje lub przekierowuje system AI third-party, wymaga osobnej oceny statusu jeszcze przed startem.

Obowiązki providera GPAI — art. 53-55

Dostawcy modeli AI ogólnego przeznaczenia — GPAI — mają osobny pakiet, niezależny od kategorii high-risk. Art. 53 wymaga:

• dokumentacji technicznej modelu, w tym procesu treningowego i ewaluacji;
• udostępnienia informacji i dokumentacji dostawcom downstream (czyli polskim MŚP integrującym te modele);
• procedury zgodności z prawem autorskim UE;
• publikacji szczegółowo wystarczającego streszczenia danych treningowych według szablonu AI Office.

Art. 55 dorzuca dodatkowe obowiązki dla GPAI z ryzykiem systemowym — w praktyce dotyczy to modeli największych, z compute powyżej progów art. 51. Dla polskiego MŚP to istotne pośrednio — jako odbiorca tych modeli przez API otrzymujesz dokumentację, którą wcześniej trzeba było wyciągać siłą kontraktową.

FRIA — Fundamental Rights Impact Assessment — art. 27

Art. 27 nakłada na niektórych deployerów obowiązek przeprowadzenia oceny wpływu na prawa podstawowe (FRIA) przed pierwszym wdrożeniem systemu high-risk. Obowiązek dotyczy:

• organów publicznych i podmiotów świadczących usługi publiczne;
• deployerów systemów z Aneksu III pkt 5 lit. b i c (scoring kredytowy, pricing ubezpieczeń życiowych i zdrowotnych).

FRIA obejmuje opis procesu, w którym używany jest system, okres i częstotliwość wykorzystania, kategorie osób narażonych, konkretne ryzyka, środki nadzoru człowieka i procedury w przypadku materializacji ryzyka. Wynik FRIA musi być przekazany do organu nadzorczego.

Dla MŚP-deployera w fintechu lub ubezpieczeniach to nowy artefakt compliance — który warto budować równolegle z DPIA z art. 35 RODO. Synergie omawiamy szerzej w artykule o wspólnym stacku NIS-2 + AI Act.

Pięć scenariuszy MŚP w PL

Scenariusz 1: kupujesz Copilota dla zespołu. Microsoft jest providerem, Twoja firma jest deployerem. Copilot nie jest klasyfikowany jako system high-risk — wpada w kategorię ograniczonego ryzyka (transparentność wobec użytkownika końcowego, art. 50). Twoje obowiązki są minimalne — informacja dla pracowników, monitoring użycia.

Scenariusz 2: wdrażasz HR-tech AI do screeningu CV. Dostawca HR-tech jest providerem high-risk (Aneks III pkt 4). Twoja firma jest deployerem high-risk — z pełnym pakietem art. 26: informacja dla kandydatów i pracowników, logging, nadzór człowieka, FRIA (jeśli wpadasz w art. 27 ust. 1 — większość MŚP-pracodawców prywatnych nie wpada, ale weryfikacja jest wymagana).

Scenariusz 3: integrujesz GPT-4 jako copilot dla działu obsługi klienta. OpenAI jest providerem GPAI. Twoja firma — jeśli używa modelu tylko przez API, w funkcji niewchodzącej w Aneks III — jest deployerem ograniczonego ryzyka. Obowiązki: informacja dla użytkowników końcowych, że rozmawiają z systemem AI (art. 50).

Scenariusz 4: fine-tunujesz model open-source do scoringu kredytowego i sprzedajesz pod własną marką. Stałeś się providerem high-risk — przez połączenie istotnej modyfikacji modelu z przeznaczeniem z Aneksu III pkt 5 lit. b. Pełen pakiet art. 16-21, art. 27 ust. 1 lit. b dla Twoich deployerów (klientów finansowych).

Scenariusz 5: jesteś dystrybutorem amerykańskiego SaaS-a z AI w UE. Jeśli SaaS jest high-risk a dostawca nie ma authorised representative w UE — możesz być traktowany jako importer (art. 23) lub authorised representative (art. 22) — z konkretnymi obowiązkami, w tym weryfikacją, że provider przeprowadził conformity assessment i sporządził dokumentację.

QA10 — gdzie to sprawdzamy

W Audytcie AiP rozdzielamy role dla każdego systemu AI w stacku klienta — kto jest providerem, kto deployerem, czy występuje ryzyko przejęcia roli providera przez art. 25. Dla deployerów w kategoriach Aneksu III pkt 5 przygotowujemy też pierwszą iterację FRIA.