The Phrases That Overstate What Your AI Actually Does

Somewhere between the sales deck and the delivered system, a sentence gets simpler. "AI drafts the response and a member of the team checks it before it sends" becomes "AI handles customer replies." Nobody sat down and decided to overstate anything. The longer version was true, accurate and a bit dull. The shorter one reads better on a slide, so it survived the edit.

That gap between what the system does and what the sentence says feels harmless right up until the first visible miss, the moment a client, a board member or an auditor asks how the mistake happened and someone has to explain that "handles" always meant "drafts, with a human checking." The words you use to describe an AI system become the standard you are judged against when it fails, whether or not they were ever a technically accurate description of what the system does. This is a communications problem, not a technical one, and it is worth treating as its own discipline rather than folding it into whatever governance policy already covers how the system is built and run.

Which phrases quietly overstate what your AI does?

A short list, all heard in real sales calls, board packs and case studies:

• "Fully automated." Almost nothing worth doing in a B2B workflow is fully automated end to end. There is usually a person who set the rules, a person who reviews exceptions, or a person who is meant to but has stopped bothering because nothing has gone wrong yet. "Fully" is doing a lot of work in that sentence, and it is rarely true under cross-examination.
• "The AI handles it." Handles is a word that hides a decision. Does the system decide and act, or does it draft and wait? Those are different products with different failure modes, and the sentence gives no way to tell which one you have built.
• "AI-powered", with no description of the mechanism. This phrase has become near-meaningless through overuse, but the real problem is what it omits: what the system reads, what it decides, what it writes back, and what happens when it is wrong. A reader who cannot answer those four questions from your description has not been told anything they can rely on.
• "No human involvement needed", presented as a selling point. Framed as efficiency, this sentence is also a promise that nobody is watching. If that turns out to be true and something goes wrong at scale, "no human involvement needed" is the line that gets read back to you.

None of these are lies in the sense of being invented. They are compressions of something true with a qualifier attached, and the qualifier is the part that went missing.

Why does the erased human matter more than the erased task?

The dangerous overclaim is rarely about capability. It is about control. When a description drops the human checkpoint, it does not just describe the system inaccurately, it removes the one thing that made the system defensible. A system that drafts a customer response for a person to approve is a different risk proposition to one that sends the response itself, even if the underlying model and prompt are identical. The moment your language collapses that distinction, you have told your client, your board or your insurer that a control exists that, in the telling, no longer does. This matters because the people relying on your description were never told to inspect the system themselves. They were told a sentence, and built a decision on top of it: a board approved budget on the basis the process was supervised, a client signed a contract on the basis a person reviewed anything customer-facing. Our approach when we scope this kind of work is to write down, decision by decision, which ones the system is trusted to make outright and which need a human gate first; that split is the substance behind any accurate claim, and we set it out in more detail in our piece on which decisions should be left to AI. If your marketing sentence does not match that split, the sentence is wrong, not the system.

Who actually holds you to the sentence you chose?

More people than write the marketing copy expect.

Clients hold you to it first, because they built their own process around what you told them the system does. If a client relied on "fully automated" to justify removing their own checking step, the conversation about fault starts with your words, not your architecture.

Boards hold you to it because budget and risk appetite were signed off against a specific description. A board that approved an initiative on the understanding a human reviews every output before it reaches a customer has approved a different risk than one that approved unsupervised action, and minutes tend to record which one they thought they were getting.

Insurers and regulators read marketing claims literally, because that is their job. UK advertising rules require marketing claims to be truthful and backed by evidence for anything a reasonable person would take as factual, and the advertising regulator has been explicit that this applies to claims about what AI or automated systems do just as to any other product claim: overstating capability is a straightforward accuracy problem, with no special leeway because the technology is new. None of that requires a dramatic reading. It only requires that the words in your sales deck matched, at the time you used them, what the system actually did. This sits alongside, but is distinct from, the internal governance question of how an AI system should be controlled and who is accountable for it, covered separately in our guide to building an AI governance framework. Governance is about the system. This is about the sentence you use to describe it, and the two can drift apart by accident if nobody checks them against each other.

How do you stop sales, marketing and delivery telling three different stories?

The practical fix is not a policy document, it is a short, plain-language register that anyone in the business can check before they describe an AI system externally. For each system in production or in sale, write down three things in a sentence each: what the system does on its own, what a person has to check or approve before anything happens, and the one approved sentence that describes both without either overclaiming or underselling. Keep it to a page per system. The point is not thoroughness, it is that a salesperson on a call and a delivery lead writing a case study reach for the same sentence rather than each compressing the truth in their own direction. This register earns its keep the moment a system changes. If a workflow moves from "drafts for review" to "sends automatically for low-risk cases, drafts for review above a threshold", the approved sentence has to change with it, and every downstream document (deck, proposal, case study, client email) has to catch up. Without it, the case study on your website keeps saying "the AI handles it" long after the system underneath has changed twice, and nobody notices until a client quotes it back to you. The same register is useful groundwork before you build or buy anything: if you cannot yet write an honest one-sentence description of what an AI agent in your business would do and what would stay human, that is usually a sign the scope is not yet real; our explainer on what AI agents actually are is a reasonable place to start that conversation with a non-technical board.

Does admitting the human gate cost you the sale?

The instinct is that "AI-assisted, with a person checking" sounds weaker than "fully automated" in a pitch. Our experience of selling into sophisticated UK buyers suggests the opposite: the precise claim tends to land better than the sweeping one. A buyer with any technical or risk background hears "fully automated" and immediately asks the question your sentence was trying to avoid: what happens when it gets something wrong? If you cannot answer, you have handed them the objection. If your sentence already said "AI drafts it, a person approves it before it goes out", you have answered the objection before it was raised, and you look like the vendor who has actually thought about failure. This is also the more defensible commercial position. A claim that survives a hard question from a buyer's risk function is worth more than a bolder claim that collapses under the same question, because the buyer is evaluating whether they can trust what you tell them next, not just your AI. We build this into how we scope AI implementation work with clients: describe what the system will do, describe what stays human, and use that description, not a rounder-sounding version of it, in every proposal and case study that follows. If you want a second opinion on where your current systems sit against that description, our AI implementation work starts with exactly that exercise.

Frequently asked questions

Is this the same thing as an AI governance policy?

No, and treating them as the same document is a common mistake. A governance policy sets out how an AI system is controlled internally: who approves it, who monitors it, what happens when it fails. This is about the external sentence you use to describe that system to clients, boards, investors and regulators, which can drift out of line with the governance reality even when the governance itself is sound.

Who inside the business should own the approved wording for an AI system?

Whoever is accountable for the system's delivery, usually alongside whoever signs off client-facing marketing, should agree the one-sentence description together, because sales and marketing will otherwise each compress it independently. The person who actually built or configured the system is the only reliable check on whether the sentence is still accurate.

What should we do if we find an existing overclaim already published somewhere?

Correct it as soon as it is found rather than waiting for a review cycle, starting with anywhere a client or prospect is likely to see it and rely on it: proposals, case studies, the website. A quiet correction now is a much smaller conversation than an explanation after a visible miss makes the client go back and re-read what you told them.

Does this apply to internal AI tools too, or only client-facing claims?

It applies wherever someone downstream makes a decision based on your description, and that includes internal use. A team that believes an internal tool is "fully automated" will stop checking its output, which recreates the exact risk this piece describes even though no client or regulator is involved.

John Kelleher is a Claude Certified Architect (Foundations and Professional) and leads SpotDev, a Claude Registered Partner and OpenAI Select Partner.