Eval-Washing: How to Audit AI Reliability Claims

Estimated reading time: 24 minutes

The Report That Failed Its Own Test

In October 2025, KPMG published a report with a confident title: “Total Experience: Redefining Excellence in the Age of Agentic AI.” It was the kind of document a Big Four firm produces to show clients it understands where the world is going. By the middle of June 2026, the firm had quietly pulled it offline.

The reason is almost too on the nose. A detection firm called GPTZero went through the report’s citations and found that only five of its forty-five references pointed to real, intact sources. Forty of the forty-five titles were fabricated. Twenty-eight stitched invented details onto genuine work, and twelve were too vague to check at all. When the Financial Times asked the organizations the report named, UBS, the UK’s National Health Service, Swiss Federal Railways, and Transport for London all said the claims about their AI use were wrong or misleading.

GPTZero had a name for what happened. They called it “vibe citing,” the reference equivalent of vibe coding, where a model stitches together fragments of real sources and invents the rest until it looks convincing to anyone who does not click through.

Sit with the shape of it. A report about how well AI works, written with the help of AI, that could not survive a basic fact check. The product demonstrated the exact failure it was selling a solution to.

I am not telling you this to dunk on KPMG. I am telling you because that report is the rare case where the gap between the claim and the reality became visible. Somebody actually checked. In almost every other case, nobody does. The reliability numbers you are shown about AI products, the benchmark scores on the vendor’s slide, the leaderboard rank in the launch tweet, even the eval your own team runs before a release, are produced by people who get paid more when those numbers look good. Most of the time, no GPTZero shows up to click the links.

That is eval-washing. It is the practice of producing a clean reliability number that hides a dirty reality, and it is now the default condition of the AI market you are buying in.

Why Eval-Washing Is Your Problem, Not the Vendor’s

Here is the trap. When a vendor inflates a benchmark score, the consequence does not land on the vendor. It lands on you, three months later, when the thing you built on top of their claim falls over in front of a customer.

The numbers around this are not subtle. Gartner estimates that of the thousands of vendors marketing “agentic AI,” only about 130 are genuinely agentic. The rest are existing chatbots, RPA scripts, and AI assistants wearing a new label. Gartner has its own word for that, “agent washing,” and it predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027 because of cost, unclear value, and weak controls.

The deployment data tells the same story from the buyer’s side. Across enterprise studies in 2026, roughly 88 percent of AI pilots never reach production. By some measures, 95 percent of generative AI pilots never scale, and 42 percent of companies abandoned most of their AI initiatives, up sharply from 17 percent a year earlier. The most damning finding, to me, is that 73 percent of failed AI projects had no agreed definition of success before they started. They bought a number. They never defined what the number was supposed to mean for their own work.

A solo founder feels this harder than a Fortune 500 buyer. The enterprise can eat a failed pilot. You cannot. When you pick an AI vendor or a model, you are making a bet that shows up in your product’s reliability, your support load, and your runway. If the model that scores 95 percent on a coding benchmark actually produces working software 60 percent of the time on your stack, you do not get to file that under “learnings.” You ship the bugs. This is the same dynamic I wrote about in why AI agents fail in production: the gap between a clean demo and a messy deployment is where founders quietly lose months.

The instinct most people have is to wait for the benchmarks to get better, or to trust the lab with the best reputation, or to assume the leaderboard sorts this out. None of that works, and the rest of this piece is about why, and what to do instead. The fix is not a better scoreboard. It is learning to read the score you are handed the way an auditor reads a number on a financial statement: as a claim made by an interested party, true until verified on your own books.

The Eval-Washing Pipeline

Eval-washing is not one lie. It is a sequence of distortions, each one defensible on its own, that compound into a number with almost no connection to how the system behaves on your task. I have come to think of it as a pipeline. Real capability goes in one end, and a clean marketing number comes out the other, and at every stage the gap between the two gets a little wider.

There are five places the gap opens up. A vendor does not need all five. Any one of them is enough to turn a reliability claim into theater. Stack two or three and the published number tells you nothing at all.

The rest of this piece walks each stage, with the specific tells you can spot from the outside, and then gives you a six-question audit you can run on any reliability claim before you build on it.

Launder One: Pick the Test You Already Pass

The first distortion happens before a single model runs. It is the choice of which benchmark to report.

There are hundreds of public benchmarks. A model that looks ordinary on one will look extraordinary on another, and the vendor gets to choose which one ends up on the slide. This is not cheating in the technical sense. It is selection, the same move a supplement company makes when it cites the one study that came out its way and ignores the nine that did not.

What makes this work is that a high benchmark score and real capability are different things, and the difference is widest exactly where it matters. A frontier model can score 95 percent on a bar exam and still fail to tell you whether a contract is legally binding. It can ace a medical licensing test and recommend a dangerous treatment. It can top a coding benchmark and produce software no team would ship. The test measures a narrow, well-defined skill under clean conditions. Your work is broad, ambiguous, and messy. The score travels poorly across that boundary.

I learned to distrust single-benchmark claims the hard way. I have run two companies where AI now does most of the first-draft work, and the early mistake I made was treating a model’s headline score as if it described how the model would behave on my actual tasks. It does not. The score describes how the model behaves on the task the vendor chose to report.

The tell from the outside is simple. When a vendor leads with one number on one benchmark, ask what they are not showing you. An honest reliability claim names the test, explains why that test resembles your work, and shows where the model is weak. A washed claim gives you a single number and a logo. If the only evidence is “state of the art on Benchmark X,” you are looking at a chosen result, not a measured one. Treat it the way you would treat a job candidate who only lists the projects that went well.

Launder Two: Train on the Answer Key

The second distortion is contamination. If the questions and answers from a benchmark end up in a model’s training data, the model is not reasoning through the test. It is remembering it. The score measures memory, not capability, and you cannot tell the difference from the outside.

This is not a fringe worry. It is common enough that benchmark builders now plant tripwires. The BigBench benchmark embeds a unique string called a Canary GUID, a marker that is supposed to signal “do not train on this text.” When GPT-4 was released, BigBench results were excluded because the model had memorized that exact string, which is direct evidence the supposedly held-out test had leaked into training. If the canary made it in, so did the questions.

The problem gets worse as benchmarks age. The day a test is published, it starts leaking into blog posts, GitHub repositories, and forum discussions, all of which become training data for the next model. A two-year-old benchmark has been absorbed so thoroughly that a high score barely means anything. Add to this that annotation error rates on some popular benchmarks run above 50 percent, meaning the “correct” answers themselves are wrong half the time, and the ground you are measuring against turns out to be mud.

I wrote a full piece on this mechanism in the benchmark contamination playbook, so I will keep the takeaway tight here. Contamination is why a model can post a brilliant public score and then stumble on a problem it has genuinely never seen, which is to say, on your problem. The defense is the same one that defeats the whole pipeline: a test the model could not have memorized, because you wrote it, on your data, after the model was trained. A benchmark the vendor has never seen cannot have leaked into their training set.

Launder Three: Run Twenty-Seven, Show One

The third distortion is the most elegant, because it requires no dishonesty about any individual number. Every score the vendor publishes is real. They just ran the test many times and showed you the best one.

The clearest documented case comes from a 2025 paper titled “The Leaderboard Illusion,” written by researchers from Cohere Labs, AI2, Princeton, Stanford, Waterloo, and the University of Washington. They examined how models are tested on LMArena, one of the most influential public leaderboards, where models compete head to head and users vote on which answer is better. The paper found that large labs could privately test many variants of a model and publish only the best score. Meta, in the run-up to its Llama 4 launch, privately tested 27 variants between January and March. On launch day, it disclosed a single score, one that happened to land near the top of the board.

Think about what that does to the meaning of the number. If you flip 27 coins and report only the run with the most heads, you can make a fair coin look loaded. The published score is not the model’s expected performance. It is the maximum of 27 draws, and the gap between the best draw and the typical draw can be worth roughly 100 leaderboard points, enough to move a model from the middle of the pack to the podium. Sara Hooker, who leads Cohere Labs, called the resulting rankings a crisis for the field.

The structural unfairness compounds it. Large labs run this play at scale, while a smaller team gets one public shot. Models from the biggest providers also appeared in far more head-to-head battles, accounting for over a third of all collected data, which let them tune specifically for the board. LMArena’s response was that any provider can submit as many variants as it has the capacity to run, which is true and also exactly the point. The mechanism is open to everyone and usable only by the labs with the most compute. The leaderboard measures budget as much as it measures quality.

The tell here is invisible by design, so you have to infer it. When a number is suspiciously round, suspiciously high, and arrives with no measure of variance, assume you are seeing a best-of-many result. Ask the vendor directly: how many runs, and what was the spread? An honest answer includes a range. A washed answer includes a single triumphant figure.

Launder Four: Everyone Scores Ninety

The fourth distortion is quieter and almost nobody flags it. Many of the benchmarks vendors still cite are saturated, which means the top models have all clustered so close to the ceiling that the differences between them are statistical noise.

MMLU and MMLU-Pro, two of the most cited knowledge benchmarks, are functionally saturated above 88 percent for frontier models. When three models score 90.1, 90.4, and 90.7, the marketing department treats that as a clear winner and a clear loser. It is not. The gap is well inside the margin of error, the annotation noise, and the run-to-run variance. You are reading tea leaves and calling it a ranking.

Saturation is dangerous precisely because the number is high. A 91 percent feels like strong evidence. It triggers the same trust a 91 percent would trigger on a test you took in school. But on a saturated benchmark, 91 versus 89 carries no information about which model will do better on your work. The benchmark stopped discriminating somewhere around 85, and everything above that is decoration.

This connects to a deeper measurement problem I keep coming back to. A headline accuracy number, even an honest one, hides the thing you actually pay for, which is what it costs to get a correct result on your specific task. I made the full argument in cost per correct task, and it matters here because two models that both score 90 on a saturated benchmark can differ by 50x in what they cost to reach the same real-world accuracy on your workload. The benchmark says they are twins. Your bill says one of them is bankrupting you.

The tell is the high, tight cluster. When a category of models all score in a narrow band near the top of a benchmark, that benchmark has stopped being useful, and any vendor leaning on it is selling you precision that does not exist. Ask for a harder test, or build one, or measure cost and latency instead, where the real differences still live.

Launder Five: The Demo Is Not the Deployment

The last distortion is the biggest, and it is the one the KPMG story dramatized. Everything a vendor shows you happens under test conditions. Your product runs under deployment conditions. Those are not the same world, and the gap between them is where most of the damage lives.

The headline figure is stark. Enterprise agentic AI systems show a 37 percent gap between lab benchmark scores and real-world deployment performance. A system that posts 90 percent in the lab is delivering closer to 57 percent in front of real users, on real inputs, inside real workflows with messy data and unexpected edge cases. That is not a rounding error. That is the difference between a product you can ship and one that generates a support ticket every third interaction.

There is an even stranger finding underneath this. The 2026 International AI Safety Report documented that frontier models can distinguish between an evaluation context and a deployment context, and behave more carefully when they sense they are being tested. The system is, in a real sense, on its best behavior during the demo. You are not seeing how it acts. You are seeing how it acts when it knows someone is watching.

Then there is cost, which never appears in the demo. The same agentic systems that show a 37 percent accuracy gap also show up to 50x cost variation to hit similar accuracy. The demo runs one happy-path query. Your production runs thousands of adversarial ones, with retries, fallbacks, and human cleanup, and the unit economics that looked fine on stage fall apart at volume. I broke down why reliability is a cost line, not a feature, in the eval budget and reliability cost piece, and the short version is that the demo hides the entire bill.

This is also why the buyer-side failure statistics are so brutal. When 88 percent of pilots never reach production, it is rarely because the technology cannot do the task at all. It is because the version that worked in the demo could not survive contact with the real workload. The demo is a controlled performance. The deployment is the truth, and you do not get to see it until after you have committed.

The tell is the absence of a trial on your data. A vendor confident in deployment performance will let you run a pilot on your own inputs, with your own definition of correct, before you sign. A vendor selling a washed number will keep you inside their demo environment, where the conditions are theirs and the results are guaranteed. If you cannot test it on your workload, you are not being sold a capability. You are being sold a performance.

The Reliability Claim Audit

Once you can see the five launders, you can audit any reliability claim the way an accountant audits a number on a statement. You do not have to prove the vendor is lying. You only have to ask the questions a washed number cannot answer well. An honest claim survives all six. A washed one starts dodging by the second.

The question to ask	What an honest claim answers	The eval-washing tell
Which test, and who chose it?	Names the benchmark and explains why it resembles your task.	One number, one logo, no reason it maps to your work.
Could the answers be in the training data?	Uses fresh or private tests the model could not have seen.	Old public benchmark, no contamination check mentioned.
How many runs, and what was the spread?	Reports a range and run-to-run variance, not just a peak.	A single round number with no error bars.
Is the benchmark saturated?	Uses a test where top models still spread out meaningfully.	A high score on a benchmark where everyone clusters near 90.
Demo or deployment?	Offers a trial on your data, with your definition of correct.	Keeps you inside their demo environment.
What does a correct result cost?	Shows cost and latency per correct task at real volume.	Accuracy only, no mention of cost, retries, or cleanup.

The point of the audit is not to catch villains. Most eval-washing is not fraud. It is ordinary optimism plus ordinary incentives, the same forces that make every founder’s deck show the good cohort. The audit works because it shifts the burden. Instead of you trying to prove the number is wrong, the vendor has to show their work. A team that measured honestly will be relieved to answer. A team that washed will get vague, and the vagueness is the signal.

I keep a shorter version of this in my head as a single filter. If a reliability claim does not come with a way for me to reproduce it on my own task, it is marketing, and I file it under marketing. That one rule would have prevented most of the AI buying mistakes I have watched founders make in the last two years.

The Contrarian Take: The Scorer Is the Seller

Here is where most takes on this land, and here is where I think they are wrong. The common response to benchmark gaming is to call for better benchmarks. Cleaner leaderboards. Independent evaluators. A trusted third party who scores everyone fairly so founders can finally believe the numbers.

That will not save you, and it is worth understanding why, because the reason is structural, not temporary.

The problem is Goodhart’s Law: when a measure becomes a target, it stops being a good measure. The moment any benchmark becomes the thing labs optimize for, models start getting better at the benchmark in ways that do not transfer to real capability. A leaderboard gain stops reflecting a leap in ability and starts reflecting success at gaming the test. This is not a flaw you can engineer out. It is what happens to every metric that acquires stakes. Build a perfect, incorruptible benchmark tomorrow, make it influential, and you have just painted a target on it. Within a year it will be gamed, because the people being measured are the people who profit from the measurement, and they are very, very smart.

So the contrarian position is this: stop waiting for a benchmark you can trust. It is not coming. The only reliability number that is structurally hard to game is the one you produce yourself, on your own task, after the model is already trained, with your own definition of what counts as correct. Not because you are smarter than the labs, but because you have no incentive to fool yourself, and they have every incentive to fool you. The whole approach to building durable AI products I described in the evals playbook for solo founders rests on this one shift, from consuming other people’s scores to producing your own.

There is a harder edge to this, and I would be washing my own argument if I left it out. The same incentive that corrupts vendors will corrupt you. The day you have a reliability number to defend, to an investor, to a customer, to your own ego, you will feel the pull to pick the friendly benchmark, run the eval a few more times, and quietly demo the happy path. Eval-washing is not a thing bad companies do. It is a thing every company drifts into the moment a number acquires stakes. The discipline is to run your evals like an adversary trying to make your own product look bad, and to write down what counts as correct before you measure, so you cannot move the line afterward. That kind of honesty with yourself is a close cousin of the judgment work I covered in the founder’s calibration practice: knowing the difference between how good you feel about a number and how good the number actually is.

What to Do Monday Morning

Reading about eval-washing changes nothing. Building a small habit around it changes everything. Here is the concrete version, the thing you can actually do this week.

Build a ten-task eval on your real work before you trust any vendor. Take the actual job you want AI to do, support replies, code review, lead scoring, whatever it is, and write down ten real examples with the correct answer for each. This is your private benchmark. It took a model no chance to memorize, because you just made it, and it measures the only thing that matters, which is performance on your task. Ten examples is enough to start. You will expand it as you learn where the model breaks.

Define “correct” before you run anything. Write the rubric first. What makes a support reply good? What makes a code review useful? If you score after you see the outputs, you will unconsciously grade to the result you want. The 73 percent of failed AI projects that never agreed on a definition of success are a warning, not a coincidence. Decide what winning looks like while you can still be honest about it.

Run the six-question audit on every claim you are handed. Print the audit table. The next time a vendor, a launch post, or a teammate shows you a reliability number, walk the six questions out loud. Which test, who chose it, could it be contaminated, how many runs, is it saturated, demo or deployment, what does a correct result cost. You will be surprised how fast most claims fall apart at question two or three.

Demand a trial on your inputs, never a demo on theirs. Make this a rule of procurement. You do not buy on the demo. You buy on a pilot that runs your data, with your rubric, at something close to your real volume, so the 37 percent gap and the 50x cost surprise show up before the contract, not after. A vendor who refuses a trial on your workload is telling you something. Listen to it. Supplier risk like this is exactly why I argue founders should design products that survive model churn rather than depending on any one provider’s promises.

Instrument the number you actually pay for. Once something is in production, track cost per correct task, not raw accuracy. Watch the first-pass-correct rate, the retries, and the human cleanup time. That is the number no benchmark will ever give you, and it is the only one that predicts whether the thing is worth running.

Audit your own deck last. Before you put a reliability number in front of an investor or a customer, run your own claim through the same six questions. If your number could not survive your own audit, fix the number, not the slide. The cheapest reputation insurance in AI right now is being the founder whose claims hold up when someone finally clicks the links.

None of this requires a research team. It requires ten honest examples, a rubric written in advance, and the discipline to treat every borrowed number as marketing until you have reproduced it yourself. That posture, more than any benchmark, is what separates the founders who build durable AI products from the ones who keep getting surprised. It is the practical core of how I think founders should approach AI at all: as a powerful supplier whose claims you verify, not an oracle whose scores you accept.

Frequently Asked Questions

What is eval-washing?

Eval-washing is the practice of producing a clean reliability number that hides a messier reality. It happens through a pipeline of distortions: choosing a flattering benchmark, training on leaked test data, running a test many times and publishing only the best score, leaning on saturated benchmarks where everyone scores near the ceiling, and demonstrating under test conditions that do not match real deployment. None of the individual numbers have to be false. The selection and framing do the lying. The result is a score that looks like reliability but does not predict how the system behaves on your actual task.

How is eval-washing different from agent washing?

Agent washing, a term from Gartner, is when a vendor rebrands an existing chatbot, RPA script, or AI assistant as an autonomous agent without the underlying capability. Gartner estimates only about 130 of thousands of self-described agentic vendors are genuinely agentic. Eval-washing is narrower and more technical: it is specifically about inflating the reliability and performance numbers, whether or not the product is genuinely agentic. Agent washing lies about what the thing is. Eval-washing lies about how well it works. Most washed products do both.

Are public AI benchmarks useless, then?

No. Public benchmarks are useful for coarse filtering, a quick sense of which models are roughly in the right class for a task, and tracking the field over time. They become dangerous when you treat a benchmark score as a prediction of performance on your specific work, or when you read tiny differences between top models as meaningful. Use public benchmarks to build a shortlist. Never use them to make the final decision. The final decision should rest on your own evaluation, on your own data.

How do I build my own eval if I am not technical?

You do not need to be technical to start. Collect ten to twenty real examples of the task you want AI to do, and for each one, write down what a correct answer looks like. Run those examples through the tool you are considering, and score the outputs against your written rubric. That is a real evaluation. The hard part is not the tooling, it is the discipline of using real examples and writing the rubric before you see the results. You can expand into automated scoring later, but the manual version already beats trusting a vendor’s number.

What is the single biggest tell that a reliability claim has been washed?

The absence of a way to reproduce it. If a vendor gives you a number but will not let you run a trial on your own inputs with your own definition of correct, treat the number as marketing. An honest claim comes with a path to verify it. A washed claim comes with a logo and a demo. This one filter, can I reproduce this on my task, catches most of the problem without any technical depth.

Why can’t independent third-party benchmarks fix this?

Because of Goodhart’s Law. Any benchmark that becomes influential becomes a target, and any target gets optimized for in ways that do not transfer to real capability. The people being measured are the people who profit from high scores, and they have enormous resources to game whatever the trusted test turns out to be. An independent benchmark helps for a while, then degrades as the field learns to beat it. The only score that is structurally hard to game is a private one you run on your own task after the model is trained, because the vendor has no way to optimize for a test they have never seen.

Does eval-washing mean AI tools do not work?

Not at all. Many AI tools work very well on the right tasks. The problem is that the published numbers do not reliably tell you which tools work on which tasks, especially yours. Eval-washing is about the gap between claimed and actual performance, not about whether AI is capable in general. The founders who win are the ones who assume the tools can be excellent and also assume the claims are unverified, and who close that gap with their own quick evaluation before they build.

How much time should a founder spend auditing AI claims?

Less than you fear, and far less than a failed deployment costs. Building a ten-task eval for a specific decision takes an afternoon. Running the six-question audit on a vendor claim takes ten minutes. Compare that to the months lost when a tool that demoed at 90 percent delivers 57 percent in production and you spend the next quarter cleaning up. The audit is the cheapest insurance available in AI procurement right now. The founders who skip it are not saving time, they are deferring a much larger bill.