The AI wrote wrong information into our CRM. What do we do now?
Stop the writer at the integration layer rather than by revoking credentials, which would break reads too. Then determine scope by querying every record touched by the integration's dedicated user within the affected window. Correct what you can, which depends entirely on whether prior values were preserved. If you cannot answer which records it touched, that gap is the real finding and it needs fixing before the writes resume.
Contain without breaking everything else
The instinct is to pull the API credentials. Resist it. In most integrations the same credential handles reads, which means revoking it also blanks your dashboards, stops your briefs and takes down reporting at the exact moment you need to investigate.
The right control is a write kill-switch in the integration layer — a flag that lets data continue flowing in while nothing flows out. If your setup does not have one, that is the first thing to build after the incident, and it takes about an hour.
Establish scope before you fix anything
Fixing before scoping is how one bad afternoon becomes two. Three questions, in order.
- Which records were touched? Answerable in seconds if AI writes come from a dedicated system user, and nearly unanswerable if they come from a shared account or a person's login. This is the argument for dedicated integration identities.
- What was there before? If the integration preserved prior values — in a shadow field, an audit table, or the platform's own change history — recovery is mechanical. If it overwrote in place with no record, some of it is gone.
- What consumed the bad data downstream? Dashboards, exported reports, a marketing list, an automated follow-up that already went to a customer. The write is rarely the last stop.
The design choices that decide how bad it gets
Nearly all the difference between a contained incident and an unrecoverable mess comes from decisions made before anything went wrong. Write to dedicated fields rather than fields humans also edit, so a bad write never destroys a human-entered value. Preserve the prior value on every write. Use a dedicated system identity. Log every write with a reference to what produced it.
None of this is exotic; it is ordinary integration hygiene applied to a component that is probabilistic. It is exactly what we mean when we say an integration has to be built for the day it misbehaves, not just for the demo.
What to do before turning it back on
Reproduce the failure on a small set and confirm you understand it. A write that went wrong once because of an unexpected input will go wrong again the next time that input appears, and "we fixed the records" is not the same as "we fixed the cause."
Then resume in a lower tier — writes queued for batch approval rather than applied directly — until a clean run demonstrates it holds. Downgrading the automation tier after an incident and earning it back with evidence is a healthier pattern than an all-or-nothing switch, and it is how operational AI stays trustworthy over years rather than weeks.
Topics: incident response · writeback · CRM · recovery
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.