Averages hide uneven capability
Frequent simple questions can lift a score while concealing rare consequential errors. Energy tasks require distinctions by question type, consequence and conditions of use.
AI task evaluation and release assurance.
Evaluation should answer whether AI is usable, not just whether it scores well.
With governance arrangements still evolving, enterprises need a bridge from technical performance to deployment decisions. We believe evaluation should centre on business consequences: which errors can be tolerated, which must be prevented and how the system behaves with insufficient information.
A SIGNAL WORTH EXAMINING79%
of surveyed data leaders are early in defining how to scale and govern agents3
2025 · 1,700 senior data and analytics leaders globallyTHE ZHICE INTERPRETATION
Governance capability will determine how far AI can go.
Agents reading information, organising workflows and initiating actions across systems challenge existing application boundaries. We believe scale means more than additional users and calls: permissions, evaluation, exception handling and accountability must expand together. Governance belongs in product design so the organisation knows when to delegate and when to intervene.
THE ARGUMENT BEHIND THE VIEW
A judgement needs a complete argument.
Evaluation should answer whether AI is usable, not just whether it scores well.
EXAMINING AI THROUGH THE TASK
THE REASONINGThe business conditions behind the view
The task environment changes
Knowledge updates, permission changes and new interfaces can invalidate earlier tests. Evaluation must keep corresponding to real work rather than indefinitely repeating a familiar question set.
Release is a conditional judgement
Passing a model test does not establish that the full workflow is usable. Review, recovery and user understanding contribute alongside technical evidence.
IMPLICATIONS FOR LEADERS
What should leaders reconsider?
Define acceptance by consequence
Separate tasks that must be answered correctly, should prompt clarification or should be refused. Use appropriate checks rather than one aggregate score for every scenario.
Test boundaries and recovery together
Examine missing inputs, conflicting evidence, unauthorised requests and tool failures. Establish whether the system knows when to stop or hand over.
Bind evidence to deployment scope
Record validation conditions against the version and scope of use. Reassess when users, tasks or authority expand instead of extrapolating one test indefinitely.
WHEN TO RECONSIDER
Evaluation has a cost. Lower-consequence tasks may justify lighter validation with explicit uncertainty. High-consequence uses cannot rely on sampled satisfaction alone.
When the overall score improves, are the errors that matter most also being controlled more reliably?
FROM PERSPECTIVE TO PRACTICEPut this perspective to work.
ExpandCollapse
Put this perspective to work.
Generic benchmarks cannot establish whether a model understands enterprise equipment identifiers, contract constraints or source versions. Average accuracy can conceal rare but severe errors. Release assessment needs explicit business-quality criteria, failure scenarios and acceptable boundaries.
Stratify tasks and risks
Have business and technology teams define acceptable output. Select samples by frequency, difficulty and failure consequences, including unanswerable tasks, conflicting evidence and out-of-scope requests.
Compare systems and failure patterns
Run repeatable comparisons across model, retrieval, prompt and tool configurations. Isolate failure sources, combine expert and automated review, and record versions and evaluation-leakage risks.
Establish release and regression evidence
Agree severe-error, latency and cost criteria in advance, retaining defects and decisions. Run relevant regression checks after model or knowledge changes.
Work products
Task evaluation set and expert scoring rubric
System comparison, failure analysis and defect register
Release criteria, regression suite and review record
What to measure
- Critical-error rate
- Report by risk class instead of substituting an overall score for high-impact error checks.
- Robustness and cost
- Observe quality, response time and full task cost under input variation, source changes and load variation.
Findings apply to the tested tasks, versions and conditions. Passing one evaluation does not establish safety or effectiveness in every setting.
Data notes and research foundationsExpandCollapse
- 1Stanford HAI · AI Index 2025
Comparison of inference cost at GPT-3.5-level MMLU performance; not a reduction in total enterprise AI or project costs.
Stanford 2025 · Nov 2022–Oct 2024 · GPT-3.5-level performance - 2Stanford HAI · AI Index 2026
OSWorld is a structured computer-use benchmark; the result is not an energy-production success rate or a deployment threshold.
Stanford AI Index 2026 · OSWorld benchmark - 3IBM Institute for Business Value · 2025 CDO Study
Self-reported status in a cross-industry, cross-geography survey, not a measured maturity score for energy enterprises.
IBM 2025 · 1,700 senior data and analytics leaders globally
THE NEXT CONVERSATIONThe question worth discussing:
Contact ZHICE