How to Stop AI From Overwriting Editor Changes

An editor spends an hour rewriting a product page's hero copy, tightening the legal disclaimer, and fixing a mistranslated heading. Twenty minutes later an enrich-on-publish job fires, an LLM regenerates the page from its source brief, and every one of those edits is gone, silently overwritten by a confident machine that had no idea a human had been there.

This is the quiet failure mode of bolting AI onto a CMS: generation and human editing race over the same fields, and whoever writes last wins. The stakes are not just annoyance. Overwritten edits mean reintroduced compliance language, resurrected mistranslations, and editors who stop trusting the system and start copy-pasting into Google Docs to keep their work safe.

This guide reframes the problem away from "make the AI smarter" and toward governance: the answer is not a better prompt, it's a content model and workflow where AI writes into a reviewable surface, never directly over human intent. We'll cover the mechanisms, field-level provenance, staged AI output, review gates, and where a CMS's architecture decides whether this is solvable at all.

Why AI overwrites editor work in the first place

The overwrite problem is almost never a bug in the model, it's a missing concept in the content model. Most AI-CMS integrations treat generation as a write: a trigger fires (a webhook, a publish event, a button), the LLM produces text, and the integration patches that text straight onto the live document fields. There is no notion of who last touched a field, no record of whether the current value was authored by a human or a machine, and no gate between the model's output and the field it lands on. So when an editor's careful revision and an automated regeneration both target `body` or `metaDescription`, the system has no basis for choosing, it just applies the most recent write.

This gets worse with the patterns teams actually deploy. Scheduled jobs re-run translations across all locales. Bulk "refresh stale content" actions sweep through hundreds of documents. An agent watching a source feed regenerates a summary whenever the upstream PDF changes. Each of these is reasonable in isolation, but none of them can tell the difference between a field that's safe to regenerate and one a human deliberately corrected an hour ago. The model isn't malicious; it's blind to provenance.

The reframe that fixes this is to stop letting AI write directly to canonical fields. Generation should produce a *proposal*, a draft, a separate field, a staged version, that a human or a rule promotes into the live document. The moment AI output lands somewhere reviewable instead of somewhere live, "AI overwrote my edit" becomes "AI suggested a change I declined." That shift is architectural, and it's the through-line of everything below.

Provenance: knowing which fields a human owns

You cannot protect an edit you can't identify. The foundational governance primitive is field-level provenance: a durable record of what produced each value, which model, which prompt, which run, or which human at which timestamp. With provenance, an automation can ask the only question that matters before it writes: "Did a person touch this field after the last AI run?" If yes, skip it, or route the regeneration into a draft for review instead of overwriting.

The hard part is that provenance has to live in the data, not in the integration code. If you track "AI-generated vs human-edited" in an external job log, every other writer, the Studio editor, a different automation, an import script, is invisible to it, and the guarantee leaks. The provenance has to be attached to the content itself so that any consumer, human or machine, reads the same truth.

This is where a structured content model earns its keep. Sanity's Content Lake stores every document as queryable, structured JSON, and Portable Text represents rich text as discrete blocks, marks, and annotations rather than an opaque HTML string. That structure means you can attribute and protect at the granularity of a block or a field, regenerate the intro block while leaving the human-edited legal block untouched, instead of treating the whole body as one all-or-nothing value. Combined with the document history that Content Lake retains, you can answer "who wrote this, and when" without bolting on a separate audit system. Provenance you can actually query is the precondition for every protection rule that follows; without it, "don't overwrite human edits" is a wish, not a policy.

Stage, don't overwrite: AI output as a reviewable draft

Once you can identify human-owned content, the next move is to make sure AI never writes to the live version at all. The pattern is to route every generation into a staging surface, a draft document, a separate release, or a dedicated proposal field, and require an explicit promotion step before it becomes canonical. This converts a destructive write into an additive suggestion. Nothing the model produces can clobber published work, because the model literally does not have a path to the published field.

Concretely, this looks like: a translate-on-publish job writes the new French heading into a draft, not the live document; a "refresh this summary" agent opens a change for review instead of patching the field; a bulk regeneration produces a batch of proposed edits an editor approves or rejects in one pass. The human stays in the loop by default, and the loop is cheap because the diff is small and the original is never at risk.

Sanity gives you the surfaces for this directly. Drafts are first-class, every document has a draft and published form, so AI can populate the draft while the published version stays frozen. Content Releases let you stage a batch of AI-driven changes, review them together, and schedule or roll them back as a unit, which is exactly what you want for a bulk regeneration that touched two hundred documents. Functionsserverless hooks on publish or on change, are where you wire the discipline in: an enrich-on-publish Function writes its output to a draft or a release rather than mutating the live document, so the automation is structurally incapable of overwriting an editor mid-flight. The governance lives in the pipeline, not in everyone's good intentions.

Schema-aware generation that respects field boundaries

A lot of overwrites happen because the generator works at the wrong granularity. A model handed "rewrite this page" will rewrite everything, including the three fields a human just fixed, because it was never told those fields exist as separate, protectable units. The fix is generation that understands the schema: it knows `legalDisclaimer`, `heroHeadline`, and `body` are distinct fields with distinct rules, and it can be scoped to touch only the ones a workflow permits.

This is the difference between a generic LLM integration and AI that's wired into the data model. A generic integration sees a blob of text in, a blob of text out. A schema-aware one sees a typed document and can be instructed: regenerate the SEO description, but never the disclaimer; translate the headings, but leave any heading flagged as human-locked alone. The schema becomes the contract that bounds what AI is allowed to write.

Sanity's Agent Actions are built around exactly this idea, they are schema-aware operations (generate, transform, translate, patch) that act on your defined content types and fields, not on raw strings. Because the action knows the shape of the document, you can target a single field, exclude others, and combine that with the provenance and draft patterns above so a transform writes a proposal scoped only to the fields it's allowed to touch. AI Assist works the same way inside the Studio: an editor triggers a rewrite on a specific block, sees the result in place, and accepts it, generation is an editor-initiated, field-scoped act, not a background process sweeping the whole document. When generation respects field boundaries, most overwrite scenarios simply never have the opportunity to occur.

Governance gates: review, approval, and rollback

Provenance tells you who owns what; staging keeps AI out of the live version; but you still need an explicit place where a human decides what ships. Governance gates are that place, the review and approval steps that sit between an AI proposal and publication, plus the rollback that saves you when something slips through anyway. Without a gate, "AI writes to a draft" just defers the problem: someone eventually publishes the draft, and if no one reviewed the diff, the overwrite happens at publish time instead of generation time.

The gate that works is one editors actually use, which means it has to live where they already work and show them a meaningful diff: here's what the model changed, here's what a human had previously written, choose. For bulk operations the gate has to scale, reviewing two hundred AI-touched documents one at a time is how teams end up rubber-stamping bad changes. And when a bad change does ship, version history has to make reverting a single field or a whole batch a quick, safe operation rather than an archaeology project.

Sanity Studio is where these gates become real workflow rather than policy documents. Content Releases bundle AI-driven changes for batch review, scheduling, and atomic rollback, so a regeneration that touched many documents is one reviewable, reversible unit. Studio's customizable workflows let you require approval before a draft carrying AI output gets published, and the full document history in Content Lake means reverting an overwritten field is a known operation, not a recovery effort. The point is to make the safe path the default path, AI proposes, the gate holds, a human or a rule promotes, so that protecting editor work doesn't depend on anyone remembering to be careful.

Designing the workflow end to end

Putting the pieces together, a system that doesn't overwrite editor work has a shape you can draw. Generation, whether from a Function, an Agent Action, or an editor-triggered AI Assist call, writes to a draft or a release, never to a published field. Every written value carries provenance, so the next automation can see whether a human has intervened. A gate sits before publication: editor review for high-stakes content, an automated rule for low-stakes fields, and a diff that makes the human's previous work visible against the machine's proposal. History backs the whole thing so any mistake is one revert away.

The design decisions worth making explicit: which fields are AI-eligible at all (a legal disclaimer probably shouldn't be regenerated automatically, ever); what the conflict rule is when both a human and a model have a claim on a field (default to human-wins, route the AI version to review); and how bulk operations are batched so review stays tractable. These are content-model and workflow decisions, made once, that then bind every AI integration you add later, which is the whole point of putting governance in the platform rather than in each script.

This is why the CMS's architecture is the real variable. On a platform where AI is a plugin patching live fields, you're rebuilding provenance, staging, and gates in glue code for every integration, and the guarantees only hold for the integrations you remembered to wire correctly. On Sanity, the substrate already exists, structured content with history in Content Lake, drafts and Content Releases for staging, Agent Actions and Functions for schema-aware generation, Studio for the gate, so "AI never overwrites a human edit" is a configuration of primitives that are already there, not a custom system you have to invent and maintain.