The EU AI Act and Your AI Architecture: What Changes in 2026
The EU AI Act introduces binding requirements for high-risk AI systems. Article 10 mandates data governance. Article 15 demands accuracy and robustness. Here's what that means for how you architect AI infrastructure.
Article 10: Data Governance Is Now an Architectural Requirement
Article 10 of the EU AI Act imposes binding data governance obligations on high-risk AI systems. Paragraph 2 requires that training, validation, and testing datasets be "subject to appropriate data governance and management practices." Paragraph 3 mandates that datasets be "relevant, representative, free of errors and complete." Paragraph 5 requires that personal data processing for bias monitoring be subject to "appropriate safeguards for the fundamental rights and freedoms of natural persons."
Most AI architectures fail Article 10 because data governance is bolted on at the policy layer. An access control list does not prevent a misconfigured pipeline from feeding PII into a training dataset. A data catalog does not stop an engineer from joining an identity table to a feature store during model development. Policy-based governance depends on humans following procedures. Article 10 does not care about your procedures — it cares about outcomes.
Split-knowledge architecture addresses Article 10 structurally. When identity data lives in Sandbox A and AI processing happens in Sandbox B, with no network path between them, the AI system physically cannot access identity information during training or inference. Data governance becomes an infrastructure property, not a policy aspiration.
Article 15: Accuracy, Robustness, and Cybersecurity
Article 15(1) requires high-risk AI systems to "achieve an appropriate level of accuracy, robustness and cybersecurity." Article 15(3) mandates resilience against "attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities." Article 15(4) requires that the system be "resilient as regards errors, faults or inconsistencies."
The cybersecurity dimension of Article 15 is where most organisations will struggle. A monolithic AI system — one where identity data, behavioural data, and model outputs coexist — presents a single attack surface. Compromising that system yields a fully linked dataset: names, behaviours, AI-derived risk scores, all in one breach.
In a dual-sandbox architecture, a breach of Sandbox B yields pseudonymised behavioural data and model outputs. The attacker gets transaction patterns tagged to opaque tokens like tok_a7f2x9k4. Without access to the ID Bridge mapping table — which sits in a separate infrastructure boundary with HSM-protected encryption — those tokens are computationally irreversible. The cybersecurity posture improves because the blast radius is architecturally bounded.
The Market Is Responding
The enterprise world has noticed. Gartner projects the AI governance platform market at $492M in 2026, surpassing $1B by 2030. Forrester forecasts 30% CAGR through 2030. Confidential computing — the infrastructure layer for processing data in encrypted memory — is projected at $59.4B by 2028 (MarketsAndMarkets).
The funding signals are equally clear. Companies building infrastructure-level data privacy solutions are raising significant rounds — including a $90M Series C led by Goldman Sachs for a confidential computing leader with 150+ enterprise customers across banking, government, and healthcare. AI governance startups have raised rounds of $125M, $34M, and more in the past 12 months alone.
What's driving this? The same regulatory deadline that should be driving your architecture decisions: August 2, 2026. The market is pricing in what regulators have already written into law.
Where Most Architectures Fail: A Requirements Checklist
| AI Act Requirement | Article | Typical Architecture | Split-Knowledge Architecture |
|---|---|---|---|
| Data governance for training datasets | Art. 10(2) | Policy-based. Relies on engineers not joining identity tables to training data. | Structural. Sandbox B has no network path to identity data. Training data is pseudonymised by design. |
| Bias monitoring with privacy safeguards | Art. 10(5) | Requires access to demographic data alongside model outputs. Creates privacy risk. | Sandbox B receives generalised demographic attributes (age bracket, region) — sufficient for bias detection, insufficient for identification. |
| Logging of high-risk system operations | Art. 12(1) | Application-level logging, often inconsistent across services. | Append-only audit service logs every operation across all components. Immutable hash chain prevents tampering. |
| Transparency to users | Art. 13 | Disclosure that AI is used. Difficult to prove what data the AI accessed. | Provable statement: the AI processed pseudonymised data. It could not identify you during inference. |
| Human oversight mechanism | Art. 14 | Manual review queues. Reviewer sees full identity + AI output simultaneously. | Re-linkage protocol. Human reviewer inspects AI output first (pseudonymised), then requests identity through the ID Bridge with audit trail and time-limited access. |
| Accuracy and robustness | Art. 15(1) | Tested in environments where identity and AI data are co-mingled. | Sandbox B can be stress-tested independently. Model validation does not require access to identity data. |
| Cybersecurity resilience | Art. 15(3) | Single perimeter. Breach exposes everything. | Two sandboxes + bridge. Breach of one component does not compromise the others. Token rotation invalidates any stolen correlations. |
| Conformity assessment documentation | Art. 43 | Documentation describes one large, interconnected system. Audit scope is broad. | Clear boundaries. Assessors can evaluate Sandbox B (AI system) independently of Sandbox A (identity vault). Reduced scope, faster assessment. |
Enforcement Timeline and Penalty Structure
The AI Act entered into force on 1 August 2024. The enforcement timeline is staggered:
- February 2025: Prohibited AI practices (Art. 5) became enforceable.
- August 2025: Obligations for general-purpose AI models (Chapter V) apply.
- August 2026: Full enforcement of high-risk AI system requirements (Art. 6-15, 26-27), including conformity assessments, market surveillance, and penalties.
The penalty structure is the sharpest in EU regulatory history for technology:
- Up to 7% of global annual turnover for violations of prohibited AI practices (Art. 99(3)).
- Up to 3% of global annual turnover for non-compliance with high-risk AI system requirements, including Art. 10 and Art. 15 (Art. 99(4)).
- Up to 1.5% of global annual turnover for supplying incorrect information to authorities (Art. 99(5)).
For context, GDPR penalties cap at 4% of global turnover. The AI Act raises the ceiling by 75% for the most severe violations. And unlike GDPR's first years, regulators will not grant a grace period — the staggered timeline is the grace period.
What Article 10 Means for Your Data Pipeline
Consider a standard ML pipeline: data ingestion, feature engineering, model training, inference serving, monitoring. In a monolithic architecture, identity data can leak into any stage. A feature engineering step that joins customer demographics to transaction data creates a training dataset that contains both identity and behaviour. That dataset violates Article 10(5) the moment it is used for bias monitoring without "appropriate safeguards."
In split-knowledge architecture, the pipeline operates differently:
- Ingestion: Raw data enters the Gateway. Identity attributes route to Sandbox A. Behavioural attributes route to Sandbox B with opaque tokens replacing all direct identifiers.
- Feature engineering: Occurs entirely within Sandbox B. Features are derived from pseudonymised behavioural data. No identity columns exist in the feature store.
- Training: Models train on pseudonymised datasets. Membership inference tests and canary token injection verify that models have not memorised identity data.
- Inference: Requests arrive at Sandbox B as token + context payload. The model outputs a prediction tagged to a token it cannot resolve to a person.
- Monitoring: Bias monitoring uses generalised attributes (age bracket, region) that Sandbox B receives at ingestion. These attributes satisfy Art. 10(5) bias detection requirements while maintaining k-anonymity of k>=5.
Each stage satisfies Article 10 because the architecture makes non-compliance physically difficult. An engineer cannot accidentally join identity data to training data because the identity data is not accessible from Sandbox B's network.
The Conformity Assessment Advantage
Article 43 requires conformity assessments for high-risk AI systems. These assessments evaluate whether the system meets the requirements of Articles 8-15. For a monolithic system, the assessment scope covers the entire infrastructure — every database, every service, every network path.
For a dual-sandbox system, the assessor can focus on Sandbox B for AI-specific requirements (model governance, accuracy, bias) and on the ID Bridge for pseudonymisation integrity. Sandbox A is a standard identity vault — well-understood, with mature compliance patterns. The assessment becomes modular.
This matters practically. Conformity assessments cost time and money. Reducing scope reduces both. Organisations that architect for assessability — not just compliance — gain a structural advantage when August 2026 arrives.