AI procurement is a decision about a service, its risks and the institution's future control—not just a comparison of model features. A well-written specification helps teams distinguish a convincing presentation from a solution they can govern.
The questions below are a starting point for public-sector and institutional buyers. Adapt them to applicable procurement rules, your organisation's policies and the consequence of the intended use.
1. What outcome are we buying?
Describe the service problem and its baseline without prescribing AI as the only acceptable solution. Ask suppliers to explain why their approach is appropriate and what a non-AI alternative would look like.
Define success through service outcomes and constraints. Include accessibility, relevant language support and the needs of people affected by the decision, not just the experience of the purchasing team.
2. What happens to our data?
Request a clear data-flow description covering hosting, processing, logs, subcontractors and support access. Ask whether your information is used to train or improve any supplier model, and how that restriction is enforced.
Examine deletion, correction, retention and export arrangements. Data residency is important, but the physical location of a server does not by itself resolve questions about access, control or applicable obligations.
- Which people and organisations can access the data?
- What information is retained in prompts, outputs and logs?
- How is a deletion request propagated to copies and backups?
3. What evidence supports the claims?
Ask for evaluation against a representative sample of your intended tasks, with a test design agreed before results are presented. Record limitations, failure cases and the conditions under which the supplier's claims apply.
Use acceptance criteria that can be verified by the institution. Avoid treating a headline benchmark, a certification claim or a polished demo as sufficient evidence that the proposed service will work in your environment.
4. Who controls changes and incidents?
Clarify who approves changes to models, prompts, data sources and subcontractors. Ask how the institution is notified, what evidence accompanies a change and whether a release can be delayed or reversed.
Define incident reporting, support responsibilities and routes for challenging an output. Where the consequences are significant, contract and operating arrangements should make accountability visible rather than transferring decisions to an opaque service.
5. Can we leave without losing the service?
Review the ability to export data, configuration and relevant records in usable formats. Distinguish material the institution owns from supplier technology that cannot be transferred.
Cost the transition and establish a fallback for service continuity. An exit clause is only useful if the technical and operational work required to exercise it is understood. Bring procurement, service, security and legal teams together before commitment, not after a supplier has become indispensable.
General practical guidance, not legal advice. Adapt these steps to your organisation and seek appropriate specialist advice.