Governance that says yes

Govern data for what it lets the business do, not for its own sake. Data has to earn its place commercially, so treat it as a product with customers and an owner, not as a reporting cost. You can't govern everything at once, so start with the data your revenue and key decisions depend on, and make every control point to something it lets people do.

Ownership has to cover the whole journey, from source to the reports at the end. The team that creates data owns it as a product and publishes it to an agreed data contract, so others can rely on it. Whoever builds on it owns what they build. Lineage connects the two, so when something changes upstream you know who's affected. If billing changes how it records a tariff, the teams building on that data hear about it before their reports break.

A small central team sets the standards owners work to and decides what crosses domains. Owners make the calls within those standards, and stewards look after the data day to day.

Governance only works if everyone treats data as their responsibility, not just the data team's. Software teams often change a field or a status to suit their own system without knowing that a finance report or a client feed depends on it. Usually nobody told them. Engineers need to see who uses their data, and treat a change to it like a change to an API.

Controls help, but people go around them unless the safe route is the easy one. That means keeping data in governed tools: sharing a link to a dashboard or dataset rather than exporting a file, so masking and retention still apply.

It also helps when people understand why a rule exists, not just what it says, because then they follow it where no control reaches. That takes practical training on your own data, not a yearly policy course. And it should feel normal to ask "can we use this?" early, because asking early is how you get a quick yes.

Classification is the foundation most other controls build on. You can't mask what you haven't labelled, or decide whether data can go into AI if nobody knows what's in it. The labels belong in a good data catalogue, next to each dataset's owner and definition, so there's one place to look. Label columns, not just tables, because a table takes the label of its most sensitive column. Four levels is the common pattern, such as Public, Internal, Confidential and Restricted. Use whatever names your organisation already has.

Doing it by hand doesn't scale. An LLM can classify columns from their names, a sample of the data and the system's design documents, with a human feedback loop so that corrections improve its future answers. The sample may hold personal data, so if your rules need it, the model can be self-hosted and the data never leaves your own setup.

Lineage is what lets ownership and classification reach past the source. It answers two questions: "where did this number come from?" and "what breaks if I change this?". A change at source can be traced to every owner it affects, and a column that's personal at source stays labelled personal in everything built from it. Capture it automatically from the platform, because diagrams drawn by hand are out of date by the next release.

When two people bring different numbers to the same question, both are usually right. They're just counting different things. The fix is a definition and an owner for anything people rely on. Different views are fine, as long as each has its own name.

On the business side, that means the KPIs and key concepts, such as what counts as an active customer. On the technical side, it means what each data product represents, its grain and how its key figures are calculated. Keep both in the catalogue, so every report works from the same definitions and the same question gets the same answer.

I think of quality in three layers. Generic checks, like freshness, volumes and nulls, can be run without knowing anything about the data. They're easy to switch on, but on their own they mostly raise noise. Domain checks need someone who knows the data, such as spotting gaps in a customer's charges. Consumer checks are about what a particular team or customer expects: a system can rightly allow a customer more than one live account, while a client's reports assume one. Most of the value is in the last two.

Flag bad rows rather than dropping them, so counts still reconcile to the source and nothing goes missing unnoticed. Then turn quality issues into metrics with an owner, where people already look, and fix them at source.

Most data should be open to the people you work with, and the tight controls kept for personal and sensitive data. Give anyone with the right relationship, such as an employee or a contractor under contract, access by default. Tie the tight controls to classification, so a new table holding personal data is protected as soon as it's classified, without anyone writing a new rule.

The mechanics are what make that safe. Manage access through a single identity provider, so joiners, movers and leavers change what people can see automatically. Grant it by role and write it as code, so every change is reviewed and can be audited.

The decision to collect personal data is made in the source system, so the warehouse's job isn't to second-guess it. Its job is to protect it. Most uses of data don't need the personal details in it. An analyst reporting on live accounts doesn't need names or addresses. So mask personal and sensitive fields by default as the data is served. People and tools still get what they need, without detail they don't. Any new use of personal data needs a clear purpose and an early privacy impact assessment.

If something does go wrong, or a customer asks what you hold on them, classification and lineage show you quickly what's involved and where it is.

Capturing data from day one doesn't mean keeping all of it forever. Personal data in particular needs a retention period, set by what it's used for and by what the law requires. Decide those periods early, even if nothing needs deleting yet. A young business with a seven-year period may not reach it for years, which gives it time to build deletion properly, as long as it works before the oldest data hits the limit.

Set retention against the classification, so it applies automatically rather than table by table. Deletion has to reach every copy: lineage shows where the data went, and table history and backups can hold deleted rows long after you think they've gone.

Share data system to system, as a product, rather than as one-off extracts. Each share is backed by a data contract covering what's in it and an agreement covering what the recipient can do with it, and the catalogue says what the data means. Whether it goes through an open sharing protocol or as files to the recipient's own storage, the terms stay the same.

What you can do also depends on whose data it is. If it's yours, you decide how it's shared. If you hold it for a client, as most SaaS businesses do, your agreement with them sets the limits, including which suppliers can touch it. A client may be happy for their data to sit with your cloud provider but not with a new AI supplier. Check that before you build, not after.

AI governance isn't a separate programme. It sits on the data governance you already have: classification decides what a model can see, and access and masking still apply to what it reads. AI agents get their own identity and role, like any other user, so the same rules cover them.

On top of that, each use of AI needs two decisions. First, where it can run: your rules on the data set the limit, and the job picks the option within it. Second, how you'll know it's working: test it on real examples before launch and keep measuring after, with a person checking where the stakes are high.