Procuring AI: A Practical Guide
Guide · 3 min read
Buying an AI system is not the same as buying conventional enterprise software. The product is probabilistic, its behaviour shifts as data and models change, and much of the value sits in integration rather than in the licence. Treat it as the acquisition of a capability with an operating commitment attached, not a one-off purchase.
Understand what you are actually buying
Conventional procurement asks what a system does. AI procurement has to ask how reliably it does it, on whose data, and under what conditions it fails. Two suppliers offering the same category of tool may differ far more in data handling, latency, and failure modes than in the headline feature list. Establish the business outcome first — the decision or task being supported — and work backwards to the capability required.
Separate the layers. A model, the hosting and serving infrastructure, the integration into your workflows, and the human oversight around it are distinct purchases with distinct risks. Suppliers frequently bundle them, which obscures where the cost and the dependency actually sit. Unbundle them on paper before you negotiate, so that each element can be weighed on its own terms.
Oversight is part of the purchase, not an afterthought. Someone must be accountable for the outputs the system produces, and that accountability has to be resourced in the plan and priced into the business case. A system with no named owner is a system nobody will catch when it drifts.
Evaluate against your own conditions
Vendor demonstrations are staged on clean, well-behaved inputs. Your data is neither. Insist on a structured trial using representative samples from your own environment, and score the results against criteria agreed before the trial begins rather than after. The point of the trial is to surface failure modes you would otherwise discover in production.
Model quality is necessary but not sufficient. The system that succeeds in production is the one whose outputs can be checked, whose failures can be traced, and whose behaviour stays within bounds an operator can name. Procurement should ask not only whether the tool is accurate today, but whether the organisation can tell when it stops being accurate.
- Fitness for the task — does it meet the accuracy you need on your data, not on a public benchmark?
- Data handling — where data is processed and stored, and whether it is used to train shared models.
- Integration cost — the engineering and change effort to make it work inside your systems and processes.
- Transparency and audit — what you can inspect, log, and reconstruct after the fact.
- Exit — what you take with you, in what format, and how quickly, if the relationship ends.
Rule of thumb: If a supplier will not let you test on your own data under a clear scoring rubric, that is itself a finding. Treat the trial as the evaluation, not the demonstration.
Questions to ask
- What specific decision or task does this system improve, and how will we measure that improvement?
- Which components are we buying outright, and which dependencies are we accepting for the long term?
- How will the system behave on the edge cases our operation actually produces?
- Who owns the outputs once the system is live, and what does the exit look like in data, cost, and time?
Vendor Evaluation Criteria for AI Platforms
Framework · 3 min read
A vendor evaluation is only as good as its criteria. Begin with the question the platform must answer in your operation, then test candidates against weighted criteria using your own data. The aim is a defensible comparison, not a ranking of feature lists.
Weight the criteria before you score
Decide what matters, and how much, before any vendor demonstrates. This stops the most polished presentation from quietly setting the agenda. A weighting that reflects your own constraints — regulatory, operational, financial — is more useful than a generic scorecard, because it forces the trade-offs into the open where they can be argued about and recorded.
Weighting is a discipline, not a formality. When two criteria conflict — a lower cost that comes with looser data terms, say — the weighting forces a decision rather than a compromise that satisfies no one. Record the weights and the reasoning behind them; months later they are the only way to explain why the choice was made and to defend it if challenged.
| Criterion | Weight | Evidence to require |
|---|
| Task fit on your data | High | A trial scored on representative samples, not a benchmark |
| Data governance | High | Processing locations, retention, and training use stated in writing |
| Exit and portability | High | A defined route to export data and switch without rebuilding |
| Integration effort | Medium–high | A scoped estimate of the engineering and change work required |
| Transparency and audit | Medium–high | Logging, versioning, and reconstruction of past outputs |
| Total cost of ownership | Medium | Licence, serving, integration, and oversight costs together |
| Vendor viability | Medium | Evidence of support, roadmap, and financial durability |
Test, do not be told
Ask for trial access and run the scenarios that matter to you. A vendor that performs well on your hard cases is worth more than one that performs perfectly on easy ones. Record the results as you go, so the eventual decision rests on evidence the whole team can see and challenge.
A trial should be scored by the people who will live with the result, not only by those who ran the purchase. Involve the operators whose work the platform touches, because they will find the failure modes that a demonstration, however honest, is designed to hide.
- Score independently; do not let a single demo drive consensus.
- Separate the score for the model from the score for the company behind it.
- Re-test when a material change lands — models and pricing both move.
Rule of thumb: Rank on the weighted total, but keep the raw scores. The gap between criteria often tells you more about fit than the final number does.
Questions to ask
- What evidence will you provide against each criterion, and who owns it?
- How does the platform perform on our hardest cases, not the easy ones?
- What changes when we scale from a trial to production use?
- How would we leave, and what would that cost us in time and data?
Build vs. Buy Decision Framework
Strategy · 3 min read
The build-or-buy question is usually answered badly because it is framed as a single decision. In practice it is a set of decisions about layers — the model, the serving infrastructure, the integration, and the oversight — and the right answer often differs by layer.
Where the line falls
Build the layers that carry your differentiation and your data advantage. Buy the layers where the capability is commodity and the market moves faster than you can. Most organisations will buy the model and the serving, and build the integration and the surrounding workflow, because that is where their knowledge of the business is concentrated and where a generic supplier cannot follow.
The mistake to avoid is building out of pride and buying out of haste. A build decision commits you to maintaining a capability for years; a buy decision commits you to a dependency for at least as long. Both are strategic, and both should be argued in the same meeting rather than decided in separate rooms by people with different incentives.
The calculus is not only about capability but about consequence. A component on the critical path of a regulated process, or one that holds data you cannot expose, may need to be owned even when buying is cheaper, because the risk of dependency outweighs the saving. Conversely, a capability that is genuinely commodity — routine extraction, transcription, standard classification — is rarely worth building, because a supplier will always do it better and keep doing it better.
- Build when the capability is genuinely differentiating, when control of the data is decisive, or when the work must sit inside proprietary systems.
- Buy when the capability is commodity, when time to value dominates, or when the in-house expertise to maintain it does not exist and will not be hired.
- Buy, then integrate when a purchased component is sound but only useful once embedded in your own processes.
Time horizon matters as much as the decision itself. A capability you will need for a decade is a candidate to own; one the market is actively reinventing is a candidate to rent, even at a higher short-term price, so that your commitment does not outlive the technology. Write down the horizon the decision assumes, because it is the assumption most likely to be wrong and the most costly to discover late.
Rule of thumb: Build the seams, buy the engines. Your advantage rarely lives in the model itself; it lives in how the model is wired into how you work.
Questions to ask
- Is this capability part of what we are, or merely something we use?
- Can we maintain this ourselves for the full life of the commitment?
- What would we have to know to switch suppliers later, and would we keep that knowledge?
- Which layer of this decision are we actually making right now?
Contractual Safeguards for AI Services
Legal · 3 min read
Contracts written for conventional software rarely fit AI services. The clauses that carry the weight are those dealing with data, change, liability, and exit — the areas where an AI service differs most from a static product. What follows is practice guidance from procurement work, not legal advice.
Clauses that carry the weight
Standard SaaS terms assume a fixed product delivered over a subscription. An AI service is not fixed: the model may be updated, behaviour may drift, and outputs are probabilistic by design. Each of those realities needs a clause that names it, and every clause should be written so the operations team, not only the lawyers, can act on it.
Two protections matter more than the rest. The first is clarity about where your data goes and what it trains. The second is a route out that does not depend on the supplier's goodwill. Everything else can be negotiated in degrees; these two are close to binary, and their absence is difficult to remedy after signature.
- Data ownership and use — who owns inputs and outputs, and whether your data is used to train shared or third-party models.
- Change and drift — how and when the model may change, the notice you receive, and how versions are recorded.
- Performance and accuracy — what is promised, how it is measured, and against what standard.
- Audit and transparency — your rights to inspect, log, and reconstruct how a decision was reached.
- Liability — who carries the cost when the system is wrong, and how that is bounded.
- Exit and portability — return of data, format, timing, and transition support.
Do not accept standard terms unmodified
An agreement that handles sensitive data, informs decisions about people, or sits inside a regulated process should not be signed on the supplier's default terms. Route it through the same scrutiny you would apply to any system of consequence, and record the reasoning so the next negotiation starts from your position rather than theirs.
A clause is only as strong as the operation behind it. Rights to audit mean little without a way to exercise them; a performance guarantee means little without a measure you can verify. Pair each commercial protection with the internal capability that makes it real, or the protection exists only on paper.
Leverage is best gathered before selection, when competing suppliers still want the business. Once a platform is embedded and the team is trained, the room to change terms shrinks, and the supplier knows it. Set your contractual position at the point of maximum choice, not at renewal. This is practice guidance, not legal advice; qualified counsel should review any agreement before signature.
Rule of thumb: If a contract cannot answer what happens to your data on exit, and who is accountable when the model is wrong, it is not ready to sign.
Questions to ask
- Is our data used to train anything beyond our own instance?
- How will we be told when the model changes, and can we reconstruct an old decision afterwards?
- Where does liability sit when the system produces a wrong output we act on?
- What exactly do we get back on exit, in what format, and by when?
Vendor Strategies for Industry
Strategy · 3 min read
Smaller and mid-sized organisations face the same AI decisions as large ones, with less room for error and less capacity to absorb a failed programme. The answer is not to avoid the tools, but to structure commitments so that each step is small, reversible, and earns the next.
Match the commercial model to the need
The range of ways to obtain AI capability is wider than it once was, and the right model depends on how much control you need and how much uncertainty you can carry. The guiding principle is to keep the commitment proportionate to the evidence you have, and to prefer structures that let you stop without writing off the whole investment.
- Open-weight models with managed hosting — you keep control of the weights and the data plane while a provider runs the underlying infrastructure.
- Pay-per-use API services — no capital commitment, cost tracks actual use, and switching is closer to a configuration change than a migration.
- Shared or consortium buying — pooled demand to reach better terms and share infrastructure without sole ownership of it.
- Phased commitments — begin with a narrow scope, prove value against a stated measure, and extend only on evidence.
The choice is not permanent. An organisation might run open-weight models with managed hosting for a capability it intends to own, use pay-per-use APIs for experiments it may abandon, and join a shared arrangement for infrastructure too costly to carry alone. What matters is that each choice is made deliberately, with its exit understood before it is taken.
Keep the exit open
The most valuable position for an organisation of limited means is optionality. Prefer arrangements where the data you accumulate can be exported in a usable form, where the integration is not so bespoke that it binds you to one supplier, and where the contract can be wound down without losing the work already done. Optionality is cheaper to build in at the start than to buy back later.
Data is the part of the exit most often overlooked. Models can be replaced and interfaces rewritten, but if your data sits in a supplier's proprietary format and cannot be exported in a usable form, you have lost the asset the engagement was accumulating. Insist on portability before you accumulate, and test the export once, early, while the relationship is still cooperative.
Where the stakes warrant it, consider combining buying power with others in a similar position — through an industry body, a shared services arrangement, or a consortium. Pooled demand can reach terms a single mid-sized buyer cannot, and shared infrastructure spreads the fixed cost. The discipline is the same as buying alone: keep scope narrow, keep the exit open, and scale only on proof.
Rule of thumb: Never make the next commitment larger than the evidence from the last one. If a step cannot be reversed at acceptable cost, it is too large to take on faith.
Questions to ask
- What is the smallest commitment that would prove value, and how will we measure it?
- If we stopped in six months, what would we keep and what would we lose?
- Is our data and integration portable, or does it quietly lock us in?
- Could we reach better terms by buying alongside others, and is that worth the coordination?
← Back to Knowledge Bank