The EU AI Act entered into force in August 2024, and its obligations have been landing in waves ever since: prohibited practices in February 2025, general-purpose AI duties in August 2025, and the bulk of the high-risk regime in August 2026. Most coverage focuses on which systems fall into which risk tier. For the people who run data platforms, the more useful question is different: when the obligations apply to you, what will you need to prove, and can your platform produce that proof?
The Act is an evidence regulation
Strip the 113 articles down to what touches a data platform and three duties remain:
1. Data governance (Article 10). High-risk systems must be trained on datasets subject to documented governance: relevance, representativeness, error handling, and an examination of possible biases. You cannot document a dataset you cannot trace. In practice, Article 10 is a lineage requirement: which sources fed which training set, transformed by which code, when.
2. Record-keeping and logs (Article 12). High-risk systems must log events automatically across their lifecycle, in a way that allows tracing back. That covers training runs and inference alike. “We could reconstruct it from tickets” will not survive a conformity assessment.
3. Technical documentation (Article 11 and Annex IV). Providers must maintain documentation describing the system, its data, its training, its evaluation and its limits, kept up to date. The cheapest way to keep documentation up to date is to generate it from systems of record instead of writing it after the fact.
What this means concretely
Map those duties onto platform capabilities and the shopping list writes itself:
| AI Act duty | Platform capability |
|---|---|
| Trace training data (Art. 10) | Automatic lineage from source tables to training runs |
| Log the lifecycle (Art. 12) | Audit trail covering training and inference, exportable |
| Document the system (Art. 11) | Experiment tracking, model registry with versions and stages |
| Demonstrate accuracy & robustness (Art. 15) | Metric history per run, reproducible evaluations |
| Keep evidence available for authorities | Artifacts and logs on storage you control, with retention |
Notice what is absent from that table: nothing requires a specific vendor, a specific model or a specific cloud. The Act regulates traceability, and traceability is an architecture property.
The jurisdiction angle
There is a second, quieter implication. The evidence base the Act demands, training data, logs, model artifacts, is itself sensitive. It describes your models, your data and your decisions. Keeping that evidence on infrastructure subject to a non-EU jurisdiction creates exactly the kind of dependency European regulators keep warning about. Evidence for a European regulation is most defensible on European infrastructure, under your own keys.
How Polnor maps to this
Polnor records column-level lineage automatically from every query, job and notebook, so the Article 10 trail exists without anyone maintaining it. Every training run logs its parameters, metrics and artifacts through an MLflow-compatible tracker, and models move through a versioned registry with back-links to the endpoints serving them. The audit log covers both training and inference and exports hourly to your own S3, in your own European region. When the conformity assessment comes, the documentation is a set of queries, not a quarter of archaeology.
If August 2026 is on your risk register, request a demo and we will walk through the evidence checklist against your current stack.