Separate AI evaluation from a polished demonstration

A polished AI demonstration can make a difficult workflow look simple. It can also omit the document preparation, retries, and human corrections that made the result possible. Buyers should appreciate the demonstration without mistaking it for acceptance evidence. Ask for a separate test that exposes the conditions under which the proposed service succeeds or fails.

Define the question each activity answers

A demonstration explains how the experience might work. Evaluation asks whether the system meets a defined requirement under stated conditions. Keep those purposes separate in the purchasing process. NIST calls for documented test sets and metrics, deployment-like test conditions, and disclosure of limits on generalization.[7]

Before the presentation, agree on the workflow, permitted data, user roles, and success criteria for evaluation. Do not accept a broad claim of readiness because one carefully chosen question receives a good answer. The relevant decision concerns the proposed scope, not a model’s apparent ability to converse about many topics.

Expose the preparation and assistance

Ask which files were cleaned, which examples influenced the prompt, and whether an operator selected or edited the answer. These are not inherently improper activities. They become misleading when the buyer believes the shown result came from an unattended process that had no comparable preparation.

Record model settings, available tools, retrieval sources, and manual steps for the evaluation run. Use representative inputs that were not selected to flatter the system. Include missing information, unusual document layouts, and requests the service should decline. Keep customer-sensitive material out unless the evaluation environment has appropriate approval and controls.

Questions for an evaluation session

Have business owners observe the test as well as technical staff. Capture complete runs, including unsuccessful attempts, so reviewers can inspect what actually happened rather than only the final screen.

• Were acceptance criteria fixed before the team saw the evaluation inputs?
• Which human interventions, retries, and data repairs were required?
• Can reviewers trace important answers to the evidence supplied?
• Does the system recognize unavailable information and out-of-scope requests?
• Are failed cases, operating limits, and remaining manual effort included in the decision record?

Hypothetical example: a quotation assistant

A hypothetical buyer watches an assistant turn a complete sales inquiry into a quotation draft. In a separate evaluation, the buyer supplies an inquiry with an unclear delivery location and a product reference absent from the approved catalog. The required behavior is to ask for clarification.

If the assistant invents a product match and delivery promise, the evaluation records a failure even though the draft looks presentable. If staff repair the draft, their work remains part of the result. The buyer can then decide whether that review burden fits the intended service rather than judging only the appearance of the quotation.

Make a scoped purchasing decision

Use the findings to choose a limited pilot, request specific repairs, or decline the proposed scope. An unseen test is still only a sample and cannot prove universal reliability. Preserve the limitations in the decision record. A useful evaluation makes uncertainty visible enough to manage, rather than converting a convincing presentation into an unsupported guarantee.