At some point in the past two years, every software product you evaluate became an AI product. The ticketing tool is now an AI ticketing platform. The CRM has an agent. The vendor deck that used to lead with features now leads with a demo of something autonomous, and the demo is always flawless, because demos are a genre whose entire craft is flawlessness.
This puts buyers in a difficult position that deserves a name: the AI-washing problem. Genuine capability and cosmetic capability present identically in a sales cycle. Both have the demo, the case studies, the benchmark chart. The differences only surface in production, months after signature, which is precisely when they are most expensive to discover. And the stakes compound in 2026 because AI vendors are not just software suppliers: they process your data, shape decisions your organisation makes, and increasingly take actions in your name. A bad AI vendor choice is not a bad tool; it is a bad employee with system access and a contract that is hard to exit.
This article is the buying discipline: the scorecard I recommend, the tests that separate capability from theatre, and the contract terms that matter specifically for AI.
Why AI procurement is different
Standard software procurement asks: does it have the features, does it integrate, is the vendor viable, what does it cost? All still necessary, all now insufficient, because AI products differ from conventional software in four ways that break the standard playbook.
Performance is probabilistic and data-dependent. A conventional feature either works or does not. An AI capability works some percentage of the time, and that percentage depends on your data, your edge cases, your users’ phrasing. The vendor’s accuracy number was measured on their distribution, not yours, which is why the central act of AI procurement is testing on your own data, and everything else is preamble.
Your data is part of the deal. Every AI vendor relationship is a data flow. What they receive, what they retain, what they train on, and where it is processed are not privacy-team footnotes; they are core commercial terms. The governance article’s flow-control pillar meets procurement exactly here.
The product underneath moves. Vendors swap underlying models, update prompts, and retrain systems continuously. The product you tested in March is not the product running in September, which conventional procurement, built for versioned software, has no reflex for.
Failure modes are novel. Hallucination, prompt injection, drift, and (for agent products) wrong actions taken confidently. Evaluating a vendor without probing these is evaluating a car without brakes testing.
The six-dimension scorecard
Figure 1 shows the scorecard I use: six dimensions, weighted for your context, each scored with evidence rather than assertion.
Capability, proven on your data. The anchor dimension. Insist on a structured pilot against your documents, your tickets, your edge cases, scored against criteria you wrote before the pilot began. Bring your evaluation suite (the same one your model portfolio depends on); a vendor who resists testing on your data is answering your question, just not in words.
Data terms. What is received, retained, trained on, and where. The questions with teeth: is our data used to improve models that serve other customers? Can we get zero-retention processing? Where is inference performed, and can it be pinned to a region? What happens to our data, including derived artefacts like embeddings, at exit? For Australian buyers, the residency and third-party questions have direct supervisory relevance, and “we’re SOC 2 compliant” answers none of them.
Transparency and explainability. Can the vendor tell you which models power the product, what changes when they update, and can the product show its work: sources for answers, reasoning for recommendations, logs for actions? A vendor who cannot explain their own system cannot help you explain it to your regulator.
Security and safety posture. Beyond the standard certifications: how do they handle prompt injection? What guardrails constrain agent actions, and what are the human-approval boundaries? Have they been independently red-teamed? The breach statistics from the governance article (13% of organisations already reporting AI-related breaches, overwhelmingly where access controls were missing) are vendor-selection statistics too.
Viability and roadmap honesty. The AI vendor landscape is consolidating, and many current products will not exist in three years. Funding runway, customer concentration, and dependence on a single upstream model provider all belong in the assessment. So does roadmap honesty: a vendor whose answer to every gap is “next quarter” is selling futures.
Exit economics. Priced before entry, as always: data export completeness (including your prompts and fine-tuning artefacts), contractual exit assistance, and the realistic switching cost. Lock-in is not disqualifying, unpriced lock-in is.
The tests that separate signal from theatre
Scorecards structure judgement; these tests generate the evidence that fills the Figure 1 dimensions with something better than vendor assertion. Four that earn their time.
The edge-case gauntlet. Assemble thirty to fifty of your genuinely hard cases: the ambiguous ticket, the contract with the weird clause, the query in broken English. Run them live, in front of you, without vendor pre-processing. The flawless demo corpus cannot survive contact with your gauntlet, and the vendor’s reaction to failure (candour versus choreography) is itself a scored data point.
The wrongness probe. Deliberately feed inputs designed to elicit confident errors: questions with false premises, requests outside the product’s competence, and for agent products, instructions embedded in processed content (a basic prompt-injection test). What you are measuring is not whether errors occur (they will) but whether the product fails safely: hedging, declining, escalating to humans, or failing confidently and fluently.
The reference call with the churned customer. Vendor-supplied references are selected for enthusiasm. Ask instead for a customer who left, or find one through your network. Ten minutes with a churned customer is worth ten reference calls, and a vendor with no discoverable churned customers is a vendor with a very short history.
The update-day question. Ask precisely: when you change the underlying model or prompts, how do we find out, what regression evidence do we get, and can we pin a version or test before rollout? This single question sorts mature AI vendors from wrappers faster than any other, because it probes whether they operate the evaluation discipline they are implicitly asking you to outsource.
Contracting for a moving product
The contract is where AI-specific risk either gets allocated or gets inherited by default, and Figure 2 summarises the terms that matter beyond the standard commercial set.
The philosophy running through Figure 2 is that conventional contracts assume static products and advisory outputs, and both assumptions are now false. Performance floors (tied to metrics from your pilot, with remedies) replace feature warranties. Change-notification clauses replace version schedules. Training-use prohibitions and retention limits codify the data terms. And for agent products, liability language must engage with the new question directly: when the vendor’s system takes a wrong action in your name, whose loss is it? Vendors have standard answers to none of these yet, which is exactly why they are negotiable now and will not be once the market’s standard terms harden.
One procedural note: weight the scorecard before you meet vendors, with your risk tier doing the weighting. A drafting assistant for internal use can trade transparency for capability; a system touching customer decisions cannot. Deciding the weights in advance is what prevents the demo from deciding them for you, because the demo is very good at that.
Partners, not just products
A closing distinction. Some of what you are buying is not products but partners: integrators, consultancies, managed-service providers building on your behalf. The scorecard adapts, with one dimension promoted to the top: knowledge transfer. The engagement test is whether your organisation is more capable when they leave than when they arrived, and the contract should name the mechanism (paired delivery, documentation standards, capability milestones) rather than the sentiment. A partner who builds you a system your team cannot operate has sold you a dependency with extra steps, and in a field moving this fast, dependencies age badly. The same scorecard logic applies at renewal, not just at purchase: partners and products alike should be re-scored annually against the alternatives the market now offers, because the vendor landscape is repricing itself continuously and incumbency is not evidence. The buyers who do best in this market are not the toughest negotiators; they are the ones who never stop being able to walk away.
With sourcing decided (the spectrum, the model portfolio, the vendors) the track turns to the question that dominated 2026’s strategy conversations: agents. Systems that do not just answer but act, where to start, and how to avoid learning the expensive lessons personally. That is the next article.