Provider vs deployer wg AI Act – jak jednoznacznie ustalić swoją rolę?

Pierwsza decyzja przed jakimkolwiek compliance z AI Act. Bo od tego zależy które artykuły rozporządzenia w ogóle Cię dotyczą. Dwie nazwy które brzmią podobnie a oznaczają zupełnie różne pakiety obowiązków.

AI Act wprowadza dwie role uczestniczące w łańcuchu systemów sztucznej inteligencji - provider (dostawca) i deployer (operator/użytkownik biznesowy).

Polskie tłumaczenie nie jest jeszcze ustabilizowane. Spotyka się "dostawca" i "operator," "podmiot dostarczający" i "podmiot stosujący," "dostawca" i "użytkownik systemu AI." W całym artykule używam terminów provider i deployer bo są precyzyjne i jednoznaczne.

Ustalenie czy jesteś providerem czy deployerem jest pierwszą i najważniejszą decyzją w compliance z AI Act. Bo od tego zależy które przepisy w ogóle Cię dotyczą.

Definicje z rozporządzenia

AI Act w art. 3 podaje konkretne definicje obu ról.

Provider to osoba fizyczna lub prawna, organ publiczny, agencja lub inny podmiot który rozwija system AI lub model AI ogólnego przeznaczenia albo zleca jego rozwój, a następnie wprowadza go do obrotu lub oddaje do użytku pod własną nazwą lub znakiem towarowym – odpłatnie lub nieodpłatnie.

Deployer to osoba fizyczna lub prawna, organ publiczny, agencja lub inny podmiot używający systemu AI pod swoją kontrolą – z wyjątkiem sytuacji gdy system AI jest używany w ramach osobistej działalności pozazawodowej.

Dwa kluczowe rozróżnienia.

Provider tworzy lub zleca stworzenie systemu AI i wprowadza go do obrotu. Deployer używa systemu który ktoś inny dostarczył.

Provider działa pod własną nazwą albo znakiem towarowym. Deployer działa pod kontrolą własną ale używa cudzego produktu.

Provider – kto pod to podpada w praktyce

Klasyczny provider to firma technologiczna która tworzy system AI i sprzedaje go innym podmiotom.

OpenAI tworząca GPT i udostępniająca go przez API – provider. Anthropic tworzące Claude – provider. Microsoft tworzący Copilot – provider. Polskie startupy AI tworzące własne modele – providery.

Ale nie tylko firmy "stricte technologiczne."

Bank który zlecił zewnętrznej firmie stworzenie autorskiego modelu scoringowego AI i wdrożył go pod własną nazwą jako "Bank XYZ Smart Scoring" – w tym kontekście może być providerem mimo że nie pisał kodu. Wprowadził system do obrotu pod własnym znakiem towarowym i pod własną nazwą.

Firma która dotrenowała otwarty model open-source na własnych danych specjalnie dla swojego sektora i udostępnia go klientom – też wchodzi w rolę providera.

Status providera nie zależy więc od tego czy sam pisałeś kod. Zależy od tego czy wprowadzasz system do obrotu pod własną odpowiedzialnością.

Deployer – kto pod to podpada w praktyce

Deployer to każda firma która używa systemu AI dostarczonego przez kogoś innego do swoich zadań biznesowych.

Sklep internetowy używający systemu rekomendacji AI dostarczonego przez zewnętrznego dostawcę – deployer. Bank wykorzystujący zewnętrzny system scoringowy bez modyfikacji – deployer. Firma używająca Copilota w pracy z Microsoft 365 – deployer. Szpital używający systemu wsparcia diagnostyki AI od zewnętrznego dostawcy – deployer.

Większość firm w gospodarce nie tworzy systemów AI od zera. Używa gotowych rozwiązań. To znaczy że większość firm jest deployerami a nie providerami.

To jest ważne bo deployery mają znacznie węższy zakres obowiązków niż providerzy. Większa część AI Act dotyczy providerów – którzy ponoszą główną odpowiedzialność za bezpieczeństwo i zgodność systemów AI. Deployery mają obowiązki bardziej operacyjne – używanie systemu zgodnie z instrukcjami, nadzór ludzki, w wybranych przypadkach FRIA.

Gdy granica się zaciera – cztery scenariusze ryzyka

AI Act w art. 25 wprowadza zasadę że deployer może stać się providerem w określonych sytuacjach. To znaczy że Twoja rola nie jest stała – może się zmienić wskutek Twoich działań.

Scenariusz pierwszy: zmiana celu.

Używasz systemu AI dostarczonego przez kogoś innego. Provider przeznaczył go do konkretnego celu opisanego w instrukcjach. Ty używasz go do innego celu niż przewidziany.

Konkretny przykład. Kupujesz system AI do analizy CV pod kątem dopasowania do stanowiska. Provider przeznaczył go do filtrowania kandydatów przed rozmową z rekruterem. Ty używasz go do automatycznego odrzucania kandydatów bez interwencji rekrutera.

Zmieniłeś cel. W tym momencie wchodzisz w rolę providera dla zmodyfikowanego użycia – z całym pakietem obowiązków providera.

Scenariusz drugi: znacząca modyfikacja systemu.

Kupujesz model AI i dotrenowujesz go na własnych danych w sposób który istotnie zmienia jego działanie albo wyniki. Nie jest to już ten sam system który dostałeś od providera.

W tym momencie stajesz się providerem zmodyfikowanego systemu.

Granica między "drobną zmianą" a "znaczącą modyfikacją" nie jest ostra. Fine-tuning modelu na własnym corpusie tekstowym żeby lepiej rozumiał branżową terminologię – zazwyczaj nie jest znaczącą modyfikacją. Pełne dotrenowanie modelu na własnych danych do całkiem nowego zadania – jest.

Scenariusz trzeci: rebrandowanie.

Kupujesz system AI od zewnętrznego dostawcy i wprowadzasz go do obrotu pod własną nazwą albo znakiem towarowym jako swój produkt – nawet bez modyfikacji technicznej.

Klasyczny przykład white labeling. Firma kupuje gotowy system od OpenAI i udostępnia go klientom jako "AI Assistant Naszej Firmy."

W tym momencie firma staje się providerem mimo że technicznie nic nie napisała.

Scenariusz czwarty: integracja w łańcuchu wartości.

Łączysz kilka komponentów AI od różnych dostawców w jeden system który oferujesz klientom jako swój produkt. Składasz puzzle z gotowych elementów ale efekt finalny jest Twoim systemem.

Stajesz się providerem tego zintegrowanego systemu – nawet jeśli każdy komponent z osobna jest cudzym produktem.

Praktyczny test dla Twojej firmy

Cztery pytania w kolejności żeby ustalić swoją rolę.

Pytanie pierwsze: czy Twoja firma tworzy system AI lub zleca jego stworzenie?

Jeśli tak – jesteś providerem dla tego systemu.

Jeśli nie – idź do pytania drugiego.

Pytanie drugie: czy używasz systemu AI dostarczonego przez kogoś innego do własnej działalności?

Jeśli tak – jesteś deployerem. Ale sprawdź jeszcze kolejne pytania bo możesz wejść w rolę providera.

Pytanie trzecie: czy modyfikujesz system w sposób znaczący, używasz go do innego celu niż przewidziany przez providera, rebrandujesz go pod własną marką albo integrujesz z innymi systemami jako własny produkt?

Jeśli tak – wchodzisz w rolę providera dla zmodyfikowanego użycia obok bycia deployerem.

Jeśli nie – jesteś tylko deployerem.

Pytanie czwarte: czy system jest systemem AI wysokiego ryzyka zgodnie z załącznikiem III AI Act?

Jeśli tak – masz pełen pakiet obowiązków providera lub deployera dla systemów wysokiego ryzyka.

Jeśli nie – masz znacznie węższy zakres obowiązków ale niektóre wymogi nadal Cię dotyczą (np. obowiązek transparentności wobec użytkowników).

Co wynika z określenia roli – pakiety obowiązków

Obowiązki providera systemu AI wysokiego ryzyka są szerokie. Wdrożenie systemu zarządzania jakością. Sporządzenie dokumentacji technicznej. Rejestracja systemu w bazie UE. Ocena zgodności przed wprowadzeniem do obrotu. Monitoring po wprowadzeniu do obrotu i obowiązek zgłaszania incydentów. Współpraca z organami nadzorczymi.

Obowiązki deployera są węższe ale konkretne. Używanie systemu zgodnie z instrukcjami providera. Zapewnienie nadzoru ludzkiego nad decyzjami systemu. Monitorowanie działania systemu i informowanie providera o nieprawidłowościach. W określonych przypadkach – FRIA zgodnie z art. 27. Informowanie pracowników i osób fizycznych o tym że są poddani decyzjom systemu AI.

Te dwa pakiety obowiązków nie są opcjonalne. Są wymagalne dla każdej z ról. I ich niewykonanie wiąże się z karami administracyjnymi z AI Act.

Dlaczego ta decyzja jest tak ważna w praktyce

Bo wpływa na wszystko co robisz dalej w compliance z AI Act.

Jeśli błędnie zakwalifikujesz się jako deployer mimo że jesteś providerem – nie wdrożysz wymaganych systemów zarządzania jakością, dokumentacji technicznej i procesów oceny zgodności. Przy kontroli organ stwierdzi że jako provider miałeś szersze obowiązki których nie wypełniłeś.

Jeśli błędnie zakwalifikujesz się jako provider mimo że jesteś deployerem – wdrożysz nadmiarowe procesy i poniesiesz koszty których nie musiałeś ponosić.

Pierwsze pomyłki są groźniejsze niż drugie. Niedoszacowanie roli prowadzi do braków w compliance. Przeszacowanie prowadzi do nadmiarowego compliance ale nie do naruszenia.

Dlatego przy każdej wątpliwości – warto pochylić się nad scenariuszami art. 25 i sprawdzić czy nie wpadasz w rolę providera mimo że formalnie kupiłeś gotowy system.

Czy używanie ChatGPT w pracy przez moich pracowników czyni mnie deployerem?

Tak ale w bardzo ograniczonym zakresie. Jeśli pracownicy używają ChatGPT do własnych zadań – piszą maile, robią research, tłumaczą teksty – jesteś deployerem ale używasz systemu który w większości zastosowań nie jest systemem wysokiego ryzyka. To znaczy że nie podlegasz najszerszemu pakietowi obowiązków deployera systemów wysokiego ryzyka. Ale obowiązek transparentności – informowanie odbiorców gdy treść została wygenerowana przez AI – nadal Cię dotyczy. Plus warto mieć politykę użycia AI w firmie żeby pracownicy nie wpisywali poufnych danych do publicznego modelu.

Kupiliśmy gotowy system od dostawcy z USA. Czy on jest providerem czy my?

Co do zasady dostawca pozostaje providerem a Wy jesteście deployerem – chyba że wchodzicie w jeden z czterech scenariuszy z art. 25. Sam fakt że dostawca jest spoza UE nie czyni Was providerem. AI Act stosuje się do systemów wprowadzanych do obrotu w UE niezależnie od pochodzenia – dostawca z USA musi spełniać wymogi providera jeśli udostępnia system w UE. Wy macie obowiązki deployera. Warto natomiast w umowie z dostawcą wprost zapisać kto pełni jaką rolę i kto za co odpowiada – żeby przy ewentualnej kontroli była jednoznaczność.

Dotrenowuję model open-source na własnych danych. Kiedy staję się providerem?

Granica jest nieostra ale wytyczne wskazują na dwa kryteria. Pierwsze: czy modyfikacja istotnie zmienia działanie albo wyniki modelu w sposób który wykracza poza pierwotny zakres przewidziany przez twórcę open-source. Drugie: czy udostępniasz dotrenowany model innym podmiotom pod własną nazwą. Fine-tuning niewielkiego zakresu na własnych danych branżowych zachowując oryginalne zastosowanie – prawdopodobnie nadal deployer. Gruntowne dotrenowanie zmieniające zakres zadań modelu i udostępnienie go jako "Twojego" modelu pracowniczego – provider. Granicą jest też skala – kilka godzin fine-tuningu różni się od kilku miesięcy intensywnego treningu.

Czy firma która używa Microsoft Copilot integruje to z Teams i CRM-em staje się providerem?

Sama integracja z istniejącą infrastrukturą firmową nie czyni Cię providerem. Copilot pozostaje produktem Microsoftu którego oni są providerem. Wy jesteście deployerem zintegrowanego systemu. Sytuacja zmienia się gdyby firma stworzyła własne rozszerzenie Copilota i sprzedawała je klientom jako własny produkt – wtedy w odniesieniu do tego rozszerzenia firma stałaby się providerem. Sama konfiguracja Copilota dla własnych potrzeb wewnętrznych – nie.

Mała agencja marketingowa używa kilku narzędzi AI. Czy musi się tym przejmować?

Częściowo tak ale w ograniczonym zakresie. Większość typowych narzędzi marketingowych AI – generatory tekstu, narzędzia do tworzenia grafik, asystenty pisania – nie są systemami wysokiego ryzyka według załącznika III. To znaczy że agencja jako deployer nie podlega najszerszym obowiązkom z AI Act. Ale obowiązek transparentności wobec klientów końcowych pozostaje – gdy publikujesz treści wygenerowane przez AI, klient powinien o tym wiedzieć. Plus odpowiedzialność za to co publikujesz spoczywa na agencji niezależnie od narzędzia którym to wygenerowała.

Co się stanie jeśli błędnie zakwalifikujemy się jako deployer mimo że jesteśmy providerem?

Przy kontroli organ nadzorczy zweryfikuje rzeczywistą rolę firmy a nie deklarowaną. Jeśli faktycznie spełniacie kryteria providera – wszystkie obowiązki providera Was dotyczą niezależnie od tego jak się nazywaliście wewnętrznie. Naruszenie obowiązków providera może być sankcjonowane karą do 15 milionów euro lub 3% rocznego obrotu. Plus organ może nakazać wstrzymanie używania systemu do czasu spełnienia wymogów. Dlatego błąd w klasyfikacji w stronę deployera mimo że jest się providerem jest groźniejszy niż błąd w drugą stronę.

Czy są przepisy które mówią wprost kto jest providerem a kto deployerem dla konkretnych systemów?

W AI Act samym – nie ma takiej listy. Klasyfikacja zawsze opiera się na ogólnych definicjach z art. 3 i scenariuszach z art. 25. Komisja Europejska i krajowe organy nadzorcze publikują wytyczne ale są one ogólne. W praktyce klasyfikacja wymaga analizy konkretnej sytuacji – kto stworzył system, kto go wprowadził do obrotu, kto go modyfikuje, pod jaką nazwą jest oferowany. Przy wątpliwościach warto skonsultować się z prawnikiem specjalizującym się w AI Act przed wdrożeniem – niż naprawiać klasyfikację post factum.

Czy provider i deployer to są jedyne role w AI Act?

Nie. AI Act wprowadza więcej ról – importer, dystrybutor, autoryzowany przedstawiciel. Importer to podmiot mający siedzibę w UE który wprowadza do obrotu system AI od dostawcy spoza UE. Dystrybutor to podmiot w łańcuchu dostaw inny niż provider i importer udostępniający system na rynku UE. Autoryzowany przedstawiciel to podmiot wyznaczony przez providera spoza UE do działania w jego imieniu. Każda z tych ról ma własny zakres obowiązków – znacznie węższy niż provider ale szerszy niż "nic." W większości polskich firm te role nie są istotne – ale warto wiedzieć że istnieją żeby przy łańcuchu dostaw z udziałem podmiotów spoza UE prawidłowo zidentyfikować swoją rolę.

Artykuł powstał przy wsparciu AI. Weryfikacja merytoryczna i redakcja: Damian Bielecki, Typ od RODO.