What Is a Data Governance Operating Model? The Context Layer View

---

A data governance operating model is the system of decision rights, roles, processes and technology that decides who defines, owns, approves and changes your data. Once AI agents query that data, those decisions have to reach the agent too. Atlan records them in the context layer, which people and agents both read.

---

The traditional outputs of an operating model were documents for people: a charter, a RACI, a glossary, a policy PDF. An agent can ingest those documents, but it cannot tell which version is current, who approved it, or whether it applies to the table in front of it. Structured fields answer those questions, so owners, certifications, classifications and policies need to exist as governed context in an enterprise context layer. In Atlan they live as domains, policies, governance workflows and personas. Through the Atlan MCP server and its agent skills, AI tools can reach governed definitions, glossaries and lineage (Atlan docs, Atlan MCP overview).

The model has four working parts and one structural choice:

• Decision rights name who can define, approve, change and retire a data asset.
• Roles assign that work to an executive sponsor, a council, domain owners, stewards and custodians.
• Processes and their rhythms keep decisions current through certification reviews, change approval, access requests and deprecation.
• Technology records each decision and delivers it to the people and agents who act on the data.
• The choice of centralized, decentralized, federated or hybrid sets where decision rights sit.

What it is	The decision rights, roles and recurring processes that make data governance run day to day
What it decides	Who defines, owns, approves, changes and retires each data asset
Core roles	Executive sponsor, governance council, data owners, data stewards, data custodians
Common models	Centralized, decentralized, federated, hybrid
What changes with AI agents	Decisions must be machine-readable and delivered before the agent acts, with named humans still accountable
Related standards	DAMA-DMBOK; NIST AI RMF GOVERN function (voluntary)

---

What does a data governance operating model actually decide?

An operating model turns the idea of governance into specific decisions, the people who own them and the cadence on which they get revisited. A policy says customer emails are restricted. The operating model says who classified the column, who can grant an exception, and how often someone checks the classification is still right.

A common reference point is the DAMA-DMBOK, which describes the functions, roles and methods of data management. Its second edition updated the data governance content, and DAMA started a DMBOK 3.0 project in 2025 (DAMA International). The book gives you the menu. Your operating model picks from it and puts real names against each item.

In practice it settles five kinds of question. Meaning: what active_customer or net_revenue means, and who signs off on the definition. Ownership: which person or team answers for each domain, table and metric. Access: who can see which data, and who approves an exception. Trust: which assets are certified, and when that certification expires. Change: who approves a schema change, a renamed field or a retired dashboard.

Every one of those answers is something an agent will act on, which is why data governance rules have to be readable by AI agents. A shared data governance taxonomy and a common context layer glossary do more for that than another charter.

---

How is a data governance operating model different from a framework or a policy?

A governance framework says what good looks like. A policy states one specific rule. The operating model says who does the work, how and when. Teams often mix the three up. The practical difference is the calendar: the operating model schedules the policy reviews and certification checks that keep the other two current.

	Governance framework	Operating model	Policy
Answers	What principles and capabilities do we need?	Who decides, through which process, on what schedule?	What is the rule for this data?
Typically owned by	Executive sponsor and council	Council, domain owners and stewards	A named policy owner, often in legal, security or the data office
Typically changes	With strategy	On a set review cycle, and whenever the organization changes	When regulation or risk changes, or at its review date
Example artifact	Principles document	RACI, review calendar, escalation path	“PII columns are masked for non-HR roles”
Who consumes it	Leadership	Owners, stewards, engineers	People and, increasingly, AI agents

An AI governance framework adds model risk, evaluation and use-case approval on top of this, which is where data governance and AI governance start to overlap. A framework can stay on paper. Policies and operating decisions cannot, because agents act on both every time they query a table.

---

What are the components of a data governance operating model?

A data governance operating model has four components: decision rights, roles, processes with their operating rhythms, and the technology where decisions are recorded. Each one used to produce a document. Each one now also needs an output a machine can read.

Decision rights

Decision rights name who can define, approve, change and retire each class of data asset. A finance steward defines net_revenue; the finance domain owner approves changes to it; a platform engineer can deprecate the table that feeds it only after both sign off. Without written decision rights, disagreements escalate to whoever is loudest. The same question now comes up one layer higher, as teams work out who owns the context layer.

Roles: owners, stewards, custodians and the council

The executive sponsor funds the program and breaks ties. The council sets cross-domain standards. Data owners are accountable for a domain, stewards maintain definitions and quality day to day, and custodians run the systems that store and move the data.

AI programs push teams to write these roles down. NIST’s AI Risk Management Framework, released in January 2023 and “intended for voluntary use” (NIST), sets this as GOVERN 2.1: “Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization” (NIST AI 100-1, 2023). A context layer for data governance teams gives stewards a place to do that work, and an AI center of excellence is often where data roles and AI roles meet.

Processes and operating rhythms

Processes are the recurring work: certification reviews, change approval, access requests, deprecation. Rhythms are the part that decays. A certification approved in March says nothing about October unless something re-checks it, and context rot sets in quietly when nothing does. Glossary work shows it most clearly: managing KPI definitions and a business glossary never finishes. It only gets scheduled.

Technology: where decisions are recorded and delivered

Technology is the system of record for ownership, definitions, lineage and policy. A decision recorded there looks like a set of fields. The certified metric net_revenue carries owner: finance-data and certificate_status: VERIFIED. Two hops upstream, the source table crm.customers carries classification: PII on its email column, and the masking rule for that column is enforced in the warehouse. Atlan holds these records in its Enterprise Data Graph, connected by data lineage for AI so a change upstream is visible downstream.

Component	Traditional operating model	Agent-ready operating model
Decision rights	Written in a charter	Attached to assets as owner and approver fields
Ownership record	Spreadsheet or org chart	Named owners on every domain, table and metric
Policy	PDF on an intranet	Rules linked to the assets they govern, enforced where the data is served
Certification	Badge a person reads in a UI	Status the agent’s harness checks before the agent answers
Change approval	Ticket and email thread	Workflow whose outcome updates the context the agent reads
Audit	Who changed the data	Who changed the data, and what the agent read when it acted

---

Centralized, federated or hybrid: which data governance operating model fits?

The model type is a choice about where decision rights sit, and no type is best everywhere. Pick the one that matches how decisions already flow in your business, then test it against what happens as the number of agents reading your data grows.

Model	Who decides	Where it works	Where it breaks with AI agents
Centralized	One central team sets and enforces everything	Smaller or heavily regulated organizations	The central team becomes the queue every change to agent context waits in
Decentralized	Each domain governs itself	Independent business units with little shared data	Agents get conflicting definitions of the same metric across domains
Federated	Central standards, domain ownership and execution	Large enterprises with data shared across domains	Domains lack funded stewards and nobody checks the standards, so definitions drift between domains
Hybrid	Central for regulated data, federated for the rest	Organizations with both regulated and less sensitive data	Agents need to know which regime applies to each asset

Zhamak Dehghani, who introduced data mesh, defined the federated model in “Data Mesh Principles and Logical Architecture” (2020). She described a decision-making model led by a federation of domain data product owners and data platform product owners, with “automated execution of decisions by the platform,” and called it federated computational governance (Dehghani, martinfowler.com, 2020).

The word “computational” carries the weight for agents. A standard that a person checks every quarter reaches an agent a quarter late. How centralized and federated data teams work in the AI era, and whether data teams or AI teams own context, are the live versions of this choice. Atlan’s guides to data governance models and federated data governance go deeper on each type.

---

Why does data governance break when AI agents get involved?

Data governance breaks with AI agents because most operating models were built for people, and agents read differently. A person can be told in a meeting that the revenue table was decertified last week. An agent querying it at 2 a.m. knows only what reaches it.

If a steward certifies a table, classifies a column or names an owner, and that decision lives in a ticket, a slide or someone’s memory, the agent proceeds without it. The decision was made. It never reached the agent.

Agents force four questions every operating model has to answer:

1. Who owns this context? An agent needs a named owner it can cite, and a person who answers for the result.
2. Who approves changes? A definition edited without approval becomes an instruction to every agent that reads it.
3. How do updates propagate? A deprecation that reaches people by email and agents never produces context drift.
4. How do you audit what an agent believed? After an incident you need the definitions and policies the agent read at that moment.

Teams that already enforce access and masking where the data is served may ask why agents need context at all. If your warehouse masks the email column for every role except HR, that rule binds an agent’s service identity whether or not the agent reads a single field of context. Hard rules belong there: who can see a column, which rows a role can query, what gets masked. Context does a different job. An owner field, a certification status or a definition informs the agent’s reasoning, and a model can ignore what it is told. So split the decisions. Anything that must never happen goes into platform enforcement. Anything the agent has to judge, such as which of two revenue tables is trusted, goes into context, backed by a check in the agent’s harness for agents that write: if the asset is not certified, the harness refuses the call.

That split is the practical meaning of AI agent governance, and it explains why AI projects stall on data rather than models. What makes data AI-ready is mostly whether its meaning, ownership and trust status are written somewhere a machine can read.

Proportion matters too. A read-only analytics assistant and an agent that writes to production systems need different levels of review. Keep one source of decisions, connected in a context graph, and apply it in proportion to what each agent is allowed to do. Atlan’s guide to the AI governance operating model covers tiers and the CDO and CAIO split.

---

How to make a data governance operating model agent-ready

Making a data governance operating model agent-ready changes where its decisions are recorded and how they travel. People stay accountable for every decision; each decision also becomes something an agent can read, check and cite.

1. Record every decision where an agent can read it. Owners, certifications, classifications and definitions become structured fields on assets. This is the core of context engineering, and certified metric definitions are what a semantic layer exposes to agents.
2. Put hard rules where the data is served. Access and masking belong in platform enforcement, linked to the assets they govern so stewards can see them. Express quality and schema expectations as data contracts for AI, and design agent access control around role-based access in the context layer. Sensitive fields need the same treatment as in any AI pipeline that handles PII.
3. Deliver decisions before the agent queries. The agent’s harness should look up owner, certification status and applicable policy for each asset it plans to use, and refuse uncertified assets for agents that write. An MCP server is one delivery route; MCP delivers business context to the agent at the point it chooses what to query.
4. Make rhythms propagate. A decertification or deprecation should reach agents the same day it reaches people. Context drift detection flags when the context an agent reads no longer matches the source.
5. Keep humans accountable and auditable. Put people on the loop, with named owners in the graph and decision traces for AI agents that record which assets each agent read and what their status was at the time.

Worked example: one decertification, end to end

Here is how the five steps play out for a single decision, as an illustration. On Tuesday morning a finance steward finds that net_revenue double-counts refunds. She opens a change request; the finance domain owner approves decertification that afternoon, and the metric’s status moves from VERIFIED to DEPRECATED, with net_revenue_v2 named as the replacement. Lineage shows three dashboards and one finance assistant reading the old metric. The dashboards’ owners get a notice. The assistant’s harness checks status before each query, so its next request for net_revenue is routed to net_revenue_v2 or refused. On Thursday, when the CFO’s office asks why Monday’s answer differed from Wednesday’s, the decision trace shows which metric the assistant read on each day and its status at the time.

Most operating models fail for reasons none of this touches. A council that meets but never touches a pipeline produces minutes. Stewards named on an org chart without time or tooling produce stale definitions. Sponsors change, budgets shrink, and domains resist shared definitions. Machine-readable context makes a working program reachable by agents; it cannot rescue one with no business purpose. Implementing an enterprise context layer for AI works best after a clear decision about which business questions agents must answer first.

To find where you stand, run an AI readiness assessment and an AI-ready data checklist. For a fuller curriculum, Atlan’s Modern Data Governance Operating Model course is marked coming soon and taking early-access sign-ups; its planned modules include “Operating Rhythms for Governance,” “Your Core Team and The Skills They Need” and “Design Your Metadata Model.”

---

How do you measure whether a data governance operating model is working?

Measure the business outcome the program was set up for first, then measure whether its decisions reach people and agents in time to change what they do. Coverage numbers alone, such as glossary terms written or tables tagged, count activity.

If the program exists to close the books faster or cut regulatory findings, measure that. Then check delivery. The agent-facing signals below depend on one piece of instrumentation: log the asset identifiers and certification status that each agent call reads, with a timestamp.

What to measure	People-facing signal	Agent-facing signal
Ownership	Share of critical assets with a named owner	Share of agent-read assets that have a named owner
Definitions	Certified definitions for top business metrics	Share of agent queries that resolve to a certified definition
Certification	Certifications reviewed on schedule	Agent calls that read a deprecated asset after its decertification timestamp
Policy	Exceptions approved within the agreed window	Agent calls refused by the harness or the warehouse because of a policy
Change propagation	Days from decision to communication	Time from decertification to the last agent call that still reads the old asset

There is evidence that context of this kind changes agent output. According to Atlan AI Labs research, adding rich semantic metadata delivered a 38% relative improvement in AI-generated SQL accuracy: the win rate rose from 16.1% to 22.2% across 174 unique queries run three times each, 522 evaluations on a 13-table dataset (Atlan AI Labs). The added context was business glossaries, SQL usage patterns and domain hints on top of the schema. That covers the meaning side of an operating model; owners, certifications and approval paths were outside the test. Tie the signals above to context layer ROI and to data quality for AI agents, so the operating model is judged on what agents get right.

---

How Atlan supports a data governance operating model

Atlan records an operating model’s decisions in the context layer, where people work with them and AI tools can reach them. The mapping below uses Atlan’s product documentation as of November 2026.

Operating model component	What Atlan’s documentation describes
Decision rights and ownership	Domains and subdomains organize assets by business function, business unit or brand, region or environment, and promote shared ownership and domain-level governance; domain policies currently apply only within the products module (Manage domains). Data products carry stakeholder roles such as domain owner, data product owner and data engineer (What are data products).
Policy	The policy center gives each policy a named owner and an admin approval step, deprecates a previous version only once the revised one is approved, and reports non-compliant changes to policy owners in near real time (Manage policies).
Rhythms	Governance workflows, switched on from Atlan’s Labs page, ship with templates for change management, new entity creation, access management and policy approval (Automate data governance).
Access	Personas define what each user can see and do, and active governance workflows take precedence over persona permissions, including for admins (Design access, personas, and governance).
Delivery to AI tools	Through the Atlan MCP server and its agent skills, AI tools can search enterprise context, traverse end-to-end lineage and access governed data definitions and glossaries, and every action respects the permissions already set in Atlan (Atlan MCP overview).

Atlan’s Context Agents generate asset descriptions (Atlan). Treat those drafts like any proposed definition: they enter the certification rhythm, and a named steward decides what becomes trusted. MCP for data lineage shows the lineage side in detail, and context graph vs knowledge graph explains the structure underneath. For the governance team’s view, see context engineering for AI governance.

---

Real stories from real customers: Shared vocabulary that reaches AI

A shared business language is one of the oldest outputs of any operating model. Workday’s is now delivered to AI through Atlan’s MCP server.

At CME Group, shared vocabulary and lineage are what Kiran Panja credits for the move from reactive data management to proactive AI enablement.

---

Which of your decisions can an agent already read?

Everything that made an operating model work before agents still applies, and much of it is political: a sponsor who stays, stewards with real hours, domains willing to share one definition of revenue. Agents add volume and remove the follow-up question. An analyst who doubts a number can ask in a meeting. An agent reading net_revenue at 2 a.m. cannot, and no council will review its queries by hand.

Pick your most-queried domain and list its owners, certified metrics, access rules and open change requests. For each, check whether an agent can read it today or whether only a person in the room knows it. The AI-ready data guide covers the rest of that check. The question most programs have not answered yet is who reads the decision traces once agents start acting on that domain every hour.

---

FAQs about data governance operating models

1. What is a data governance operating model?

A data governance operating model is the system of decision rights, roles and recurring processes that decides who defines, owns, approves and changes data in an organization. It turns governance principles into named owners, review cadences and escalation paths. With AI agents reading enterprise data, those decisions also have to be recorded in a form agents can read.

2. What is the difference between a data governance framework and an operating model?

A framework describes what good governance looks like: principles, capabilities and goals. An operating model assigns that work to people and processes, saying who decides, how and on what schedule. The framework changes with strategy. The operating model changes as the organization does, and it owns the review calendar that keeps policies and certifications current.

3. What are the types of data governance operating models?

The four common types are centralized, decentralized, federated and hybrid. Centralized puts all decisions with one team. Decentralized lets each domain govern itself. Federated sets central standards and leaves ownership with domains. Hybrid applies central control to regulated data and federated control elsewhere.

4. What roles are in a data governance operating model?

Typical roles are an executive sponsor who funds and arbitrates, a governance council that sets standards, data owners accountable for domains, data stewards who maintain definitions and quality, and data custodians who run the underlying systems. For AI risk, the voluntary NIST AI Risk Management Framework calls for roles and lines of communication to be documented and clear to everyone involved.

5. Which data governance operating model is best for a large enterprise?

Large enterprises with data shared across domains often choose a federated model: central standards with domain ownership and execution. Its common failure is domains without funded stewards, where standards exist but nobody checks them. It works with AI agents when the shared rules are enforced by the platform, not by periodic manual review.

6. Why do data governance operating models fail?

Organizational causes come first. Councils meet without changing pipelines, stewards are named but never given time, sponsors move on, and the program is not tied to a business outcome anyone cares about. With AI agents, a newer failure appears: decisions are made but never reach the agents acting on the data.

7. How does a data governance operating model change for AI agents?

Owners, certifications, classifications and policies have to be recorded as structured context, delivered before an agent queries, and kept current as review rhythms run. Hard rules such as access and masking stay enforced where the data is served. Humans remain accountable, and audit has to capture which assets each agent read and their status when it acted.

---

Sources

1. Body of Knowledge (DAMA-DMBOK), DAMA International
2. AI Risk Management Framework, National Institute of Standards and Technology
3. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023
4. Data Mesh Principles and Logical Architecture, Zhamak Dehghani, martinfowler.com, December 2020
5. Rich semantic metadata improves AI-generated SQL accuracy, Atlan AI Labs
6. Context Agents, Atlan
7. The Modern Data Governance Operating Model course (coming soon), Atlan
8. Manage domains, Atlan documentation
9. What are data products, Atlan documentation
10. Manage policies, Atlan documentation
11. Automate data governance, Atlan documentation
12. Design access, personas, and governance, Atlan documentation
13. Atlan MCP overview, Atlan documentation