Back in April, an AI told me everything was backed up and could be fully restored. It was wrong on both counts.

In my last piece I wrote about my boss realising AI could do the doing. This is the other half of that story: what happens when the doing goes wrong. I have been learning AI on the job, like everyone else. It is a powerful tool, and it is very tempting just to let it get on with it. But this is live data, and that deserves respect.

I was clearing out old forms that nobody used any more, with an agreed list of which ones to archive. I asked the AI to do it. On the first small test it deleted the wrong one: a form that was showing in the search results on screen, but was never on the list.

It had only backed up the forms we meant to remove, so the one it deleted was not in there at all. And having a backup turned out to be very different from being able to restore. The platform had no way to bring back a deleted form. As luck had it, it would still let us read the deleted form's definition, so we pulled a copy afterwards. But the most that copy could do was let us build a new one, and even that was rejected at first, because a newer rule required the fields to be grouped in a way the original had never followed.

No data was lost, because the form had no submissions yet, but a team had been about to start using it and only found out it was gone when they came to put it live. The AI rebuilt it from that copy, but all it could bring back were the fields. The formatting and the logo had gone, and the form looked a mess. The team needed it quickly and were not happy with the result, so in the end they rebuilt it themselves. That is not a restore. It is a rebuild.

The tools have moved on a long way since April, and I doubt it would happen now. But that was never really the point. The AI told me we were covered, with complete confidence, and I took its word for it without checking. That was as much my mistake as the AI's, and I suspect I am not the only one relying on that kind of reassurance.

Some of what I do now came straight out of that day.

The full backup is no longer the AI's judgement about what is in scope. It is a separate script that snapshots every form, field, workflow and list before any destructive change, because the mistake that hurt me was made to something I never meant to touch. Alongside it sits a rollback plan: how a change would be undone is recorded before it is made.

My deletion scripts now check each item against the agreed list before acting, and skip anything that does not match.

For putting one thing right, I built a separate tool that restores or rebuilds a single field, form or list from the backup and leaves everything else alone. Restoring a whole backup to fix one mistake can do damage of its own, because it also rolls back everything everyone else has done since.

And I check what the AI actually did, not what it says it did. When I tested every prompt for a client's reporting training, the CRM's built-in AI would sometimes build a chart using filters that looked reasonable and were wrong. The chart looked finished. The numbers did not answer the question. So the first rule I gave staff was to read the filters the AI had chosen before trusting the chart.

The rest is thirty years of migration habit that I used to treat as good practice and now treat as essential, because I move so much faster with AI than I ever did by hand.

Every cleanse follows the same pattern: export, clean, test on a sample of fifty, check the result, and only then import the rest. At a bigger scale, on one migration, 400,000 gift transactions went through repeated test imports into a sandbox over several weeks, then a full dry run, and only then the real migration weekend. A raw extract of every table was saved before any transformation ran, so when a number looked odd on the other side I could go back to exactly what the old system said.

Standardising the country across a whole contact base sounds simple until you find the field only accepts official names. "South Korea" is not on the list. "Korea, Republic of" is. Each common name has to be mapped before anything is written, or the update is rejected.

Where a wrong match would compound, I leave the decision to a person. When I designed a process for teams to import their own leads, the rules only match an organisation on its ID, its web domain or its exact name, and never create a new organisation automatically. A wrong match, or a duplicate that splits one organisation in two, is far harder to unpick than a record left for someone to decide.

All of it is good practice for anyone working with live data, and some of it I learned the hard way. None of it makes the work risk-free, but then doing it by hand never was.

But the care is not the point. The point is what it lets me do.

On one migration, back when I was still working in a chat window, the client noticed 95 gifts had arrived in the new system with no clear type. The AI wrote queries against the old database, I ran them and fed back the results, and between us we found that many came from an online giving platform retired years before, so they were online gifts whatever the payment field said.

On another project, members could not get into a members' hub a previous supplier had left half-built. The AI unpicked why, from lists built on retired fields to a workflow that let almost nobody through, and within a week the hub was open to the members it was built for. Working that out myself could have taken weeks.

With those checks around it, AI in my experience is, for the most part, more accurate than a person doing the same work by hand, and it keeps far more of a database's complexity in mind at once than I can. That is why I love working this way.

If you would like AI doing that kind of work on your own data, with the undo built in, I would be glad to talk it through.