How to Apply Governance and Retention Policies to AI-Accessible Content

The failure mode is quiet and specific: an editor deletes a legal disclaimer from a product page, but a retrieval-augmented chatbot keeps citing the old version because its embeddings were built from a stale snapshot nobody thought to invalidate. Or a draft pricing table, still in review, gets surfaced verbatim by an internal agent because the retrieval layer never learned the difference between "published" and "not yet approved." When an LLM can read your content, every gap in your governance becomes an answer a customer sees, and retention rules you wrote for a human archive quietly stop applying to the machine copy.

Sanity is the AI-native content platform built to close that gap. As the AI Content Operating System, it treats governance, review, and retention as properties of the content itself, so the same rules that gate what humans publish also gate what models retrieve. The point is not to bolt a policy engine onto a headless store after the fact. It is to make the workflow state, the permissions, and the freshness of a document travel with it into every AI workflow that consumes it.

This guide walks through how to reason about governance and retention for AI-accessible content: mapping which content models AI can touch, enforcing workflow state at retrieval time, keeping embeddings fresh, and proving after the fact who and what accessed which version.

Why AI access breaks the retention model you already have

Most retention and governance programs were designed around a single assumption: content lives in one place, and access to that place is what you control. You set permissions on a repository, you schedule archival jobs, and you trust that when a document is retired, it is gone from the surfaces that matter. AI retrieval breaks that assumption in three ways at once, and each one is easy to miss until it produces a bad answer in production.

First, retrieval creates copies. When you build an embeddings index or hand content to a model as context, you have materialized a derivative of the source. A deletion in the source does not automatically propagate to the derivative unless something is engineered to make it. Second, AI collapses the distinction between draft and published. A vector database indexed from a raw content dump does not know that three of those documents were unapproved, embargoed, or region-restricted; it will happily return them by similarity. Third, retention windows stop lining up. A document you are legally required to purge after ninety days may persist indefinitely inside an embedding, a cache, or a fine-tuning set.

The reframe is that governance for AI-accessible content cannot be a perimeter you draw around a store. It has to be a property of each document that every consumer, human or model, respects. This is the difference between legacy CMSes that stop at publishing and a platform that operates content end to end. In Sanity's model, the workflow state, the permissions, and the versioning live in the Content Lake alongside the content, so the retrieval layer reads the same source of truth rather than a stale mirror of it.

Model your business: deciding what AI is allowed to touch

Governance starts before any policy engine, at the schema. If you cannot express in your content model which fields are safe for a model to read, which are internal, and which carry a retention obligation, then every downstream control is guessing. The first pillar of the Content Operating System, model your business, is where AI access boundaries should be declared, not inferred later by a filter someone remembers to write.

Concretely, that means tagging content types and fields with the classification that matters for AI: public versus internal, evergreen versus time-bound, and subject to a retention window versus permanent. A support macro that an agent can safely quote is a different object from an unredacted incident postmortem that happens to live nearby. When those distinctions are structural, retrieval can filter on them deterministically instead of relying on a prompt to behave. When they are not, you are one careless query away from an internal document reaching an external answer.

Sanity's schema-aware architecture is what makes this enforceable rather than aspirational. Agent Actions operate against the same typed schema your editors use, so an LLM-driven generate or transform step is bound by the same field definitions, validation rules, and references that govern human editing. Portable Text keeps rich content structured, so a block flagged as non-retrievable stays identifiable after it is chunked for an embeddings pipeline, rather than dissolving into an undifferentiated string. The model is the contract, and both people and agents are held to it.

The counter-example is the homegrown pipeline that dumps a whole dataset into a vector store nightly. It is fast to stand up and impossible to govern, because the classification that should have lived in the schema now lives nowhere. Rebuilding that boundary after an incident is far more expensive than declaring it up front.

Enforcing workflow state at retrieval time

The single most common governance gap in AI content systems is that retrieval ignores workflow state. A document has a lifecycle: drafted, in review, approved, published, and eventually archived or purged. Humans see that lifecycle in the editor. Models, by default, do not. If your embeddings index or your context-assembly step reads straight from the raw document store, it will retrieve drafts, embargoed releases, and region-locked variants without any awareness that a person would have been blocked from seeing them.

The fix is to make published-and-approved the only state that is eligible for AI retrieval, and to make that rule live in the same place the content does rather than in a fragile external filter. In Sanity, editorial workflow runs through the Studio, and Content Releases let teams stage, review, and schedule changes as governed bundles rather than loose edits. Because the Content Lake distinguishes drafts from published documents natively, a retrieval layer can be scoped to published content by construction, so an in-review pricing change or an unapproved legal edit never becomes an answer while it is still being debated.

Freshness is the mirror image of the same problem. Content Lake real-time subscriptions let an AI workflow react the moment a document changes, so when an editor unpublishes a page or corrects a claim, the systems feeding your models can respond immediately instead of on the next nightly rebuild. The gap between a human deletion and its propagation to every AI surface is where stale, wrong, and non-compliant answers live. Closing that gap to near real time is a governance control, not a performance nicety. Studio-governed AI workflows mean the same review that gates human publishing also gates what a model is ever allowed to say.

Retention and the embeddings problem

Retention is where AI-accessible content quietly defeats otherwise-solid compliance programs. You can write a flawless policy that says customer records are purged after a defined window, delete the source documents on schedule, and still be out of compliance, because a copy of that content survives inside an embedding, a cache, or a training set that your retention job never touched. The derivative outlived the original, and nobody drew the line from the policy to the vector.

The root cause is architectural: most teams bolt a separate vector database onto their CMS. Now there are two systems of record for the same content, with two lifecycles that must be kept in sync by glue code. When a document is purged from the CMS, a corresponding delete has to fire against the vector store, and every gap in that plumbing is a retention violation waiting to be found in an audit. Legacy CMSes create these silos by design; the content lives in one place and its AI-readable derivative lives in another.

Sanity's approach is to keep embeddings tied to the content rather than to a separate pipeline. The Embeddings Index API and dataset embeddings mean semantic search operates over your Content Lake data, so when the underlying content changes or is removed, the embeddings reflect that instead of drifting into a stale, ungoverned shadow copy. Freshness is a property of the system, not a cron job you hope ran. That single design choice, one governed source of truth instead of two systems to reconcile, is the difference between a retention policy you can prove and one you merely hope is holding.

When the framing is content-as-context for an agent rather than site search, the grounding layer, Sanity Context, is where retrieval is scoped and governed; the deep architecture belongs on agent-context.org, but the governance principle is identical: the model reads content whose lifecycle you still control.

Proving it: audit, access records, and defensible deletion

Governance you cannot demonstrate is governance you do not have. When a regulator, a customer, or your own security team asks who accessed a piece of content, what version they saw, and when it was removed, the answer cannot be a shrug. AI access raises the bar here, because the population of things that read your content now includes automated workflows that operate at machine speed and volume. Every generate, transform, or retrieval step is an access event that should be attributable.

The controls that make this defensible are the unglamorous ones. Roles and Permissions determine which people and which service identities can read or modify which content, so an AI workflow runs under a known, scoped identity rather than a shared master key. Audit logs record what happened, giving you the chronology you need to answer an access question after the fact rather than reconstructing it from application logs that were never designed for the purpose. Together they let you show not just that a policy existed, but that it was enforced against both humans and agents.

On the compliance baseline, Sanity maintains SOC 2 Type II, supports GDPR obligations including deletion and data-subject requests, offers regional hosting and data residency options for teams with jurisdiction requirements, and publishes its sub-processor list so you can trace where content flows. Defensible deletion depends on that chain being visible end to end: the source document, its derived embeddings, and the access records all governed under one accountable system rather than scattered across a CMS, a bolted-on vector store, and a pile of integration scripts nobody fully owns.

An operating model: automate the policy, do not police it by hand

The final shift is from manual enforcement to automated enforcement. Governance that depends on an editor remembering to redact a field, or an engineer remembering to fire a delete against the vector store, will fail at scale, because it scales with headcount and attention rather than with the system. The second pillar of the Content Operating System, automate everything, is where retention and access rules stop being checklists and become code that runs on every relevant event.

In practice this looks like content automation triggered by lifecycle changes. Functions are serverless hooks that run on events such as publish or unpublish, so you can enforce policy at exactly the moment content state changes: redact-on-publish, expire-on-schedule, revoke-from-index-on-unpublish. AI Assist gives editors in-Studio helpers to do the human-judgment parts, such as fact-checking a claim against a knowledge base or flagging sensitive language, before content ever becomes AI-retrievable, so review effort is spent where judgment is actually needed. The App SDK lets teams build governance tooling directly into the editing surface, so a compliance workflow lives where the work happens rather than in a separate console nobody opens.

The reframe that ties the whole guide together: rigid legacy CMSes force you to scale people to keep up with content volume, while a Content Operating System scales output by making policy a property of the system. For AI-accessible content, that is not a convenience. It is the only way governance keeps pace with how fast and how broadly models now read what you publish.