AI data governance

AI data governance is not a second privacy program. It is the existing data rules applied to prompts, completions, embeddings, retrieval indexes, and fine-tunes — the copies that ordinary data maps often miss. If you cannot say which system is the source of record, who may send that record to a model, whether the vendor may train on it, how long the prompt lives, and whether the bytes may leave your VPC, you do not govern the model. You govern a slide.

This is the data cut of AI governance: discover where company data already meets a model, risk-tier the flow, implement guardrails in your environment (gateway, redaction, allow lists), operationalize. NIST AI RMF still applies. MAP is data class and intended use. MEASURE is logs and retention you can prove. MANAGE is blocking a class from leaving, or deleting a copy you should not have made.

This post is the data questions that need owners. The pass/fail companion is the AI governance checklist.

Pick the source of record before you embed it

A model is not a system of record. Neither is a vector index, a chat history, or a "knowledge base" someone stood up for a demo. The source of record is the system you already trust for that object: the policy CMS, the claims system, the CRM, the repo. Retrieval may read it. Completions may quote it. They do not replace it.

Write this down per use case:

• Which system is canonical for each object the model may see.
• Whether the model may only read, or may propose a write that a human commits back to that system.
• What happens when the source changes. Stale chunks in an index are a data-quality incident, not an AI mystery.
• Whether chat history is allowed to become an unofficial second store of customer facts.

Yes/no:

• You can name the source for every high-risk flow on the inventory.
• A wrong model answer is corrected in the source, then the index, not only in a follow-up prompt.
• Embeddings and caches have an owner and a rebuild path. Orphan indexes are shadow data.

If the demo corpus is a zip of production exports, treat it as an ungoverned copy: no permissions, no retention. Discover those copies first.

Permissions on the model path cannot exceed the source

The model inherits access, or it becomes a bypass. If a user cannot open a file in the source system, the retrieval layer must not return it because the index was built with a service account. That single mistake is how "an assistant for the company" turns into a permissions leak.

Controls that hold:

• Retrieval filters on the user identity, not on a shared bot identity, for anything above public or internal non-sensitive.
• Indexes built with the same ACL story as the source, or rebuilt often enough that revoked access actually revokes.
• Prompt logs treated as the data class of their contents. A log of customer records is a customer-record store.
• Admin browse of other people's prompts is off by default.

Yes/no:

• A revoked user loses model access to that corpus the same day they lose source access.
• Security can name who can read raw prompts for a given workspace.
• Connectors that sync chats into Slack or tickets do not copy restricted data into a looser system.

Do not invent a new permission model for AI. Reuse the one you already have.

Separate training data from inference data in policy and in the path

Training, fine-tuning, and evaluation corpora are durable copies. Inference is a live prompt plus retrieved context. Teams collapse the two and then cannot answer a deletion request or a "do not train" clause.

Split the rules:

• Inference: which classes may be sent to which endpoint, whether they may leave the VPC, whether they are redacted first, how long the vendor retains the prompt.
• Training and fine-tuning: which classes may ever be copied into a training set, who approves that copy, where it lives, when it is deleted, and whether a vendor may use it to improve a shared model.
• Eval sets: treated as production-like if they contain real records. Prefer synthetic or redacted cases for anything restricted.

Yes/no:

• "We do not train on your data" is in the contract for inference, and you still did not put restricted data in a vendor fine-tune without a second review.
• Employees cannot paste a production export into a fine-tune UI because it was handy.
• The inventory row says whether the system is inference-only or has a trained artifact, and who owns that artifact.

Vendor evaluation belongs here. Residency, retention, subprocessors, and who can see prompts are data questions. Use the AI vendor evaluation framework before a pilot becomes the path.

Retention for prompts is a data-retention decision

Prompts and completions are records. They often contain the source data plus a user's intent. Default vendor retention, your SIEM retention, and your chat-product history will not match unless you set them.

Decide, in writing:

• How long you keep prompts and completions for low, medium, and high tiers.
• How long the vendor keeps them, including backups and abuse review.
• How long embeddings and uploaded files live after a user deletes a conversation.
• Who can export a conversation, and whether that export is itself a retained copy.

Yes/no:

• You can delete or expire a high-risk conversation and state the outer bound for backups.
• Prompt retention is not longer than you need for incident review and shorter than a second warehouse of customer data.
• Legal has mapped prompt stores to the same schedule as similar tickets or emails, or has given a reason they differ.

If you cannot answer retention, assume the data is still there and you cannot prove deletion.

Treat PII as a block-or-redact problem, not a training problem

PII, health data, payment data, credentials, and unique identifiers that re-identify a person are restricted. "The employee stripped the name" is not a control. Residuals identify people. Account numbers in a paragraph still leave.

Practical rules:

• Restricted classes do not go to personal or consumer chatbots. That is a shadow AI kill, not a workshop.
• On sanctioned paths, a gateway redacts or blocks before the request leaves your tenancy.
• Retrieval of restricted records happens only for systems tiered and approved for that class, with a human on write-backs.
• Logs either store the redacted form or inherit the restricted class and the matching access.

Yes/no:

• There is a hard no for public models and restricted data, including "just this once."
• Redaction is tested with your real field formats, not only with "John Smith."
• A residual-PII finding in a log is an incident, not a shrug.

Attach the existing PII definition to the model path. You do not need a new one.

Write down what may leave the VPC, and enforce it on the wire

"In our cloud" is vague. Name the boundary: VPC, tenancy, region, and whether an external model provider is allowed to see the payload. Then enforce that boundary with routing, not with a guideline.

Allowed patterns, pick per tier:

• Low-risk public or internal non-sensitive text may leave to an approved external endpoint, logged.
• Medium-risk confidential text may leave only to a contracted tenant in an approved region, through the gateway.
• High-risk restricted text stays in the VPC or in a region you pin, or it is redacted to a non-restricted residue before it leaves. If you cannot do either, the use case does not ship.

Yes/no:

• You can draw the packet path for each production system on the inventory.
• An engineer cannot point a high-risk service at a public API key and still pass review.
• Cost controls and allow lists live on that path so a new SaaS feature cannot quietly become an egress.

Implement the boundary in your environment. A policy that says "prefer private networking" without a route that fails closed will lose to the first deadline. Operationalize the rest: stale indexes, expired eval corpora, vendor term changes, new shadow pastes.

If you want those rules as a gateway, an inventory, and NIST-mapped artifacts in your environment, start from AI governance.