How is AI data governance different from traditional data governance?

Traditional governance protects data at rest and in analytics queries. Generative AI adds three new surfaces: the retrieval index that feeds the model, the prompt and response stream, and the model itself. You need lineage from source to embedding to answer, per-user access filtering inside retrieval, and evaluation for hallucination, toxicity, and leakage — not just row-level security on a table.

Which frameworks and regulations apply to generative AI governance?

The most common references are the NIST AI Risk Management Framework (including its Generative AI Profile), ISO/IEC 42001 for AI management systems, and the EU AI Act's obligations for general-purpose and high-risk AI. Sector rules still apply on top: HIPAA for health data, GLBA and SOX for financial, and GDPR or CCPA for personal data used in training, retrieval, or fine-tuning.

What is the difference between Unity Catalog, Microsoft Purview, and an AI gateway?

Unity Catalog and Microsoft Purview govern the data layer: catalogs, lineage, permissions, and now vector indexes and model registries. An AI gateway (Databricks AI Gateway, Azure AI Content Safety, or a homegrown proxy) governs the request layer: routing, rate limits, prompt and response logging, redaction, and safety filters. You typically need both — the catalog decides what data an AI system may see, the gateway decides what the AI system may do with it.

Playbook · 2026

Data Governance for Generative AI: A 2026 Playbook

Q: What is data governance for generative AI?

Data governance for generative AI is the set of policies, controls, and tooling that decide which data an AI system can read, generate, or expose — and how you prove it after the fact. It extends classic data governance (ownership, quality, lineage, access) with AI-specific concerns: prompt and output logging, PII redaction, retrieval scoping, model and prompt versioning, evaluation, and human review.

Q: How do you build trust in generative AI systems?

Trust comes from four visible controls: sourced answers with citations back to governed data, per-user access filters applied inside retrieval, an evaluation harness that runs on every prompt or model change, and complete audit logs of prompt, retrieved chunks, model version, and response. When users can see where an answer came from and admins can replay it, adoption follows.

Q: How do you handle PII in a RAG or LLM application?

Classify data before it enters the index, redact or tokenize direct identifiers at ingestion, and store sensitivity tags on every chunk. At query time, filter retrieval by the caller's entitlements and re-scan prompt and response for leakage. For regulated data, route through a private model or self-hosted endpoint and disable provider training and long-term prompt retention.

How to build data governance for generative AI: trust, access control, lineage, PII, RAG guardrails, and evaluation — with examples and an FAQ.

TL;DR

Generative AI does not need new governance principles — it needs governance applied to three new surfaces: the retrieval index, the prompt and response stream, and the model itself. Classify data before it becomes embeddings, filter retrieval by the caller's entitlements, log every prompt/response with the model and prompt version, and run an evaluation harness on every change. Do that, and trust, compliance, and adoption follow.

Why generative AI breaks classic data governance

Traditional data governance assumes a human writes a query against a governed table. Generative AI inverts that: a model composes an answer from many sources, some of them unstructured, and the "query" is a natural-language prompt that can smuggle instructions or leak context. Row-level security on the warehouse is necessary but not sufficient — you also need to govern the vector index, the prompt, and the response.

The most common failure modes I see in production: an employee-facing assistant that retrieves HR documents the caller isn't entitled to; a customer chatbot that echoes a few tokens of another customer's data; a RAG pipeline whose embeddings were built from a snapshot that predates a GDPR deletion. All three are governance failures, not model failures.

The five pillars of data governance for generative AI

Data classification and lineage. Every source — table, document, ticket, transcript — carries a sensitivity tag (public, internal, confidential, restricted) that follows it into chunks, embeddings, and cached answers. Unity Catalog, Microsoft Purview, and Collibra all now model vector indexes and model artifacts as first-class assets; use that.
Access control inside retrieval. Do not rely on the model to keep secrets. Filter the vector search by the caller's identity and entitlements before the top-k is passed to the model. Store ACLs on the chunk, not just on the source document.
Prompt, response, and model-version logging. Every request stores prompt, retrieved chunk IDs, model name and version, prompt template version, latency, and cost. Without this you cannot reproduce an answer, honor a deletion request, or investigate a leak.
Evaluation as a gate. A golden set of prompts runs on every model swap, prompt-template change, or index rebuild. Score for correctness, groundedness, hallucination, PII leakage, and toxicity. Regressions block the release.
Human review and feedback. High-stakes flows keep a human in the loop and capture thumbs-up/down with reason codes back into the evaluation set. This is how governance stays alive after launch instead of decaying into a slide deck.

A reference architecture

The shape most enterprise programs converge on:

Sources ──► Ingestion + PII redaction ──► Governed lake (Delta/Iceberg) │ ├─► Feature/label store (fine-tuning, evals) │ └─► Chunker ──► Vector index (with ACLs + tags) │ User ──► App ──► AI Gateway ──► Retriever ──► Prompt ──► LLM ──► Response │ │ │ │ │ └── audit ────┴── audit ─────┴── audit ┴──audit ┘ │ Evaluation + human review

The AI gateway is the single choke point where you enforce authentication, rate limits, redaction, safety filters, and full audit — the same role an API gateway plays for microservices. On Databricks that's the AI Gateway plus Unity Catalog; on Azure it's API Management plus Azure AI Content Safety and Purview; on AWS it's Bedrock Guardrails plus a Lake Formation-governed store.

Worked example: an internal policy assistant

A finance team wants an assistant that answers questions about internal policy, contracts, and vendor SOWs. The naive build indexes SharePoint and calls it done. The governed build:

Ingestion tags each document with owner, department, and sensitivity from the source system's metadata; PII is redacted or tokenized before chunking.
Chunks inherit ACLs from the document; the vector index stores acl_group_ids so retrieval filters at query time by the caller's group membership.
The retriever returns citations; the response renders them inline so users can verify sources — the single biggest driver of adoption in my engagements.
An AI gateway logs prompt, retrieved chunk IDs, model version, template version, and user; a nightly job runs an evaluation set of 200 real questions with known-good answers.
A dashboard tracks groundedness, unanswered rate, and thumbs-down reasons; policy owners get alerts when a document they own starts producing bad answers.

Regulatory landscape

Three references cover most enterprise conversations in 2026:

NIST AI RMF and Generative AI Profile — a control taxonomy that maps cleanly onto the five pillars above; useful shared language with risk and audit.
ISO/IEC 42001 — an AI management system standard that certifies how you govern AI, not any single model. Increasingly requested by enterprise customers as a procurement gate.
EU AI Act — obligations for general-purpose and high-risk AI, including transparency, technical documentation, and post-market monitoring. Even if you are not in the EU, the documentation bar is a reasonable default.

Sector rules still apply on top: HIPAA for health data, GLBA and SOX for financial, GDPR and CCPA for personal data used in training, retrieval, or fine-tuning. The "right to be forgotten" is the underrated one — plan for how a deletion request propagates from the source table through embeddings and cached answers.

A 90-day rollout plan

Days 1–30 — Inventory and classify. List every data source a candidate AI use case would touch. Assign owners and sensitivity tags. Stand up lineage in Unity Catalog or Purview and enable audit logging on the model endpoints you already use.
Days 31–60 — Ship one governed use case. Pick one narrow, high-value use case (support triage, policy Q&A, sales research). Enforce retrieval-time ACLs, route through an AI gateway, and log everything. Publish a one-page AI card that names the model, data sources, owners, and known limits.
Days 61–90 — Evaluate and expand. Build the golden evaluation set from real user questions. Wire it into CI so no model, prompt, or index change ships without passing. Only then scale to the next use case.

Common anti-patterns

Standing up a "governance committee" before shipping a single governed use case — governance without a system to govern rots.
Relying on prompt instructions ("do not reveal PII") as a security control. The prompt is not a boundary; retrieval and the gateway are.
Building one giant enterprise index. Segment by domain and sensitivity — the blast radius of a misconfigured ACL is much smaller.
Skipping evaluation because "the model is smart enough." Every prompt-template edit is a silent deploy without it.
Treating training-data governance and RAG governance as the same problem. They share tooling; they do not share risks.

Frequently asked questions

What is data governance for generative AI?

The policies, controls, and tooling that decide which data an AI system may read, generate, or expose — and how you prove it after the fact. It extends classic data governance with AI-specific concerns: prompt and response logging, PII redaction, retrieval scoping, model and prompt versioning, evaluation, and human review.

How is it different from traditional data governance?

Traditional governance protects data at rest and in analytical queries. Generative AI adds three new surfaces — the retrieval index, the prompt/response stream, and the model itself — each of which needs its own controls.

How do you build trust in generative AI systems?

Sourced answers with citations, per-user access filters inside retrieval, an evaluation harness on every change, and complete audit logs of prompt, retrieved chunks, model version, and response.

How do you handle PII in a RAG or LLM application?

Classify and tag at ingestion, redact or tokenize direct identifiers before chunking, filter retrieval by the caller's entitlements, and re-scan prompt and response for leakage. For regulated data, use a private model or self-hosted endpoint and disable provider training and long prompt retention.

Which frameworks and regulations apply?

NIST AI RMF (with its Generative AI Profile), ISO/IEC 42001, and the EU AI Act, plus your sector rules — HIPAA, GLBA, SOX, GDPR, CCPA.

Unity Catalog vs. Microsoft Purview vs. AI gateway?

Catalogs govern the data layer (assets, lineage, permissions, vector indexes, model registries). An AI gateway governs the request layer (routing, redaction, logging, safety). Most programs need both.