Data Governance Framework: From Pillars to Proof

Key takeaways

• A data governance framework is an operating model for data: who decides, under which rules, through which processes, on which technology. Every guide on the first page of Google agrees on that much.
• What changed is the output. Once AI systems enter the estate, a data governance framework has to emit documentary evidence, not just decisions.
• Article 10 of the EU AI Act sets eight explicit requirements for training, validation and testing data, from collection origin through bias mitigation to the identification of data gaps.
• DAMA-DMBOK, DCAM, DGI and COBIT all predate regulated training data. They remain useful skeletons, but none of them tells you what to file.
• One test settles whether your data governance framework works: can it produce a dataset datasheet, a lineage record and a bias examination report for any model currently in production.

What a data governance framework actually is

A data governance framework is the operating model that defines how an organisation collects, stores, secures and uses data. It has four recurring parts: policies and standards that set the rules, roles and ownership that carry accountability, processes that turn rules into routine, and technology that records what happened. Read the ten pages currently ranking for this term and you find those same four pillars under different labels, sometimes stretched to five, seven or ten components.

That consensus is accurate and incomplete. It describes a decision-making structure. It says almost nothing about what the structure has to produce. For twenty years that omission did not matter much, because the audience for data governance was internal: a data quality dashboard, a stewardship council, a catalogue that helped analysts find things. The consumer of the data governance framework was the organisation itself.

That is no longer true. When data feeds an AI system, the consumer of your data governance framework can be a notified body, a market surveillance authority or an enterprise customer running vendor due diligence. Those readers do not accept an operating model as an answer. They ask for records. A data governance framework that cannot produce them is a governance narrative, which is a different thing, and it is the gap this article is about. It sits directly under the broader question of AI governance as an operating discipline.

Data governance versus data management

The distinction is simpler than most guides make it. Data management is execution: pipelines, storage, quality rules, master data, integration. Data governance is the authority layer above it: who is allowed to decide, what the standard is, and how the organisation proves the standard was met.

A useful way to hold the difference is that management answers how, governance answers who says so and where is the proof. A data governance framework that only produces process documentation has described management and called it governance.

The four models everyone cites, and what each was built for

Every ranking page names the same shortlist. They are not competitors, they were built for different jobs.

The common 2026 pattern is to pair them: DAMA-DMBOK defines what good practice looks like, DCAM scores how close you are. DMBOK 3.0 is in development and extends into machine learning data management, which tells you the direction of travel.

Why none of them was written for AI systems

All four were designed to govern data as an organisational asset. None was designed to govern data as a component of a regulated product. That is the shift, and it is not cosmetic.

Under an asset model, the question about a dataset is whether it is accurate, findable, secured and owned. Under a product model, the question is whether this specific training set was relevant and sufficiently representative for the specific purpose the model was placed on the market to serve, and whether you can show your working. A data governance framework built on the asset model will answer the first question comfortably and the second not at all.

What changes when AI enters the data estate

Three things change at once.

First, training, validation and testing data become a regulated object with statutory quality criteria attached. They are no longer just inputs to an analytics workload, they are the evidentiary basis of a compliance claim about a product.

Second, datasets acquire an accountable owner who has to answer for representativeness, not only accuracy. Those are different properties. A dataset can be flawlessly accurate about the wrong population.

Third, the inventory your data governance framework depends on stops being reliable. Data governance assumes you know which systems consume which data. Undeclared tools break that assumption quietly, which is why shadow AI is a data governance problem before it is a security one. If a team is pasting customer records into an unapproved assistant, no register in your data governance framework records that flow, and no policy in it applied.

EU AI Act Article 10: the obligations your data governance framework has to satisfy

Article 10 is the clause that turns data governance from good practice into a legal requirement for high-risk AI systems. Under Article 10(1), high-risk systems developed with training techniques must be built on training, validation and testing data sets that meet the quality criteria set out in the article.

Article 10(2) then states that those data sets must be subject to data governance and management practices appropriate for the intended purpose, and lists eight things those practices must cover. Read as a specification for your data governance framework, they are:

1. Design choices, documented rather than assumed.
2. Data collection processes and origin, including, for personal data, the purpose for which it was originally collected.
3. Data preparation operations: annotation, labelling, cleaning, updating, enrichment and aggregation.
4. Assumptions about what the data is supposed to measure and represent, written down.
5. Assessment of availability, quantity and suitability of the data sets needed.
6. Examination for biases likely to affect health and safety of persons or fundamental rights, including discriminatory effects.
7. Appropriate measures to detect, prevent and mitigate those biases.
8. Identification of data gaps or shortcomings that prevent compliance, and how they will be addressed.

Article 10(3) adds the quality bar itself: data sets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose, with appropriate statistical properties for the populations the system is meant to serve. Article 10(4) requires that data sets account for characteristics particular to the geographical, contextual, behavioural or functional setting where the system will be used. A hiring model validated on one national labour market does not inherit that validation when it crosses a border.

Article 10(5) contains a narrow and often misread permission: providers may exceptionally process special categories of personal data where strictly necessary to detect and correct bias, subject to safeguards, and only where other data cannot effectively serve that purpose. It is a controlled exception, not a licence to collect sensitive attributes routinely. Article 10(6) closes the loop for systems that do not learn from data: only the testing data obligations apply. The wider structure of these duties is covered in our EU AI Act operator’s guide.

Annex IV and the datasheet duty

Article 10 says what the data must be. Annex IV says what you must have written down. Point 2(d) of Annex IV requires the technical documentation to include, where relevant, datasheets describing the training methodologies and techniques and the training data sets used: a general description of those data sets, information about their provenance, scope and main characteristics, how the data was obtained and selected, labelling procedures, and data cleaning methodologies. Point 2(g) extends the same discipline to validation and testing data and to the metrics used to measure accuracy and robustness.

This is the sentence that changes what a data governance framework has to build. Lineage stops being a convenience for analysts and becomes a documentation deliverable with a named format. The academic reference behind it is Gebru and colleagues, Datasheets for Datasets, which proposed exactly this form: motivation, composition, collection process, preprocessing, uses, distribution and maintenance. If you want a template for the artifact Annex IV asks for, that paper is where to start. Our guide to AI system documentation covers the rest of the file.

What deployers owe under Article 26(4)

Most data governance content addresses the organisation that owns the data. The AI Act also binds the organisation that merely buys the system. Under Article 26(4), a deployer that exercises control over input data must ensure that data is relevant and sufficiently representative in view of the intended purpose of the high-risk system. Article 26(6) requires it to keep the automatically generated logs for at least six months.

So if you licence a scoring model and feed it your own records, your data governance framework carries a statutory duty over those records. Buying the model does not outsource the data obligation.

Mapping the pillars to ISO 42001 and the NIST AI RMF

The useful move is not to replace your data governance framework but to re-scope each pillar so it emits something. This table is the compressed version of that mapping.

ISO/IEC 42001 puts its data requirements in Annex A control A.7, Data for AI systems, which breaks into A.7.2 data for development and enhancement of AI systems, A.7.3 acquisition of data, A.7.4 quality of data, A.7.5 data provenance, and A.7.6 data preparation. If you are certifying against 42001, that is the checklist your data governance framework has to answer to, and it aligns closely with Article 10 without duplicating it. We have written separately on why ISO 42001 alone does not deliver AI Act conformity.

The NIST AI RMF supplies the risk vocabulary rather than a certification target. MAP 2.3 covers scientific integrity and test, evaluation, verification and validation considerations, explicitly including experimental design and data collection and selection. MAP 4.1 and 4.2 address third-party data and the obligation to review externally sourced material for bias, privacy and security risk before it is approved. That last one matters more each year, because most organisations now train or tune on data they did not collect. The full cross-mapping across regimes is in our comparison of NIST AI RMF, ISO 42001, the EU AI Act and the OECD principles.

The artifact list: what the data governance framework has to emit

Here is the practical translation. A data governance framework covering AI systems should be able to produce, on request and per system, the following nine items.

1. Dataset register keyed to the AI system inventory, so any model can be traced to the data it consumed.
2. Dataset datasheet for each training, validation and testing set, in the Annex IV shape.
3. Lineage record from source system to model input, including every transformation.
4. Bias examination report naming the protected characteristics examined and the method used.
5. Mitigation decision log recording what was done about what the examination found, including decisions to accept residual bias and who accepted them.
6. Data gap and shortcoming register with owners and target dates, which is Article 10(2)(h) made operational.
7. Labelling and annotation protocol, with inter-annotator agreement where the labels are subjective.
8. Retention and lawful basis record, joined to the data protection impact assessment wherever personal data is in scope.
9. Named sign-off per dataset release, because an unsigned artifact is an assertion rather than a control.

Items four and five are where most programmes are thinnest, and they are the ones an auditor reaches for first. Our guide to AI bias covers the examination methods themselves.

The critical data element register, extended to AI

Regulated firms already maintain a critical data element register. You do not need a second one. You need a foreign key.

Add a relation from each critical data element to the AI systems that consume it, and the register stops being a data quality artefact and starts answering compliance questions: which models are affected if this element degrades, which datasets inherited this element’s known defects, and which model owners must be told when its definition changes. That single join converts existing work into AI Act evidence at very low cost, and it is the highest-return change most organisations can make to an existing data governance framework.

Building it in 90 days

A workable sequence for an organisation that already has some data governance and now needs it to cover AI.

1. Weeks 1 to 2, scope and legal trigger. Determine which systems are high-risk, which are general-purpose models you are merely deploying, and which are out of scope. The obligations differ sharply, and scoping errors are expensive later.
2. Weeks 3 to 4, inventory. List AI systems and the datasets each consumes. Expect the list to be incomplete on the first pass, and plan a discovery sweep for undeclared tools.
3. Week 5, classification. Tag each dataset by sensitivity, lawful basis, source (internal, third party, synthetic, scraped) and whether it is training, validation or testing.
4. Week 6, ownership. Assign one named owner per dataset. Not a team, a person. Accountability that is shared is accountability that is absent.
5. Weeks 7 to 9, documentation. Write the datasheets to the Annex IV shape. Start with the highest-risk system, because that is where the format gets stress-tested.
6. Weeks 10 to 11, representativeness testing. Compare dataset statistical properties against the intended user population and the deployment setting. Record the gaps you find rather than resolving them silently.
7. Week 12, sign-off and cadence. Get named approval, then set the review trigger. Tie it to retraining events, not to the calendar.

The cadence point is the one most programmes get wrong. If your AI governance framework reviews data annually while models retrain weekly, the documentation describes a system that no longer exists.

Where data governance frameworks fail

Five failure modes account for most of it.

Maturity theatre. The programme scores itself against a capability model and reports improvement, with no evidence behind the score. Self-declaration is not evidence, and any serious assessment treats it as unscored.

Tooling first. A catalogue is bought before anyone has written the policy it is supposed to enforce. The tool then encodes whatever conventions the implementation consultant preferred.

No owner for training data. Source systems have owners. The derived training set that was assembled from four of them, filtered, relabelled and frozen for a model release usually has none.

The registers never join. The data catalogue and the AI system inventory live in different tools maintained by different teams, so no query can answer which model used which data. This is the single most common reason a data governance framework produces nothing usable during an AI audit.

Scope stops at personal data. Privacy programmes cover personal data well. Article 10 covers all training data, including operational, sensor and synthetic data with no personal element at all.

FAQ

What are the four pillars of a data governance framework?

Policies and standards, roles and ownership, processes, and technology. Some vendors split these into five, seven or ten components, but the additions are usually subdivisions rather than new categories. Data quality, metadata management and lineage sit inside processes and technology. For AI systems, treat a fifth concern as mandatory even though it is rarely listed: the evidence the data governance framework produces, meaning the datasheets, lineage records and bias reports a regulator or auditor can actually read.

What are the five key principles of data governance?

Accountability with a named owner for every dataset, transparency about origin and transformation, quality defined against a stated purpose rather than in the abstract, protection appropriate to sensitivity and lawful basis, and traceability from source to consumption. Under the EU AI Act, quality and traceability carry the most weight, because Article 10(3) requires data to be relevant and sufficiently representative in view of the intended purpose, which is a purpose-relative test rather than a general one.

What is the difference between data governance and AI governance?

Data governance governs the data. AI governance governs the systems built on it, plus the models, the deployment decisions, human oversight and the incident response around them. They overlap at exactly one place, the training data, and that overlap is where the EU AI Act puts its heaviest documentation obligations. In practice the two should share an inventory and a risk taxonomy while keeping separate owners and separate review cadences.

Which data governance framework should we adopt: DAMA-DMBOK, DCAM or DGI?

Most organisations do not need to choose. DAMA-DMBOK gives the practice definition and vocabulary, DCAM gives the maturity scoring, DGI gives the decision-rights and accountability design. A common pattern is DMBOK for practice and DCAM to measure progress against it. If AI systems are in scope, none of the three is sufficient on its own, because none specifies the artifacts Annex IV requires. Layer ISO/IEC 42001 Annex A.7 on top for that.

Does the EU AI Act require a data governance framework?

For high-risk AI systems, effectively yes. Article 10(2) requires training, validation and testing data sets to be subject to appropriate data governance and management practices, then specifies eight things those practices must cover. The Act does not name a framework or mandate a particular model, so you can satisfy it with an adapted version of what you already run. What it does mandate is the documentary output, through Annex IV.

Who owns the data governance framework?

Ownership usually sits with a chief data officer or an equivalent data governance lead, with a steering body for cross-functional decisions. What matters more than the title is that dataset-level ownership is individual and that the owner has authority to block a release. Where AI systems are in scope, the data governance framework owner and the AI governance owner need a standing joint decision on training data, because neither can approve a dataset release alone.

Conclusion

The first page of Google will tell you a data governance framework has four pillars and that you should pick a model. That is true and it is where most guidance stops. The harder question is what your data governance framework hands over when someone outside your organisation asks how a model’s training data was assembled, whether it represented the people it would be used on, and who signed it off.

If the honest answer today is a policy document and a catalogue screenshot, the gap is not in your pillars. It is in the artifacts they were never asked to produce. Start with the dataset register keyed to your AI inventory, and the rest of the evidence chain has somewhere to attach.

See how AI Sigil turns data governance obligations into evidence you can hand to an auditor.