Your AI shouldn't touch a real customer's data the first time it actually tries to. Said like that it sounds obvious, and yet it's exactly what breaks when someone connects an agent to an ERP or a CRM in a hurry: the day it finally writes, it writes live, without anyone having seen beforehand what it was about to change. At AutoBoost we ran into the same risk while reviewing a deep structural change to our own client and collaborator management system, and the fix we applied is a rule that holds for any AI, script, or automated process you're about to give write access to real data.
The change: restructuring real data with no room for a failure halfway through
We needed to restructure how our clients' projects and hour bundles are organized: add a client specific code, keep a history of the courtesy hours we occasionally give away, and allow hourly billable bundles alongside fixed package bundles. None of this could be tested in a throwaway environment and called done: the change had to run against the real database, with clients and collaborators using the system at that exact moment.
The risk wasn't that the change was poorly designed. The risk was that a failure halfway through would leave the system in an in between state: new columns half filled in, projects merged before they should have been, or new code reading a structure the previous step hadn't finished preparing yet. That kind of failure doesn't announce itself with a clear error. It shows up as odd data someone notices days later, once it's far more expensive to undo.
The rule: simulate by default, write only when explicitly asked
We split the change into two steps, and gave each one a property that wasn't up for negotiation: by default, the script that runs either step writes nothing. It only reads the real database and shows, for every client and every project, exactly what would change if it were allowed to write. It takes an explicit flag to flip it from "here's what I would do" to "I'm actually doing it."
The two steps, in order:
- Step 1, additive only. It creates the new columns and fills them in from what already existed, without touching or removing anything that already worked. If this step fails halfway through, the system keeps working exactly as before, because nothing was removed.
- Step 2, depends on the new code already deployed. It merges projects and removes what's now obsolete, and only runs once the code that depends on step 1 is already live in production. The two steps are never run together, even though technically they could be.
The point isn't the tool or the language the script is written in. It's that the default mode is the safe one, and the dangerous mode has to be explicitly requested. And that a step which depends on another waits its turn, instead of trusting that "it's probably ready by now."
Why this isn't just an internal engineering anecdote
This same rule is exactly what any AI you give write access to a real system should follow, not just a one off migration script. An AI agent that quotes, invoices, or updates inventory inside your ERP is doing, in miniature and every day, the same thing a migration does: it reads a state, decides a change, and writes it. If you can't see what it's about to write beforehand, you're trusting it to get it right the first time, every time, and no agent does that consistently.
In the AI sales agent we built for an industrial distributor with over 50,000 products in its catalog, the agent first validates who the customer is, checks real stock, and applies the correct rate before creating the actual opportunity or order inside Odoo (see the full case at AI sales agent inside the ERP). That sequence of checks is, underneath, the same "rehearse before you write" principle applied to every single message, not just to a migration that runs once.
Checklist before giving an AI write access to real data
Before letting an AI agent (or any automated process) write to your ERP, your CRM, or your customer database, these are the questions we ask ourselves at AutoBoost:
| Question | Why it matters |
|---|---|
| Does it have a "simulate only" mode that shows what would change without touching anything? | If you can't see the change before it happens, the first real mistake is one you discover, not the simulation. |
| Does writing require an explicit flag to turn on? | The safe mode has to be the one that runs by default, never the other way around. |
| If the change has several steps, does the dependent one wait until the first is live in production? | Running two dependent steps at once multiplies the damage of any mid run failure. |
| Can the additive step be reverted without loss if something goes wrong? | A step that only adds, never deletes or merges, always leaves a way back. |
| Has someone actually reviewed the simulation against real data before authorizing the write, or is everyone trusting it's "probably fine"? | The simulation only counts if someone reads it before saying yes. |
If your answer to the first or second question is "no," it doesn't mean your AI is guaranteed to fail. It means that if it does, there's nothing standing between that failure and your real data.
How we apply this at AutoBoost
Our approach is that AI should contribute where it adds value, and code should act as the guardrail where it's needed: first the data gets organized and the process gets locked down, and only then is the AI allowed to act on it with write access. We apply this both to our own internal systems and to the AI agents we integrate into our clients' ERP, CRM, or accounting, using the same data platform that already lets an AI reason over more than a million sales lines for a group of pharmacies and reconstruct figures the original system was calculating wrong (see the case at data platform and controller AI).
If you're evaluating giving an AI write access to your real system and you're not sure whether it actually has a genuine rehearsal mode today, or just the promise that "it works fine," tell us about your case and we'll review it with you.
