When AI-assisted work goes wrong on a client project
The mistake is rarely the expensive part. The expensive part is the day you spend unable to say how far it reaches.
Sooner or later an AI-assisted deliverable will reach a client with something wrong in it. A figure copied from the wrong period. A citation to a source that does not say what the summary claims. A migration script that passed review and failed on the client's data. None of this is new. People made these mistakes before any model was involved, and review exists because they did.
What is new is the question that follows. Once a client knows AI was part of the work, the first mistake they find stops being a single error and becomes a question about everything else you delivered. How you answer it decides whether the relationship survives the week.
The three questions the client will ask
Every version of this conversation comes down to the same three questions, usually in this order.
- What happened? Which step introduced the error, and which step should have caught it.
- How far does it reach? Which other deliverables went through the same process, and are they wrong too.
- What changes? What you will do differently so the next one is caught before it ships.
The first and third are about judgement, and most teams answer them well. The second is about evidence, and it is where the day goes. Without a record of which work went through which workflow, the honest answer to "how far does it reach" is "we will have to check everything", and that answer costs more trust than the error did.
| The client asks | With a record | Without one |
|---|---|---|
| What happened? | Drafting was AI-assisted; the error survived the review on this deliverable | We think it came from the drafting step |
| How far does it reach? | Four other deliverables went through the same workflow that week; we have checked them | We are going through everything |
| What changes? | Figures now get a second check against the source before review sign-off | We will be more careful |
Separate the tool from the decision
It is tempting to explain the error by pointing at the model. Resist it. A person chose to use the tool on this work, a person reviewed the output, and a person decided it was ready to send. That is where the accountability sits, and it is also where the fix sits. The model's behaviour is useful context for deciding what to change. It is not a reason the client should accept.
This is the same line attribution draws in the other direction. The person who directed the work gets the credit when it goes well. The same person owns it when it does not. Recording AI involvement does not dilute either.
Find how far it reaches before the client asks
The useful move is to answer the second question before it is asked. Start from the deliverable that failed and work outward along three lines.
- Same workflow. Other work drafted or produced the same way, in the same workstream, around the same time.
- Same review step. Other work signed off by the same check that missed this one. If the check was the weak point, everything it passed is in scope.
- Same window. If a prompt, a template or a model changed recently, work produced since the change is the priority.
This only takes an afternoon if the record already says which work was AI-assisted, how, and who reviewed it. If it does not, it takes as long as re-reading everything, which is why teams that keep no record tend to over-apologise and under-explain. The record is not paperwork for its own sake. It is what turns "we are looking into it" into a list.
Correct, then say what changes
Fix the deliverable first, and send the correction on its own, without the explanation attached. Then send the answer to the three questions, briefly. The client needs to know which other work you checked and what you found, including when the answer is nothing.
Say what changes in the process, not in the tooling. "We now check every figure against its source before review sign-off" is a commitment the client can hold you to. "We have switched models" is not, because it says nothing about whether the next error will be caught. If your AI disclosure policy promises a particular kind of review, this is the moment to show that the promise has a record behind it.
An illustrative example
The numbers here are illustrative. A consultancy delivers a quarterly market report. The first draft of each section is AI-assisted, and a senior analyst reviews the whole report before it goes out. Two days after delivery, the client spots a growth figure that belongs to the previous quarter.
Because the firm records which sections were drafted with AI and who reviewed them, the lead can see within the hour that the same drafting workflow produced four other reports that week, all reviewed by the same analyst against the same checklist. They check those four. One has the same kind of error, in a report the client has not opened yet. The firm corrects both, tells the client the same day, and adds a source check for every figure to the review checklist.
The client's reply is about the second report, the one they had not found yet. That is the part that kept the work.
The record is the apology that works
Clients do not expect AI-assisted work to be flawless. They expect the people delivering it to know what they did. The fastest way to show that, on the worst day of a project, is a record that answers "how far does it reach" before anyone has to ask.