GPAI w praktyce – co zmienia AI Act dla firm używających ChatGPT, Claude i Gemini?

Wprowadzenie

EU AI Act wprowadza odrębny reżim dla tzw. general-purpose AI models (GPAI), czyli dużych modeli ogólnego przeznaczenia używanych m.in. przez ChatGPT, Claude i Gemini. Dla firm, które po prostu „wołają API” tych dostawców, najważniejsze są nowe obowiązki deployera oraz to, jak umowy z OpenAI, Anthropic i Google pomagają (albo utrudniają) te obowiązki wypełnić.

Od 2 sierpnia 2025 r. wchodzą w życie obowiązki dla providerów modeli GPAI, a od sierpnia 2026 r. w pełni egzekwowane są sankcje za naruszenia, co oznacza, że 2026 jest rokiem realnej implementacji tych wymogów w produktach i kontraktach.

Co to jest GPAI według AI Act

AI Act definiuje general-purpose AI model jako model o „znacznej ogólności”, zdolny do kompetentnego wykonywania szerokiego zakresu różnych zadań oraz możliwy do wykorzystania w wielu downstream systemach i aplikacjach. W praktyce chodzi o duże modele trenowane na ogromnych zbiorach danych, często w trybie self-supervision, które potrafią generować tekst, obrazy lub audio, tłumaczyć, streszczać, odpowiadać na pytania itd.

W dokumentach wdrożeniowych Komisji Europejskiej przyjmuje się, że modele trenowane z użyciem mocy obliczeniowej powyżej 10²³ FLOPs i generujące treści (tekst, obrazy, audio) domyślnie traktuje się jako GPAI, a przy 10²⁵ FLOPs mówimy o modelach z „systemic risk”, objętych dodatkowymi obowiązkami. Do tej kategorii zaliczają się współczesne komercyjne API, m.in. GPT‑4/4o, Claude, Gemini 1.5/2.0 oraz modele oferowane przez Azure OpenAI.

Provider vs deployer vs użytkownik – kluczowe role

AI Act rozróżnia kilka ról: w uproszczeniu provider, deployer oraz użytkownik końcowy. Zrozumienie, kim jesteś w danym scenariuszu, determinuje listę obowiązków – inaczej odpowiada OpenAI czy Google, a inaczej SaaS, który „wbudowuje” te API w swój produkt.

Provider (dostawca modelu)

Provider to podmiot, który rozwija model lub zleca jego rozwój i wprowadza go na rynek pod własnym imieniem lub znakiem towarowym – odpłatnie lub bezpłatnie. W kontekście ChatGPT, Claude i Gemini providerem są odpowiednio OpenAI, Anthropic i Google, bo to oni trenują model GPAI i udostępniają go przez API lub własne aplikacje.

Deployer (wdrażający system AI)

Deployer to podmiot, który używa systemu AI „pod swoją władzą”, z wyłączeniem czysto prywatnego, nieprofesjonalnego użycia. Jeżeli Twoja firma buduje produkt, który korzysta z OpenAI/Anthropic/Google przez API, to właśnie Ty jesteś deployerem – to Ty decydujesz o celu użycia, danych wejściowych, integracji z innymi systemami oraz o tym, jak wynik trafi do użytkownika końcowego.

Użytkownik końcowy

Użytkownik końcowy to klient lub pracownik, który korzysta z Twojego systemu (np. chatbota na stronie), ale nie ma bezpośredniego stosunku umownego z providerem GPAI. W relacji B2B może się zdarzyć, że Twój klient sam staje się deployerem, jeśli dalej integruje model lub Twój system w swoich aplikacjach, co wymaga jasnego uregulowania ról w umowach.

Obowiązki providerów GPAI – na czym możesz się oprzeć

Providerzy GPAI mają własny katalog obowiązków w rozdziale AI Act poświęconym general-purpose AI, w tym wymogi przejrzystości, dokumentacji technicznej, bezpieczeństwa oraz zarządzania ryzykiem (szczególnie dla modeli z ryzykiem systemowym). Komisja przyjęła wytyczne i Code of Practice dla providerów GPAI, które mają pokazać, jak spełniać te obowiązki w praktyce.

Providerzy muszą m.in. udokumentować charakterystykę modelu, ograniczenia, znane ryzyka i parametry wydajności, a także wdrożyć polityki zgodności z prawem autorskim oraz – dla modeli z ryzykiem systemowym – dodatkowe mechanizmy monitorowania i redukcji ryzyka. Część tej dokumentacji powinna być udostępniana downstream deployerom, ponieważ to na niej opierasz własną analizę ryzyka i obowiązki informacyjne wobec użytkowników.

Co musi zrobić deployer używający ChatGPT, Claude lub Gemini przez API

Dla typowej firmy SaaS, która „tylko” wywołuje API OpenAI/Anthropic/Google, kluczową rolą jest deployer – a obowiązki zależą od tego, czy Twoje zastosowanie wchodzi w katalog high-risk, czy pozostaje w kategoriach ograniczonego ryzyka. Większość zastosowań typu asystent tekstowy, generowanie draftów, podpowiedzi w aplikacjach biznesowych będzie klasyfikowana jako niższy poziom ryzyka, ale wciąż objęta wymogami przejrzystości i oznaczania treści generowanych przez AI.

Dla deployera kluczowe są m.in. następujące obowiązki:

• informowanie użytkowników, że wchodzą w interakcję z systemem AI, chyba że jest to oczywiste z kontekstu (np. wyraźny „AI assistant” w interfejsie);
• oznakowanie treści generowanych lub modyfikowanych przez AI – szczególnie tam, gdzie mogą być uznane za „synthetic / deepfake content”;
• zapewnienie, że zastosowanie systemu AI jest zgodne z prawem, w tym RODO, prawem pracy, konsumenckim i własności intelektualnej;
• w przypadku zastosowań high‑risk (np. scoring kredytowy, rekrutacja) – wdrożenie systemu zarządzania ryzykiem, human oversight, monitorowanie działania systemu, logowanie oraz raportowanie poważnych incydentów.

Część obowiązków (logi, monitorowanie, analiza incydentów) w praktyce zależy od tego, jak skonfigurujesz integrację z API – czy przechowujesz wyniki i prompt, czy masz własne logi, czy korzystasz z narzędzi takich jak Vertex AI z wbudowanym loggingiem.

API a architektura, logi i dane – na co uważać technicznie

AI Act nie mówi wprost, jak zaprojektować architekturę systemu, ale pewne wymagania (np. logowanie, monitorowanie, możliwość wyjaśnienia decyzji w przypadku high‑risk) wymuszają konkretne decyzje techniczne. Jeśli liczysz, że „całą odpowiedzialność weźmie na siebie provider API”, najprawdopodobniej będziesz miał problem z wykazaniem zgodności przy audycie lub incydencie.

Przy projektowaniu integracji z API warto po stronie deployera zadbać co najmniej o:

• rejestrowanie kluczowych interakcji (prompt, output, metadane) w sposób umożliwiający analizę błędów i incydentów, z uwzględnieniem RODO i minimalizacji danych.
• klasyfikację danych, które wolno wysyłać do ChatGPT/Claude/Gemini (np. zakaz wysyłania wrażliwych danych osobowych, jeśli nie masz podstawy prawnej i odpowiednich zabezpieczeń).
• mechanizmy sanityzacji danych po stronie aplikacji (maskowanie, pseudonimizacja) zanim trafią do API.
• możliwość wymuszenia konfiguracji „no training” lub równoważnych ustawień, jeśli provider je oferuje, tak aby dane klientów nie były używane do dalszego trenowania modeli bez ich zgody.

W praktyce oznacza to, że zespół techniczny, prawny i bezpieczeństwa musi wspólnie zdefiniować politykę korzystania z API (data classification policy), a następnie egzekwować ją w kodzie, konfiguracji i procesach operacyjnych.

Umowy z OpenAI, Anthropic i Google a AI Act – co sprawdzić

Nawet jeśli provider formalnie odpowiada za swoje obowiązki GPAI, to wiele z Twoich obowiązków jako deployera wymaga od niego dostarczenia konkretnych informacji (dokumentacja, charakterystyka modelu, znane ryzyka, ograniczenia). Dlatego AI Act wymusza de facto nową jakość w relacjach kontraktowych z dostawcami LLM – standardowe „cloudowe” T&Cs często nie są wystarczające.

Przeglądając lub negocjując umowy (Terms of Use, Enterprise Agreement, DPA) z OpenAI, Anthropic czy Google, warto zwrócić uwagę co najmniej na następujące obszary:

1. Rola stron i zakres użycia

Umowa powinna jasno odzwierciedlać, że dostawca pełni rolę provider GPAI, a Twoja firma – deployer używający modelu w określonych celach. W opisie usług (service description) warto dodać referencje do konkretnych modeli (np. GPT‑4o, Claude 3, Gemini 1.5 Pro) oraz typów zadań, dla których są używane.

2. Dokumentacja wymagana przez AI Act

AIActStack i inne opracowania praktyczne rekomendują, aby deployer uzyskał od providera pakiet dokumentów obejmujący m.in.: opis przeznaczenia i ograniczeń modeli, charakterystykę danych treningowych (w wysokim poziomie), metryki jakości i stronniczości, opis architektury oraz wyniki ocen bezpieczeństwa. W umowie warto wprost zobowiązać providera do przekazania takiej dokumentacji oraz aktualizacji przy istotnych zmianach modelu.

3. Zgodność z RODO i wykorzystanie danych do trenowania

Warunki korzystania z usług OpenAI, Anthropic i Google oraz ich dodatki RODO (DPA) regulują sposób przetwarzania danych, retencję oraz to, czy dane klienta mogą być użyte do dalszego treningu modeli. Z perspektywy AI Act ważne jest, byś mógł wykazać, że masz kontrolę nad tym, co dzieje się z danymi przesyłanymi do API oraz że odpowiada to komunikacji wobec Twoich użytkowników (np. w polityce prywatności).

4. Logi, audyt i dostęp do informacji o incydentach

W przypadku zastosowań high‑risk potrzebujesz możliwości udokumentowania działania systemu, analizy incydentów oraz – w razie potrzeby – raportowania do organów. Umowa z providerem powinna więc regulować dostęp do logów, czas ich przechowywania oraz zasady informowania o poważnych incydentach bezpieczeństwa lub zmianach w modelu istotnych dla ryzyka.

5. Odpowiedzialność, gwarancje i SLA

Standardowe T&Cs providerów zwykle bardzo ograniczają odpowiedzialność za błędne lub szkodliwe outputy modeli, co z punktu widzenia AI Act przerzuca ciężar zarządzania ryzykiem na deployera. W kontraktach enterprise warto szukać przynajmniej bardziej precyzyjnych SLA dotyczących dostępności, bezpieczeństwa i wsparcia w audytach, nawet jeśli odpowiedzialność za merytoryczną treść odpowiedzi modelu pozostaje po Twojej stronie.

Praktyczne kroki dla firmy w 2026 r.

Dla większości firm w 2026 r. kluczowe nie będzie „pisanie własnego AI Act”, ale uporządkowanie kilku obszarów wokół istniejących integracji z API GPAI. Dobrym punktem startowym jest krótka mapa zastosowań i ról, a potem iteracyjne domykanie luk w dokumentacji, architekturze i kontraktach.

Przykładowy plan działania:

• Zidentyfikuj wszystkie miejsca, w których Twoje systemy korzystają z ChatGPT, Claude, Gemini lub innych modeli GPAI (w tym „shadow AI” w zespołach).
• Dla każdego zastosowania ustal, czy może wchodzić w zakres high‑risk z załącznika AI Act (np. scoring kredytowy, HR, krytyczne decyzje administracyjne); jeśli tak – zastosuj pełny reżim high‑risk (risk management, human oversight, logi, DPIA).
• Zapewnij podstawowe wymogi przejrzystości: jasne oznaczenie interfejsów AI w produktach, informacja w politykach prywatności i regulaminach oraz oznaczanie treści generowanych przez AI tam, gdzie może to wprowadzać w błąd.
• Poproś providerów (OpenAI, Anthropic, Google) o pakiet dokumentacji zgodny z AI Act – wiele kancelarii i narzędzi compliance publikuje gotowe template’y maili, ale kluczowe jest, abyś rzeczywiście otrzymał i zrozumiał te materiały.
• Przejrzyj istniejące umowy (w tym DPA) pod kątem kwestii opisanych wyżej: role, dokumentacja, logi, incydenty, wykorzystanie danych do trenowania, SLA.
• Ustal wewnętrzną politykę klasyfikacji danych dla AI (jakie typy danych wolno wysyłać do jakich modeli/konfiguracji) i wdroż ją technicznie w kodzie i konfiguracji.
• Przygotuj się na audyty i pytania klientów – szczególnie B2B – którzy sami będą deployerami i będą od Ciebie oczekiwać informacji wymaganych przez AI Act.

W efekcie AI Act staje się dla firm używających ChatGPT, Claude i Gemini mniej „abstrakcyjnym rozporządzeniem UE”, a bardziej konkretną checklistą: wiedzieć, jakiego modelu używasz, w jakim celu, na jakich danych, z jakim ryzykiem, na jakich warunkach kontraktowych i co mówisz o tym swoim użytkownikom.

Źródła

• Article 3: Definitions | EU Artificial Intelligence Act
• Guidelines for providers of general-purpose AI models
• The General-Purpose AI Code of Practice
• EU AI Act: OpenAI, Anthropic & Google Guide | AIActStack
• EU AI Act Obligations for Companies That Use OpenAI, Gemini, or Azure AI APIs
• Provider or Deployer? Decoding the Key Roles in the AI Act
• Chapter IV & V – Obligations for providers of GPAI models
• EU AI Obligations for GPAI Providers: Compliance, Enforcement Deadlines 2025–2027
• OpenAI – Terms of Use
• AI Data Classification: What Is Safe for ChatGPT & Copilot