← Insights

Procurement7 min read

How to buy AI as a Canadian public body

Most public-sector AI procurements that go wrong were decided wrongly before the RFP was written. The statement of work describes a product rather than a decision, the impact assessment is started after award, and the evaluation grid scores demos instead of evidence. The sequence below is the one we see work.

Start with the decision, not the system

Write down the decision the system will inform or make, who is accountable for it today, and what happens to a person when it is wrong. A tool that drafts correspondence for an officer to edit is a different procurement from one that triages applications, even if both are "a language model". The Directive on Automated Decision-Making turns on exactly this distinction.

Run the Algorithmic Impact Assessment early

For federal institutions, the Directive requires an Algorithmic Impact Assessment before a system that makes or supports an administrative decision goes into production. The AIA produces an impact level from I to IV, and the level sets the obligations: peer review, notice to the people affected, human involvement in the decision, explanation and testing requirements.

Do a first pass before going to market. The impact level belongs in the RFP, because it decides what the vendor has to deliver — and a vendor quoting a Level I system for a Level III use case is quoting a different project.

Choose the vehicle

Federal buyers can use the pre-qualified Artificial Intelligence Source List, run an open competition, or start with a challenge-based or pilot contract. Provinces and municipalities have their own vendor-of-record arrangements. The right vehicle depends on how well the problem is understood: a source list suits a defined need; a phased pilot suits one where the data quality is still unknown.

Write requirements a vendor can be held to

  • Data residency, stated as a location and a list of permitted subprocessors — not "Canadian cloud".
  • The model and its version, and what happens when the vendor wants to change it.
  • Logging: what is recorded for each output, for how long, and who can read it.
  • An evaluation set you own, and the accuracy threshold measured against it.
  • Exit: the format your data and any fine-tuned weights are returned in.

Evaluate on evidence

Score the vendor’s answers to your evaluation set, not their demonstration. Ask for the audit reports behind every certification on their website, and read the scope section — a SOC 2 report that covers a corporate network but not the hosting environment does not cover your data.

A procurement built this way is slower to write and much faster to defend. When the auditor, the privacy commissioner or a journalist asks why the system behaves as it does, the answer is already in the file.


More insights


Working through this on a live procurement? We brief evaluation teams under NDA.

Request a Briefing