Streszczenie AI
Rozporządzenie EU AI Act jasno definiuje modele ogólnego przeznaczenia (GPAI), klasyfikując je według mocy obliczeniowej i określając obowiązki dawcy (provider) oraz wdrażającego (deployer), od szczegółowej dokumentacji technicznej po audity i ścisłą zgodność z przepisami prawnymi. Od 2 sierpnia 2026 r. obowiązują wymogi przejrzystości – użytkownicy muszą wiedzieć, że interakcja z AI, a generowane treści muszą być oznaczone, a systemy wysokiego ryzyka podlegają szczegółowym testom i rejestracji w AI Office. Wdrażanie wymaga kolejnych nakładów technicznych: filtrowanie danych, logging, zero‑retention oraz jasno określonych umów B2B, które zabezpieczają zarówno kwestie bezpieczeństwa, jak i ochrony danych.
Spis treści:
- Wprowadzenie
- Klasyfikacja GPAI i progi obliczeniowe w świetle AI Act
- Role w łańcuchu wartości: Provider, Deployer, Użytkownik
- Obowiązki deployera korzystającego z zewnętrznych API
- Architektura techniczna: logowanie, sanityzacja danych i polityka API
- Audyt umów B2B z dostawcami LLM (OpenAI, Anthropic, Google Cloud)
- Praktyczny plan wdrożenia dla zespołów IT i Product Managementu
- Źródła
Wprowadzenie
Rozporządzenie EU AI Act ustanawia precyzyjne ramy prawne dla modeli sztucznej inteligencji ogólnego przeznaczenia (GPAI – General-Purpose AI), wykorzystywanych w modelach takich jak GPT-4o, Claude 3.5/3.7, Gemini 1.5/2.0 czy Llama 3. Dla podmiotów integrujących zewnętrzne API kluczowy jest podział odpowiedzialności pomiędzy dostawcę bazowego fundamentu (provider) a podmiot wdrażający go w aplikacji (deployer). Od 2 sierpnia 2026 r. obowiązują już w pełni unijne uprawnienia egzekucyjne Europejskiego Biura ds. AI (AI Office) oraz bezpośrednie wymogi dotyczące przejrzystości interakcji i oznaczania wygenerowanych treści.
Klasyfikacja GPAI i progi obliczeniowe w świetle AI Act
Zgodnie z art. 3 pkt 63 AI Act, model GPAI to model AI charakteryzujący się znaczną ogólnością, zdolny do kompetentnego wykonywania szerokiego zakresu odrębnych zadań oraz dający się zintegrować z wieloma downstream aplikacjami. Reżim prawny dzieli te modele na dwie podstawowe grupy w oparciu o ich moc obliczeniową oraz potencjalny wpływ rynkowy:
Kategoria modelu | Kryterium techniczne | Kluczowe obowiązki prawne | Przykłady modeli |
|---|---|---|---|
| Standardowy model GPAI | Model ogólnego przeznaczenia trenowany poniżej progu 1025 FLOPs | Dokumentacja techniczna, podsumowanie danych treningowych, polityka prawa autorskiego (Copyright Policy), udostępnienie specyfikacji dla deployerów. | Mniejsze modele open-weights, wyspecjalizowane wersje SLM/LLM. |
| GPAI z ryzykiem systemowym (GPAI-SR) | Moc obliczeniowa treningu > 1025 FLOPs lub decyzja AI Office | Wszystkie wymogi standardowe + ewaluacja modeli (red-teaming), ocena i mitygacja ryzyk systemowych, raportowanie incydentów krytycznych, podwyższony poziom cyberbezpieczeństwa. | GPT-4o, Claude 3.5 Sonnet / Opus, Gemini 1.5 Pro / 2.0 Ultra. |
Wszystkie wiodące komercyjne interfejsy API oferowane przez OpenAI, Anthropic, Google oraz Microsoft Azure podlegają pod rygorystyczne wytyczne unijnego Kodeksu Praktyki GPAI (Code of Practice), zatwierdzonego pod auspicjami AI Office jako narzędzie weryfikacji zgodności z art. 53 i 55 AI Act.
Role w łańcuchu wartości: Provider, Deployer, Użytkownik
Prawidłowe przypisanie roli w ekosystemie AI determinuje bezpośredni zakres odpowiedzialności prawnej i technicznej:
- Provider (Dostawca): Podmiot, który opracowuje lub zleca opracowanie modelu/systemu AI i wprowadza go na rynek lub oddaje do użytku pod własną nazwą lub znakiem towarowym. W przypadku wywołań API są to m.in. OpenAI, Anthropic, Google lub AWS. Provider odpowiada za bezpieczeństwo samego modelu bazowego, jego ewaluację oraz dostarczenie dokumentacji technicznej downstream integratorom.
- Deployer (Wdrażający): Osoba fizyczna lub prawna, organ publiczny bądź agencja, która wykorzystuje system AI pod swoją jurysdykcją w ramach działalności zawodowej. Firma SaaS integrująca API GPT-4 czy Claude w swoim systemie CRM lub aplikacji analitycznej działa jako Deployer i odpowiada za cel użycia, filtrowanie danych wejściowych, interfejs oraz zgodność operacyjną.
- Użytkownik końcowy / Podmiot dotknięty: Osoba wchodząca w bezpośrednią interakcję z gotową aplikacją (np. klient czatu, pracownik). Jeśli klient B2B kupuje system SaaS i modyfikuje jego działanie lub integruje go we własnych procesach decyzyjnych, sam może wejść w reżim deployera, co wymaga precyzyjnego uregulowania w SLA i umowach powierzenia.
Obowiązki deployera korzystającego z zewnętrznych API
Firmy, które budują rozwiązania bazujące na zewnętrznych modelach GPAI, nie mogą polegać wyłącznie na deklaracjach providera. Od 2 sierpnia 2026 r. obowiązują bezpośrednie wymogi w zakresie przejrzystości (art. 50 AI Act):
- Obowiązek informacyjny (Art. 50 ust. 1): Deployer musi zapewnić, że osoby fizyczne są jednoznacznie informowane o interakcji z systemem AI w czasie rzeczywistym, chyba że wynika to wprost z okoliczności i kontekstu użycia.
- Oznaczanie treści syntetycznych i deepfake (Art. 50 ust. 2 i 4): Treści generowane (audio, wideo, fotorealistyczne obrazy lub teksty publikowane w celach informacyjnych) muszą być oznaczone w formacie odczytywalnym maszynowo oraz w sposób widoczny dla odbiorcy jako wygenerowane przez sztuczną inteligencję.
- Weryfikacja klasyfikacji ryzyka (Annex III): Wdrożenia AI w obszarach takich jak rekrutacja (screening CV), scoring kredytowy, ocena ryzyka ubezpieczeniowego czy infrastruktura krytyczna podlegają rygorystycznym wymogom dla systemów wysokiego ryzyka (High-Risk AI Systems). Zgodnie z unijnym harmonogramem, pełne wymogi certyfikacji i zgodności dla systemów standalone z Załącznika III zaczną obowiązywać od 2 grudnia 2027 r., lecz deployerzy muszą już teraz rejestrować architekturę i gromadzić dokumentację.
- AI Literacy (Art. 4): Wymóg zapewnienia odpowiedniego poziomu kompetencji personelu zajmującego się obsługą i nadzorem systemów AI w organizacji.
Architektura techniczna: logowanie, sanityzacja danych i polityka API
Zgodność z AI Act wymaga wdrożenia konkretnych mechanizmów na poziomie architektury backendowej integracji API. Kluczowe obszary inżynierii danych obejmują:
- Bramka pośrednicząca (API Gateway / Proxy LLM): Wdrożenie warstwy pośredniczącej przed wysłaniem promptu do providera, realizującej automatyczną anonimizację, usuwanie numerów PESEL/identyfikatorów oraz detekcję danych wrażliwych (PII).
- Niezależne rejestrowanie zdarzeń (Audit Logging): Przechowywanie zrzutów prompt/completion, identyfikatorów wersji modeli, parametrów inferencji (temperature, top_p) oraz metadanych czasowych w bezpiecznym, niezmiennym repozytorium logów (zgodnie z RODO i retencją danych).
- Konfiguracja Zero-Data Retention i No-Training: Egzekwowanie w wywołaniach API (lub umowach Enterprise) parametrów wykluczających wykorzystywanie danych wejściowych i wyjściowych do ponownego dotrenowywania modeli przez OpenAI, Anthropic czy Google.
- Mechanizmy Human-in-the-Loop (HITL): Implementacja interfejsów walidacji i akceptacji wyników generowanych przez model przed wykonaniem akcji w zewnętrznych bazach danych lub systemach transakcyjnych.
Audyt umów B2B z dostawcami LLM (OpenAI, Anthropic, Google Cloud)
Poleganie na standardowych konsumenckich regulaminach (Terms of Service) stanowi istotne ryzyko prawne. Kontrakty biznesowe (Enterprise Agreement, BAA, DPA) powinny gwarantować:
- Dostęp do Technical Documentation Pack: Zobowiązanie providera do dostarczania aktualnej dokumentacji modelu (architektura, ograniczenia, ewaluacja stronniczości, data cutoff) na potrzeby audytów deployera.
- Procedury powiadamiania o incydentach: Jasny czas reakcji i obowiązek informowania deployera o incydentach bezpieczeństwa, anomalnych zachowaniach modelu lub podatnościach na jailbreak w warstwie API.
- SLA i gwarancje wersjonowania: Zabezpieczenie przed nagłym wycofaniem lub niekontrolowaną zmianą zachowania wersji modelu (tzw. model drift), która mogłaby zaburzyć procedury zgodności w środowisku produkcyjnym.
Praktyczny plan wdrożenia dla zespołów IT i Product Managementu
Aby zachować pełną zgodność operacyjną, organizacje powinny zrealizować następującą listę kontrolną:
- 01Inwentaryzacja modeli i wywołań API: Identyfikacja wszystkich punktów styku z LLM w ekosystemie aplikacyjnym, w tym narzędzi wewnętrznych wykorzystywanych przez zespoły programistyczne.
- 02Wdrożenie etykietowania UI/UX: Wprowadzenie w interfejsach użytkownika czytelnych oznaczeń informujących o generowaniu odpowiedzi przez sztuczną inteligencję oraz dodanie znaków wodnych / metadanych w wygenerowanych plikach multimedialnych.
- 03Klasyfikacja danych (AI Data Classification): Utworzenie formalnych reguł określających, jakie kategorie danych (publiczne, wewnętrzne, poufne, PII) mogą być przesyłane do poszczególnych endpointów API.
- 04Weryfikacja pakietów dokumentacji GPAI: Pobranie i zarchiwizowanie kart modeli (System Cards / Model Cards) udostępnionych przez dostawców API dla wykorzystywanych wersji silników.
- 05Przegląd procedur bezpieczeństwa i RODO: Sprawdzenie aktualności umów powierzenia przetwarzania danych (DPA) pod kątem transferów transgranicznych i braku retencji promptów do celów szkoleniowych.
