Sztuczna inteligencja to nie tylko technologia – to także gąszcz regulacji. W 2025 r. weszły w życie przepisy AI Act, które – obok dobrze już znanego przedsiębiorcom RODO – określają obowiązki związane z danymi i odpowiedzialnością. Największym wyzwaniem jest ustalenie, kim jesteś w danym projekcie: administratorem czy procesorem (RODO)? Dostawcą czy podmiotem stosującym (AI Act)? Błędna kwalifikacja grozi nie tylko karami, ale też sporami z kontrahentami i klientami.
W tym poradniku przeprowadzę Cię krok po kroku przez proces identyfikacji ról, pokażę mechanizmy „zmiany roli” i obowiązki, jakie wiążą się z każdą z nich. Wszystko ilustruję przykładami, które pomogą Ci zastosować przepisy w praktyce.
Czym jest system AI, a czym model AI?
Na gruncie AI Act rozróżnienie tych dwóch pojęć ma kluczowe znaczenie.
- System AI – to system oparty na maszynie, zaprojektowany do działania z różnym poziomem autonomii, zdolny do adaptacji i generowania wyników (np. predykcji, treści, decyzji). Po wdrożeniu może wpływać zarówno na środowisko fizyczne, jak i wirtualne.
- Model AI – to element, który może stać się systemem dopiero wtedy, gdy zostanie uzupełniony o dodatkowe komponenty, np. interfejs użytkownika, integracje czy reguły użycia.
📌 Ważne: modele ogólnego przeznaczenia (tzw. GPAI) mają własny reżim obowiązków. Może on działać równolegle z obowiązkami dotyczącymi systemów AI – to oznacza, że podmiot musi sprawdzić oba reżimy.
Role w RODO – administrator i procesor
RODO (Rozporządzenie o ochronie danych osobowych) operuje na pojęciach:
- Administrator danych osobowych – to ten, kto samodzielnie lub wspólnie z innymi ustala cele i sposoby przetwarzania.
➡️ Pamiętaj, że administrator nie musi mieć fizycznego dostępu do danych. Wystarczy, że to on podejmuje kluczowe decyzje, do czego i jak dane będą wykorzystywane. - Podmiot przetwarzający (procesor) – to podmiot, który przetwarza dane osobowe w imieniu administratora. Jego rola może być ograniczona np. tylko do przechowywania danych albo ich analizy zgodnie z poleceniami administratora.
Role w AI Act – dostawca i podmiot stosujący
Z kolei AI Act posługuje się innymi kategoriami:
- Dostawca (provider) – podmiot, który rozwija system AI (albo model GPAI) lub zleca jego rozwój, a następnie wprowadza go do obrotu lub oddaje do użytku pod własną nazwą lub marką.
- Podmiot stosujący (deployer) – to ten, kto wykorzystuje system AI, nad którym sprawuje kontrolę, w ramach działalności zawodowej.
👉 Drobna, ale kluczowa różnica: dostawca odpowiada za stworzenie i wprowadzenie systemu, a podmiot stosujący – za jego wykorzystanie zgodnie z przeznaczeniem.
Równoległe obowiązki – co to oznacza w praktyce?
Możesz być jednocześnie:
- dostawcą systemu AI (AI Act) i administratorem danych (RODO),
- podmiotem stosującym (AI Act) i procesorem danych (RODO).
Albo nawet w ramach jednego projektu pełnić różne role na różnych etapach. Dlatego tak ważne jest rozrysowanie pełnej mapy ról – od rozwoju modelu, przez wdrożenie, po wykorzystanie danych wejściowych i wyników.
Jak przypisać rolę w konkretnym projekcie? – test trzech warstw
Najprościej analizować rolę, patrząc na trzy warstwy działania systemu: rozwój – wdrożenie – dane wejściowe/wyjściowe. Do tego dochodzi jeszcze infrastruktura, która bywa rozproszona (np. model w chmurze jednego dostawcy, dane u innego, a interfejs w Twojej aplikacji).
Warstwa 1: rozwój systemu (development)
- Kto uczy model (np. trenuje, dostraja, wybiera dane i metryki jakości)?
👉 To najczęściej dostawca (AI Act).
👉 Jeżeli w tym procesie wykorzystywane są dane osobowe i to Ty decydujesz o ich celach i sposobach użycia, stajesz się administratorem danych (RODO).
Warstwa 2: wdrożenie systemu (deployment)
- Kto decyduje, w jakim celu system będzie używany, jakie parametry zostaną ustawione, jakie integracje i filtry zastosowane?
👉 To rola podmiotu stosującego (AI Act).
👉 W RODO – jeśli decydujesz o celach i sposobach przetwarzania danych wejściowych/wyjściowych, jesteś administratorem. Jeżeli działasz tylko „w imieniu” innego administratora – jesteś procesorem.
Warstwa 3: dane wejściowe i wyjściowe (input/output)
- Kto dostarcza dane wejściowe, a kto nad nimi faktycznie sprawuje kontrolę?
👉 Podmiot stosujący (AI Act) ma obowiązek zapewnić ich adekwatność i reprezentatywność, jeżeli system jest wysokiego ryzyka (art. 26 ust. 4 AI Act).
📌 Wniosek praktyczny: nawet jeśli to nie Ty stworzyłeś model, Twoja odpowiedzialność rośnie, gdy go wdrażasz i „karmisz” własnymi danymi.
Mechanizm „zmiany roli” w AI Act
Nie zawsze pozostajesz w roli, którą miałeś na starcie. AI Act przewiduje, że dystrybutor, importer, podmiot stosujący lub strona trzecia może zostać uznany za dostawcę systemu wysokiego ryzyka, jeżeli:
- umieści własny znak towarowy/nazwę na systemie,
- dokona istotnej zmiany w systemie,
- zmieni jego przeznaczenie tak, że staje się systemem wysokiego ryzyka.
Co to jest „istotna zmiana”?
To modyfikacja, która:
- nie była przewidziana przy ocenie zgodności dostawcy,
- ma wpływ na zgodność systemu z wymogami prawnymi,
- albo powoduje zmianę przeznaczenia.
⚠️ Konsekwencja praktyczna: możesz „niechcący” stać się dostawcą – wraz z pełnym pakietem obowiązków (m.in. dokumentacja, ocena zgodności, system zarządzania ryzykiem).
Obowiązki podmiotu stosującego
Podmiot stosujący nie jest „biernym” użytkownikiem. Jego obowiązki obejmują m.in.:
- korzystanie z systemu zgodnie z instrukcją dostawcy,
- monitorowanie działania i zgłaszanie incydentów (do dostawcy lub właściwych organów – podobnie jak art. 33 RODO w kontekście naruszeń danych),
- w niektórych przypadkach – przygotowanie oceny skutków dla praw podstawowych (analogicznej do DPIA w RODO),
- zapewnienie adekwatności i reprezentatywności danych wejściowych (jeśli system jest wysokiego ryzyka).
👉 To oznacza, że nawet korzystając z „gotowego narzędzia”, odpowiadasz za to, jak je karmisz i jak je monitorujesz.
Kiedy dostawca jest administratorem, a kiedy procesorem (RODO)?
Na gruncie RODO rola dostawcy zależy od tego, w jakim celu i na jakiej podstawie wykorzystuje dane osobowe:
- Dostawca jako administrator
- zazwyczaj na etapie treningu/dostrajania modelu, gdy samodzielnie decyduje o zbiorach danych, ich jakości i kryteriach użycia,
- przy ulepszaniu usług (np. wykorzystuje dane klientów do poprawy swojego modelu, tworzenia nowych funkcjonalności lub monitorowania jakości),
- gdy narzuca istotne parametry przetwarzania danych wejściowych/wyjściowych – wówczas nie działa „w imieniu klienta”, tylko we własnym interesie.
- Dostawca jako procesor
- gdy świadczy usługi czysto techniczne (np. udostępnia API, hostuje inferencję),
- nie wykorzystuje danych klientów do własnych celów,
- działa wyłącznie na udokumentowane polecenie administratora (np. w ramach umowy powierzenia).
📌 Pułapka: często w regulaminach dostawców znajdują się zapisy typu „dane mogą być użyte do ulepszania usług”. To przesuwa rolę dostawcy w stronę administratora lub nawet współadministratora, bo oznacza własny cel przetwarzania.
Scenariusze ról w praktyce
Scenariusz A: SaaS z własnymi danymi
Firma korzysta z gotowego narzędzia AI w modelu SaaS.
- Dostawca – rozwija system i wprowadza go na rynek → dostawca (AI Act). W RODO: jeśli nie używa danych klientów do swoich celów → procesor.
- Klient – używa systemu zgodnie z przeznaczeniem → podmiot stosujący (AI Act). W RODO: administrator (bo decyduje, w jakim celu i jak wykorzystuje dane swoich klientów).
Scenariusz B: trening na danych klienta
Dostawca modelu prosi klienta o udostępnienie danych do dalszego trenowania.
- Dostawca – jeśli używa danych do swoich celów (np. poprawa modelu dla wszystkich klientów), staje się administratorem albo nawet współadministratorem (RODO).
- Klient – nadal jest administratorem wobec swoich klientów i jednocześnie podmiotem stosującym (AI Act).
- Obie strony mogą pełnić równolegle role administratorów → konieczna umowa o współadministrowanie (art. 26 RODO).
Scenariusz C: on-premises (model własny klienta)
Klient instaluje system AI na własnych serwerach, dostawca dostarczył tylko kod i dokumentację.
- Klient – staje się dostawcą i podmiotem stosującym (AI Act), a także administratorem danych (RODO).
- Dostawca – może nie pełnić żadnej roli na gruncie RODO, jeśli nie ma kontaktu z danymi i nie ingeruje w ich przetwarzanie.
Przykłady z praktyki (zmienione dane)
Przykład 1: Skoring najemców w spółce „MiejskiLokum”
Firma z Wrocławia wdraża system do oceny ryzyka najmu. Oparty jest na modelu „NeuroScore SA”, ale z własnym interfejsem i integracją z bazą danych.
- „MiejskiLokum” → podmiot stosujący (AI Act), administrator (RODO).
- „NeuroScore SA” → dostawca modelu.
👉 Jeśli „MiejskiLokum” doda moduł scoringu poza zakresem oceny zgodności – automatycznie staje się dostawcą systemu wysokiego ryzyka.
Przykład 2: Chatbot HR „Hekate” w firmie „Alfabeta”
„Alfabeta” wdraża chatbota do preselekcji CV. Dostawca „LangShip” oferuje hostowaną usługę i nie używa danych klientów do trenowania.
- „Alfabeta” → podmiot stosujący (AI Act) i administrator (RODO).
- „LangShip” → procesor (RODO).
👉 Jeśli jednak „LangShip” zacznie używać danych klientów do „ulepszania usług”, stanie się administratorem w tym zakresie.
Rola mieszana – jak to działa w cyklu życia?
W praktyce rzadko bywa tak, że rola pozostaje stała. Przykład:
- Na etapie rozwoju dostawca jest administratorem (RODO).
- Na etapie wdrożenia klient staje się administratorem i podmiotem stosującym.
- Gdy klient wprowadzi istotną modyfikację → zmienia się w dostawcę (AI Act).
⚠️ Dlatego tak ważna jest mapa ról – pokazująca, kto odpowiada za dane i obowiązki w każdej fazie projektu.
Checklista przypisania ról (AI Act + RODO)
Aby prawidłowo ustalić swoją rolę, warto przejść przez prosty test krok po kroku:
Krok 1: Co wdrażasz?
- Czy to tylko model (np. API do LLM), czy już pełny system (z interfejsem, regułami i integracją)?
👉 Jeśli system – możesz być dostawcą (AI Act), nawet jeśli bazujesz na cudzym modelu.
Krok 2: Kto ustala cel i sposoby przetwarzania danych osobowych?
- Ten podmiot jest administratorem (RODO).
👉 Pamiętaj: dostęp fizyczny do danych nie jest konieczny – liczy się decyzyjność.
Krok 3: Czy dane klienta służą do trenowania/ulepszania modelu?
- Tak → z dużym prawdopodobieństwem dostawca jest administratorem albo współadministratorem.
Krok 4: Czy zmieniasz przeznaczenie systemu albo istotnie go modyfikujesz?
- Tak → stajesz się dostawcą systemu (AI Act), z obowiązkiem ponownej oceny zgodności.
Krok 5: Czy system jest wysokiego ryzyka?
- Jeżeli tak – sprawdź dodatkowe wymogi, np. art. 26 ust. 4 AI Act dotyczący danych wejściowych.
Najczęstsze pułapki i sposoby ich uniknięcia
⚠️ „Prompt to nie trening”
- Wprowadzanie promptów przez użytkowników nie czyni Cię automatycznie administratorem danych w kontekście trenowania. Rola zależy od tego, kto decyduje o celach i środkach ich dalszego wykorzystania.
⚠️ Mylące zapisy w umowach
- Klauzule o „ulepszaniu usług” często oznaczają, że dostawca staje się administratorem we własnym zakresie.
👉 Rozwiązanie: żądaj jasnego podziału ról i możliwości opt-in/opt-out.
⚠️ Rozproszona infrastruktura
- Model, dane wejściowe i wyniki mogą być obsługiwane przez różnych dostawców (np. model w chmurze A, interfejs w chmurze B).
👉 Wymaga to zmapowania przepływów i oceny, kto pełni rolę administratora lub procesora w każdym punkcie.
⚠️ Filtry i moderacja
- Podmiot stosujący musi wdrożyć własne mechanizmy kontroli (np. filtrowanie treści, monitoring incydentów).
👉 Nie wystarczy powoływać się na dostawcę – AI Act nakłada bezpośrednie obowiązki.
Oceny skutków: DPIA i FRA
Na gruncie RODO i AI Act mogą się pojawić równoległe obowiązki:
- DPIA (Data Protection Impact Assessment) – ocena skutków dla ochrony danych osobowych (art. 35 RODO). Obowiązkowa, gdy przetwarzanie może powodować wysokie ryzyko naruszenia praw osób fizycznych.
- FRA (Fundamental Rights Assessment) – ocena skutków dla praw podstawowych (AI Act). Może być wymagana od podmiotów stosujących systemy wysokiego ryzyka.
📌 Dobra praktyka: łączyć oba procesy w jeden dokument – pozwala to uniknąć powielania pracy i lepiej zarządzać ryzykiem.
Dobre praktyki kontraktowe i organizacyjne
- Mapa ról i przepływów – rozrysuj, kto pełni funkcję dostawcy, podmiotu stosującego, administratora, procesora.
- Klauzule dotyczące treningu – precyzyjnie określ, czy dane klienta mogą być używane do doskonalenia modeli.
- Mechanizm zmiany roli – ustal w umowie, kiedy i jak strony oceniają, czy doszło do „istotnej zmiany” systemu.
- Instrukcje i logi – dokumentuj zgodność z instrukcją dostawcy, zbieraj logi działań i incydentów.
- Polityka danych wejściowych – określ, jak zapewniasz ich adekwatność i reprezentatywność (zwłaszcza w systemach wysokiego ryzyka).
Podsumowanie – kluczowe wnioski
- System AI ≠ model AI – dodanie interfejsu czy integracji może sprawić, że zwykły model staje się systemem objętym pełnym reżimem AI Act.
- Role z AI Act i RODO nakładają się, ale są odrębne – AI Act patrzy na funkcję w łańcuchu dostaw i stosowania, RODO – na cele i sposoby przetwarzania danych osobowych.
- Zmiana przeznaczenia lub istotna modyfikacja systemu powoduje, że podmiot stosujący może stać się dostawcą – a to oznacza dużo większe obowiązki.
- Podmiot stosujący nie jest „biernym” użytkownikiem – musi m.in. monitorować zdarzenia, stosować się do instrukcji dostawcy i dbać o jakość danych wejściowych.
- Umowy i polityki są kluczowe – źle sformułowane klauzule (np. o „ulepszaniu usług”) mogą zmienić rozkład odpowiedzialności i przesunąć role.
- Łączenie DPIA i FRA – ocena skutków dla danych osobowych (RODO) i dla praw podstawowych (AI Act) powinna być przeprowadzana razem, aby lepiej zarządzać ryzykiem.
Cytaty z przepisów (słowo w słowo)
RODO – Rozporządzenie (UE) 2016/679:
- art. 4 pkt 7
„‚administrator’ oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub inny podmiot, który samodzielnie lub wspólnie z innymi ustala cele i sposoby przetwarzania danych osobowych; jeżeli cele i sposoby takiego przetwarzania są określone w prawie Unii lub w prawie państwa członkowskiego, to również w prawie Unii lub w prawie państwa członkowskiego może zostać wyznaczony administrator lub mogą zostać określone konkretne kryteria jego wyznaczania.”
- art. 4 pkt 8
„‚podmiot przetwarzający’ oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub inny podmiot, który przetwarza dane osobowe w imieniu administratora.”
AI Act – Rozporządzenie Parlamentu Europejskiego i Rady w sprawie sztucznej inteligencji:
- art. 3 pkt 1
„‚system sztucznej inteligencji (system AI)’ oznacza system oparty na maszynie, który został zaprojektowany do działania z różnym poziomem autonomii i który może, po wdrożeniu, w celu wyraźnie określonym przez człowieka, generować dane wyjściowe, takie jak prognozy, zalecenia lub decyzje, które wpływają na środowiska, z którymi system ten wchodzi w interakcję.”
- art. 3 pkt 23
„‚istotna zmiana’ oznacza modyfikację w systemie AI po jego wprowadzeniu do obrotu lub oddaniu do użytku, która nie została przewidziana lub zaplanowana przy początkowej ocenie zgodności przeprowadzonej przez dostawcę i która ma wpływ na zgodność systemu AI z wymogami ustanowionymi w rozdziale III sekcja 2, lub która powoduje zmianę przeznaczenia, w odniesieniu do którego oceniono system AI.”
- art. 26 ust. 4
„Bez uszczerbku dla ust. 1 i 2 podmiot stosujący zapewnia, w zakresie, w jakim sprawuje on kontrolę nad danymi wejściowymi, adekwatność i wystarczającą reprezentatywność danych wejściowych w odniesieniu do przeznaczenia systemu AI wysokiego ryzyka.”
Tematy porad zawartych w poradniku
- „ustalanie ról AI Act a RODO 2025”
- „obowiązki podmiotu stosującego system AI”
- „istotna zmiana systemu AI – konsekwencje prawne”
- „dostawca AI a administrator danych osobowych”
- „ocena skutków DPIA i FRA przy sztucznej inteligencji”
Przydatne adresy urzędowe
- Urząd Ochrony Danych Osobowych: https://uodo.gov.pl
- Komisja Europejska – Ochrona danych: https://ec.europa.eu/info/law/law-topic/data-protection_pl
- EUR-Lex – prawo UE: https://eur-lex.europa.eu/
- Data.europa.eu – portal danych: https://data.europa.eu/
- Strona KE nt. sztucznej inteligencji: https://single-market-economy.ec.europa.eu/