How to Route AI-Generated Drafts Through Approvals and Compliance Checks

A marketing manager asks an in-Studio assistant to draft twelve product descriptions, approves them in a hurry, and three weeks later legal discovers one made an unsubstantiated health claim that shipped to production in four locales. Nobody can say who reviewed it, what source it was grounded in, or when it went live. That is the failure mode of ungoverned AI content: not that the model was wrong, but that the wrong output moved through your pipeline with no seatbelt. Sanity is the AI Content Operating System, an intelligent backend built to keep AI-generated drafts governed, reviewable, and safe inside the editorial loop rather than leaking straight to publish.

The instinct is to slow AI down with more manual gates. That trades one problem for another, because reviewers who read everything read nothing carefully. The better frame is routing: treat an AI-generated draft as a first-class content state that must pass explicit checks, carry provenance, and land in a human's queue before it can ship. This guide covers how to design that route, from the moment a model writes a block to the moment it clears compliance and publishes.

Why AI drafts break traditional approval workflows

Most approval workflows were designed for a world where a human authored every word, so the volume was self-limiting and the accountability was implicit. When a person wrote it, a person owned it. AI generation inverts both assumptions. A single editor can now produce hundreds of drafts an hour, and the model that wrote them owns nothing. Your reviewers, sized for human throughput, become the bottleneck or, worse, the rubber stamp. Enterprises feel this fast: the pilot that promised faster content ends up either stalled in review or shipping unchecked because review could not keep pace.

The deeper problem is that a legacy CMS treats content as a binary, draft or published, with no room for the states AI workflows actually need: generated-but-unverified, grounded-against-a-source, flagged-for-legal, cleared-for-locale. Legacy CMSes stop at publishing, so the governance you need lives outside the tool in spreadsheets, Slack threads, and tribal knowledge. That is exactly where provenance goes to die. When an auditor asks which source a claim came from, or a regulator asks who approved a financial disclosure, a draft-versus-published model has no answer.

Routing fixes this by making the intermediate states explicit and enforceable. An AI-generated draft should not be able to reach the published state without traversing the checks you defined, and each transition should leave a record. This is less about adding friction and more about encoding your policy into the content lifecycle so that the safe path is the default path, not the disciplined exception. The rest of this guide builds that route step by step, starting with how the draft is created.

Design the draft state so provenance travels with the content

Governance starts before the first review, at the moment the model writes. If an AI-generated draft arrives as an undifferentiated blob of text, you have already lost the metadata that makes the rest of the route enforceable. You cannot check what you cannot inspect. The fix is to generate into a structured content model where every AI-touched field carries its own provenance: which model produced it, what prompt and source grounded it, when it was generated, and whether a human has since edited it.

This is where a structured format earns its keep. Portable Text represents rich text as discrete blocks, marks, and annotations rather than a wall of HTML, which means you can attach provenance at the block level and preserve it as the content moves through chunking, retrieval, and generation. A single paragraph that a model rewrote can be flagged independently of the ones a human wrote, so reviewers spend their attention where the risk actually is. Sanity, the AI-native content platform, wires this in at the schema layer: Agent Actions generate and transform content against your schema, so outputs land as validated, structured fields rather than free text that has to be parsed after the fact.

Grounding belongs here too. When a draft is generated from a Knowledge Base or a dataset embedding rather than the model's open-ended imagination, the source is knowable and reviewable, and compliance checks downstream can verify claims against it. AI Assist lets editors generate, summarize, or fact-check a block against that grounding source directly in the Studio. The principle is the same throughout: design the draft state so that everything a reviewer and an auditor will later need is captured at creation, not reconstructed after an incident.

Route drafts into staged review with Content Releases

Once drafts carry provenance, they need somewhere to go that is neither the author's private workspace nor the live site. The middle ground is a staging state where related changes are grouped, reviewed together, and scheduled as a unit. Reviewing a batch of AI-generated product updates one document at a time invites inconsistency; reviewing them as a coherent release lets a legal or brand reviewer see the whole surface area of a change before any of it ships.

Content Releases in Sanity provide this staging layer. A set of AI-generated drafts can be bundled into a release, previewed exactly as it will appear on the frontend through the Presentation Tool and Visual Editing, and held until every required approval is in. Because the release is a first-class object, its status is queryable: you can ask which releases are awaiting legal sign-off, which are cleared, and which are scheduled, rather than chasing that state across email. This is the routing mechanism made concrete, drafts do not drift toward publish, they move through named gates.

Studio Workspaces and Roles & Permissions determine who can move a release between states. An editor might generate and stage, but only a compliance role can mark a release cleared, and only a publisher can schedule it. That separation of duties is the governance backbone: the person who prompted the model is not the person who signs off that its output is safe. Legacy CMSes make you work their way, forcing your policy into whatever fixed workflow the vendor shipped. A Content Operating System adapts to yours, so the review stages, the roles, and the ordering match the way your organization actually approves content, whether that is a two-person editorial check or a five-step regulated-industry gauntlet.

Automate compliance checks with Functions before a human ever looks

Human reviewers are expensive and inconsistent at the mechanical parts of compliance: checking that a disclaimer is present, that no banned claim slipped in, that a regulated term is used correctly, that every locale variant exists. These are exactly the checks you want to run automatically on every AI-generated draft, so that human attention is reserved for judgment calls rather than checklist enforcement. If a machine can catch it, a machine should catch it first.

Functions are serverless automation hooks that fire on content events, and they are the right place to encode mechanical compliance. A moderate-on-publish function can scan a draft for prohibited claims and block the transition if it finds one. An enrich-on-publish function can verify that required disclosures are attached. A translate-on-publish function can fan a cleared draft out to every required locale so that no market ships an unreviewed variant. Because these run inside the content lifecycle rather than as an external batch job, they gate the transition itself: a draft that fails the check cannot advance, full stop.

The important design move is to run automated checks before the release reaches a human, not after. When the mechanical failures are filtered out upstream, your compliance reviewer opens a release that is already free of missing disclaimers and banned phrases, and can focus on the genuinely ambiguous. This is how you scale output without scaling headcount: rigid CMSes force you to add people as volume grows, while automation in the content layer lets a fixed review team handle far more AI-generated throughput. AI Assist can even fact-check a flagged block against the grounding Knowledge Base in the Studio, turning a compliance failure into a one-click remediation instead of a rewrite from scratch.

Give reviewers grounding and context, not just a text diff

A reviewer who sees only the final text of an AI-generated draft is guessing. Is this claim true? Where did the number come from? Did the model invent the citation? Without grounding visible at review time, the human gate becomes theater, a signature on something the reviewer had no real way to verify. The most common governance failure is not a missing approval step, it is an approval step where the approver lacked the context to approve responsibly.

The remedy is to surface provenance and source alongside the draft. Because the draft was generated against a Knowledge Base or dataset embedding and that link was preserved, a reviewer can see which passages grounded which claims and check them without leaving the Studio. Embeddings tied to content mean the semantic relationship between a generated claim and its source is inspectable rather than lost. When freshness matters, Content Lake real-time subscriptions and the Live Content API ensure the reviewer is looking at the current state of both the draft and its grounding source, not a stale snapshot from when generation ran.

This is also where Sanity Context fits, the grounding layer that makes AI outputs traceable back to governed content. For teams building agent-driven pipelines, the deeper retrieval and grounding architecture is a topic in its own right; the governance point here is narrower and non-negotiable: a reviewer must be able to answer where did this come from before they clear it. Content Source Maps carry that lineage through to the rendered page, so even after publish you can trace a live claim back to the field, the source, and the release that shipped it. Provenance that survives all the way to production is what turns a review signature into an audit-defensible decision.

Keep an audit trail that survives the regulator's question

The test of a governance system is not whether it works on a good day but whether it can answer a hostile question months later. When a regulator, an auditor, or your own legal team asks who approved this, what did they see, and when did it go live, the answer must exist as a record, not a reconstruction. AI generation raises the stakes because the volume of content and the opacity of the model make after-the-fact reconstruction effectively impossible. If the trail was not captured as the content moved, it does not exist.

Every transition in the route should be logged: the model that generated a draft, the automated checks it passed or failed, the human who cleared each stage, and the release that carried it to production. Audit logs and Roles & Permissions in Sanity provide the accountability layer, recording who did what and constraining who could do it in the first place. Combined with Content Releases as the unit of change and Content Source Maps as the lineage from claim to page, you get a chain of custody for AI-generated content that runs from prompt to published pixel.

Compliance posture matters here too, and it is worth being precise. Sanity maintains SOC 2 Type II compliance, supports GDPR obligations, offers regional hosting and data residency options, and publishes its sub-processor list so you know exactly who touches your content. Those are the facts to bring to a security review, stated plainly and without embellishment. The broader point is that governance for AI content is not a single feature but a property of the whole route: structured generation, staged review, automated checks, grounded reviewers, and an immutable trail. A legacy CMS that stops at publishing leaves each of those to bolt-on tools and manual discipline. A Content Operating System operates content end to end, which is what lets the safe path be the default one.