How to Implement an Effective Data Governance Framework in the AI Act Era

What a data governance framework is today (and what it isn't)

A data governance framework is the structured set of policies, processes, roles and technologies that determines how an organization defines, manages, protects and uses its data across its entire lifecycle. It's not a cataloging project with an end date. It's not installing a tool and calling it a "catalog." It's not naming someone "data owner" without giving them authority or real time to exercise it.

In 2026, a complete framework spans six dimensions that must operate in parallel, with cross-visibility. If each one lives in a silo, what you have isn't governance — it's the illusion of governance, which is almost worse because it creates false confidence:

• Data governance architecture: domain structure, platforms and access layers.
• Data governance roles: who decides, who executes, who audits, and with what authority.
• Data quality management: rules, thresholds, alerts and continuous remediation processes.
• Metadata automation: capturing, enriching and publishing metadata without manual friction.
• Data lineage tools: traceability from source all the way to the report or AI model.
• AI Act compliance: dataset documentation, bias management and auditable logs of automated decisions.

Real problems seen in complex environments

Managing data across a group with multiple airlines — each with its own stack, its own teams and its own business definitions — teaches you to spot the structural failures of governance before they show up in an audit report. These are the ones that recur most often, regardless of industry:

• The same KPI, five different definitions. In multi-entity environments without a centralized business glossary, each team calculates its metrics independently. The result: a leadership meeting can start by arguing over which number is correct instead of what decision to make.
• Catalogs built and abandoned. Budget gets invested in a tool, an initial metadata load happens, and three months later nobody updates it because "there's no time." Without a maintenance process built into daily work, the catalog becomes a liability, not an asset.
• Inherited RBAC with no review. Access groups configured in Snowflake or Power BI in year one are still active in year three, with users who changed roles, left the company, or hold privileges that no longer match their function. That's a security risk and an audit problem.
• Lineage broken between layers. Data arrives from a transactional source, goes through several transformations, and lands on an executive dashboard. But if someone asks "where exactly does this number come from," the answer is silence or a multi-day investigation.
• One-off data quality management. Quality gets validated at project kickoff, a report gets published, and it isn't measured again until the next audit. Data quality isn't a state; it's a continuous process.

These problems aren't exclusive to small or low-maturity organizations. I've found them in environments with thousands of users, modern cloud stacks and well-trained data teams. The root cause is almost always the same: governance is treated as a compliance project with an end date, not a permanent organizational capability.

How the AI Act changes the rules

AI Act compliance introduces a level of documentary rigor few organizations have today. Since August 2, 2026, AI systems classified as high-risk — HR tools, credit scoring, candidate selection, critical infrastructure control — must meet a set of requirements about the data feeding them.

What matters here is that the AI Act doesn't just regulate the model: it regulates the data that model was trained, validated and monitored with. That means your data governance framework must explicitly extend to AI datasets:

• Training dataset documentation: origin, transformations applied, selection and exclusion criteria.
• Bias management: representativeness analysis, fairness metrics and evidence of continuous monitoring.
• Full traceability: lineage covering everything from the original source to the model deployed in production.
• Automated decision logging: auditable logs of when and how the model made decisions affecting people.
• AI data lifecycle management: retraining processes, dataset versioning and controlled model retirement.

If you already have an operational data governance framework with lineage, a catalog and quality control, adapting to the AI Act is incremental and manageable. If you don't, the adaptation cost multiplies. Penalties for noncompliance can reach 3% of global annual turnover for provider-obligation infringements, and up to 7% for infringements of the prohibited-practices regime.

For a deeper look at the Regulation's specific deadlines and obligations, see The AI Act in 2026: timeline, obligations and when real application begins.

Data governance framework, step by step

1. Define the data governance architecture before touching tools

The first mistake organizations make is buying a tool before the structure is clear. The data governance architecture answers three questions: what are my data domains? who owns each one? how do they connect and what access layers exist? Without this map, any catalog you install will be a metadata repository with no context — useful to no one.

In multi-entity environments like the one I managed at IAG, this architecture is designed in two layers: a corporate layer with master domains (Customers, Product, Operations, Finance) and shared canonical definitions; and a local layer per entity with its own adaptations, always subordinate to corporate standards.

2. Formalize data governance roles with real authority

Data governance roles without formal authority are decorative. A Data Steward who can't make a single decision without going through three committees can't do their job. A Data Owner with no time allocated to review their domain's quality is a name on a RACI chart, not an accountable owner.

The minimum viable structure includes: Data Owners per domain with formal accountability and dedicated time, Data Stewards with operational decision-making capacity, a Data Governance Committee that meets monthly with a real agenda, and a Data Engineering team that implements and maintains the framework's technical infrastructure. In regulated environments, the DPO needs direct visibility into the framework, not just into GDPR matters.

3. Implement a metadata catalog with metadata automation

Metadata automation is what makes a catalog sustainable long-term. If populating and maintaining metadata depends on intensive manual work, the catalog dies within weeks. The goal is for technical metadata (schemas, types, lineage) to be captured automatically from Snowflake, dbt or your data platform, so Data Stewards only need to enrich the business context: definitions, owners, sensitivity classification and quality rules.

In practice, this means integrating the catalog with your data pipelines from day one, not as an afterthought. A catalog fed retroactively is never up to date.

4. Activate data lineage tools with end-to-end coverage

Lineage is data's proof of life. It must cover the full journey: transactional source → ingestion → transformation → semantic model → consumption (dashboard, API or AI model). With Snowflake and dbt, technical lineage can be almost fully automated. Business lineage — which business transformation each step represents, what rules were applied, who approved them — requires initial manual enrichment, but stays low-maintenance once established.

Data lineage tools are also the foundation of the documentation the AI Act requires for high-risk systems. No lineage, no traceability. No traceability, no compliance.

5. Establish data quality management as a continuous process

Data quality management isn't an ETL validation step. It's a data SLA: a set of defined rules, acceptance thresholds agreed with the business, automatic alerts when they're breached, and remediation processes with an assigned owner. Tools like dbt tests, Great Expectations or Soda let you define these rules as code, integrate them into pipelines, and publish results on dashboards visible to Data Owners.

In environments with multiple data sources — as happens in groups with several operating entities — quality rules are defined at two levels: global rules applicable to all domains and local rules specific to each entity or market.

6. Govern access with granular RBAC and periodic review

Access management is one of the most neglected dimensions of governance and one of the most critical in audits. Implementing RBAC in Snowflake with Row-Level Security in Power BI's semantic layer guarantees each user sees exactly what they should — no more. Automating access request and approval workflows adds full traceability: who requested, who approved, when and why.

Equally important is periodic review. Active access should be reviewed at least quarterly, with documented evidence. An audit dashboard showing active access, last review dates and users with privileges pending quarterly validation turns this task into a manageable process, not a semi-annual investigation project.

7. Document AI datasets per the AI Act

For every high-risk AI model, create a dataset record: origin, extraction date, transformations applied, representativeness metrics, owner and last review date. This document is your first line of defense in an AESIA or AEPD inspection. It doesn't need to be complex; it needs to be complete, up to date and accessible to the compliance team.

Recommended tools by maturity and stack

There's no perfect tool for every context. The choice depends on your tech stack, budget and existing governance maturity. This table summarizes the strongest options on the market in 2026:

For teams working with Power BI who want to go deeper on the BI Ops and access-control layer, ISO 42001 vs NIST AI RMF: how to choose your AI Governance framework complements this guide well from the management-framework angle.

What works in practice: cases from complex environments

Case 1 — Federated governance across a multi-airline group

Managing data across a group of seven airlines operating under one holding company presents a challenge most frameworks don't account for: each entity has its own definition of key concepts like "active passenger," its own quality rules and its own data teams with different cultures. A single, centralized framework doesn't work — it generates pushback and immediate workarounds.

The model that worked was a federated data governance architecture in two layers: a corporate layer with master domains, canonical definitions, cross-entity lineage in Snowflake and global access policies; and a local layer per airline with its own adaptations, always subordinate to corporate standards. The centralized catalog with automated ingestion from Snowflake and semantic models in Power BI drastically reduced discrepancies between reports within the first six months of operation.

Case 2 — RBAC and access auditing in Snowflake and Power BI

In auditable environments with sensitive operational data, access management can't depend on emails and verbal approvals. Implementing granular RBAC in Snowflake — with roles per business domain, not per individual user — combined with Row-Level Security in Power BI's semantic layer guarantees each profile accesses exactly what it needs, with no over-privileging.

The differentiating factor was the audit dashboard: a Power BI view showing active access by role in real time, last review dates, and users with privileges pending quarterly validation. This turned access review from a dreaded manual task into a twenty-minute process with documented evidence.

Case 3 — Metadata automation in commercial BI teams

In BI consulting projects for commercial teams, one of the main bottlenecks is the time analysts spend hunting for the correct definition of a metric or the origin of a field. The solution was integrating dbt Docs as a living documentation layer — automatically updated with every deploy — and publishing business metadata directly on Power BI Service datasets, with descriptions, owners and sensitivity classification visible to any user.

The most tangible result wasn't technical: it was the reduced onboarding time for new analysts and fewer questions to the data team about definitions. When documentation lives where the user already works, it gets used. When it lives in a separate wiki, it doesn't.

Common mistakes in adopting a data governance framework

These are the most frequent failure patterns seen across the market, both in organizations just starting out and in those that have spent years trying to consolidate their governance:

• Starting with the tool, not the structure. Buying Collibra or Purview before domains, roles and policies are defined guarantees an empty, expensive catalog. The tool amplifies what already exists; if nothing exists, it amplifies the chaos.
• Data governance roles with no authority or time. The Data Steward "is responsible" but can't make a single decision without approval from three committees and spends 10% of their day on governance. Accountability without authority or resources doesn't produce results — it produces frustration and quiet abandonment of the role.
• Data quality as a one-off event. Measured at project kickoff, a findings report gets published, and it isn't reviewed again until the next audit. Data quality is perishable: a process with no continuous monitoring doesn't take long to degrade.
• Assuming the AI Act is only for Big Tech. Any company using risk scoring, candidate selection systems, predictive analytics in essential services, or automated decisions affecting people can fall within scope. Company size isn't the criterion — the type of AI use is.
• Technical lineage with no business context. Knowing data comes from table X in system Y isn't enough. What the business needs — and what the AI Act requires — is understanding what business transformation that data represents, what rules were applied, who approved them, and whether the data is subject to regulatory restrictions.
• Not measuring governance ROI. Without visible metrics — reduced quality incidents, faster resolution of data queries, number of unauthorized access attempts caught — the governance budget gets cut in the next planning cycle. What isn't measured doesn't get defended.

Conclusion: data governance is a competitive advantage

A well-implemented data governance framework doesn't just reduce regulatory risk under the AI Act. It speeds up analyst onboarding, improves trust in data for decision-making, reduces production quality incidents, and builds the documentary infrastructure that lets AI usage scale sustainably.

The difference between organizations that move forward and those that stall isn't budget or technology — it's whether they treat governance as a project with an end date or as a permanent organizational capability. The ones that understand it that way are the ones that, in the years ahead, will be able to deploy high-risk AI with confidence, speed, and documentary evidence ready for any inspector.

If you're evaluating where to start or how to mature your current framework, the first step is always the same: an honest assessment of where you stand. Without that map, any investment in tools or processes is likely to get lost in already-accumulated technical and organizational debt.

Checklist: AI Act-ready data governance framework

• Data domains defined and assigned to Data Owners with a formal RACI.
• Operational data governance roles with real authority, dedicated time and regular meetings.
• Active metadata catalog with automated ingestion from data platforms.
• End-to-end data lineage documented: transactional source → transformation → consumption.
• Data quality management with defined rules, thresholds, alerts and remediation owners.
• RBAC implemented with RLS at the semantic layer and documented quarterly access review.
• Dataset records for all high-risk AI models (AI Act, Art. 10).
• Auditable automated-decision logs accessible to AESIA and the AEPD.
• Audit dashboard with governance KPIs visible to stakeholders and compliance.
• Governance ROI measured and communicated to leadership quarterly.

Frequently asked questions

What is a data governance framework and why is it urgent to implement now?

A data governance framework is the set of policies, processes, roles and technologies that govern how an organization manages, accesses and uses its data. With the AI Act fully in force since August 2, 2026, implementing one has moved from best practice to a legal obligation for companies operating high-risk AI systems. On top of that, in any advanced analytics environment, data quality and traceability are directly proportional to the quality of business decisions.

Which roles are essential in a data governance framework?

The minimum roles are: a Chief Data Officer (CDO) or equivalent with executive authority, Data Stewards per business domain with operational decision-making power, Data Owners with formal accountability for the quality and use of their data, a Data Engineering team for technical implementation, and a Data Governance Committee for strategic decisions. In regulated environments, the DPO needs direct visibility into the framework.

How does the AI Act affect my company's data governance?

The AI Act requires high-risk AI systems to have documented training data, traceable lineage, auditable quality metrics and access governance. This means your framework must cover not just operational data, but also the datasets used in AI models, with documentary evidence to support AESIA and AEPD inspections. Fines for noncompliance reach up to 3% of global annual turnover.

Which data lineage tools are best to start with?

For cloud teams on Snowflake or Databricks, OpenMetadata is the strongest, most actively maintained open source option in 2026. For enterprise solutions with support, Collibra, Alation or Microsoft Purview are the most mature. For most teams starting out, dbt plus OpenMetadata offers the best balance of cost, automation level and a reasonable adoption curve.

How long does it take to implement a complete data governance framework?

A minimum viable framework — defined roles, a basic catalog, access policies and lineage for critical domains — can be operational in 3 to 6 months with organizational will and dedicated resources. A mature framework with metadata automation, continuous data quality management and full domain coverage takes 12 to 24 months, depending on the organization's size, accumulated technical debt, and the amount of cultural change required.