EU AI ACT · ARTICLE 10 · DATA GOVERNANCE · ENFORCEMENT 02.08.2026

Art. 10 AI Act: 7 błędów data governance które kosztują €15M karę

Piotr Reder · aiactaudit.pl 05 maja 2026 · ~14 min czytania

Większość artykułów o EU AI Act skupia się na klasyfikacji ryzyka (Annex III) lub GPAI obligations. To są sławne tematy. Ale gdy Twój system wpada w high-risk i przychodzi audit, pierwsze pytanie którym dostaniesz to nie "ile to kosztowało" ani "czy macie human oversight". Pierwsze pytanie to: pokażcie mi dokumentację training danych. To jest Art. 10 AI Act.

Z 22 wymogów Art. 9-15 dla high-risk systems, Art. 10 Data Governance jest najczęściej pomijaną sekcją w EU SMB SaaS audit'ach jakie widziałem. Konsultanci sprzedają fluff "AI ethics workshop". Tymczasem European AI Office i EU notified bodies oczekują konkretnej dokumentacji data lineage, bias testing, data quality controls. Brak = €15M kara per Art. 99(4).

TL;DR

Art. 10 wymaga 7 rzeczy: data lineage (skąd i kiedy), data minimization (czemu te a nie inne), bias detection + mitigation (z konkretnymi metrics), sensitive data justification (Art. 10(5) — special category data tylko jeśli niezbędne), separation training/validation/test sets (no contamination), data quality controls (completeness, accuracy), dokumentowane procedures (auditable trail). 60% EU SMB SaaS pomija minimum 3 z tych 7. Każdy gap = potencjalna €15M kara dla high-risk systems.

Czym jest Art. 10? (overview)

Art. 10 AI Act to data governance and management practices dla high-risk AI systems (Annex III). Obowiązuje od 02.08.2026 dla większości high-risk obligations, ale ten artykuł jest "data foundation" — bez compliance Art. 10 nie ma sensu mówić o Art. 14 (human oversight) lub Art. 15 (accuracy). Bez data nie ma nothing.

Sześć subsections Art. 10:

Art. 10(1) — high-risk systems trenowane z data muszą być developed na podstawie training/validation/test sets meeting quality criteria w (2)-(5)
Art. 10(2) — data governance practices muszą być w place: design choices, data collection processes, data prep operations, formulation of relevant assumptions, prior assessment of availability/quantity/suitability, examination for biases, identification of gaps
Art. 10(3) — training/validation/test sets muszą być relevant, sufficiently representative, free of errors, complete in view of intended purpose
Art. 10(4) — sets muszą uwzględniać characteristics of geographical, behavioural, contextual, functional setting
Art. 10(5) — special category personal data (GDPR Art. 9 — race, health, biometrics, etc.) tylko jeśli strictly necessary dla bias detection/correction, z appropriate safeguards
Art. 10(6) — appropriate measures dla detect, prevent, mitigate biases

Penalty per Art. 99(4): €15M lub 3% global annual turnover, whichever is higher (lower for SMB per Art. 99(6)).

Kto musi compliance? (scope)

Art. 10 dotyczy providerów high-risk systems. Jeśli Twój system wpada w jeden z 8 obszarów Annex III i Twoja firma jest providerem (developing/training/placing on market), Art. 10 jest mandatory. Decision tree dla Annex III tutaj.

Pełen scope:

Provider high-risk AI system = full Art. 10 obligations
Deployer high-risk AI system = lighter Art. 26 obligations + cooperation z provider'em na Art. 10 issues
Distributor / Importer high-risk AI system = checks na czy provider spełnił Art. 10 (Art. 25-27)

Dla SMB SaaS najczęstsze case: jesteś provider swojego high-risk systemu (ty go napisałeś), nawet jeśli używasz GPAI API od OpenAI/Anthropic do underlying inference. Provider vs deployer w kontekście GPAI.

7 błędów data governance dla EU SMB SaaS

Lista bazuje na audit'ach jakie widziałem (wstępny benchmark) + analizie public AI compliance reports z 2025-2026 (Anthropic, OpenAI, Mistral compliance disclosures). Sortowane od najczęstszego do najrzadszego.

Błąd #1 — Brak training data lineage

Co to jest: nie wiesz skąd pochodzą dane treningowe Twojego modelu. "Z internetu", "od klientów", "scrape'owane". To NIE jest data lineage per Art. 10(2)(b).

Co Art. 10 wymaga: dla każdej category training data — source identification (URL / API / vendor / contract reference), collection date range, collection method (scrape / purchase / user-submitted), licensing posture (PD / CC / proprietary / consent-based), volume metrics (count + size).

Częstość w EU SMB: ~80% SaaS używających training data nie ma formalnego data lineage. Excel z URLami nie wystarczy.

Penalty risk: 🔴 wysoki. Audit zaczyna od tego pytania. Brak lineage = audit fail = potencjalnie €15M.

Fix: data lineage doc z 5 polami per source: name + URL/contract + dates + license + volume. Dla scraping — robots.txt compliance log. Maintain per release. 4-8h pracy initial, 2h/release ongoing.

Błąd #2 — Bias detection bez metrics

Co to jest: mówisz "testujemy na bias" ale nie masz konkretnych liczb. "Sprawdziliśmy że działa dobrze dla różnych grup" — to nie spełnia Art. 10(2)(f) i Art. 10(6).

Co Art. 10 wymaga: identifiable bias metrics per protected category (gender, age, ethnicity, disability, geography per Art. 10(4)). Standard frameworks: demographic_parity_difference, equalized_odds_difference, predictive_parity_ratio, disparate_impact_ratio. Plus baseline measurement + post-mitigation re-measurement.

Częstość w EU SMB: ~70% audit'ów pokazuje "we tested for bias" bez konkretnych metric values lub group breakdowns.

Penalty risk: 🔴 wysoki. Audit looks for numbers. Brak liczb = audit fail.

Fix: wybrać 2-3 standardowe metrics (np. demographic parity + equalized odds), measure baseline na test set z protected attributes (lub proxy jeśli sensitive data nie kolekcjonowane), document w technical documentation Annex IV. Tools: Aequitas (open source), IBM AI Fairness 360, Microsoft Fairlearn. 2-3 dni pracy data scientist.

Błąd #3 — Brak data minimization w collection

Co to jest: kolekcjonujesz wszystkie dane jakie się da, "na wszelki wypadek". Art. 10(2)(d) wymaga relevant assumptions about information data is supposed to measure and represent + Art. 10(3) wymaga relevance/representativeness. Crosswalks z GDPR Art. 5(1)(c) data minimization principle.

Co Art. 10 wymaga: documented justification for each feature/column in training set — co ma to mierzyć/reprezentować. Features bez clear purpose = audit red flag. Z perspektywy Art. 10 + GDPR przecięcia, "we collect everything" jest legal nightmare.

Częstość w EU SMB: ~60% SaaS kolekcjonuje features które nie są używane w final model lub bez clear documentation purpose.

Penalty risk: 🟠 medium-high. Kara z Art. 99(4) AI Act + GDPR Art. 83(5) podwójnie (max GDPR €20M / 4% turnover).

Fix: data dictionary doc — lista wszystkich features w training set z 3 polami: purpose (dlaczego kolekcjonujesz), used in model (yes/no — jeśli no, dlaczego dalej kolekcjonujesz), retention policy (jak długo trzymane). Drop features bez clear purpose. 1-2 dni pracy.

Błąd #4 — Sensitive data bez Art. 10(5) justification

Co to jest: kolekcjonujesz lub używasz GDPR Art. 9 special category data (zdrowie, biometryka, race, religia, polityczne views, orientacja, członkostwo związkowe) w training ale nie masz strict necessity justification per Art. 10(5).

Co Art. 10(5) wymaga: sensitive data tylko gdy "strictly necessary" dla bias detection / correction, z appropriate safeguards (encryption, pseudonymization, retention limits, access controls, no transmission to third parties without consent). Plus dokumentacja DPIA per GDPR Art. 35.

Częstość w EU SMB: ~30% SaaS używających behavioral data ma elementy sensitive data (np. health-tech, fertility apps, mental health). Większość bez formal Art. 10(5) justification.

Penalty risk: 🔴 bardzo wysoki. Sensitive data violations z AI Act + GDPR podwójna kara, plus class action exposure (consumer rights).

Fix: jeśli używasz sensitive data — dedykowany doc Art. 10(5) Justification z: (1) co konkretnie kolekcjonujesz, (2) dlaczego strictly necessary (alternatives explored), (3) safeguards in place, (4) retention timeline, (5) DPIA reference. Jeśli możliwe — nie kolekcjonuj (proxy lub synthetic alternatives). 2-3 dni pracy + legal review €1-2k.

Błąd #5 — Validation/test sets pomylone z training

Co to jest: nie masz proper separation training / validation / test sets per Art. 10(1). Albo masz tylko train + test (bez validation), albo używasz test set do hyperparameter tuning (= contamination).

Co Art. 10 wymaga: trzy distinct sets: training (model fits weights), validation (hyperparameter tuning, model selection), test (final evaluation only — touched once). Plus documentation kiedy data była partitioned, jaki seed, jakie ratio.

Częstość w EU SMB: ~50% startup ML pipelines ma improper separation. Często "test set leak" przez time-series cross-validation issues lub przez używanie test set do model selection.

Penalty risk: 🟠 medium. Audit może pokazać że accuracy claims są overstated przez data leakage = misleading documentation = Art. 99(4) violation.

Fix: proper 70/15/15 split (lub time-based split dla time series), document w data prep doc, lock test set w separate file/encryption, pull only przy final evaluation. Tools: scikit-learn train_test_split z random_state, MLflow lub Weights & Biases dla experiment tracking. 4-8h pracy.

Błąd #6 — Brak data quality controls (errors/missing/duplicates)

Co to jest: nie masz proceduralnego sprawdzenia czy training data jest "free of errors and complete" per Art. 10(3). Nikt nie sprawdził missing values, duplicates, outliers, encoding issues, label noise.

Co Art. 10 wymaga: documented data quality assessment z metrykami: completeness rate (% missing values per feature), duplicate rate, label accuracy (manual sample audit, np. 100 records), encoding consistency, outlier detection (z disposition log: kept / removed / corrected).

Częstość w EU SMB: ~75% startup ML produkuje modele bez formal data quality report. "It works in tests" jest insufficient documentation.

Penalty risk: 🟠 medium. Audit może wymagać re-training jeśli quality issues podważają safety claims.

Fix: data quality report per training run: pandas profiling lub Great Expectations dla automatic report, manual label audit na 100-200 sample (with second annotator dla agreement), outlier disposition log. Auto-include w technical documentation Annex IV. 1-2 dni pracy initial, 0.5 dnia per release.

Błąd #7 — Brak documented data governance procedure

Co to jest: wszystko o data robisz ad-hoc. Każdy ML engineer ma swój sposób. Nie ma procedure document. Art. 10(2) explicite wymaga "data governance and management practices" — to jest procedural wymóg, nie tylko technical.

Co Art. 10 wymaga: written procedure document covering: data sourcing approval, quality gates przed training, bias testing checklist, sensitive data handling, validation protocols, retention/deletion schedule, incident response (np. discovered bias post-deployment), version control. Roles + responsibilities (kto jest data steward).

Częstość w EU SMB: ~85% nie ma formal data governance procedure document. Tribal knowledge, no audit trail.

Penalty risk: 🟡 medium-low individually, ale combined z błędami #1-6 = audit fail compounding.

Fix: 5-10 page Data Governance Procedure doc — template dostępny w naszym sample audit. Ownership: jedna osoba (CTO / Lead ML / Compliance Lead). Review quarterly. 1-2 dni pracy initial draft.

Decision tree — czy Twoja AI ma data governance gap?

┌─ Czy Twoja AI jest high-risk per Annex III?
│   (rekrutacja, kredyt, edukacja, healthcare, biometryka,
│    infrastructure, law enforcement, migracja, sądy)
│
├─ NIE → Art. 10 nie applies. Możesz zignorować ten artykuł.
│
└─ TAK → Art. 10 mandatory. Continue:

  Q1: Czy masz documented training data lineage
      (source / dates / licenses / volumes per category)?
      ├─ NIE → 🔴 GAP #1. Wysokie ryzyko audit failure.
      └─ TAK → Q2

  Q2: Czy masz bias metrics z konkretnymi values
      per protected category (gender/age/ethnicity/etc.)?
      ├─ NIE → 🔴 GAP #2. Wysokie ryzyko.
      └─ TAK → Q3

  Q3: Czy każdy feature w training data ma
      documented purpose i used-in-model status?
      ├─ NIE → 🟠 GAP #3. Medium ryzyko (+ GDPR exposure).
      └─ TAK → Q4

  Q4: Jeśli używasz sensitive data (GDPR Art. 9),
      czy masz Art. 10(5) Strict Necessity doc + DPIA?
      ├─ Używamy sensitive data, brak doc → 🔴 GAP #4. Krytyczne.
      ├─ Nie używamy sensitive data → Skip do Q5
      └─ Mamy doc → Q5

  Q5: Czy masz proper train/validation/test separation
      bez data leakage?
      ├─ NIE → 🟠 GAP #5.
      └─ TAK → Q6

  Q6: Czy masz data quality report
      (completeness/duplicates/label audit) per training run?
      ├─ NIE → 🟠 GAP #6.
      └─ TAK → Q7

  Q7: Czy masz Data Governance Procedure document
      z named roles + responsibilities?
      ├─ NIE → 🟡 GAP #7.
      └─ TAK → ✅ Art. 10 prawdopodobnie compliant.
                  Audit recommended dla legal certainty.

Z 7 gap'ów, jeśli masz 3 lub więcej = high probability audit fail. Jeśli 1-2 = manageable, fix przed enforcement deadline 02.08.2026. Jeśli 0 = jesteś w top 5% EU SMB SaaS w data governance.

GDPR crosswalk — gdzie Art. 10 AI Act zazębia się z GDPR

Art. 10 AI Act nie zastępuje GDPR — działa na nim. Cross-references które każdy compliance lead musi rozumieć:

Art. 10 AI Act	GDPR equivalent	Implikacja
(2)(a) design choices	Art. 25 privacy by design	Documented design decisions wymagane przez oba
(2)(b) data collection	Art. 6 lawful basis + Art. 5(1)(b) purpose limitation	Collection musi mieć lawful basis + AI purpose
(2)(c) data prep	Art. 5(1)(c) data minimization	Pre-processing musi minimize, nie maximize
(2)(f) bias examination	Art. 22 automated decision-making	Bias = non-discrimination obligations
(3) error-free / complete	Art. 5(1)(d) accuracy principle	Inaccurate data = GDPR violation also
(5) sensitive data	Art. 9 special category data	Strict necessity test = GDPR Art. 9(2)(g) public interest substantial
(6) bias mitigation	Art. 5(1)(a) fairness principle	Bias = unfairness, GDPR violation

Praktyczna implikacja: jeśli już jesteś GDPR-compliant z DPO i DPIA culture, Art. 10 AI Act jest 60% done. Brakujące 40% to AI-specific bits (bias metrics, training/validation separation, data lineage in ML pipeline context).

Jeśli NIE jesteś GDPR-compliant — masz większy problem niż AI Act. GDPR enforcement już dawno live, max kara €20M / 4% turnover.

SMB-friendly framework — 5 kroków do compliance

Pełen Art. 10 compliance to ~6-8 weeks dla EU SMB SaaS. Można rozłożyć:

Krok 1 — Data inventory (1-2 dni)

Lista wszystkich training data sources używanych w high-risk system. Per source: name, URL/contract, date acquired, license, volume, modality. Excel/Notion OK na start, formalize w docs latem.

Krok 2 — Data dictionary + minimization (2-3 dni)

Per feature: purpose, used in model (Y/N), retention. Drop unused features. Check sensitive data — jeśli present, pivot do Krok 5.

Krok 3 — Data quality report + train/val/test separation (3-5 dni)

Pandas profiling lub Great Expectations dla automated quality checks. Manual label audit na 100-200 records. Lock test set. Document.

Krok 4 — Bias metrics baseline (3-5 dni)

Wybierz 2-3 metrics (demographic parity + equalized odds + predictive parity). Run on test set z protected attributes (real lub proxy). Document baseline values. Plan re-measurement post-mitigation.

Krok 5 — Sensitive data + DPIA (5-10 dni jeśli applicable)

Jeśli używasz GDPR Art. 9 data: strict necessity justification + DPIA + safeguards. Legal review €1-2k. Jeśli nie używasz — skip.

Krok 6 — Procedure document + governance roles (2-3 dni)

5-10 page Data Governance Procedure z named roles, escalation paths, review cadence. Sign off przez CEO/CTO.

Total effort: ~3-4 weeks of focused work dla SMB without sensitive data, ~6-8 weeks ze sensitive data + DPIA. Ongoing cost: ~10% of team capacity dla maintenance + per-release updates.

Common pitfalls dla SaaS używającego LLM API

"Używamy GPT-4 / Claude API, więc nie trenujemy own model — Art. 10 nie applies?"

Half-true. Art. 10 dotyczy training data dla Twojego high-risk system. Jeśli LLM API jest tylko inference w Twojej pipeline (input → API → output), training data dla Twojego "system" to prompts + few-shot examples + system prompts + RAG documents które kolekcjonujesz lub używasz. Art. 10 applies do tych.

Konkretne mapping:

Few-shot examples w system prompt = training-like data dla Twojego system. Wymagają data lineage + bias check.
RAG corpus (knowledge base, vector DB) = training-like data. Wymagają licensing review + sensitive data screening.
User feedback / ratings używane do prompt tuning lub model selection = training data per Art. 10.
Fine-tuning data jeśli używasz OpenAI fine-tuning lub LoRA na open-source = full training data per Art. 10. Możesz stać się GPAI provider w niektórych przypadkach.

Misconception: "API-based AI = nie my trenujemy = nie Art. 10". Reality: Art. 10 dotyczy data driving system behavior, nie tylko model weights. Twoje prompts + RAG + few-shot examples są data that trains system behavior. Audit będzie ich szukał.

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

Naruszenie Art. 10 (jako część Art. 9-15 high-risk obligations) podlega Art. 99(4): €15 milionów lub 3% global annual turnover, whichever is higher (per Art. 99(6) lower of dla SME — które per Recommendation 2003/361/EC = <250 employees i <€50M turnover).

Historical signal: AccessiBe FTC settlement $1M w 2025 (US, accessibility AI false claims). EU enforcement na high-risk AI Act jeszcze nie ma precedensu, ale GDPR enforcement jest predykcyjny: Meta €1.2B (2023), Amazon €746M (2021) — EU regulators nie boją się dużych kar.

Pierwsza wave AI Act enforcement spodziewana Q4 2026 - Q1 2027 (3-6 miesięcy post-deadline 02.08.2026). Targety: media-prominent companies, lub te z public complaints (CV screening, predictive lending).

Sprawdź swój risk exposure — penalty calculator liczy dla Twoich konkretnych liczb (revenue, scale, sensitive data presence).

Action items dla EU SMB SaaS — checklist

Mam high-risk AI system (Annex III). Dziś (lub w tym tygodniu) zrobię:

📋 Data inventory — lista wszystkich training/RAG/few-shot sources (1 day)
🎯 Data dictionary — purpose + used-in-model + retention per feature (1-2 days)
📊 Bias metrics baseline — 2-3 standard metrics na test set (3-5 days)
🔍 Sensitive data audit — czy używamy GDPR Art. 9 data? jeśli tak → DPIA + Art. 10(5) doc (5-10 days)
✂️ Train/val/test separation — proper split, locked test set (4-8h)
📈 Data quality report — completeness/duplicates/label audit (1-2 days)
📝 Data Governance Procedure — 5-10 page doc z named roles (1-2 days)
🔄 Quarterly review cadence — calendar entries dla każdej training run / release

Przybliżony total: 3-4 weeks of focused effort (więcej jeśli sensitive data). Możesz to zrobić internally lub zlecić audit ze nas (€799 founding price, ~14 dni delivery).

Sprawdź swoją Art. 10 ekspozycję

Penalty calculator policzy potencjalną karę dla Twoich konkretnych liczb (revenue, employees, sensitive data presence, current compliance level). Plus 5-pytaniowy quiz da Ci precise gap diagnostic per Art. 10 subsection.

Otwórz Penalty Calculator →

Vs konsultanci sprzedający "AI ethics workshop"

Ostrzeżenie. Konsultanci EU AI Act często sprzedają "AI ethics workshop" za €5-15k. Workshop jest fluff: dyskusje o "responsible AI principles", "ethics framework", "stakeholder engagement". Audit nie patrzy na to.

Audit patrzy na:

Documented data lineage
Quantified bias metrics
Annex IV technical documentation
Logging trail per Art. 12
Human oversight mechanism per Art. 14
Accuracy/robustness measurements per Art. 15

Jeśli Twój consultant sprzedaje "ethics" bez konkretnych data lineage docs, bias measurement reports, technical Annex IV — szukaj kogoś innego. EU compliance to data + dokumentacja, nie philosophy.

Sprawdź sample audit — pokazuje exactly co audit zawiera (data lineage tab, bias metrics tab, gap analysis per Art. 9-15, action plan).

Kluczowe takeaways

Art. 10 jest najczęściej pomijaną sekcją w EU SMB SaaS audits — 60% startupów ma 3+ gaps
7 błędów ranked: data lineage > bias metrics > minimization > sensitive data > train/val separation > quality controls > procedure doc
GDPR crosswalk: jeśli jesteś GDPR-compliant, jesteś 60% done z Art. 10
Penalty €15M / 3% turnover per Art. 99(4) za high-risk Art. 10 violations (lower-of dla SMB)
3-4 weeks of focused work dla pełnego compliance dla SMB without sensitive data, 6-8 weeks z sensitive data
API-based AI nie zwalnia z Art. 10 — prompts + RAG + few-shot to "training data" per audit
Konsultanci sprzedający "ethics workshop" nie pomogą w audicie — wymagają data + dokumentacja, nie philosophy
Enforcement Q4 2026 - Q1 2027, media-prominent firms targety pierwsze

Disclaimer: ten artykuł jest informacyjny, NIE legal advice. Konkretne implications dla Twojego systemu wymagają legal opinion od EU AI Act-specialized lawyer, najlepiej w połączeniu z technical audit. Zamówienie audytu dostępne — zwracamy 100% kasy w 30 dni jeśli nie znajdziemy minimum 3 actionable findings.