AI data governance is the part of a governance program that answers what information may reach an AI system, where it goes afterwards, how long it stays, and who may see what comes out.
It is the domain most often assumed to be covered by an existing privacy program and most often not, because AI systems introduce categories of data that a conventional data map has no row for.
The categories a classic data map misses
An organization that has done privacy work properly usually knows where its personal data lives and who processes it. AI adds several things that sit outside that picture.
Prompts. What a member of staff types, and what they paste in for context. This is frequently the most sensitive material in the whole system and it is created by users rather than collected by a process, so nothing in the existing data map anticipates it.
Retrieved context. Where a system searches your own documents to answer a question, the material it retrieves is part of the transaction even though nobody chose it for that request.
Embeddings and indexes. Derived representations of source content, held separately from the source, and frequently subject to different retention and access rules by default.
Conversation history. Retained across sessions, often by default, and often visible to administrators.
Logs. Kept for abuse monitoring and support, sometimes by the vendor rather than by you, and sometimes on a different retention schedule from everything else.
Outputs. The neglected category. A model output can contain personal data, can be wrong about a person, and can end up in a record that is later disclosed. It is data your organization created and holds.
An AI data map that covers only inputs is half a map.
Start with a rule, not a taxonomy
The single highest-value artifact in this domain is one sentence stating which categories of information may not be entered into an AI system.
It needs to be specific enough for a member of staff to apply without asking. "Do not enter confidential information" fails that test because nobody agrees what it covers. A rule naming the categories your organization actually holds, such as personal data about identifiable individuals, credentials, unreleased financial information, or material covered by a specific agreement, passes it.
Write the rule before building the taxonomy. Organizations that begin with a classification scheme frequently spend a quarter on it and never reach the sentence that would have changed behavior in week one.
Where the data actually goes
Four questions, and they have separate answers even though marketing material tends to collapse them into one.
Is it used to train a model? Yours, the vendor's, or a third party's.
Is it retained, and for how long? Training and retention are different questions. A supplier may not train on your content while still holding it for abuse monitoring.
Who else sees it? Subprocessors, including the model provider where the supplier does not operate the model itself.
Where is it processed? Geographically, which matters for organizations with residency obligations.
Ask which of the four answers are contractual and which are described in a policy the supplier can revise. That distinction is covered further in AI vendor risk assessment.
Access, and the permission problem
The most consistently underestimated risk in this domain is not exfiltration. It is that a retrieval system answers using everything the requesting account can reach.
Organizations accumulate over-broad permissions for years without consequence, because nobody reads a shared drive end to end. A system that can search it and summarise the answer changes that overnight: material that was technically accessible and practically invisible becomes a sentence in a response.
The mitigation is unglamorous and effective. Review what the indexed sources contain and who can reach them before switching retrieval on, not afterwards, and treat the deployment as an access review with an AI feature attached.
Retention, deletion and the awkward questions
Decide retention deliberately rather than accepting a default, and establish what deletion actually covers.
Three questions to put in writing to any supplier: can we require deletion on request and on termination; what is excluded from that, including logs, caches and backups; and how long does an exclusion persist. A commitment to delete that does not reach the logs is a partial commitment, which is fine if you know it and a problem if you assume otherwise.
Where a system holds personal data, establish before deployment that you can locate an individual's data and act on it. Discovering that you cannot, at the point somebody asks, is a poor time to find out.
Outputs are records, and that has consequences
The category organizations handle worst is the one they create themselves. A model output that enters a document, a ticket, a case file or an email is a record, and it inherits every obligation your organization already has about records.
Three consequences follow. It is disclosable: where public records law, discovery or a subject access right applies, an AI-generated passage is not exempt because a machine drafted it. It is retained: it falls under your retention schedule, and if the schedule has no category for it, it will be kept indefinitely by default. And it may be wrong about a person, which is a different problem from being wrong in general, because a factual error about an identifiable individual sitting in a record has its own remedies attached.
The practical step is small. Decide whether outputs are marked as AI-assisted when they enter a record, decide who is accountable for the accuracy of the record rather than of the model, and make sure the retention schedule has somewhere to put them. None of that requires new technology and all of it is far cheaper to decide now than to reconstruct later.
What the federal evidence says about how hard this is
In March 2026 GAO reported that OMB's government-wide AI guidance did not fully address the privacy-related risks and challenges it identified. GAO found the guidance addressed two of ten identified challenges and did not address the other eight, among them how agencies should evaluate AI models handling sensitive data, practices for data storage, metrics for privacy impact, and the technological tools available to protect information. GAO made two recommendations.
That finding concerns federal agencies and OMB guidance addressed to them. It does not create an obligation for any other organization. It is worth citing for a different reason: if government-wide guidance produced with substantial resources left eight of ten privacy challenges unaddressed, an organization finding this domain difficult is encountering a genuinely hard problem rather than falling behind a solved standard.
The joint CISA, NSA and FBI guidance on AI data security is the more operational reference, covering data risks across the AI lifecycle from development and testing through deployment and operation.
Working with an existing privacy program
In most organizations this domain is not new work by a new team. It is a set of questions added to a function that already exists.
Bring whoever owns privacy into AI decisions at the assessment stage rather than at the approval stage, extend the existing data map to the categories at the top of this page, and add AI systems to whatever review cycle already applies to processors. The NIST Privacy Framework is a reasonable structure where one is wanted; note that it is at version 1.0 with version 1.1 at initial public draft, so cite it with that status attached.
Where your organization applies AI to content and knowledge specifically, the same questions arrive earlier and in more concentrated form, and AI-powered content management is where they usually surface first.
One sequencing note. Privacy review is frequently scheduled after a pilot has run, on the reasoning that there is no point reviewing something that may not proceed. That ordering guarantees the review arrives after real data has already been through the system, at which point the reviewer is assessing an incident rather than a proposal. A short conversation before the pilot costs less than either.
Where to go next
Data governance is one domain of the AI governance framework and depends on knowing what systems exist, which is the inventory. The per-use-case decision method is AI risk assessment, and the security controls are covered in the AI cybersecurity risks to assess before deployment.
LABUSA works on AI data governance alongside existing privacy and security functions rather than around them, as part of our AI governance and responsible AI work. If retrieval over your own documents is what prompted the question, that is the most common starting point and a conversation is the place to begin.