GPAI obligations dla EU SMB SaaS

Większość artykułów o EU AI Act skupia się na high-risk Annex III. Tymczasem dla EU SMB SaaS który używa GPT-4, Claude, Gemini lub Mistral API — to GPAI (general-purpose AI) obligations są codziennością. Q3-Q4 2026 = okno enforcement dla GPAI providers, ale obowiązki deployerów (czyli Wasze) zaczęły się 02 sierpnia 2025. Tak — rok temu.

Czym właściwie jest GPAI?

EU AI Act definiuje GPAI w Art. 3(63) jako "AI model... that displays significant generality and is capable of competently performing a wide range of distinct tasks". W praktyce: foundation model trenowany na masywnym datasecie z capability cross-domain. LLM (GPT, Claude, Llama), vision-language models (CLIP, DALL-E), multimodal (Gemini, GPT-4o).

Ważne odróżnienie:

• GPAI model = sam model (weights + architecture)
• GPAI system = produkt który integruje GPAI model (np. ChatGPT, Claude.ai, ale też Twoja aplikacja używająca GPT-4 API)

Reguły Art. 53-55 dotyczą providerów GPAI modeli. Reguły dla GPAI systemów użytych w high-risk use case są w innych miejscach (Art. 25 łańcuch dostaw, Art. 28 obowiązki deployer high-risk).

Provider vs deployer — który jesteś

To jedyne pytanie które ma znaczenie dla SMB. 95% EU SMB SaaS jest deployerem. Jeśli Twoja firma:

• Trenuje własny foundation model z compute > 10²² FLOPs (≈ €1M+ training cost) → Provider GPAI, full Art. 53 obligations
• Trenuje własny model ale < 10²² FLOPs → nie GPAI, regular AI rules apply
• Fine-tunuje GPAI (np. fine-tune Llama 3 na własnych danych) z znaczną modyfikacją → możliwe że jesteś provider derived modelu (Recital 109), wymaga audit
• Używa GPAI API (OpenAI, Anthropic, Mistral, Google) → Deployer GPAI system, light obligations
• Hostuje open-source GPAI (Llama, Mistral) bez modyfikacji w produkcji → możliwe że jesteś distributor (Art. 25), still mostly deployer-tier obligations

Provider obligations (Art. 53)

Jeśli faktycznie jesteś provider GPAI (rzadkie dla SMB, ale możliwe — np. fine-tuning Mistral na własnym datasecie do specyficznej domeny z > 10²² FLOPs lub własny large model trenowany od zera), Art. 53 wymaga 4 rzeczy:

1. Technical documentation (Art. 53(1)(a))

Annex XI EU AI Act wylicza pełną listę. Skrót dla SMB:

• Opis ogólny i intended purpose modelu
• Tasks model jest w stanie wykonywać + capability metrics
• Acceptable use policies (gdzie model NIE powinien być używany)
• Date of release + sposoby distribuowania
• Architektura + liczba parametrów + modality (text / image / audio)
• Procedures for testing + validation results
• Risk management procedures (znane limitations, hallucinations rate, etc.)

Format dokumentacji: dowolny, ale musi być up-to-date i kept for 10 lat post-release.

2. Documentation for downstream providers (Art. 53(1)(b))

Drugi dokument: lighter version technical doc dla firm które będą integrować Twój model w swoje systemy. Ma im pomóc spełnić ich własne Art. 9-15 obligations (jeśli ich system jest high-risk).

Praktycznie: model card w stylu Hugging Face, ale z konkretnymi polami z Art. 53(1)(b): intended use, limitations, evaluation results, training data sources (ogólnie), copyright posture.

3. Copyright policy (Art. 53(1)(c))

Provider musi opublikować policy o przestrzeganiu Union copyright law, zwłaszcza Art. 4 DSM Directive (text-and-data mining opt-out). Po polsku: jeśli text-data minowałeś internet do training i właściciele content opt-out'owali (np. przez robots.txt, ai.txt, headers), Twoja policy musi respektować te opt-outs i opisywać jak to robisz.

To była niezwykle gorąca kwestia w 2025-2026 — większość frontier providers (OpenAI, Anthropic) opublikowała detailed copyright policies, część open-source modeli ma luki (np. Mistral początkowo).

4. Training data summary (Art. 53(1)(d)) — TEN obowiązek najczęściej zaskakuje

Provider musi opublikować "sufficiently detailed summary" o danych użytych do training. Template został opublikowany przez European AI Office w lutym 2025. Wymaga:

• General data sources: publicly available datasets (Common Crawl, Wikipedia, ArXiv), licensed data, user-generated content (z ToS reference), proprietary data
• Modality breakdown: ile text vs image vs audio
• Volume estimates: tokens / images / hours per category (kompletność zapełniona percentages OK)
• Scraping practices: czy respect'ujesz robots.txt, ai.txt, opt-outs
• Languages covered: które European Union languages są represented
• Time period: kiedy data została zebrana

Systemic risk GPAI — threshold 10²⁵ FLOPs (Art. 51)

EU AI Act dzieli GPAI providerów na dwie klasy:

1. Standard GPAI — Art. 53 obligations
2. GPAI z systemic risk — Art. 53 + Art. 55 (additional)

Threshold dla "systemic risk" w Art. 51 = compute użyte do training > 10²⁵ floating-point operations (FLOPs). To bardzo wysoka poprzeczka — w 2026 r. tylko najwięksi providers ją przekraczają (GPT-4o, Claude 3.5 Opus, Gemini 1.5 Ultra, Llama 3.1 405B).

Dla SMB to academic interest, nie practical concern. Nawet duże EU AI startupy (Mistral, Aleph Alpha, Black Forest Labs) mogą lub mogą nie hit'nąć 10²⁵ FLOPs — to ~$50M+ training run.

Art. 55 additional obligations (jeśli jesteś systemic risk provider)

• Model evaluation z standardized protocols (red teaming, adversarial testing)
• Identyfikacja + mitigation systemic risks (CBRN, election manipulation, large-scale fraud)
• Tracking + reporting serious incidents
• Adequate cybersecurity protections dla model weights

Penalties Art. 99(4) — €15M / 3% turnover

Naruszenie obowiązków GPAI przez providera podlega standard non-compliance penalty z Art. 99(4): €15 milionów lub 3% global annual turnover, whichever applies (lower of dla SMB per Art. 99(6), higher of dla non-SME).

Konkretnie: jeśli OpenAI nie publikuje training data summary (Art. 53(1)(d) violation), max kara = max(€15M, 3% × OpenAI revenue ~$3.4B) = ~$102M. Dla solo provider GPAI z €100k revenue = max(€15M, €3k) = €15M absolute, ale per Art. 99(6) lower-of dla SME = €3k.

Dla deployerów: penalty za misuse może padnąć z innych artykułów (np. Art. 50 transparency dla chatbot bez disclosure, Art. 99(4) za high-risk system z GPAI integrated).

Decision tree dla SMB SaaS

┌─ Czy używasz API foundation modelu (OpenAI/Anthropic/Mistral/Google)?
│
├─ TAK → Jesteś DEPLOYER GPAI system
│         Light obligations: ToS compliance, no safety guardrail removal,
│         internal documentation. Pełne obowiązki TYLKO jeśli Twój system
│         wpada w high-risk Annex III — wtedy Art. 9-15 wobec systemu.
│         Sprawdź czy provider opublikował AI Act compliance docs.
│
├─ NIE → Trenujesz własny model?
│        ├─ TAK → Compute > 10²² FLOPs (~€1M+ training cost)?
│        │       ├─ TAK → Jesteś PROVIDER GPAI
│        │       │       Full Art. 53 obligations.
│        │       │       Compute > 10²⁵ FLOPs (~$50M+ training)?
│        │       │       ├─ TAK → + Art. 55 systemic risk obligations
│        │       │       └─ NIE → Standard GPAI (Art. 53 only)
│        │       └─ NIE → NIE jest GPAI. Regular AI rules.
│        │
│        └─ NIE → Fine-tunujesz GPAI z znaczną modyfikacją?
│                ├─ TAK → Możliwe derived model = jesteś provider
│                │        derived modelu. Audit needed.
│                └─ NIE → Pure deployer, light obligations.
└─

Co to znaczy w praktyce dla EU SMB SaaS — 4 scenariusze

Scenariusz A: Chatbot na OpenAI API

Sytuacja: SaaS support chatbot, GPT-4 API, ~5k users miesięcznie.

Klasyfikacja: Deployer GPAI system + Art. 50 transparency (limited risk: chatbot user-facing).

Co robić: dodać "Powered by AI" disclosure (Art. 50), sprawdzić czy OpenAI ma published Art. 53 compliance (mają — ToS + Privacy Policy + Model Card), 1-pager internal documentation, monitor output dla harmful patterns. NIE jesteś provider GPAI.

Scenariusz B: CV screening on Anthropic Claude API

Sytuacja: HR-tech SaaS, Claude API do parsing + ranking CVs.

Klasyfikacja: Deployer GPAI + Provider HIGH-RISK system (Annex III #4 employment). To jest zła wiadomość — Twój system jest high-risk niezależnie od tego że używa GPAI.

Co robić: full Art. 9-15 obligations wobec Twojego systemu (risk management, data governance, technical documentation, logging, human oversight, accuracy, cybersecurity), conformity assessment Annex VI, EU registration, post-market monitoring. Anthropic spełnia swoje GPAI provider obligations osobno — Twoja odpowiedzialność jest na poziomie SYSTEMU. Decision tree dla high-risk.

Scenariusz C: Fine-tuned Llama 3 dla legal-tech

Sytuacja: EU legal-tech startup, fine-tunes Llama 3 8B na własnym datasecie polish legal documents (~50k docs).

Klasyfikacja: Borderline. Fine-tuning compute prawdopodobnie poniżej 10²² FLOPs threshold (Art. 51 dla "model" status — recital 99). Ale Recital 109 sugeruje że znacząca modyfikacja może czynić Cię providerem derived modelu.

Co robić: 80% szans że nadal jesteś deployer (fine-tuning bez fundamental modification ≠ provider). Konserwatywnie — dokumentuj fine-tuning methodology (lighter wersja Art. 53(1)(a)), publish small training data summary dla swojego fine-tuning dataset (Art. 53(1)(d)). Audit recommended dla legal certainty.

Scenariusz D: Self-hosted Mistral dla privacy-sensitive deployment

Sytuacja: EU healthcare SaaS, self-hosts Mistral Small 3 dla GDPR-compliant on-premise deployment, BEZ modifications.

Klasyfikacja: Deployer GPAI system + Provider HIGH-RISK system (Annex III #5 healthcare).

Co robić: sprawdź czy Mistral opublikował Art. 53 compliance docs (Mistral ma model cards + tech reports, ale formal AI Act Art. 53 doc — verify). Twoje obowiązki = full Art. 9-15 wobec healthcare AI system. Self-hosting NIE czyni Cię provider GPAI — distribuujesz to Mistralowi.

Timeline enforcement — co i kiedy

Dla SMB istotne: jeśli używasz GPT-4 API w 2026 roku, OpenAI ma już swoje obowiązki spełnione (live od 02.08.2025). Masz prawo wymagać od nich AI Act compliance documentation jako część Twojego vendor management.

Vendor checklist — co weryfikować u Twojego GPAI providera

Przed wdrożeniem GPAI w produkcji EU, sprawdź czy Twój provider opublikował:

1. Technical documentation Annex XI compliant (model card może wystarczyć dla mniejszych providerów)
2. Acceptable use policy z explicite EU AI Act references
3. Copyright policy — jak respect'ują Art. 4 DSM Directive, czy honorują robots.txt / ai.txt opt-outs
4. Training data summary per European AI Office template (publicly available na ich stronie)
5. Incident reporting channel — gdzie zgłosić jak ich model wygenerował something problematic
6. Status systemic risk — czy > 10²⁵ FLOPs (jeśli tak, dodatkowo Art. 55 docs)

Status providerów (na 04.05.2026):

• OpenAI — full Art. 53 compliance, training data summary live, copyright policy detailed. Systemic risk classified.
• Anthropic — full Art. 53, model cards, copyright policy. Systemic risk classified dla Claude 3.5 Opus+.
• Google — Gemini compliance docs live. Mixed disclosure quality dla mniejszych modeli.
• Mistral — partial. Tech reports + model cards exist, Art. 53(1)(d) summary template format pełny dopiero 2026 Q1.
• Meta (Llama) — model cards + responsible AI license, formal Art. 53 doc partial.
• DeepSeek / Qwen / inne Chinese providers — minimal EU AI Act compliance documentation. Wysokie ryzyko dla EU production deployment.

Pułapki dla SMB — 4 najczęstsze błędy

1. Confusion: "używamy AI = jesteśmy GPAI provider"

Błąd: używasz API (OpenAI, Claude) → myślisz że masz Art. 53 obligations.

Prawda: jesteś deployer. Provider obligations są na barkach OpenAI/Anthropic. Ty masz light obligations (ToS, internal docs).

2. Pomijanie copyright policy provider'a

Błąd: deployujesz open-source GPAI bez sprawdzenia czy ich training data respektowała copyright.

Prawda: jeśli provider łamie Art. 53(1)(c) i European AI Office wszcyna investigation, vendor może być force'owany do retractowania modelu — Ty stracisz dependency.

3. Fine-tuning = automatic provider status

Błąd: robisz LoRA fine-tune na 5k examples → boisz się że jesteś GPAI provider z full Art. 53.

Prawda: małe fine-tunes ≠ significant modification per Recital 109. Pełen pre-training od zera lub fine-tune z €1M+ compute = potencjalny provider. Pośrednie = grey zone, audit needed.

4. GPAI w high-risk system = "OpenAI handles it"

Błąd: SaaS używa GPT-4 do CV screening → myśli "OpenAI ma compliance, my OK".

Prawda: Twój system jest osobnym high-risk (Annex III #4). OpenAI compliance dla GPAI modelu nie zwalnia Cię z full Art. 9-15 obligations dla Twojego systemu. To dwie różne odpowiedzialności w łańcuchu dostaw.

Action items dla EU SMB SaaS

1. Inventory swoich GPAI integracji. Lista per system: provider, model name, use case, czy user-facing czy internal, czy wpada w high-risk Annex III.
2. Verify provider compliance. Dla każdego dostawcy: znajdź ich AI Act compliance page (zwykle /policies/eu-ai-act lub /trust). Zapisz link + date last verified.
3. Internal documentation. 1-page per system: nazwa, co robi, jaki model, jakie guardrails, jaki monitoring. Wystarczy dla deployer.
4. Art. 50 transparency check. User-facing AI? Dodaj disclosure ("Treść/odpowiedź wygenerowana przez AI"). Loguj implementation date.
5. High-risk overlap check. Jeśli któryś system wpada w Annex III — full Art. 9-15 obligations, niezależnie od tego że używa GPAI. Annex III decision tree →

FAQ

Czy muszę publikować training data summary jeśli fine-tunuję LLama 3?

Najprawdopodobniej NIE — LoRA fine-tune ≠ significant modification per Recital 109. Jeśli compute fine-tuningu > 10²² FLOPs (rzadkie), tak. Konserwatywnie: krótka notatka opisująca fine-tuning dataset (1-2 strony) jako vendor due diligence dla downstream users.

Czy Stable Diffusion to GPAI?

Tak, image generation foundation model. SD 1.5 / 2.x / 3.x — wszystkie GPAI per Art. 3(63). Stability AI ma swoje provider obligations.

Co z chińskimi modelami (DeepSeek, Qwen)?

Jeśli używasz w EU production = wysokie ryzyko regulatory. Większość chińskich providerów nie publikowała formal Art. 53 documentation per European AI Office template. EU AI Office może wszcząć investigation, model może być force'owany do retractowania z EU market — stracisz vendor dependency. Dla mission-critical deployments preferuj European providers (Mistral, Aleph Alpha) lub US providers z EU compliance (OpenAI, Anthropic).

Czy embedding models (text-embedding-3, voyage-2) to GPAI?

Edge case. Strict interpretation Art. 3(63) "wide range of distinct tasks" — embedding models są zwykle single-task (vector representation). Większość legal opinion: NIE są GPAI w sensie EU AI Act. Provider obligations mniej restrykcyjne. Ale zawsze sprawdź vendor classification.

Co znaczy "significant modification" przy fine-tuningu?

Recital 109 nie daje precyzyjnej definicji. Practical heuristics używane przez compliance counsel:

• Fine-tune compute < 10²² FLOPs → typowo nie significant
• Fine-tune compute > 10²³ FLOPs → likely significant (€10M+ training run)
• Architecture change (np. dodanie warstw, MoE conversion) → significant niezależnie od compute
• Domain adaptation bez architecture change → typowo nie significant

Konserwatywnie: jeśli niepewny, treat jak significant i dokumentuj jak provider derived modelu. Lepsze od niedoszacowania.

— Piotr Reder, aiactaudit.pl. 04 maja 2026.