Data governance operating model: Data Owner, Data Steward, committee and RACI

Data governance has ceased to be a theoretical conversation and has become an operational necessity.

As organizations advance in Data & AI initiatives, friction points increase: 

• Who can use the data.
• Which version is valid?.
• How is quality guaranteed?.
• Which decisions to prioritize.

In this context, the problem It is not usually a lack of tools or intention, but the absence of a clear model for making decisions.

Many organizations invest in ambitious governance frameworks that end up being difficult to implement. The result: more bureaucracy, less speed.

The alternative is not to eliminate government, but to implement a viable governance model that works with clear roles, defined responsibilities, and rhythms that sustain frictionless operation.

This article proposes that approach: moving from concept to implementation.

The problem: data governance without owners is bureaucracy without impact.

In many organizations, data governance exists on paper, but not in practice. There are policies, guidelines, and definitions, but when a concrete decision arises, no one has a clear mandate to make it.

This misalignment creates a recurring pattern: teams know that data is critical, but they lack clarity on who defines what. The result is that Decisions are diluted or escalated unnecessarily..

The symptoms are clear: no one makes decisions about the data, conflicts arise between departments, and initiatives are stalled due to a lack of clarity.

Behind these symptoms lies a structural problem: a lack of ownership. As a consequence, governance becomes a consultative process with no real impact. That is to say, without ownership, There is no government.

What is an operating model and why does it define government success?

Before defining roles or tools, it's necessary to understand what a data governance operating model truly means. It's not about how the company is organized, but about how decision-making flows. 

It is the set of explicit rules that determine who decides, who executes, and how those actions are coordinated over time.

An operating model It includes roles, responsibilities, decisions, and cadences.. Its value lies in its ability to order execution.

When the operating model is clear, teams can move forward without relying on constant validation. When it isn't, every decision becomes an exception.

This directly impacts Data & AI initiatives, where a lack of data consistency leads to unreliable results. Also It affects privacy issues., where ambiguity in responsibilities exposes the organization to unnecessary risks.

In conclusion, we can point out that the operational model is what transforms data governance into a real capability, not just an intention.

Key roles: Data Owner, Data Steward, IT and Business

A common mistake is over-structuring the governance framework with multiple roles that end up overlapping. In practice, A minimum viable model works best when it relies on a few well-defined roles..

Each role fulfills a specific function within the decision-making system. It's not just about assigning names, but about defining clear and sustainable responsibilities over time.

The balance between these roles is what allows the model to function without generating unnecessary friction:

Data Owner (business)

This person has ultimate responsibility for a data domain. They define what that data means, what quality is expected, and what it can be used for.

It is not a technical role, but a business one, because decisions about data are directly linked to the value it generates.

Data Steward (operational)

This is the role the government plays on a daily basis. It is responsible for quality, documentation, and issue management.

Its value lies in translating the Data Owner's definitions into concrete practices. 

IT / Data Platform

It is the one that enables the model. It defines how data is accessed, integrated, and protected.

Without this layer, government cannot scale; but without business, it loses its purpose.

Security / Compliance

It acts as a guarantor of compliance. It defines policies and validates that controls are applied correctly.

Its function is not to stop, but to ensure that the use of the data is correct.

Data committee: what it decides and what it doesn't. 

The data committee is often one of the most poorly designed components of the model. In many cases, it becomes a space for reporting or monitoring, where progress is shared but no decisions are made.

An effective committee has a clear objective: to unlock decisions that cannot be resolved in the operation.

This implies explicitly defining its scope:

• What needs to be decided: data rules, priorities, and conflicts between areas.
• What not to do: operate, review daily tasks, and turn into an informational meeting.

Frequency is also key. A monthly committee meeting is usually sufficient to maintain momentum without creating overload.

Participants should represent the key areas: business, data, IT, and compliance. This should be based on decision-making capacity, not hierarchy.

The central idea is simple: the committee exists to decide, not to inform.

Minimum viable RACI: who defines, who implements, who approves

In practice, most data governance roadblocks are not due to a lack of information, but to a lack of clarity about who needs to be involved in each decision.

The RACI solves that problem. It's not just a formality or another document: it's the mechanism that translates the operational model into action. It ensures that every decision has a clear path, avoiding ambiguities, unnecessary back-and-forths, and escalations that could have been resolved at the appropriate level.

A good RACI doesn't aim for complexity. It aims for something much simpler: that, in any situation, Everyone should know who executes, who decides, and who participates..

What does each role mean in practice?

• Responsible (responsible for execution). This is the person who makes things happen. They execute the task, coordinate actions, and ensure the process moves forward. In data governance, this is usually the Data Steward or operational teams.
• Accountable (final responsibility / decision-maker). This person has the final say. They define and take responsibility for the outcome. There should only be one person accountable for each decision. In most cases, this is the Data Owner.
• Consulted (Consulted). They are the ones who provide input or validation before the decision is made. Their participation improves the quality of the decision, but it doesn't block it.
• Informed (Informed).  These are the people who need to be aware of the outcome, but they don't actively participate in the decision. This role prevents rework and subsequent misalignments.

The key to RACI is not listing people, but clearly defining the decision flow.

Two real-world examples of RACI in operation

Case 1: Quality problem in critical data

Situation: Inconsistencies are detected in a dataset used for executive reports.

• Responsible: Data Steward. Identifies the issue, documents it, and coordinates its resolution
• Accountable: Data Owner. Defines what level of quality is acceptable and prioritizes the solution.
• Consulted: IT / Data Platform. Analyzes the technical origin of the problem and proposes solutions.
• Informed: Data users. Receive alerts about the problem and its resolution

What does RACI solve in this case? It avoids arguments about "whose problem is it?" The Data Owner defines the standard, IT provides the technical solution, and the Data Steward implements it.

Case 2: Defining a new use of data (AI or analytics case)

Situation: A team wants to use existing data for a new analytical model.

• Responsible: Data team / Data Steward. Analyzes availability and prepares data.
• Accountable: Data Owner. Defines whether that usage is valid from a business perspective.
• Consulted: Security/Compliance + IT. They assess risks, access, and technical feasibility.
• Informed: Business stakeholders. They are aware of the new use and its impact

What does RACI solve in this case?: It ensures that new uses of data are not defined solely from a technical standpoint, but with business validation and compliance.

Conclusion regarding both cases

In all cases, the pattern is the same: when the RACI is clear, decisions flow. But when it isn't, bottlenecks appear.

The goal is not to document everything, but Identify critical decisions and ensure that each one has a defined path..

Cadences and rituals: how to sustain the model without friction

Defining roles and responsibilities is only the first step. The central challenge is sustaining the model over time.

Without clear timelines, government becomes reactive. Problems are addressed only when they erupt, and decisions are driven by urgency rather than priorities. Conversely, a system with too many meetings leads to burnout and bureaucracy.

The objective is Finding a balance with a system of rituals that keeps the model active without overburdening the teams.

A minimum viable scheme can be structured as follows:

• Weekly: operations (issues, quality, follow-up). Allows for resolving operational problems before they escalate.
• Monthly: committee (strategic decisions). Ensures alignment on key decisions.
• Quarterly: model review. Allows for adjusting the model based on what has been learned.

Beyond frequency, what matters is consistency. A model that runs consistently generates trust and predictability.

Common mistakes when implementing data governance

Implementing data governance does not usually fail due to a lack of knowledge, but rather due to errors in execution.

One of the most frequent mistakes is defining roles without real clarity. If the boundaries between responsibilities are blurred, decisions become diluted and conflicts increase.

Another common mistake is designing committees without decision-making power. They become mere coordination bodies that fail to resolve structural problems.

It is also common to fall into excessive governance without delivery. Time is spent defining frameworks and policies, but not making them work in practice.

The lack of integration between IT and business is another critical issue. If these areas operate in a decoupled manner, the model loses effectiveness.

Finally, many organizations do not measure the impact of government. Without metrics, it is difficult to justify investment or adjust the model.

These errors share a common root: prioritizing design over execution.

Checklist to know when to scale

Before scaling a data governance model, it is necessary to validate that the basic elements are resolved.

This checklist It serves as a quick reference to identify whether the model is ready to operate or if it still requires adjustments.

Your operating model is ready if:

• Each domain has a defined Data Owner.
• There is a Data Steward with clear responsibilities.
• IT and business are aligned in accessing and using data.
• There is a committee with decision-making power (not just monitoring).
• There is a documented and applied RACI.
• There are clear cadences (operation + decision).
• Results are measured (quality, use, impact).

If any of these points are not covered, the model is likely to experience friction when scaling.

Next step

Moving from design to implementation requires concrete tools. Understanding the model is not enough; it must be applied.

Therefore, a practical approach is to start with a minimum viable kit that allows for the rapid structuring of data governance, including:

• RACI Matrix 
• Definition of roles
• Committee outline
• Cadence calendar
• Implementation Guide 

If the goal is to accelerate implementation and adapt it to the organization's context:

Schedule a work session to design the model and implementation plan.

To delve deeper into the strategic approach to Data, Go read this article.