Public AI benchmarks are being gamed, so enterprises are quietly building private eval suites
A model that tops the public leaderboard this month can lose to a model ranked ten places lower once you run both against your own production traffic. That gap is no longer an edge case — internal benchmarking teams at several enterprise AI buyers now report a roughly 37% divergence between published benchmark scores and measured performance on their own agentic workloads. The public leaderboard has stopped being a reliable purchasing signal, and procurement teams know it.
The result is a quiet build-out of private evaluation infrastructure. Instead of trusting MMLU, HumanEval, or GPQA scores at face value, enterprise AI teams are standing up internal eval suites that test models against their own data, their own tools, and their own failure modes — and treating the public numbers as, at best, a first-pass filter.
Why the public numbers stopped being trustworthy
Part of the problem is contamination: widely used benchmarks have been public long enough that their questions, or close paraphrases of them, plausibly leak into training data. But a subtler problem has emerged even for benchmarks run cleanly — measurement fragility. Researchers have shown that simply reordering the answer choices on MMLU multiple-choice questions, without changing a single word of content, can shift a model's measured accuracy by up to 13 percentage points. A benchmark that sensitive to formatting isn't really measuring capability; it's measuring the model's robustness to a specific answer-key convention.
Cost adds a second layer of noise. Teams comparing models on accuracy alone have found up to 50x variation in inference cost between models that land within a percentage point of each other on the same benchmark. A leaderboard that ranks purely on accuracy hides the fact that the second-best model might be running at a fraction of the cost — or that the top model achieved its score using an inference-time compute budget no production system would actually use.
What a private eval suite actually looks like
The teams building this infrastructure aren't starting from scratch. Tooling has matured quickly: OpenAI shipped Evals 2.0 in June 2026 with first-class support for custom graders and agentic multi-turn tasks, and Inspect AI reached version 0.3.12 in July with better support for tool-use evaluation and sandboxed code execution scoring. Commercial platforms — Patronus AI, Braintrust, and Galileo among them — now sell managed private-eval pipelines specifically aimed at enterprises that don't want to build grading infrastructure in-house.
A typical private suite has three layers. First, a golden dataset pulled from the company's own historical support tickets, code review comments, or document workflows — never public data, precisely because public data is what gets gamed. Second, task-specific graders: for a coding assistant, that might mean actually running generated code against a test suite rather than asking another LLM to judge correctness by eye. Third, a regression harness that reruns the full suite against every new model release or fine-tune, so a vendor's model update can't silently degrade performance on the tasks that matter to that specific business.
The incentive problem this doesn't solve
Private evals fix the contamination and formatting-sensitivity problems, but they introduce a new one: they're expensive to build and maintain, which means only well-resourced buyers get an accurate picture of model performance. A startup evaluating which API to build on still has to lean on public leaderboards, Twitter threads, and vendor marketing — the exact signals that got noisy in the first place. Model providers, meanwhile, have every incentive to keep optimizing for the benchmarks that smaller buyers still trust, even as their best enterprise customers quietly stop looking at those numbers at all.
What to do about it
If you're evaluating models for a production workload, treat public benchmark rank as a shortlist filter, not a final answer. Build even a minimal private eval — 50 to 100 real examples from your own use case, graded by a rubric your team agrees on — before committing to a model for anything beyond prototyping. Watch the cost-per-task number alongside accuracy; a model that's 2 points better on your eval but 10x more expensive per call is rarely the right production choice. And re-run your eval suite whenever a provider ships a "silent" model update, since accuracy on your specific tasks can drift even when the public benchmark score stays flat.