Data Governance: Agreements That Support Decisions

The term “data governance” is often associated with committees and documents. Its actual function is more concrete: establish agreements that make it possible to know what data means, who is accountable for it, how reliable it is, and who may use it.

Let us start with a scene you might recognize

Picture a table called customers in your company data warehouse. Everyone uses it: finance to calculate revenue, marketing to launch campaigns, the BI team for the dashboards leadership reviews every Monday. One day, someone new asks a basic question: who owns this table?

$ describe table customers

owner:        (unassigned)
description:  (empty)
last_updated: 11 months ago
used_by:      47 dashboards, 12 pipelines

A critical table with no owner, no description, and 47 dashboards depending on it. More common than it looks.

Silence. The person who created it no longer works at the company. Nobody knows for sure whether status = 'A' means "active" or "archived". Finance and marketing report different active-customer figures every month, and every results meeting starts with twenty minutes of arguing over whose number is the real one. We have seen this scene, with small variations, in telecom operators, banks, and startups. It is not a technology problem — all of those companies had modern tools. It is an agreements problem.

The definition, without jargon

Data governance is, in essence, agreeing on your data and writing that agreement down. Four agreements, specifically:

• Who answers for each piece of data. Every important table, report, or metric has an owner with a first and last name. If customers breaks, nobody hunts for a culprit: everyone knows who to ask.
• What each thing means. "Active customer" has one official definition, written down and shared — not five versions living in five different heads.
• How reliable it is. You know whether the data arrived complete, on time, and without duplicates, before a broken dashboard tells you in front of leadership.
• Who can use what. Personal data is identified and protected; not everyone with warehouse access can export your customers' phone numbers.

Formal definitions — like the one in the DAMA-DMBOK framework, the classic body of knowledge of the discipline — speak of "the exercise of authority and control over the management of data assets". That is correct, but the essence is the one above: explicit agreements instead of tribal knowledge.

What happens without it?

The absence of data governance almost never feels like a catastrophe. It feels like permanent friction that everyone ends up normalizing:

• The Monday report wakes up broken. Someone renamed a column in a source system on Friday afternoon. Nobody knew what depended on it, so nobody gave a heads-up. It is discovered when leadership asks why the dashboard is empty.
• Two departments, two truths. Finance says there are 1.2 million active customers; marketing says 1.5. Both are right by their own definition — and that is exactly the failure.
• Analyses take weeks instead of days. Most of an analyst's time goes into finding the data, understanding what it means, and verifying whether it can be trusted. Only a fraction goes into actually analyzing it.
• Fear of touching anything. Nobody deletes or modifies old tables "just in case something uses them". The warehouse accumulates layers of sediment, and every year everything gets a little slower and more expensive.
• Silent regulatory risk. Personal data copied across six different tables, with nobody knowing which ones or who has access. With data protection laws advancing across Latin America, this is no longer a technical detail: it is a legal risk.

How to recognize a useful governance practice

A useful practice is defined by how it assigns decisions and reduces operating friction:

• Accountability close to the data. Owners resolve issues within a clear framework; a council arbitrates exceptions rather than every change.
• Continuous operation. Definitions, controls, and owners are reviewed when systems or business needs change.
• Proportional scope. Work starts with critical decisions and assets instead of trying to govern everything at once.

Why it matters more than ever

For years, the cost of not having data governance was tolerable: slow reports, arguments over numbers, the occasional regulatory scare. Artificial intelligence changed that equation. An AI model trained on data with no definitions, no owners, and no quality controls does not produce timid errors: it produces confident, wrong answers, at scale, in front of customers.

If a human analyst uses a dubious figure, someone can challenge it in a meeting. If an AI agent incorporates that figure into an automated workflow, the error may propagate before review. AI does not correct disordered data by itself. An AI initiative therefore needs definitions, provenance, and controls for the data it uses.

Where do you start?

You do not start by creating a committee or buying a tool. You start small and concrete:

• Inventory what is critical. Not the whole warehouse: the 20 or 50 tables and the 10 reports the business actually lives on.
• Assign owners. One person per critical asset. Not a department, not a team: one person.
• Write down the key metric definitions. What an "active customer" is, what "revenue" is, since when, and with which exceptions.
• Measure the quality of what is critical. Simple rules at first: did today's data arrive? Are there duplicates? Are there nulls where there should be none?

These four steps point to three capabilities every governance practice ends up needing: a data catalog, lineage (the dependency map), and data quality. We cover those three pillars in detail in the next article of this series.

Data governance turns implicit knowledge into responsibilities and controls the organization can operate.

If you need to define ownership, metrics, quality, or an operating model, tell us about your case. If the gap is not yet clear, the maturity self-assessment can help locate it.