Obowiązki providera GPAI i co fine-tuning naprawdę wyzwala w unijnym AI Act

by
Dawid Winiarski
Last update:
July 17, 2026

Co obejmuje ten przewodnik

Unijny AI Act nakłada na providerów modeli sztucznej inteligencji ogólnego przeznaczenia (GPAI) odrębny zestaw obowiązków, osobny od zasad dla systemów wysokiego ryzyka, które większość osób czyta w pierwszej kolejności. Te obowiązki znajdują się w Rozdziale V, w artykułach 51-56, i obowiązują od 2 sierpnia 2025 roku. Jeśli korzystasz z modelu wyłącznie przez API, to w dużej mierze problem kogoś innego. Jeśli robisz fine-tuning, retrenujesz albo w inny sposób modyfikujesz model, liczy się pytanie, czy sam stałeś się providerem.

Ten przewodnik jest dla liderów inżynierii, właścicieli AI governance i prawników w firmach, które budują na modelach fundamentowych. Wyjaśnia, kto liczy się jako provider GPAI, gdzie przebiega granica ryzyka systemowego wyznaczona na poziomie 10^25 operacji zmiennoprzecinkowych, kiedy fine-tuning przechodzi z niegroźnej customizacji w status providera, oraz jakie konkretne obowiązki dotyczące praw autorskich i przejrzystości się z tym wiążą. Odróżnia obowiązujące prawo od wytycznych AI Office, które je interpretują, i zaznacza, gdzie tekst prawny jest wciąż niejasny.

Na koniec powinieneś umieć spojrzeć na projekt modyfikacji modelu i wyrobić sobie obronne stanowisko co do tego, czy dotyczą Cię artykuły 53-55, i co musiałbyś wtedy wyprodukować.

  • Obowiązki providera GPAI z artykułów 53-55 obowiązują od 2 sierpnia 2025. Własne uprawnienia egzekucyjne Komisji Europejskiej i kary dla providerów GPAI zaczynają obowiązywać 2 sierpnia 2026, a modele wprowadzone na rynek przed 2 sierpnia 2025 muszą osiągnąć zgodność do 2 sierpnia 2027 (European Commission, Guidelines for providers of GPAI models).
  • Większość firm, które budują na modelu przez prompting, retrieval-augmented generation albo custom GPT, to downstream providerzy systemu AI, a nie providerzy modelu GPAI, i nie dziedziczą obowiązków z artykułu 53 (artificialintelligenceact.eu, Modifying AI Under the EU AI Act).
  • Fine-tuning może zrobić z Ciebie providera GPAI, ale tylko przy istotnych modyfikacjach. Orientacyjny próg AI Office to modyfikacja wykorzystująca co najmniej jedną trzecią mocy obliczeniowej pierwotnie użytej do wytrenowania modelu, co przy obecnych progach daje około 3 x 10^21 FLOP. To kryterium orientacyjne, nie sztywna granica (AI Office GPAI Guidelines, via artificialintelligenceact.eu).
  • Tam, gdzie faktycznie stajesz się providerem przez modyfikację, Twoje obowiązki ograniczają się do samej modyfikacji, nie do całego modelu źródłowego (Recital 109; European Commission GPAI FAQ).
  • Zakłada się, że model GPAI niesie ryzyko systemowe, gdy skumulowana moc obliczeniowa treningu przekracza 10^25 FLOP (artykuł 51 ust. 2). Modele z ryzykiem systemowym ściągają na siebie cięższe obowiązki z artykułu 55: ewaluację modelu i testy adwersarialne, ograniczanie ryzyka systemowego, raportowanie poważnych incydentów do AI Office oraz odpowiedni poziom cyberbezpieczeństwa.
  • Podstawowe obowiązki z artykułu 53 to dokumentacja techniczna (Annex XI), informacje dla podmiotów downstream (Annex XII), unijna polityka praw autorskich respektująca opt-out z text-and-data-mining oraz publiczne podsumowanie treści treningowych na szablonie AI Office.

Gdzie w AI Act znajdują się obowiązki GPAI

AI Act reguluje dwie różne rzeczy: systemy AI, podzielone na poziomy zakazane, wysokiego ryzyka, ograniczonego ryzyka i minimalnego ryzyka, oraz modele sztucznej inteligencji ogólnego przeznaczenia, regulowane osobno w Rozdziale V. Model GPAI to leżący u podstaw model, na przykład duży model językowy, który da się dostosować do wielu zadań. System AI to produkt zbudowany wokół niego.

Ten podział ma znaczenie, bo obowiązki i harmonogram się różnią. Zasady dla modeli GPAI z artykułów 51-56 zaczęły obowiązywać od 2 sierpnia 2025, dwanaście miesięcy po wejściu AI Act w życie (artykuł 113). Uprawnienia Komisji do egzekwowania tych zasad wobec providerów GPAI, w tym nakładania kar, zaczynają się rok później, 2 sierpnia 2026, a providerzy, których modele były już na rynku przed 2 sierpnia 2025, mają czas na zgodność do 2 sierpnia 2027 (European Commission, Guidelines for providers of GPAI models).

Role w łańcuchu wartości pochodzą z artykułu 3: provider, deployer, importer, dystrybutor. Provider rozwija model albo system, albo zleca jego rozwój, i wprowadza go na rynek albo oddaje do użytku pod własną nazwą. Całe pytanie dla firmy, która robi fine-tuning, brzmi: czy jej modyfikacja zmieniła ją z deployera albo downstream integratora w providera.

Kto jest providerem GPAI, a kto nie

Komisja jasno powiedziała, że spodziewa się, iż tylko niewielka liczba podmiotów downstream stanie się providerami modeli GPAI (artificialintelligenceact.eu, Modifying AI Under the EU AI Act). Typowe wzorce, które nie wyzwalają statusu providera:

  • Wywoływanie modelu przez API. Jesteś deployerem albo providerem systemu, który wokół niego budujesz, nie providerem modelu.
  • Prompt engineering i prompty systemowe. Dostosowywanie instrukcji nie modyfikuje modelu.
  • Retrieval-augmented generation. Osadzanie modelu we własnych dokumentach w czasie inferencji nie zmienia samego modelu.
  • Custom GPT-y i podobne skonfigurowane warianty. Konfiguracja z instrukcjami i narzędziami to nie trening.
  • Dostosowywanie hiperparametrów, na przykład temperature. To zmienia zachowanie w czasie działania, nie parametry modelu.

W każdym z tych przypadków nadal możesz być downstream providerem systemu AI w rozumieniu artykułu 3 ust. 68, co może wiązać się z własnymi obowiązkami wysokiego ryzyka albo przejrzystości, zależnie od zastosowania. Czego nie dziedziczysz, to zestaw obowiązków providera modelu GPAI. Przykład z praktyki: firma IT, która orkiestrowała chatboty GPT-4 pod własną marką, używając wyłącznie promptów i RAG, została oceniona jako downstream provider, a nie provider modelu GPAI, bo jej modyfikacje nie zmieniały istotnie ryzyka modelu (artificialintelligenceact.eu, Modifying AI Under the EU AI Act).

Kiedy fine-tuning robi z Ciebie providera

Fine-tuning to przypadek, który AI Act wyodrębnia. Recital 109 i wytyczne AI Office dotyczące GPAI traktują trenowanie modelu na dodatkowych danych jako rodzaj modyfikacji, który może przenieść obowiązki providera na modyfikującego. O tym, czy tak się dzieje, decydują dwie rzeczy: jak istotna jest zmiana i ile mocy obliczeniowej pochłonęła.

Próg jednej trzeciej mocy obliczeniowej

Wytyczne AI Office wprowadzają test orientacyjny: jeśli modyfikacja wykorzystuje co najmniej jedną trzecią mocy obliczeniowej pierwotnie potrzebnej do wytrenowania modelu, zakłada się, że modyfikujący stał się providerem powstałego modelu. Przy obecnym założeniu, że model jest GPAI od poziomu mniej więcej 10^23 FLOP mocy obliczeniowej treningu, jedna trzecia tej wartości daje około 3 x 10^21 FLOP (artificialintelligenceact.eu, Modifying AI Under the EU AI Act).

Do tej liczby dochodzą dwa zastrzeżenia. Po pierwsze, jest orientacyjna, nie rozstrzygająca. Nadrzędny test, z paragrafu 62 wytycznych, sprawdza, czy modyfikacja istotnie zmienia ogólność, możliwości albo ryzyko systemowe modelu. Zmiana o niskim zużyciu mocy obliczeniowej, która znacząco zmienia zachowanie albo ryzyko, może się wciąż liczyć, i AI Office przyznał to ograniczenie podczas konsultacji. Po drugie, próg jest trudny do zmierzenia w praktyce, bo modyfikujący na poziomie downstream często nie widzą pierwotnej mocy obliczeniowej treningu modelu źródłowego.

Zasada proporcjonalności

Ulga dla modyfikujących znajduje się w Recital 109 i w GPAI FAQ Komisji: tam, gdzie stajesz się providerem przez modyfikację, Twoje obowiązki providera ograniczają się do samej modyfikacji albo fine-tuningu, nie do całego modelu źródłowego. Dokumentujesz i rozliczasz to, co zmieniłeś, nie model bazowy, od którego zacząłeś. W codziennej praktyce obowiązki GPAI dla modyfikującego sprowadzają się do prowadzenia dokumentacji technicznej i podsumowania treści treningowych obejmującego zakres Twojej modyfikacji, co i tak w dużej mierze prowadziłby ostrożny zespół.

Praktyczna postawa

Praktycy opisują dwa obronne podejścia, dopóki standardy nie dojrzeją. Podejście konserwatywne traktuje każdą znaczącą adaptację jako potencjalny wyzwalacz i prowadzi dokumentację modyfikacji niezależnie od okoliczności. Podejście pragmatyczne zakłada, że obowiązki providera GPAI mają zastosowanie tylko tam, gdzie zmiana wyraźnie zmienia zachowanie, ogólność albo ryzyko, albo gdzie osiągnięty jest próg mocy obliczeniowej, i akceptuje, że w razie sporu może to wymagać mocniejszego uzasadnienia (artificialintelligenceact.eu, Modifying AI Under the EU AI Act). Tak czy inaczej, sensownym minimum jest przeprowadzenie oceny ryzyka i wpływu za każdym razem, gdy robisz fine-tuning, i zapisanie wyniku.

Granica ryzyka systemowego na poziomie 10^25 FLOP

Drugi, dużo wyższy próg oddziela zwykłe modele GPAI od modeli GPAI z ryzykiem systemowym. Zgodnie z artykułem 51 ust. 2 zakłada się, że model niesie ryzyko systemowe, gdy skumulowana moc obliczeniowa użyta do jego treningu, mierzona w operacjach zmiennoprzecinkowych, przekracza 10^25 FLOP. Modele w tym przedziale ściągają na siebie cięższe obowiązki z artykułu 55, a ich providerzy muszą powiadomić AI Office (artykuły 51 i 52).

Dla modyfikującego pytanie o ryzyko systemowe pojawia się tylko wtedy, gdy łączna moc obliczeniowa modelu źródłowego plus modyfikacji przekracza 10^25 FLOP. Dla zdecydowanej większości projektów fine-tuningu tak się nie dzieje i artykuł 55 po prostu nie ma zastosowania. Warto wiedzieć, że ta granica istnieje, żeby móc potwierdzić, że jesteś wyraźnie poniżej niej.

Czego naprawdę wymaga artykuł 53

Dla providera zwykłego (nieniosącego ryzyka systemowego) modelu GPAI podstawowe obowiązki z artykułu 53 ust. 1 to:

  • Dokumentacja techniczna · Co to oznacza: Sporządzić i utrzymywać aktualną dokumentację modelu, w tym wyniki treningu, testów i ewaluacji, co najmniej w zakresie elementów z Annex XI, dostępną dla AI Office i organów krajowych na żądanie · Źródło: Art. 53(1)(a), Annex XI
  • Informacje dla downstream · Co to oznacza: Udostępnić informacje i dokumentację, żeby providerzy integrujący model mogli zrozumieć jego możliwości i ograniczenia oraz spełnić własne obowiązki, co najmniej w zakresie elementów z Annex XII · Źródło: Art. 53(1)(b), Annex XII
  • Polityka praw autorskich · Co to oznacza: Wdrożyć politykę zgodności z unijnym prawem autorskim, w szczególności identyfikowania i respektowania zastrzeżenia praw do text-and-data-mining na mocy artykułu 4 ust. 3 dyrektywy (UE) 2019/790 · Źródło: Art. 53(1)(c)
  • Podsumowanie treści treningowych · Co to oznacza: Sporządzić i opublikować wystarczająco szczegółowe podsumowanie treści użytych do treningu, na szablonie udostępnionym przez AI Office · Źródło: Art. 53(1)(d)

Znaczenie mają dwa wyłączenia. Obowiązki dokumentacji technicznej i informacji dla downstream z punktów (a) i (b) nie mają zastosowania do modeli wydanych na naprawdę wolnej licencji open source, która publicznie udostępnia parametry, wagi, architekturę i informacje o użyciu, z wyjątkiem sytuacji, gdy model niesie ryzyko systemowe (artykuł 53 ust. 2). Obowiązki dotyczące praw autorskich i podsumowania treści treningowych nadal obowiązują modele otwarte. Providerzy mogą opierać się na General-Purpose AI Code of Practice, żeby wykazać zgodność do czasu opublikowania zharmonizowanej normy (artykuł 53 ust. 4); Code jest dobrowolny, a wśród sygnatariuszy są najwięksi providerzy modeli.

Co artykuł 55 dokłada dla modeli z ryzykiem systemowym

Poza artykułami 53 i 54, provider modelu GPAI z ryzykiem systemowym musi, zgodnie z artykułem 55:

  • Przeprowadzać ewaluację modelu przy użyciu ustandaryzowanych protokołów i narzędzi, w tym testów adwersarialnych, żeby identyfikować i ograniczać ryzyka systemowe.
  • Oceniać i ograniczać możliwe ryzyka systemowe na poziomie Unii, w tym ich źródła.
  • Śledzić, dokumentować i zgłaszać poważne incydenty oraz możliwe działania naprawcze do AI Office oraz, tam gdzie to istotne, do organów krajowych, bez nieuzasadnionej zwłoki.
  • Zapewnić odpowiedni poziom ochrony cyberbezpieczeństwa modelu i jego infrastruktury fizycznej.

To obowiązki, do operacjonalizacji których napisano General-Purpose AI Code of Practice, i dlatego providerzy z ryzykiem systemowym muszą powiadamiać AI Office i składać dokumenty przez platformę EU SEND (European Commission, Guidelines for providers of GPAI models). Dla większości firm robiących fine-tuning na komercyjnym modelu artykuł 55 nie będzie miał zastosowania, bo są daleko od granicy 10^25 FLOP.

Artykuł 54 i providerzy spoza UE

Jeśli provider modelu GPAI ma siedzibę poza Unią, artykuł 54 wymaga od niego wyznaczenia upoważnionego przedstawiciela w UE przed wprowadzeniem modelu na rynek. Przedstawiciel weryfikuje istnienie dokumentacji technicznej z artykułu 53, utrzymuje jej kopię dostępną dla AI Office przez dziesięć lat od wprowadzenia modelu na rynek i współpracuje z AI Office. Ma to znaczenie głównie dla deweloperów modeli spoza UE, ale firma spoza UE, która fine-tuningiem wchodzi w status providera, powinna wiedzieć, że ten obowiązek istnieje.

Jak to się łączy z prawami autorskimi i danymi treningowymi

Obowiązek dotyczący praw autorskich z artykułu 53 ust. 1 lit. c najczęściej wypływa w przeglądzie dostawców albo data governance. Wymaga od providera posiadania polityki respektującej unijne prawo autorskie, a konkretnie opt-out (zastrzeżenie praw), które posiadacze praw mogą wyrazić na mocy wyjątku text-and-data-mining z dyrektywy o prawie autorskim z 2019 roku. Obok niego stoi podsumowanie treści treningowych z artykułu 53 ust. 1 lit. d: publiczny, oparty na szablonie opis tego, na czym trenowano model. Razem stanowią główną dźwignię AI Act w kwestii tego, skąd pochodzą i jak są ujawniane dane treningowe. Jeśli robisz fine-tuning na własnych danych, Twoje dodatkowe podsumowanie obejmuje te dane; jeśli robisz fine-tuning na zescrapowanych albo licencjonowanych danych podmiotów trzecich, to właśnie w polityce praw autorskich to rozliczasz.

Źródła

  • European Commission, Guidelines for providers of general-purpose AI models · https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers (obowiązki GPAI od 2 sierpnia 2025; egzekwowanie i kary od 2 sierpnia 2026; modele sprzed 2 sierpnia 2025 zgodne do 2 sierpnia 2027; zgłoszenia przez EU SEND; powiadomienie o ryzyku systemowym)
  • artificialintelligenceact.eu, Article 53: Obligations for Providers of General-Purpose AI Models · https://artificialintelligenceact.eu/article/53/ (pełny tekst artykułu 53, Annex XI i XII, polityka praw autorskich, podsumowanie treści treningowych, wyłączenie dla open source, Code of Practice; wejście w życie 2 sierpnia 2025)
  • artificialintelligenceact.eu, Modifying AI Under the EU AI Act · https://artificialintelligenceact.eu/modifying-ai-under-the-eu-ai-act/ (próg jednej trzeciej mocy obliczeniowej, ~3 x 10^21 FLOP, orientacyjny a nie rozstrzygający, downstream provider a provider GPAI, proporcjonalność z Recital 109, przypadki z praktyki)
  • artificialintelligenceact.eu, Article 55: Obligations for Providers of GPAI Models with Systemic Risk · https://artificialintelligenceact.eu/article/55/ (ewaluacja modelu i testy adwersarialne, ograniczanie ryzyka systemowego, raportowanie poważnych incydentów, cyberbezpieczeństwo)
  • European Commission, General-Purpose AI Models in the AI Act — Questions and Answers · https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers (obowiązki providera ograniczone do modyfikacji; zakres zasad GPAI)
  • Regulation (EU) 2024/1689 (EU AI Act), Articles 51 to 56 and Recital 109 · https://artificialintelligenceact.eu/the-act/ (próg ryzyka systemowego 10^25 FLOP w art. 51 ust. 2; role w art. 3; proporcjonalność w Recital 109)
Subscribe to unshadowed.

Subscribe to receive the latest blog posts to your inbox and stay up to date with

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

let's start with a conversation

Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.

Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.

We'll take it from there

Julian Machowski
Head of Technical Sales
+48 783 762 997
julian@unshadowit.com
Let's connect on LinkedIn
Message received. We'll be in touch soon.
Something failed. Try again or call us directly.