Governments in the AI era

How to Buy AI as a Government: The Procurement Guide We Wish Our Buyers Had

Cari · 2026-10-01 · 7 min read

TL;DR: Governments buy AI badly when they score demos instead of outcomes. Run a small, measurable pilot, insist on open standards and data export so you can leave, make vendors explain where the AI stops and humans take over, keep citizen data in your jurisdiction, and price the full lifecycle rather than year one. Ask every vendor the ten questions below, including us.

Most guides like this are sales letters wearing a lab coat. This one is different in exactly one way: every test we recommend is a test we expect to be given. If a question in this guide makes a vendor uncomfortable, it is doing its job. If it makes us uncomfortable, you should ask it twice.

Buy outcomes, not demos

A demo is a performance. It runs on curated data, on a happy path, presented by the most fluent person the vendor employs. None of that predicts what happens when the system meets your real forms, your real staff, and your real citizens.

The alternative is to make the pilot the evaluation. Pick one service, one quarter, and a handful of metrics you define before anyone signs anything. Good candidate metrics: days from application to decision, number of verification phone calls avoided, percentage of cases resolved without a follow-up visit, staff hours per case. Then score vendors on what actually moved.

This changes the power dynamic. A vendor who is confident in their product will welcome a measured pilot because it is their fastest route to expansion. A vendor who keeps steering the conversation back to the slide deck is telling you where their strength lies.

Ask Cari this too. Ask us which metric we would commit to on your first service and what number we would consider a failure. A vendor who cannot name a failure condition has not thought hard about your problem.

Open standards are your exit rights

The most expensive part of a bad government IT contract is not the licence. It is the exit. Systems that store documents in proprietary formats and reference data in invented code lists make leaving so painful that renewal negotiations happen at knifepoint.

Three requirements protect you:

First, require that credentials and documents issued by the system follow the W3C Verifiable Credentials standard. A permit or certificate issued as a verifiable credential can be checked by any conforming verifier, not only the vendor who issued it. Your documents outlive the contract.

Second, require standard reference data. Locations should use UN/LOCODE. Goods classifications should use Harmonised System codes. When the data model is built on international standards, a migration is a project. When it is built on vendor-invented identifiers, a migration is an excavation.

Third, put data export in the contract: full export, machine-readable, documented format, on request, at no additional cost. Test it during the pilot, not at the end of the relationship.

A vendor who resists portability is telling you something. Listen to them.

Pilot-sized commitments

Start small enough to walk away from. That is the entire principle. If abandoning the pilot would be a political embarrassment or a budgetary crater, the pilot is too big, and everyone involved will feel pressure to declare success regardless of results.

One service. One agency. One quarter. A price that fits inside existing discretion. Expansion should be written into the contract as something the vendor earns by hitting the metrics you defined, not something you owe them because the kickoff meeting went well.

This also protects good vendors. A small pilot with honest metrics lets a strong product prove itself quickly, without a procurement cycle that outlasts the government that started it.

Demand honesty about AI limits

Any vendor who tells you their AI is always right should be escorted from the building politely. Models are wrong sometimes. The question is what the system does about it.

You want concrete answers to three things. Where does the system hand off to a human, and is that boundary configurable by you rather than hardcoded by the vendor? What happens when the model is wrong about a citizen, meaning what is the correction path, how fast is it, and who can trigger it? And who is accountable for a decision that affects a citizen, because the answer must be a person in your government, with the AI as an instrument, never the reverse.

Decisions about benefits, permits, and legal status should be explainable to the person they affect. If a vendor cannot show you what the citizen sees when they ask why, that gap will become your ministry's problem at the worst possible moment.

Data residency and privacy

Ask where citizen data physically lives, under whose legal jurisdiction, and exactly who at the vendor can access it. Get the answer in writing, in the contract, not in a reassuring meeting.

Then ask a sharper question: when a document is verified, does the verification phone home? It should not. A well-designed verifiable credential can be checked cryptographically without notifying the issuer or the vendor that the check happened. If every verification event flows through the vendor's servers, the vendor is accumulating a live map of your citizens' interactions with the state. That is a surveillance asset nobody voted for.

Also ask what data the vendor retains after the contract ends, and demand that the answer is none, with deletion certified.

Total cost honesty

The licence fee is the visible part of the iceberg. The real total is licence plus integration plus operations plus the cost of change over the life of the system.

Ask for a three-year total cost, not a year one price. Ask what an integration with one existing system actually costs, in money and in your staff's time. Ask what happens to pricing at renewal, because a cheap first year followed by an expensive lock-in is the oldest trick in enterprise software, and it works precisely because switching costs were never priced in.

This is where the open standards requirement pays for itself twice. Exit rights are also negotiating rights. A government that can credibly leave pays fair prices forever.

The ten questions to ask every vendor

1. What single metric will you commit to improving in a one-quarter pilot, and what result would you call a failure?
2. Do you issue documents as W3C Verifiable Credentials that any conforming verifier can check?
3. Do you use standard reference data such as UN/LOCODE and Harmonised System codes, or vendor-invented identifiers?
4. Will you contractually guarantee full machine-readable data export at no extra cost, and can we test it during the pilot?
5. Where exactly does your system hand off to a human, and can we move that boundary ourselves?
6. What is the correction path when your AI is wrong about a citizen, and how fast is it?
7. Where does citizen data live, under which jurisdiction, and who at your company can access it?
8. Does document verification phone home to your servers, or can it be done without notifying you?
9. What is the full three-year cost including integration and operations, and what changes at renewal?
10. What happens to our data, our documents, and our service on the day after we leave you?

Ask us all ten. We wrote them knowing we would have to answer them.

Common questions

Is a formal tender better than a pilot? They solve different problems. A tender compares promises; a pilot compares results. Where your procurement rules allow it, use a small pilot to generate evidence, then let that evidence inform the larger formal process. Check the specifics with your own procurement authority, because rules differ by country.

We have no AI expertise in-house. Can we still evaluate vendors? Yes, because the questions above are not technical. Days to decision, exit rights, accountability for errors, and total cost are governance questions, and governance is exactly what governments know. You do not need to understand transformer architectures to notice a vendor dodging question four.

What is the single biggest red flag? Resistance to portability. Every other weakness can be improved over a contract's life. A vendor who builds so you cannot leave has told you their retention strategy, and it is not product quality.

If you are thinking about where a small, measurable pilot could start in your country, the country onboarding page is a good first step.