Data governance and AI governance are the same job. You should only have to do it once.

You run operations at a 30-person company, and someone has decided it is time to take AI governance seriously. You download a framework. It names a data owner, a data steward, a governance lead, an agent owner, a prompt owner and a chief risk officer. You look around the room. All six of them are you, and you are also running payroll this week.

Meanwhile, your sales team connected their AI assistant to the CRM three months ago. Connect a tool to AI and it sees everything in that tool. Nothing in the framework has touched that yet.

TL;DR: Data governance (a person makes the decision) and AI governance (the machine makes the decision) rest on the same five principles: ownership, decision rights, definitions, escalation and accountability. Enterprises staff them as two programmes. You can't, and you don't need to. When every AI tool your team uses reads business data through one layer, that layer can enforce all five at once, by construction rather than by policy.

Two disciplines, one overlap. At your size, the overlap is where governance actually happens.

Why do data governance and AI governance look like two programmes?

In a large company they are run by different people, for good reasons. Data governance covers the decisions people make with data: which system is the source of truth for a customer, what counts as an active account, who may open the finance tables. Its artefacts are lineage maps, data-quality rules, metadata catalogues and master data.

AI governance covers the decisions a machine makes: what a model may answer, which tools an agent may call, how to stop it. Its artefacts are output guardrails, hallucination checks, tool permissions, model cards and a kill switch.

The split makes sense when there is a data team on one side and a risk function on the other, each with its own staff, budget and committee. You have neither. You have a long list of things that are now yours.

The overlap is the part that does the work

Put the two programmes side by side and the same five principles sit under both:

• Ownership: a named person answers for each dataset and each AI deployment.
• Decision rights: who may see, change or act on what is decided in advance, not discovered afterwards.
• Definitions: "customer", "revenue" and "churned" mean one thing, whether a person or a model is asking.
• Escalation paths: when something can't be answered or goes wrong, there is a known route to someone who can fix it.
• Accountability: there is a record of who did what, so a question about last month has an answer.

These are not data principles or AI principles. They are governance. Whether a person or a machine makes the decision changes how each principle is enforced, not what it is. That is good news for you: there is one job here, not two.

How do you govern AI without a data team?

You can't staff two programmes. But when your team and their AI tools all read business data through the same layer, that layer is where all five principles can be enforced at once, and enforced in software rather than in a policy document you have to keep reminding people about.

That layer, between your business tools and your team's AI tools, is what we built Synquil to be. Here is how each principle maps onto it:

• Ownership: you approve the schema. Synquil drafts one connected schema across your tools with read-only access. Nothing goes live until you review and apply it.
• Decision rights: default deny, down to the column. You grant each person a whole source, specific tables or specific columns, and everything else is denied. New tables stay invisible until you grant them.
• Definitions: one schema, every AI tool. Claude, ChatGPT, Cursor and Windsurf all read the same layer, so "last month's revenue" comes from the same rows whichever tool your team asks.
• Escalation: a record of what nobody could answer. Synquil's Questions tab groups the questions that came back empty by what was missing, so you know what to connect or document next. It is recorded without any link to who asked: there is no person column, and timestamps are cut to the hour.
• Accountability: an audit log nobody can edit. Every AI query is logged: who asked, from which tool, which tables, the SQL, the row count, and every blocked attempt. A database rule rejects edits and deletions.

The six roles collapse into the one you already have. The framework becomes you, working with the right defaults.

The same five principles, enforced in one layer. Every label on the rings is a control that exists in Synquil today.

The machine side needs enforcement, not instructions

Data governance can lean on people who have read the policy. AI governance can't. A model told in its system prompt not to discuss salaries still knows the salaries exist, and a cleverly worded question, or a document carrying a hidden instruction, can talk it round.

Connecting AI to data is now the easy part, and governing it is the part most organisations haven't done. A survey of 100 senior engineers at US and UK enterprises by Stacklok and the Linux Foundation's Agentic AI Foundation found that only 5% report governed, enterprise-wide MCP use in production. If companies with security teams haven't got there, nobody expects you to have done it by hand.

So in Synquil the controls apply before the model sees anything:

• Invisible, not refused. Access is checked on the server, and the model only ever receives the asker's slice of the schema, so it can't name or infer what it wasn't given. Your sales rep's AI shouldn't say "you don't have access to salaries." It should find no such data.
• Read-only, validated queries. Each question becomes one SELECT statement, which is checked before it runs. No path leads from an AI tool to a write in your source systems.
• Offboarding as the kill switch. Remove someone and their AI access ends within one request, across every source at once.

Here is how team access works in practice.

What this does not govern

Synquil governs what each person's AI can see and keeps a record of what was asked. It does not review what a model writes in an email, check generated text for hallucinations, publish model cards for models it didn't build, or classify your use case under the EU AI Act. It doesn't make you compliant with anything. What it gives you are the controls and records a compliance conversation starts from. The security details are on our trust page.

You may not need any of this yet. If it is one person and one spreadsheet, paste it into a chat. Governance starts to matter the day a second person on your team gets AI access to company data.

Governance used to be something a company grew into once it had a data team. AI moved that deadline forward. The five principles apply from the moment your team's AI can read the business, whether anyone has written them down or not. You only have to enforce them once, where your data meets your AI. AI needs context. Businesses need control.

See how per-person, per-column access works at synquil.com/#access.