What good client-controlled AI evaluation looks like

Client-controlled AI evaluation does not mean the client writes every test harness, hosts every model or excludes suppliers from the process. It means the organisation retains control of the questions, representative evidence and decisions that matter to its own use of the system.

Without that control, acceptance can collapse into a vendor benchmark, a consultant’s summary or a product team’s confidence. Each may contribute useful evidence. None can substitute for the organisation deciding what acceptable behaviour means in its workflow.

Control begins with the question

The client should define the decision the evaluation supports: release, restrict, select, remediate, expand or stop. Then it should approve the questions that make that decision answerable.

For a customer-support agent, the question is not simply “Is it accurate?” It may be: can the configured agent resolve eligible requests without making unauthorised account changes, and does it hand off excluded cases with the evidence a human needs? That question connects quality, authority and operations.

The Magenta Book places intended decisions and users at the centre of evaluation design. Its guidance applies beyond public programmes: methods should be chosen because they answer defined questions in time to influence a decision.

Own the acceptance logic

Suppliers and specialists can propose metrics and thresholds. The accountable client owner should approve what happens when they are met, missed or uncertain. Acceptance logic includes more than a score:

• hard stops for unacceptable actions;
• minimum performance for important task groups;
• coverage requirements for high-consequence scenarios;
• permitted exceptions and compensating controls;
• uncertainty that requires restricted use or further evidence;
• expiry and retest triggers.

Do not hide these judgements inside a weighted average. An agent that performs well overall but occasionally sends a payment to the wrong destination is not rescued by its average. Group findings by consequence and action type.

The NIST AI RMF Core expects deployment context, human oversight, metrics, uncertainty and repeatable evaluation processes to be documented. The client is best placed to connect those elements to its risk tolerance and operating obligations.

Curate representative cases without freezing reality

Client ownership of cases is crucial because the client knows its policies, exception patterns, users and operational constraints. Build a case portfolio with ordinary work, edge cases, known incidents, adversarial inputs and situations where the correct result is refusal or human handoff.

Document provenance and permitted use. Remove or protect personal and confidential information. Separate a stable comparison set from an evolving discovery set so repeated tuning does not quietly turn the benchmark into training material.

Representative does not mean statistically comprehensive by default. Record which populations, workflows, languages, tools and conditions are covered. Add cases when incidents, policy changes or new system authority reveal gaps. The UK government’s guidance on impact evaluation of AI interventions stresses early planning and stakeholder-informed theories of how an AI intervention is expected to create outcomes; the same logic helps expose what the case set must represent.

Separate four kinds of control

Client control can be divided so partners contribute without dominating the conclusion.

Control	Client retains	Partner may contribute
Question control	decision, scope, intended use, consequence	framing methods and challenge
Case control	approval, provenance, representativeness, use rights	case generation and adversarial variants
Evidence control	access rules, system of record, retention	instrumentation, execution and analysis
Decision control	acceptance, restrictions, owner and trigger	findings, severity recommendation and options

The same organisation need not perform every task. Independence of execution can be valuable. But the client should be able to trace how a finding was produced and commission a reasonable recheck without losing essential artefacts.

Require inspectable execution

A useful run record identifies the system and dependency versions, configuration, case, inputs, relevant context, tool calls, policy decisions, human interventions, observed outcome, evaluator judgement and deviations. What can be retained will depend on data and security constraints, but the absence of perfect traces is not a reason to accept only a headline score.

The NIST AI RMF Playbook recommends evaluation of third-party AI that addresses transparency needs without exposing proprietary algorithms. This is an important boundary: client control requires customer-relevant evidence, not ownership of a supplier’s trade secrets.

Agree how disagreements are handled. If a vendor calls a failure “expected behaviour” and the client calls it unacceptable, the deciding reference should be the approved workflow requirement—not who operates the test environment.

Keep the evidence portable

The client should retain a versioned evaluation pack that can travel across releases and, where feasible, suppliers. It includes scope, cases, acceptance logic, run manifests, findings, exceptions, remediation checks and the final decision. Tool-specific adapters may vary; the decision standard should remain intelligible.

Portability has two benefits. It reduces dependence on one evaluator, and it makes change measurable. When a model, prompt, retrieval source or tool changes, the organisation can rerun a stable subset and compare like with like.

The UK Guidelines for AI procurement encourage buyers to focus on the problem, engage multidisciplinary teams and plan for technical and commercial lifecycle concerns. Requiring evidence portability during procurement is cheaper than discovering after deployment that the buyer cannot reproduce acceptance.

Make challenge part of client control

Control is not the same as self-confirmation. A client-owned evaluation should allow internal or external challengers to question scenario coverage, metrics, severity and alternative explanations. Preserve negative results and record why findings were accepted, downgraded or deferred.

For consequential releases, assign separate roles for system building, evaluation interpretation and final acceptance. Complete separation is not always practical, especially in small teams, but the conflict should be visible. A reviewer can sample evidence or witness runs rather than duplicating every test.

Define a change policy alongside the baseline. Model substitutions, prompt revisions, policy changes, new retrieval sources, expanded user groups and additional tools can each invalidate part of the result. Classify changes by the evidence they require: a targeted regression set, a full evaluation cycle, a new privacy or security review, or only a documented observation period.

Ownership also needs maintenance. Name a steward for the case library and a decision owner for each release. The steward should track case provenance, coverage gaps, exposure to developers and retirement of obsolete cases. The decision owner should approve exceptions rather than allowing a passing pipeline to become an automatic release authority.

Measure evaluation debt. Known missing cases, unavailable instrumentation, unresolved disagreement and deferred remediation are liabilities even when a release proceeds. Keep them in a visible register with consequence, owner and review trigger. This prevents a qualified acceptance from being remembered later as unconditional proof.

Periodically give another competent team the pack and ask it to explain or rerun a sample. This recovery exercise tests whether the client owns a usable capability or merely possesses files whose meaning still depends on the original supplier.

Client control has succeeded when the organisation can answer: What did we ask? What did we test? What did we observe? What remains uncertain? Who decided? What change would make us reconsider?

That position creates better partnerships, not fewer of them. Specialists can focus on methods and challenge. Vendors can provide deep product evidence. The client keeps the decision connected to its own workflow and remains able to govern the system after the evaluation team leaves.