Four months after the European artificial intelligence regulation entered into force, the organisations that took it seriously have discovered something inconvenient. The obligations do not sit in a new compliance function. They land, almost entirely, on people who already run data governance and were already busy. That is the practical story of this regulation heading into next year: not a new rulebook, but two governance disciplines being forced to merge under teams that were never resourced for either.
You cannot govern a model without governing the data underneath it, and most organisations built those two capabilities in different departments, in different decades
The work of the next eighteen months is joining them, and it is organisational before it is legal.
Where the two disciplines actually collide
Four places, consistently. Lineage. Data governance asks where a field came from. Model governance asks what a system was trained on. These are the same question asked by different people using different vocabulary, and in most organisations neither can answer it end to end. Purpose. Privacy law asks what a dataset was collected for. Artificial intelligence obligations ask what a system is used for. The awkward case — data collected for operations, reused for training — fails both tests simultaneously and is extremely common. Quality. Data quality has historically been measured against completeness and accuracy. Model obligations add representativeness and bias, which are properties of a dataset relative to a population, not properties you can check with a validation rule. Human oversight. Access control determines who can see a record. Oversight requirements determine who reviewed a decision and whether they could meaningfully override it. The second is a process question that no permissions model answers.
| Area | Data question | Model or deployment question |
|---|---|---|
| Lineage | Where did the data originate? | What data supported development or use? |
| Purpose | On what basis was it collected and reused? | What is the intended system use? |
| Quality | Is the data accurate and complete for its task? | Does evaluation cover the relevant population? |
| Oversight | Who has authorised access? | Who reviews outputs and can intervene? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The organisational problem is worse than the technical one
In most mid-market and large organisations, the data protection officer or privacy counsel owns personal data, the chief information officer owns systems, a data team owns warehouses and reporting, and artificial intelligence deployments are happening in business units with no formal governance relationship to any of them. The regulation assumes a single accountable owner who can describe what a system does, what it was built from, who oversees it and what happens when it is wrong. Very few organisations have that person. Appointing one is the single highest-value action available, and it costs nothing but political effort.
Start with an inventory, because you almost certainly do not have one
Before any classification work, find out what is actually running. Assistant features switched on inside software you already licence. Scoring and ranking in recruitment, credit, fraud or pricing tools. Models built by a business unit on a departmental budget. Vendor products with artificial intelligence embedded that nobody procured as artificial intelligence. For each: what it does, what data it uses, whether it affects a person's rights or access to a service, who reviews its output, and whether you built it or bought it. That last field determines most of your obligations and is frequently the hardest to answer, because white-labelled products blur it.
A workable structure
One owner accountable for the merged discipline. One register covering both datasets and systems, not two. One review gate that a new deployment passes through, sized to the risk rather than uniform. And a documented position on reuse — which operational data may be used for model development, on what basis, with what record. That last document prevents more future problems than any policy statement about responsible artificial intelligence.
Practical Guidance for EU AI Act Compliance Assessment
- Appoint one accountable owner for data and model governance together.
- Build a single register, covering datasets and deployed systems.
- Inventory what is already running, including embedded vendor features.
- Record build-versus-buy for every system, because it drives your role.
- Write your reuse position before someone needs it urgently.
- Add representativeness to your data quality definition.
- Document human oversight as a process, not a permission.
- Size the review gate to risk so low-risk work is not strangled.
The Regional Angle
The first issue is that the accountable-owner problem is structurally harder in a regional group than in a single-country company. Governance here is typically organised by entity and jurisdiction: a compliance lead per country, technology shared centrally, and business units operating with genuine autonomy because local markets differ. That structure works for regulatory obligations that are territorial and breaks for obligations that follow a system across entities. When one shared recruitment or credit tool is used by seven operating companies in five jurisdictions, the question of who is accountable for it has no natural answer. Resolve it deliberately at group level, name the person, and give them the authority to stop a deployment — otherwise the accountability lands, by default, on whichever entity is unlucky enough to be audited first. The second is a data-quality problem specific to regional workforces and customer bases. Representativeness obligations assume you can characterise the population your data reflects, and the populations here are unusually heterogeneous: workforces spanning dozens of nationalities with very different educational credentials, employment histories that include periods in systems your data never saw, names that transliterate inconsistently across Arabic and Latin script, and address and identity data structured differently by country. A model trained on this data will encode those irregularities, and the failure mode is not dramatic bias but quiet inconsistency — the same person scored differently depending on how their name was entered. Test your systems against the transliteration problem specifically, because it is invisible in aggregate metrics and obvious in individual cases. The third is commercial and often comes as a surprise. Regional organisations that never intend to sell into Europe increasingly find these obligations arriving through their customers rather than through regulators: a European parent requiring group-wide alignment, a multinational client extending its own governance requirements down the supply chain, or a tender that asks for artificial intelligence governance documentation as a qualification criterion. In each case the demand is for evidence — a register, a risk classification, an oversight description — on a deadline measured in weeks. Organisations that have the inventory can produce it. Organisations that do not will spend the qualification period building one badly. Treat the inventory as sales infrastructure, not as compliance overhead, and it becomes considerably easier to fund.
The objection worth taking seriously
The strongest objection is timing. The substantive high-risk obligations do not apply until August 2026, the harmonised standards that will define what compliance actually looks like are still being developed, and guidance on several central questions has not been published. Building a governance programme now means building against a specification that does not exist, then rebuilding when it does. Meanwhile competitors ship features. The disciplined response, on this view, is to monitor closely and start eighteen months before the deadline with the standards in hand. That is sound reasoning about the parts that depend on standards, and anyone building detailed conformity procedures today is wasting effort. The flaw is that it treats all the work as standards-dependent, and the largest component is not. An inventory of what is running, a record of what data each system used, and a note of who reviewed its outputs are all things you can only build going forward. Nobody reconstructs, in 2026, which dataset trained a model in 2024 or who approved its deployment. The organisations that wait will discover that their first eighteen months of artificial intelligence deployment are undocumented, and that documenting them retrospectively is either impossible or an exercise in confident invention. Start the record now and defer the procedures. The record is the part that cannot be bought later.
Common Questions
Does this apply to us if we only buy artificial intelligence, not build it?
Yes, with different obligations. Deployers have real duties around oversight and use, and you can become a provider by putting your name on a system or materially changing its purpose.
Can our data protection officer absorb this?
Often, if they are given capacity and technical support. What does not work is adding it as a title without changing anyone's workload.
Do we need to classify every internal tool?
No. Classify against risk, and be honest that most internal productivity tooling falls at the bottom. The effort belongs where a system affects a person's rights, employment or access to a service.
What should we expect over the next twelve months?
Expect the prohibited-practice provisions and the artificial intelligence literacy obligation to bite in February, which will be the first real test of whether organisations know what they are running. Expect general-purpose model obligations to follow in August and to reshape vendor disclosures. Expect standards work to run late, and expect guidance to arrive closer to the deadlines than anyone would like. And expect customer-driven requirements to reach most organisations well before any regulator does.
EU AI Act Compliance Assessment — we build the inventory and the accountability structure first, because those are the parts you cannot backfill.