Evidence an AI Project Must Produce

The first wave of enterprise AI purchases rewarded quick answers and polished demos. Vendors showed workflows that looked simpler and cheaper, and early tests often stopped there. That bar is too low now that AI sits inside contracts, customer workflows, regulated files and board materials. The procurement question worth asking is whether the evidence behind a product still stands once the meeting is over.

Ordinary software-as-a-service (SaaS) purchases already force clear terms on uptime, data handling, access rules, logs, support, pricing and exit rights. AI purchases put the same teams in front of something less well defined: often an outside model, prompts that shift, a vector store, customer data, tool permissions, human oversight, vendor monitoring, and output that changes over time.

Practical AI procurement asks whether the evidence checklist still holds once the system is running inside the workflow, long after the demo has worked once.

Standards bodies and regulators have already set out what oversight requires

The National Institute of Standards and Technology (NIST) AI Risk Management Framework organizes the work around governance, mapping, measurement and management. Its profile for generative systems adds concerns about synthetic content, data leaks, model behavior, misuse and the limits of evaluation. European Commission guidance on the AI Act turns documentation, model limits, risk checks, incident reports, copyright rules and security measures into obligations that reach both providers and users.

Security guidance points the same way. The Open Worldwide Application Security Project (OWASP) list of large language model risks covers prompt injection, unsafe output handling, supply chain gaps, excessive agency, disclosure of sensitive data and overreliance. Guidance from the Cybersecurity and Infrastructure Security Agency (CISA) and the UK's National Cyber Security Centre (NCSC) says security ownership, transparency and secure design must extend to AI systems. NIST's 2026 request for information on agent security, issued under its CAISI program, singles out the new exposure created when model outputs are connected to actions, credentials, external data and live environments.

Consumer rules add another layer. The Federal Trade Commission (FTC) treats AI claims like any other commercial claim: they need evidence, and calling a product "AI" does not remove liability for deception or unfair practices. The details differ by sector, but a buyer can apply one rule everywhere and refuse any vendor claim that the vendor could not defend in front of a regulator, an insurer, a customer or the board.

What the evidence must include

The checklist should be a thin file, holding the smallest set of materials that lets an executive judge whether a system can run in live operations, which a scripted demonstration cannot show.

Vendors can document model limits, security measures, change procedures, data practices, evaluation methods and known failure points. Buyers still have to set the workflow scope, how far the system may act on its own, the review steps, the performance measure and the local cost of an error.

So procurement cannot hand AI decisions to legal or IT alone. Legal shapes the contract terms, security examines the controls and IT assesses the architecture, but only the operating owner can say which errors would matter, who stays accountable, and whether the productivity gain is worth the added dependence.

Six questions to put to the vendor

A capable vendor treats the checklist as part of selling, since buyers trust a supplier more when it states implementation risks in plain language. Before any move past a pilot, buyers should ask:

1. Which product claims rest on task-specific tests, and which are still directional or experimental?
2. What data enters the system, where does it reside, and how is it used for training, improvement, monitoring or support?
3. Which changes to the model, retrieval method, prompts, tools or policies could affect output quality after the contract is signed?
4. What controls address prompt injection, excessive agency, unsafe tool use and exposure of sensitive data?
5. What notice, logs, rollback options and export paths exist if the workflow has to stop?
6. Which duties stay with the buyer even when the product performs as specified?

If the answers are missing, the deal may still suit a narrow test, but it should not move into production infrastructure. The usual remedy is a tighter scope, fewer permissions, more human review, or a contract that keeps the buyer free to change course.

Five things the buyer has to define

Buyers leave their half incomplete about as often as vendors do. Teams press for evidence while producing none of their own: they ask for full model documentation without naming the target workflow, low error rates without defining which errors count, indemnity without naming who reviews the outputs, and governance dashboards without anyone who can halt the rollout. The buyer's side needs five local details:

1. Workflow in scope: inputs, outputs, users and escalation steps.
2. Autonomy limit: whether the system recommends, drafts, ranks, executes or triggers external action.
3. Error budget: which mistakes are acceptable, which need review and which are forbidden.
4. Business result sought: time saved, revenue protected, risk lowered, retention raised or learning sped up.
5. Stop rule: the metric, incident, cost change, quality drop or adoption signal that ends the effort.

The exercise only looks bureaucratic to people who treat speed as a substitute for definition. A one-page statement can shorten a deal by removing false certainty: the vendor knows what it has to prove, finance can see the obligation, security can see where the controls sit, and the sponsor can tell whether the project is an operational investment or a publicity exercise.

Why the checklist is also a strategic tool

Markets will favor organizations that adopt AI quickly without hidden weaknesses, and that advantage comes from careful procurement, structured review, bargaining power with vendors, and the habit of turning unclear systems into controlled work.

A company with a good file places sharper bets. It can accept a promising agent inside a defined workflow, decline a polished demo that hides excessive agency, secure change-notice rights before the vendor updates the product, and tell suppliers with real operating maturity apart from those with fluent language and weak control records.

The AI market will keep moving faster than standard contract cycles. Model costs will fall and features converge; rules will tighten, incidents will rewrite insurance terms, and staff will adopt tools without approval. A procurement record that captured evidence at the start gives the institution something to go back to when those conditions change.

What to do with the next purchase

This week, take the next AI tool, agent or workflow automation under consideration and, before another demo or pilot, ask for a two-page evidence checklist:

1. Page one, from the vendor: the claims that matter, limitations, data handling, security controls, change control and incident response.
2. Page two, from the buyer: workflow, autonomy limits, review owner, error budget, business proof and stop rule.

Then decide. If both pages are clear, a bounded production pilot is justified. A thin vendor page means narrowing the scope or reopening the terms. A thin buyer page means pausing, because the organization has not yet defined the task. If both pages are thin, the company has seen nothing beyond the demo and should not start a pilot.