When AI Edits the Document, Who Owns the Change?

A document can show who changed a sentence while leaving you guessing who approved what it now says. Once AI and people have both revised the wording, a name beside the final edit doesn’t answer that question.

Consider a hypothetical support policy promising a response within two business days. An AI rewrite proposes one business day. A human editor changes that to three, and a team lead approves the document. The released file looks ordinary. Its history contains a rejected proposal, a human revision, and a decision about what customers should expect.

Who owns that change? We need to distinguish the contributions before we can assign responsibility for releasing them. Otherwise, “AI-assisted” tells us very little about how the final wording got there.

Separate the Edit From the Decision

Microsoft’s September 29, 2025 announcement that Agent Mode in Word was beginning its Frontier rollout placed conversational editing inside the document application, initially on the web. That announcement establishes the rollout date, not how any particular organization reviews the resulting changes.

For a team using AI this way, the useful starting point is the person requesting the edit. Record that person separately from the software generating it. If someone then rewrites the suggestion, preserve that contribution too. Approval is another action, attached to the version the reviewer actually saw.

Those roles don’t require separate people for every task. An editor might request a rewrite, revise it, and have authority to approve it. The distinction still matters: requesting a shorter paragraph doesn’t necessarily mean approving every alteration the software makes.

The W3C PROV data model provides a vocabulary for describing this history. Documents and their versions can be represented as entities; edits and approvals as activities; people and software as agents. The model describes relationships between them. It doesn’t determine legal liability or authenticate whoever appears in an author field.

For AI-assisted document workflows involving technical writing or support material, this means defining what each recorded action represents. A comment identifies a contribution to the discussion. An approval should identify permission to release particular wording. Giving both the same generic “reviewed” status would make the record less useful.

Build a Record for One Changed Passage

Return to the response-time example. Before generating a rewrite, retain the approved two-business-day wording and its document version. Give the proposed change an identifier, then connect later revisions and decisions to it.

The following is an illustrative design, with invented identifiers. It isn’t output from a tested product or a schema that every document tool supports.

Keep the AI proposal after the human revision replaces it. If the record retains only the final three-business-day wording, a later reviewer can’t reconstruct the earlier suggestion from that entry. Rejected changes are part of the history even though they don’t belong in the published text.

NIST’s July 2024 Generative AI Profile describes provenance as information about content’s origin and history, including modifications and sources. It also recommends evaluating the relationship between provenance processes and human reviewers. The table applies that idea to a document workflow; it isn’t a NIST certification checklist.

You can retain this record within the document system or in a connected repository. Either way, make the relationship to the released version explicit enough that someone can retrieve it without relying on the original editor’s memory.

Check What Survives the Handoff

An exported file deserves its own check. The history available during editing may differ from what a recipient can inspect, depending on the application, format, and export settings. Don’t assume that every PDF loses attribution, or that preserving visible comments preserves every review decision.

Microsoft’s current documentation for editing with Copilot says its changes respect Track Changes when that feature is enabled. That’s useful functionality. It doesn’t establish that your complete approval history survives every subsequent conversion or handoff.

Test the route your team actually uses. Take the example document through review and export, then try to recover the accepted revision and its approver using the retained records. If the released file can’t carry that history, keep a controlled record elsewhere and preserve the connection between them.

The less straightforward cases deserve attention too. Accept only part of a suggestion and inspect what the record says. Have two reviewers work against the same base version, then establish which changes reached the released file. Finally, edit the passage after approval and verify that the earlier decision hasn’t silently become approval of the new wording.

A displayed author name should be traceable to an authenticated account before you rely on it for identity. Similarly, a file digest can help identify the released artifact, but it can’t tell you whether the response-time commitment is correct. Those are separate checks, and your review process needs to preserve the distinction.

Set the Approval Boundary Before Release

Changing a heading’s formatting and changing a customer commitment needn’t follow identical review paths. Decide which edits can proceed under an established policy and which need a designated person’s approval. That choice should reflect what the change means for the people using the document.

The argument for explicit AI decision authority becomes practical here. In our example, someone needs authority to approve a three-business-day response commitment. Permission to edit the file alone shouldn’t be treated as evidence of that authority.

Give that reviewer enough context to decide. Show the original and proposed wording alongside any intervening human revision. Make unresolved conflicts visible, and identify the version intended for release. A reviewer who sees only a polished final paragraph may have no reason to notice that the response time changed.

Settle who owns release before handing the workflow over to users. That person doesn’t have to perform every edit, but they need a way to establish that the required review happened and applies to the file they’re releasing. Leaving the assignment vague makes it harder to resolve a disputed change when the document is ready to go.

This doesn’t require keeping every confidential prompt indefinitely. Retain the evidence needed to explain the decision under your organization’s access and retention policy. If model-version information isn’t available, record the limitation. A useful history should make missing information apparent rather than imply a level of detail the system never captured.

Release Only the Version You Can Account For

Before releasing a consequential change, try tracing it back through the record. Find the original suggestion, establish what the human editor changed, and retrieve the decision accepting that revision. Then compare the approved version with the file being delivered.

If that connection is missing, hold the review change. Someone remembering that the document was “approved” isn’t enough to establish which wording they approved.

An editor should be able to explain their contribution without being assigned every suggestion the AI produced. The release owner needs to know precisely what they’re authorizing. We can’t ask people to stand behind changes while giving them no reliable way to inspect how those changes were made.