When a Client Wants a Guarantee the AI Won't Make Mistakes

The Short Answer

When a client wants a guarantee the AI won't make mistakes, tell them the truth: nobody can promise that about any AI model, and anyone who does is guessing. Then tell them what you can promise, which is more useful. You can promise where the AI is allowed to act, where a person checks its work before anything goes out, how the build is tested before launch, how errors are caught after launch, and how quickly you fix them. Guarantee the safety net, not the model.

That is the Safety Net Promise. It works because the client is not really asking for perfection. They are asking 'what happens to my business when it gets something wrong?' If you answer that question clearly, most clients relax. If you answer the literal question with a yes, you have signed up to be blamed for every odd answer the build ever gives, which is how a good project turns into [a client who blames your build for a problem it didn't cause](/blog/client-blames-your-build-for-a-problem-it-didnt-cause).

Why Clients Ask for This Guarantee

The request usually comes right before signing, and it almost always has one of these reasons behind it. Ask which one before you answer: 'That is a fair thing to worry about. What is the mistake you are most worried about?'

• They have seen an AI get something wrong. A chatbot made up an answer, or a story in the news did. They need to see how your build is different, not hear that it is.
• Someone above them needs reassurance. An owner, a partner, or a board wants to know the risk is handled. They need something in writing they can show.
• Their customers are on the other end. If the build talks to their customers, a wrong answer costs them a customer or a review. They need to know where the AI stops and a person takes over.
• They are testing you. Some clients ask to see whether you will overpromise. The builder who says 'no one can promise that, here is what I can promise' often wins the deal for exactly that reason.

The answer to 'what mistake worries you most?' is gold. It tells you which part of the build needs the strongest guardrail, and it gives you the first example to test against.

Build the Safety Net Promise

The Safety Net Promise is five commitments, each one about something you control. Work through them with the client before the build starts.

1. Limit what the AI is allowed to do. Write down what the build can do on its own, what it can only draft, and what it must never touch. An assistant that answers only from the client's written policies cannot invent a refund policy. Put this in your [scope of work](/blog/scope-of-work-that-prevents-scope-creep).
2. Put a person in front of anything risky. Prices, refunds, legal or medical questions, and anything sent to a customer for the first time go to a person for review. The AI drafts, the human approves.
3. Test against examples the client signs off. Collect real questions and tricky cases from the client, including the mistake they are most worried about, and show how the build handles each one before launch. This is the step clients most often want to skip, and [when a client wants to skip testing](/blog/client-wants-to-skip-testing-to-launch-faster) covers why you should not.
4. Watch it after launch. Keep a simple log of what the build did, and review it on a set schedule, more often in the first weeks. Odd answers get caught by you, not by the client's customers.
5. Commit to a fix window. Agree how fast you respond when something goes wrong, and what counts as urgent. That is a promise you can keep, and it is the one the client actually needs.

In the Claude Code desktop app you can ask Claude to turn the client's list of worries into test cases and run the build against them, then save the results as a short report the client can read. Check the report yourself before you send it, because the client will.

What to Say

Notice what the message does. It takes the worry seriously. It refuses the promise without sounding defensive. It replaces a promise you cannot keep with five you can, and it offers to put them in writing, which is what the person above the client usually wants. It does not lecture the client about how AI works.

If they push for the full guarantee anyway, hold the line: 'If I signed that, I would be guessing, and you would be relying on a guess. I would rather give you a promise I know I can keep.' A client who still insists on a zero-mistake guarantee is telling you how they will react to the first odd answer. That may be a client to walk away from.

Put It in the Contract the Right Way

Write the Safety Net Promise into the agreement as behavior you control. Describe what the build does and does not do, the review points, the signed-off test examples that define a working build, how you monitor it, and your fix window. Add a plain line that the build uses an AI model whose answers can be wrong, and that the review points exist for that reason. If the client sends their own paper with a broad accuracy promise in it, [when a client sends you their own contract](/blog/client-sends-you-their-own-contract) covers how to push back on it. This is general guidance, not legal advice, so have a lawyer look at any clause about liability.

Keep this separate from any refund promise. A [money-back guarantee](/blog/money-back-guarantee-for-claude-code-builds) is about whether the client gets the result they paid for, not about every answer the AI gives. And set the expectation early: the [expectations conversation](/blog/set-client-expectations-before-a-claude-code-build) is the right place to say that AI builds get reviewed, monitored, and tuned, so this question has an answer before anyone asks it. When something does slip through after launch, handle it the way [when a client finds a bug after launch](/blog/client-finds-a-bug-after-launch) lays out, and keep the monitoring and fixes going under a [maintenance plan](/blog/package-a-maintenance-plan-for-ai-builds).