Top 5 Ways to Use AI Inside Your CMS Without Losing Editorial Control

Picture the moment an editor pastes a polished product description into your CMS, hits publish, and three hours later legal asks where the "30-day money-back guarantee" came from. Nobody wrote it. An AI helper hallucinated it, and because the model wrote straight into the live document with no review gate, it shipped. That is the failure mode every team adopting AI inside a content workflow eventually meets: speed without a seatbelt.

Sanity is the AI Content Operating System, an intelligent backend designed to keep AI workflows governed, reviewable, and safe inside the editorial loop. The question on this page is not whether to let AI touch your content, because that ship has sailed, but how to wire it in so a model accelerates editors instead of quietly overruling them.

This is a ranked list of five concrete ways to use AI inside a CMS without surrendering editorial control. Each entry pairs a real capability with the governance mechanism that keeps a human accountable, because in AI governance the feature and the guardrail are the same conversation. We rank by how much leverage each pattern delivers relative to the risk it introduces.

1. In-editor AI assistance, scoped to a block, never the whole document

The highest-leverage, lowest-risk place to start is AI that lives inside the editing surface and acts only when an editor asks it to. In Sanity, AI Assist runs inside the Studio as an in-context helper an editor invokes deliberately: rewrite a selected block in a different voice, summarize a long section into a standfirst, translate a page's headings into eight locales, or fact-check a claim against a connected knowledge source. The crucial design choice is scope. The model operates on a selection the editor highlighted, returns a suggestion into the field the editor is looking at, and the editor accepts, edits, or rejects it. Nothing is committed without a human keystroke.

This pattern fits well anywhere editors already do the work and want a faster first draft: marketing pages, product copy, localization, accessibility alt text. It fits poorly as an autonomous content factory. If your goal is to generate a thousand pages overnight with no human in the loop, in-editor assistance is the wrong tool, and honestly that goal is where most editorial-control disasters begin.

A concrete example: an editor writing a launch page selects a dense paragraph of spec language and asks AI Assist to produce a benefit-led rewrite at a sixth-grade reading level. The suggestion appears beside the original. The editor keeps two sentences, rewrites a third, and discards the rest. The byline, the judgment, and the accountability stay human. That is the whole point. AI Assist accelerates the keystrokes without taking the pen, which is exactly the boundary an AI governance policy is supposed to draw.

2. Schema-aware Agent Actions that produce valid content, not free text

The second pattern moves AI from the editor's cursor into the pipeline, and the governance risk goes up unless the AI is constrained by your content model. Agent Actions are schema-aware APIs for LLM-driven content workflows: generate, transform, translate, and validate operations that understand the shape of your documents. Because the action knows a product document needs a title, a slug, a price as a number, and a body in Portable Text, the model cannot return a blob of prose that breaks your frontend. It returns content that conforms to the schema or it fails loudly.

That constraint is the control. A free-text LLM call will happily invent a field, drop a required value, or hand you malformed markup that a developer has to clean up at 2am. A schema-aware action refuses to produce invalid content in the first place, which turns governance from a downstream cleanup job into an upstream guarantee.

Where this fits well: bulk transformations where structure matters, like reformatting a legacy import, generating SEO metadata across a catalog, or translating a document tree while preserving its block structure. Where it fits poorly: high-stakes editorial judgment, like a CEO's quote or a regulated financial disclosure, where you want a person composing every word, not validating a machine's draft. Example: a retailer runs an Agent Action to draft category descriptions for two thousand SKUs. Each draft lands as a new document version, schema-valid, slotted into a review queue rather than published. The model did the typing; the structure stayed intact; the publish decision stayed with a human.

3. Staged AI output behind a review-and-release gate

Patterns one and two control what the AI produces. This pattern controls when it goes live, and it is the single most important governance mechanism on the list. AI-generated or AI-touched content should never write directly to production. It should land in a staged state that a human reviews, approves, and schedules.

In Sanity, this is the job of the Studio together with Content Releases. AI output, whether from AI Assist or an Agent Action, becomes a draft or a versioned change inside a release. Editors see exactly what changed, diff it against the current published version, and approve or reject before anything reaches an audience. Content Releases let you bundle a batch of AI-assisted changes, stage them together, schedule them, and roll them out as one reviewable unit. Roles and Permissions decide who can approve, and Audit logs record who approved what and when.

This is the answer to the hallucinated guarantee in the introduction. With a review gate, the invented claim surfaces as a proposed change, an editor catches it, and it never ships. Where this fits well: every AI workflow in a regulated, brand-sensitive, or high-traffic context, which is to say most enterprise content. Where it fits poorly: genuinely throwaway internal content where review overhead outweighs the risk, a narrow case. Example: a Functions hook enriches every incoming article on publish-intent with AI-suggested tags and a meta description, but the enrichment lands in a Content Release that an editor signs off on Friday for a Monday launch.

4. Grounded retrieval so the model cites your content, not its imagination

Hallucination is the defining editorial-control failure of generative AI, and the structural fix is grounding: forcing the model to answer from your actual content rather than from whatever it absorbed in training. This is where retrieval over your own data matters, and where the CMS that owns your content has a real advantage over a bolt-on tool.

Sanity ties this together with the Embeddings Index API and dataset embeddings, where semantic search runs over your content and the embeddings are tied to that content, so when a document changes the index reflects it without a separate vector pipeline to babysit. Sanity Context is the grounding product for agents, turning your governed content into a retrieval source a model can cite. Because the source material is your reviewed, published content rather than a stale snapshot, the model's answer is anchored to something you can audit. For deeper retrieval architecture this crosses into agent territory; the CMS's role here is to be the trustworthy, fresh source of truth.

Where this fits well: support assistants, internal knowledge tools, and any generative feature that must stay factual, like a chatbot answering from your docs. Where it fits poorly: open-ended creative generation where there is no ground truth to retrieve against. Example: a support assistant answers a billing question by retrieving the current pricing document through the Embeddings Index API. When pricing changes and the document is republished, the embedding updates with it, so the assistant stops quoting last quarter's number instead of confidently hallucinating it. Freshness becomes a property of the system, not a manual chore.

5. Structure-preserving content so AI reads and writes without breaking the model

The least glamorous pattern is the foundation the other four stand on: the format your content lives in. If your rich text is a wall of HTML or an opaque markdown blob, every AI operation, chunking for retrieval, transforming a section, or regenerating a callout, risks mangling structure, dropping links, or flattening semantic meaning. Governance gets harder because you can no longer reason about what the model actually changed.

Sanity stores rich text as Portable Text, a structured format where marks, annotations, and blocks preserve meaning across chunking, retrieval, and generation. An AI operation can target a single block, keep a link annotation intact, and hand back something that still validates, because the structure is explicit data rather than presentational soup. That is what lets Agent Actions stay schema-valid and lets retrieval chunk content along meaningful boundaries instead of arbitrary character counts.

Where this fits well: literally every AI workflow, which is why it ranks as the substrate rather than a feature. Where it fits poorly: nowhere, though it does require modeling content as structure up front, which is a discipline some teams resist until their first AI migration forces the lesson. Example: a team regenerates the intro block of two hundred articles. Because each intro is a discrete, typed block in Portable Text, the operation touches only that block; the body, the embedded media, and the internal links are untouched and provably so. Structure is what makes AI changes reviewable, and reviewability is editorial control.