AI data governance connects the information an AI system uses with the people allowed to approve that use. A practical program needs to answer where the data came from, which tasks may use it, who can access its derivatives, and what happens when its status changes.
Start with a data register for one deployed application. A clear register with accountable owners is more useful than a broad policy that nobody can apply to a retrieved passage, training example or logged conversation.
Distinguish AI data uses before approving a source
A dataset approved for internal search is not automatically approved for model training, evaluation, analytics or vendor support. Treat each use as a separate decision with its own recipients and retention conditions.
NIST's AI Risk Management Framework is intended for voluntary use to support trustworthy AI risk management. Its generative AI profile provides additional risk-management context. The register below is a practical implementation proposal, not a NIST certification checklist or a statement of legal compliance.
Use a register that supports operational decisions
| Field | Decision it supports |
|---|---|
| Source ID and version | Identify the exact input and its current status |
| Business owner and steward | Assign approval and maintenance responsibility |
| Classification and permitted uses | Decide which AI tasks may process the source |
| Authorized audience | Apply user, tenant and purpose restrictions |
| Processing destinations | Review services, regions and subprocessors involved |
| Derived artifacts | Find chunks, embeddings, caches and evaluation copies |
| Retention and retirement rules | Determine how long each copy remains usable |
| Evidence and review date | Show why the current decision is justified |
Keep a link to the approval evidence. A field that says “approved” without showing the scope and approver can hide significant differences between what was reviewed and what engineers implemented.
Map the full path from source to answer
Follow one source through ingestion, parsing, storage, retrieval, generation, tool use, caching and monitoring. Record each new copy or transformation.
Access controls need to survive this path. A restricted document can become exposed through an extracted table or a support trace even if the original repository remains protected. Review derived artifacts according to what they contain and reveal.
Map who can retrieve content at runtime separately from who can administer the pipeline. Operations staff may need performance metadata without access to full source text.
Give each lifecycle event an owner
Define what happens when an owner changes a document, narrows its audience, disputes its accuracy or retires it. Specify who sends the signal, which systems respond, and what evidence proves completion.
Separate immediate blocking from later cleanup. A retrieval gate may stop new use while a controlled process removes derivatives. For implementation detail, see LuMay's guide to RAG document deletion.
Do not let a connector's temporary outage silently redefine retention policy. Distinguish unavailable, unapproved, expired and retired sources in the register.
Illustrative example: an internal customer-support knowledge base
A hypothetical company approves product manuals for its support assistant. Its internal incident notes include customer details and are restricted to a smaller team.
The register permits manuals for support retrieval and evaluation. Incident notes are approved only for a restricted investigation workflow. The evaluation team therefore builds ordinary support tests from manuals and synthetic examples rather than copying incident records into a broadly accessible test set.
When an old manual is withdrawn, its source ID links to indexed chunks and cached answers. The source owner requests retirement, the platform team blocks reuse, and the steward checks completion evidence. This example illustrates assignment of responsibility; it is not a customer case study.
Test governance as application behavior
A register is useful only if the application enforces the decisions it records. Run checks under representative identities and workflows.
- A user outside the approved audience cannot retrieve the restricted source.
- A source approved for retrieval cannot enter training or evaluation automatically.
- A permission change reaches derived search content and relevant caches.
- A retired version is not reintroduced by recovery or backfill.
- An operator can identify the owner of a disputed answer source.
Record failures as gaps in a specific control or ownership relationship. “Needs better governance” is too vague to assign or verify.
Measure coverage and unresolved decisions
Track sources with current owners, sources with defined permitted uses, overdue reviews, unresolved exceptions and retirement jobs awaiting verification. Report the denominator: ten completed reviews out of twelve in-scope sources means something different from ten across an unknown estate.
A high register-completion percentage does not prove that permissions work. Pair administrative coverage with runtime test evidence and incident findings.
Who should maintain the register?
Assign business ownership for permitted use, stewardship for source quality, and platform ownership for enforcement. Security, privacy and legal specialists should resolve questions within their remit. Avoid making the engineering team the default owner of every business decision.
Choose one application, map its inputs and derivatives, and resolve the missing owners first. That produces a governance process the organization can actually operate.
