How to draft policy updates for approval with an AI agent

A good policy update arrives as tracked changes against the current version, with every change tied to its cause. That is what the agent should produce: a redline, a change log, the consequential edits to procedures and templates, and a note of open questions. The policy owner decides what stays, and the approving committee or senior manager signs off.

What is the process, and who owns it?

Policies change for four reasons: a regulatory change, an internal incident or audit finding, a change to products or systems, and the scheduled review. In each case someone must work out what to change, write it precisely, check it does not contradict other policies, and take it to whoever approves policies of that kind.

The policy owner, a named senior person, owns the content. Compliance or a policy governance team owns the process and the library. The approver is usually a committee or, for lower-tier documents, a senior manager. The agent's job is the drafting labour; when an agent can act without human approval is never the question here, because publishing a policy always needs one.

What are the steps, and at what depth?

1. Person, policy owner: opens the change. States the trigger, such as a regulatory change from tracking regulatory updates, an audit finding or a product launch, and the scope.
2. Agent, depth 1: reads the current version and the trigger. It identifies the clauses affected, quoting both the trigger text and the current clause.
3. Agent, depth 2: drafts the redline. Tracked changes against the approved version only. Each change carries a comment linking it to its cause.
4. Agent, depth 1: checks consistency. Against other policies in the library, definitions, thresholds and roles. Conflicts are listed, not silently resolved.
5. Agent, depth 2: drafts consequential changes. Procedures, forms, customer templates, training material and agent briefs that cite the changed clauses.
6. Agent, depth 2: drafts the approval paper. A one-page summary: why, what changes, what does not, the impact on teams and customers, open questions and the proposed effective date.
7. Person, policy owner: edits and agrees the draft.
8. Person, approver: approves, with any conditions.
9. Person, library owner: publishes, and the agent flags dependants to update.

Which controls apply, and what evidence does each leave?

Redline against the approved version. Never against a working copy. Evidence: the base version number on the draft.

Every change has a cause. A change with no link to a trigger is either an improvement the owner chose, recorded as such, or scope creep. Evidence: the change log, which approvers increasingly expect to see.

Conflicts surfaced. The consistency check lists every conflict with both texts quoted. Evidence: the list and how each item was resolved.

Dependants tracked. A policy change that leaves procedures and templates behind is only half done. Evidence: a dependants list, each with an owner and a status. This includes agent briefs: an agent reading an old version of a procedure will keep doing the old thing.

Approval recorded against the exact text. Evidence: the approved version is the one published, byte for byte.

What should you measure?

• Time from trigger to approved policy, by trigger type.
• Changes the owner rejected or rewrote, and why.
• Conflicts found after publication that the consistency check missed.
• Dependants still outstanding a set time after publication.
• Approval papers returned for more information.
• Agent briefs updated after a policy change, against the number that depend on it. A brief left behind means an agent still applying the old rule.

Where does it usually go wrong?

Over-drafting. Asked to update one clause, the agent tidies the whole document. Every unrequested change has to be reviewed, and some will be wrong. Restrict the redline to the scope the owner set, and offer other improvements separately, in a short list the owner can take up at the next scheduled review.

Defined terms changed by accident. Policies depend on definitions: "customer", "high-risk", "material". A drafting agent that rewords a definition for clarity can change who or what the whole policy covers. Treat any change to a defined term as a change in its own right, listed separately in the change log and checked across every document that uses it.

Policy written as procedure. Policies say what and why; procedures say how. Drafts that pull operational detail into the policy make it harder to change and to approve. The owner should push detail down.

Sanctions and screening policies. Some changes need operational action, not just words. A policy update after a change in sanctions obligations, for example, may require customers to be rescreened; see rescreening customers after sanctions list updates.

Data protection missed. A change that alters how personal data is used may need a fresh assessment. The agent should flag it; whether a data protection impact assessment is needed is for the DPO.

The AI policy itself. Policies that govern agents need the same discipline. Start from an AI agent policy template and keep it in the same library.

The wider position of compliance agents is in AI compliance agents.