GPAI Code of Practice: czy Twoja firma jest dostawcą modelu AI ogólnego przeznaczenia i jakie obowiązki się z tym wiążą?

O tym, czy firma ma obowiązki dostawcy modelu GPAI (General-Purpose AI, czyli modelu AI ogólnego przeznaczenia), nie decyduje sam fakt korzystania ze sztucznej inteligencji. Decyduje rola, jaką firma pełni wobec konkretnego modelu: czy go tworzy, w istotnym zakresie modyfikuje, czy dalej udostępnia. Większość firm, które korzystają z gotowych modeli takich jak ChatGPT, Claude czy Gemini – nawet integrując je z własną aplikacją przez API – nie staje się przez to dostawcą modelu GPAI i nie podlega obowiązkom z art. 53 rozporządzenia w sprawie sztucznej inteligencji (AI Act).

W praktyce znaczenie ma nie samo korzystanie ze sztucznej inteligencji, ale rola, jaką firma pełni w łańcuchu dostaw technologii AI. Inne obowiązki mogą dotyczyć przedsiębiorcy, który korzysta z gotowego modelu, inne podmiotu, który buduje na nim własny system, a jeszcze inne firmy, która samodzielnie rozwija i wprowadza do obrotu model AI ogólnego przeznaczenia.

To rozróżnienie jest istotne również w kontekście GPAI Code of Practice, czyli unijnego kodeksu postępowania dotyczącego modeli AI ogólnego przeznaczenia. Kodeks opublikowano 10 lipca 2025 r. i ma ułatwiać dostawcom takich modeli wykazywanie zgodności z AI Act. Sam kodeks ma charakter dobrowolny – obowiązki, których realizację ma ułatwiać, wynikają jednak bezpośrednio z AI Act.

Dla przedsiębiorcy kluczowe jest więc ustalenie jednego pytania: Czy moja firma tylko korzysta z modelu GPAI, czy w określonych okolicznościach sama staje się jego dostawcą?

Model AI ogólnego przeznaczenia to nie to samo co system AI

Zanim przejdziemy do konkretnych obowiązków, warto uporządkować podstawowe pojęcia.

Model AI ogólnego przeznaczenia (GPAI) to model, który może być wykorzystywany do wielu różnych zadań i stanowić podstawę dla różnych systemów AI. Przykładem może być duży model językowy, który po odpowiedniej integracji służy m.in. do generowania tekstów, analizy dokumentów, odpowiadania na pytania czy wspierania obsługi klienta.

Sam model nie musi być jednak produktem, z którego bezpośrednio korzysta użytkownik.

Może zostać wykorzystany przez inną firmę jako element większego systemu AI. Przedsiębiorca może na przykład uzyskać dostęp do modelu przez API, a następnie stworzyć własne narzędzie do automatycznej analizy reklamacji albo wyszukiwania informacji w dokumentacji technicznej.

W takim przypadku firma korzystająca z gotowego modelu — tylko dlatego, że zintegrowała go ze swoim rozwiązaniem — co do zasady nie staje się dostawcą tego modelu GPAI.

To istotne rozróżnienie, ponieważ AI Act nakłada obowiązki dotyczące modeli GPAI przede wszystkim na ich dostawców, a nie na każdą firmę, która wykorzystuje takie modele w swojej działalności. Komisja Europejska wskazuje przy tym, że model GPAI może być integrowany z innymi systemami AI i stanowić ich element.

A co z prompt engineeringiem, RAG albo własną aplikacją?

Samo:

• przygotowywanie rozbudowanych promptów,
• zastosowanie RAG, czyli połączenie modelu z własną bazą dokumentów,
• podłączenie modelu przez API,
• stworzenie własnego interfejsu,
• dodanie własnego brandingu,
• zbudowanie aplikacji korzystającej z gotowego modelu

nie oznacza automatycznie, że przedsiębiorca staje się dostawcą modelu GPAI.

W takim przypadku firma może być natomiast dostawcą własnego systemu AI i podlegać obowiązkom wynikającym z innych przepisów AI Act. Zakres tych obowiązków — w tym klasyfikację ryzyka systemu i wymogi dla operatora lub dostawcy systemu AI — omawiamy szerzej w ramach usługi AI Compliance

Dlatego przy wdrażaniu AI w firmie warto zacząć od prostego pytania: Co dokładnie stworzyliśmy i co właściwie udostępniamy użytkownikom?

Dopiero na tej podstawie można ustalić, które przepisy AI Act mają zastosowanie.

Kiedy firma może stać się dostawcą modelu GPAI?

Najprostszy przypadek to przedsiębiorca, który sam opracowuje model AI ogólnego przeznaczenia i wprowadza go do obrotu lub oddaje do użytku w Unii Europejskiej.

Sytuacja może być bardziej złożona, gdy firma korzysta z istniejącego modelu i go modyfikuje. Przykładowo przedsiębiorca może:

• dostroić istniejący model do określonego zastosowania,
• wykorzystać dodatkowe dane do jego trenowania,
• stworzyć jego zmodyfikowaną wersję,
• a następnie udostępniać tę wersję innym podmiotom.

Nie oznacza to jednak, że każda modyfikacja lub każde dostrojenie modelu automatycznie powoduje powstanie obowiązków dostawcy modelu GPAI.

Komisja Europejska w swoich wytycznych wskazuje, że AI Act nie traktuje każdej modyfikacji istniejącego modelu jako stworzenia nowego modelu. Podmiot, który modyfikuje lub dostraja model, może stać się dostawcą modelu GPAI w określonych sytuacjach. Jednym z istotnych kryteriów wskazanych przez Komisję jest zakres dodatkowych obliczeń wykorzystanych przy modyfikacji lub dostrajaniu modelu – w wytycznych pojawia się próg przekraczający jedną trzecią obliczeń wykorzystanych do trenowania pierwotnego modelu.

Nie należy jednak traktować tego progu jako jedynego warunku decydującego o statusie dostawcy. Przy ocenie konkretnego przypadku trzeba uwzględnić również pozostałe przesłanki wynikające z AI Act i wytycznych Komisji.

Jakie obowiązki ma dostawca modelu GPAI?

Jeżeli firma rzeczywiście jest dostawcą modelu AI ogólnego przeznaczenia, jej podstawowe obowiązki wynikają z art. 53 AI Act. Można je uporządkować w czterech głównych obszarach.

• Dokumentacja techniczna modelu. Dostawca musi przygotować i na bieżąco aktualizować dokumentację techniczną modelu — proces opracowania i trenowania, sposób testowania, wyniki ocen. Minimalny zakres określa załącznik XI do AI Act. To nie dokumentacja wewnętrzna ani marketingowa — jej celem jest umożliwienie oceny modelu przez właściwe podmioty, w tym udostępnienie jej Komisji lub organom na żądanie.
• Informacje dla firm korzystających z modelu. Dostawca musi przygotować i aktualizować informacje pozwalające zrozumieć możliwości modelu, jego ograniczenia, zadania do których może być wykorzystywany, sposób integracji oraz parametry techniczne. Minimalny zakres określa załącznik XII do AI Act — to więcej niż samo API i instrukcja obsługi.
• Polityka dotycząca praw autorskich. Dostawca musi wdrożyć politykę zapewniającą zgodność z prawem autorskim, w tym mechanizmy respektowania zastrzeżeń dotyczących text i data mining. Ogólne stwierdzenie „dane pochodzą z internetu” nie wystarczy.
• Publiczne podsumowanie treści treningowych. Dostawca musi opublikować podsumowanie treści wykorzystanych do trenowania modelu według wzoru Komisji Europejskiej. To nie obowiązek ujawnienia całego datasetu — tylko publiczne podsumowanie zgodne z wymaganiami Komisji.

Open source nie oznacza automatycznego zwolnienia ze wszystkich obowiązków

AI Act przewiduje szczególne zasady dla modeli GPAI udostępnianych na zasadach open source. Jeżeli model jest udostępniany na wolnej i otwartej licencji, a jego parametry, wagi i architektura są publicznie dostępne, dostawca może być zwolniony z części obowiązków (dokumentacja techniczna, informacje dla użytkowników). Nie oznacza to jednak pełnego zwolnienia — obowiązki dot. praw autorskich i publikacji podsumowania treści treningowych pozostają, a wyjątek nie dotyczy modeli stwarzających ryzyko systemowe.

A co z modelami stwarzającymi ryzyko systemowe?

AI Act przewiduje dodatkową kategorię modeli GPAI stwarzających ryzyko systemowe — dodatkowe obowiązki dot. oceny i ograniczania ryzyka, zgłaszania poważnych incydentów i cyberbezpieczeństwa. Jednym z kryteriów jest skala obliczeń treningowych: przekroczenie 10²⁵ FLOPs skutkuje domniemaniem zdolności dużego oddziaływania (nie jedyna droga kwalifikacji). Dla większości firm korzystających z gotowych modeli ten poziom regulacji nie jest jednak pierwszym punktem analizy — najpierw trzeba ustalić, czy w ogóle ma się status dostawcy GPAI.

GPAI Code of Practice – co właściwie daje przedsiębiorcy?

GPAI Code of Practice nie jest rozporządzeniem ani odrębnym źródłem obowiązków prawnych. To dobrowolny kodeks, opublikowany 10 lipca 2025 r., obejmujący trzy obszary: przejrzystość, prawa autorskie, bezpieczeństwo i ochronę. Pierwsze dwa dotyczą dostawców GPAI, trzeci — przede wszystkim dostawców modeli o ryzyku systemowym.

Stosowanie kodeksu może ułatwić wykazanie zgodności z AI Act (Komisja i Rada ds. AI uznały go za odpowiednie narzędzie), ale brak jego stosowania nie oznacza automatycznie naruszenia — dostawca musi wtedy wykazać zgodność inaczej. W praktyce: AI Act określa obowiązki, Code of Practice wskazuje jak je spełnić.

Prawa autorskie: sam Code of Practice nie rozwiązuje problemu

AI Act nakłada obowiązek wdrożenia polityki zgodności z prawem autorskim. Stosowanie kodeksu nie daje jednak „certyfikatu bezpieczeństwa” w tym zakresie.

Dobrym przykładem jest niemiecka sprawa GEMA przeciwko OpenAI. W listopadzie 2025 r. Sąd Krajowy w Monachium I uznał, że memorowanie chronionych utworów przez model językowy może stanowić ich zwielokrotnienie, a proste prompty prowadzące do odtworzenia utworów mogą naruszać prawa autorskie; wyjątek TDM nie obejmował samego memorowania. To wyrok I instancji dotyczący konkretnych utworów — nie oznacza, że każde trenowanie na danych z internetu jest niezgodne z prawem. Praktyczny wniosek: pochodzenie danych treningowych i sposób ich wykorzystania trzeba uwzględniać przy zarządzaniu ryzykiem prawnym.

Co to oznacza dla firmy, która kupuje AI od zewnętrznego dostawcy?

Korzystanie z rozwiązania zewnętrznego dostawcy nie oznacza przejęcia jego obowiązków jako dostawcy modelu — ale warto sprawdzić, co gwarantuje umowa: informacje o modelu i ograniczeniach, zmiany modelu, prawa do danych, odpowiedzialność za naruszenia IP, bezpieczeństwo danych, zgłaszanie incydentów, dostępność dokumentacji AI Act, zasady wykorzystania danych klienta do dalszego trenowania.

Co przedsiębiorca powinien sprawdzić? (checklista)

• Z czego dokładnie korzystamy — gotowy model, własny, czy hybryda?
• Co sami stworzyliśmy — tylko API, czy modyfikacja/trening?
• Czy udostępniamy dalej zmodyfikowany model?
• Czy nasza firma może być dostawcą GPAI (art. 53)?
• Czy model jest open source (warunki wyjątku z art. 53 ust. 2)?
• Czy model może stwarzać ryzyko systemowe (art. 51, próg 10²⁵ FLOPs)?
• Czy dokumentacja modelu jest kompletna?
• Czy podmioty korzystające z modelu otrzymują odpowiednie informacje?
• Czy istnieje polityka dot. praw autorskich?
• Czy opublikowano wymagane podsumowanie treści treningowych?
• Od kiedy stosuje się obowiązki dotyczące modeli GPAI?

Obowiązki stosuje się od 2 sierpnia 2025 r. Od 2 sierpnia 2026 r. Komisja ma uprawnienia egzekucyjne (w tym kary). Dla modeli wprowadzonych do obrotu przed 2.08.2025 termin dostosowania to 2 sierpnia 2027 r. Digital Omnibus zmienił harmonogram głównie dla systemów wysokiego ryzyka (nie GPAI) — podstawowy termin dla obowiązków GPAI się nie zmienił.

Jak wysokie mogą być kary?

Do 3% całkowitego rocznego światowego obrotu z poprzedniego roku albo 15 mln euro — w zależności co wyższe (art. 101 AI Act). Kary dot. m.in. naruszenia obowiązków, niewykonania żądania dokumentów/informacji, niewykonania działań wymaganych przez Komisję. Wysokość zależy od okoliczności, nie jest automatycznie maksymalna.

GPAI Code of Practice nie jest regulaminem obowiązkowym dla każdej firmy korzystającej z AI. Najpierw trzeba ustalić rolę firmy wobec konkretnego modelu. Samo korzystanie z ChatGPT/Claude, API czy RAG nie czyni firmy dostawcą GPAI — inaczej może być przy samodzielnym opracowaniu, istotnej modyfikacji lub dalszym udostępnianiu. Code of Practice ułatwia wykazanie zgodności, ale nie zastępuje AI Act.