Governance
AI Data Governance: A Practical Framework for Data Teams
Sema Team · June 23, 2026 · 3 min read

Every company now has an AI policy document. Very few have AI governance — because a policy PDF can't stop a language model from putting a salary column into a chat answer. Governance is only real when it's enforced in the path the data travels.
Here's the six-pillar framework we see working at data teams that moved from pilot to production.
Pillar 1: Classification — know what's sensitive, automatically
You can't protect what you haven't labeled. The classic failure is a one-time manual tagging project that's stale before it finishes. In an AI context, classification must be:
- Automatic at ingest — pattern, name and content-based detection of PII/PHI (SSN, email, phone, DOB, addresses, payroll) the moment a source connects.
- Human-reviewed — auto-flags are proposals; a data owner confirms.
- Versioned — when a column's classification changes, downstream policy changes with it.
Pillar 2: Access — identity-aware, column-level, at query time
The unit of AI-era access control is not the database or the schema — it's the column, per role, per query. A viewer asking an AI assistant about customer contact info is a different event than an admin doing the same, and the system must treat them differently: refuse one, mask-and-log the other. We covered the mechanics in depth in text-to-SQL governance.
The key architectural decision: enforcement belongs in a semantic layer that sits between questions and SQL — because that's the only place that sees the user, the question, the schema and the policy at the same time.
Pillar 3: Grounding — govern meaning, not just access
A governance program that only controls who sees what misses half the risk: wrong answers presented confidently. If "revenue" has no governed definition, the AI will invent one, and the CFO will make a decision on it. Definitional governance means:
- Metrics have owners and signed-off formulas.
- Business terms live in a maintained glossary, mapped to schema.
- The AI resolves questions against these definitions — and refuses when a term has none.
Ungoverned meaning is how you get hallucinated analytics with a green compliance checkmark.
Pillar 4: Audit — append-only, question-to-SQL, exportable
When AI generates hundreds of queries a day, "we reviewed the dashboards quarterly" is not audit. The standard to hold:
- Every question, its generated SQL, tables/columns touched, and policy decisions applied.
- Append-only storage — an audit log with UPDATE permissions is a diary.
- Exportable (CSV at minimum) for compliance reviews.
Bonus: the audit log doubles as your quality dataset. Refusals cluster around missing definitions; overrides cluster around policy gaps.
Pillar 5: Quality — trust is a governance concern
Data quality drifts, and AI amplifies drift into confident nonsense. Minimum viable quality governance for AI consumption:
- Freshness and volume checks on sources feeding AI answers.
- Health status surfaced in the answer path ("this table hasn't loaded since Tuesday"), not in a separate tool nobody opens.
- A feedback loop: when a user flags a wrong answer, the correction updates the model (definition, join, or flag), not just a ticket queue.
Pillar 6: Accountability — owners, reviews, and a paper trail
Tools enforce; people decide. The lightweight operating model:
- Domain owners sign off on definitions and sensitivity flags for their area.
- A monthly review of refusals, overrides and corrections (30 minutes, standing agenda).
- A change log for policy — who loosened what, when, why.
Putting it together
| Pillar | Question it answers | Failure if missing |
|---|---|---|
| Classification | What's sensitive? | PII leaks into answers |
| Access | Who can see it? | Wrong role, wrong data |
| Grounding | What do terms mean? | Confident wrong answers |
| Audit | What happened? | Unanswerable compliance questions |
| Quality | Is it current? | Stale data, fresh confidence |
| Accountability | Who decides? | Policy rot |
The pattern across all six: governance moved from documents into the query path. That's the design premise of Sema — classification at discovery, role-aware masking and refusals, governed definitions, and an append-only audit log, on by default rather than sold as an enterprise add-on. See how it works.
Frequently asked questions
How is AI data governance different from regular data governance?
Traditional governance managed human access to data at rest. AI governance must also manage machine access at query time: what flows into model context, what definitions ground generated queries, and how automated outputs are audited. The policies are similar; the enforcement point moves into the query path.
Who should own AI data governance?
The data platform team typically owns enforcement (the tooling), while a cross-functional group — data, security, legal, and the business owner of each domain — owns policy. What fails is making it a pure legal project (unenforceable) or a pure engineering project (no mandate).
Do we need new tools for AI data governance?
You need enforcement in the query path. If your current stack can classify sensitive columns, enforce role-based masking on AI-generated queries, and produce an append-only audit log, you're covered. If governance lives in documents rather than execution, you have a gap.
See a governed semantic layer on your own data
Connect a source or upload a CSV, and ask your first plain-English question in minutes — every answer ships with its SQL.

