Guides › AI data governance

AI Data Governance for Retrieval: Classification, Entitlement and Audit for the Data AI Systems Read

AI data governance for retrieval is the set of controls that decide which data an AI system may read on a user's behalf, in what form that data may leave the organization, and what record exists afterward. It has three parts: classification of the sources an assistant can reach, entitlement enforced at the moment of each retrieval, and an audit trail of what was retrieved for whom. Most data governance programs were built for data at rest and most AI governance programs were built for models. Retrieval sits between the two, moves more data than either, and in most organizations belongs to nobody. This page defines the three parts, maps them to the frameworks and to the data security posture tooling already in place, and gives an operating model with the metrics that show whether it is working.

Why retrieval needs its own governance

Data governance as practiced for the last fifteen years answers questions about data at rest: what exists, where it lives, who owns it, how it is classified, how long it is kept. AI governance as it has formed since 2023 answers questions about models: what they were trained on, how they are evaluated, where they are allowed to be used, how their outputs are documented. Retrieval is the moment a model is handed a copy of data at rest to answer a question for a specific person, and neither discipline has a control that fires at that moment. The data program's classification sits on the source and does not travel with the chunk. The model program's evaluations test the model's behavior and say nothing about which of your documents it was shown. A connector approved in a ten-minute change ticket then moves more regulated content in a week than the data loss prevention program stopped in a year, and the data silos guide explains why the permissions underneath were never designed for it.

The frameworks agree on the shape of the gap without naming it. NIST AI RMF asks organizations to map the data an AI system uses and to measure and manage the risks of that use. ISO/IEC 42001 asks for documented data management for AI systems across acquisition, quality, provenance and preparation. The EU AI Act imposes data governance, logging and documentation duties on high-risk systems from 2 December 2027. OWASP's 2026 Top 10 for LLM Applications lists sensitive information disclosure as LLM02 and vector and embedding weaknesses as LLM09. None of them tells you which document was shown to which user yesterday, and all of them expect you to be able to say. The framework crosswalk maps the retrieval failure modes to each framework's language.

The three parts

Each part has an owner, an artifact and a control, and the program fails when one of the three is assumed rather than built. The table states them plainly; the paragraphs that follow cover the decisions inside each.

Classification, entitlement and audit in practice

Classification for retrieval works at the level of the source. The question is not whether a given sentence contains a Social Security number but whether a SharePoint site, a Drive, a ticketing queue or a database holds personal data, health or financial records, controlled unclassified information, export-controlled data or secrets, because the connector will expose the whole source at once. The data owner answers it, the inventory records it, and the acceptable use policy states which classes may reach which assistants through which routes. Where labels exist they help, and the label coverage number from the posture tooling tells you how far they can be trusted.

Entitlement is the control most programs believe they have and do not. “The assistant respects existing permissions” is true of every major platform and describes the tenant rather than a control; in most tenants what is authorized exceeds what was intended by years of drift, which the Copilot oversharing guide works through for the most common case. A retrieval-time entitlement check does two things the platform statement does not: it tests each candidate document against the source's current permissions for the asking user at the moment of the query rather than against an index-time snapshot or a sharing scope, and it applies the same check regardless of which assistant or model is asking. The RAG permissions page covers the mechanics and the ways it is commonly built wrong.

Audit for retrieval means a record per retrieval, not per conversation. The platforms log prompts and, on some tiers, app activity, and Microsoft Purview records the resources Copilot accessed per interaction with their label IDs, which is the most complete of the native logs. What governance needs on top is the entitlement outcome, the substitution applied, the assistant and model the content went to, and all of it under identifiers that are not themselves the sensitive data, because a retrieval log that stores the retrieved text has created a new copy to govern. The telemetry page specifies the record. With that log in place the program gains its central metric, a leakage rate: the share of retrievals that returned content the user was not entitled to, measured before rollout by the self-test and continuously afterward.

How this relates to DSPM and the posture tooling you have

Data security posture management tools discover data stores, classify what is in them and report exposure, and most of them now carry an AI module that extends discovery to prompts, uploads and AI application traffic. That work is useful and the retrieval program depends on it: the source inventory, the label coverage number and the oversharing counts come from exactly these tools, or from the platform equivalents such as SharePoint Advanced Management. What posture tooling does not do, by design, is sit in the retrieval path. It reports that a site is over-shared; it does not stop the next query from reading it. It reports that a file is labeled; it does not substitute the identifiers before the model sees them. Governance for retrieval treats posture as the input and adds the two controls that act at query time. Buying a posture tool and calling the AI data governance problem solved is the most common way the program stays on paper.

An operating model

The program below fits in a quarter for a bounded scope and runs on existing roles. The sequence matters less than the fact that each step produces an artifact someone owns.

Where Hardshell sits

Hardshell is the entitlement and audit layer in this model, built to run with whatever posture tooling and classification already exist. It connects to the systems where enterprise data lives without migrating it, enforces each user's existing permissions at query time for ChatGPT, Claude, Microsoft 365 Copilot, Gemini and internal assistants alike, substitutes stand-ins for real identifiers before content reaches a third-party model, and records every retrieval under opaque IDs. Before rollout it tests what an assistant can be made to disclose and maps each finding to MITRE ATLAS technique IDs, which gives the program its first leakage number. It deploys as a cloud service, in a private cloud, or as an offline bundle.

Frequently asked questions

What is AI data governance?

The controls that decide which data an AI system may use, in what form, for whom, and with what record. For retrieval-based systems such as assistants with connectors and knowledge bases, that means classifying the connected sources, enforcing the user's entitlements at query time, and recording what was retrieved for whom.

How is AI data governance different from data governance?

Data governance manages data at rest: inventory, ownership, classification, retention. AI data governance adds the moment of use, when a model is shown a copy of that data to answer a question for a specific person. The classification does not travel with the chunk and the permissions were not designed for an assistant, so the controls have to act at retrieval time.

Is DSPM enough for AI data governance?

It is the input. DSPM discovers, classifies and reports exposure of data at rest, which supplies the source inventory, label coverage and oversharing counts. It does not enforce entitlement at query time or substitute identifiers before the model, so on its own it describes the risk without changing it.

What should an AI data governance policy cover for retrieval?

Which data classes may reach which assistants through which routes (entry, upload, connector, agent); the approval required to connect a source, including an oversharing audit; the entitlement check and substitution required for regulated classes; the retrieval log and who reviews it; and the leakage threshold that must hold before and after rollout.

Which frameworks apply to AI data governance?

NIST AI RMF (map, measure and manage the data an AI system uses), ISO/IEC 42001 (documented data management for AI systems), the EU AI Act (data governance, logging and documentation duties for high-risk systems from 2 December 2027), and OWASP's 2026 Top 10 for LLM Applications (LLM02 sensitive information disclosure, LLM09 vector and embedding weaknesses). The crosswalk page maps retrieval failure modes to each.

What metrics show AI data governance is working?

Leakage rate (retrievals that returned content the user was not entitled to), measured before rollout and continuously after; label coverage of regulated sources; count of over-shared sites and links, trending down; share of regulated retrievals with substitution applied; and retrieval log completeness across assistants.