Quick answer (TL;DR): Let the AI assistant draft anything: workflow logic, a bulk-update plan, dedupe and merge rules, a routing change, the email explaining it to sales. But install one hard gate: nothing that touches production CRM data or reaches a stakeholder goes out without a named person approving the exact final version. Draft freely; ship deliberately. That rule keeps the speed of AI drafting and the judgment of someone who knows the stack and the room. Add a verification step (always confirm the change you approved is the change that actually landed) and you can delegate real ops work without being embarrassed by it.
This is the rule that makes it safe to hand real work to AI, and it’s the backbone of The Ops Operating System.
The tension: speed versus blast radius
AI assistants are excellent drafters. In seconds they’ll produce a first version of a HubSpot workflow spec, a Salesforce validation rule, a list of merge candidates or a tricky reply to a sales leader. That speed is the appeal.
In ops, speed without a gate is dangerous because of blast radius. A bad draft email embarrasses one person. A bad bulk update rewrites lifecycle stages on tens of thousands of records, re-triggers enrolment in nurture workflows, reassigns owners and corrupts the pipeline report the CFO reads on Monday. Some of that is hard to undo; a merge, for example, changes more than most teams expect.
The assistant also doesn’t know the room. It doesn’t know this sales leader is sensitive about lead reassignment, or that this field feeds a finance reconciliation. The answer isn’t to draft less. It’s to separate drafting from shipping.
The review-before-ship rule
Write it as a hard rule in the team’s preferences file:
Nothing that changes production CRM or marketing automation data, and nothing a stakeholder will see, goes out without a named person approving the exact final version.
In ops terms that covers:
- Activating or editing workflows, flows and programs.
- Bulk updates, imports, merges and deletions.
- Changes to routing, scoring, lifecycle or field definitions.
- Anything sent to stakeholders: emails, Slack posts, tickets, decks, dashboards.
For all of it, the assistant proposes; a person decides. It drafts the exact change or the exact text; someone who knows the stack reads it, approves it or changes it; only then does it go live.
You get both halves:
- The speed of never starting from a blank page.
- The judgment of someone who knows the data and the politics, applied at the moment that matters.
The sensible exception
Relax the gate in the team’s private workspace: the shared memory files, scratch analysis, a sandbox portal. The blast radius there is small and contained. Let the assistant act freely so trivial updates don’t queue for approval. The gate is for production and for people.
The ops version: sandbox, sample, then scale
For changes to data, the gate works best as three steps:
- Draft and test in a sandbox (or on a test list) where one exists.
- Run against a small sample in production and check the result record by record.
- Then scale, with a backup export taken first.
The assistant can draft each step, write the checks and compare before-and-after exports. A person approves each step before the next.
Documents you iterate on: who owns the master?
For documents revised over weeks, such as a routing spec, a lifecycle definition doc or the quarterly ops review deck, decide explicitly who owns the master copy.
What worked best for us: we kept one anchor file and made the edits ourselves, and the assistant gave precise, located instructions (“in the routing table, change the EMEA fallback owner from X to Y”) rather than producing a new version each time. That prevented version sprawl.
Then the step that matters more than it sounds: after the edits, the assistant re-read the file and checked that each change had landed.
Why verification is non-negotiable
When a person applies a list of edits by hand, the most common error isn’t a wrong edit. It’s a half-applied one. The old value stays in one branch of the workflow; the old phrase collides with the new one in the spec.
The same applies to data changes. After a bulk update, have the assistant compare the post-change export with what was intended: did every record in scope change, did anything outside scope change, and did any workflow fire that shouldn’t have? It’s the cheapest insurance you’ll buy.
Draft freely, ship deliberately, and always verify that the change you approved is the change that landed.
A practical loop for AI-assisted ops work
- Brief the assistant with the goal and context (the shared memory already holds most of it).
- Let it draft the change, the spec or the message in full.
- Review the exact final version yourself, with your knowledge of the data and the audience.
- Iterate with specific feedback.
- For data changes: sandbox or sample first, backup export before scaling.
- Verify: have the assistant confirm the result matches the intent, with nothing half-applied.
- Then, and only then, ship, through a named person’s explicit approval.
The gate adds minutes, not days, and it’s the difference between “AI saved us time” and “AI caused an incident we spent a week unpicking.”
The mindset: a capable junior admin who needs sign-off
Treat the assistant like a sharp, fast junior admin whose changes you’d never push to production unreviewed. Not because they’re bad, but because the team owns the outcome and knows the history. You’d happily let that admin draft everything. You’d still review it before it touched live data.
That isn’t distrust of AI. It’s ordinary change control, applied at the right checkpoint.
Frequently asked questions
Can we let AI make changes directly in HubSpot or Salesforce? Let it draft any change, but apply a review gate: nothing that alters production data or reaches a stakeholder should go live without a named person approving the exact final version. Test in a sandbox or on a sample first, and take a backup export before any bulk change.
How do we stop ending up with dozens of AI-generated spec versions? Keep one anchor copy as the master and have the assistant give precise, located edit instructions rather than a new file each time.
Why should the AI verify changes afterwards? Because the most common error is a half-applied change: an old value left in one branch, or records outside scope touched by a bulk update. A post-change check against the intended result catches these before they reach a report.
Is there any ops work AI can do without review? Yes, work in the team’s private workspace, such as the shared memory files, scratch analysis or a sandbox. The gate is for production systems and for anything stakeholders will see.
This is Part 6 of The Ops Operating System. Next: how to stop a helpful AI from flattering your numbers, and how to frame results honestly for stakeholders.
Worried about changes that already went live without a gate? Our GTM Systems Audit reviews workflows, bulk-update history and data quality across your CRM and marketing automation.