Skip to content

AI in Government and Public Services

5 min read · updated August 3, 2026

Most of what makes public-sector delivery different is not technological. It is that the work is done under obligations to publish, to retain, to explain and to serve everyone, and that the contract was signed before anyone knew what the system would do in March. Nothing here states what any government currently requires.

Buying something that changes after you buy it

Public procurement fixes scope, price and acceptance criteria in advance, and evaluates against them. Hosted language models are the opposite kind of thing: the vendor can change the model behind a stable name, deprecate a version with a notice period, or alter safety behaviour, and the system a department accepted in January is measurably not the system running in June — silent model updates describes the mechanism.

That mismatch is manageable, but only in the contract, and only if someone raises it before signature. The clauses worth having are specific:

  • Version pinning. The right to call a named, dated model version, not an alias, for the term — and a stated minimum notice before that version is withdrawn.
  • Change notification. Notice of material changes to model behaviour, safety filtering or output formatting, with enough lead time to re-run acceptance tests.
  • Re-acceptance. The acceptance test suite is a deliverable that gets re-run on version change, and the results are the department’s, not the supplier’s.
  • Exit. Prompts, evaluation sets, extracted data and logs are the department’s property in a portable format. A body that cannot leave has bought a dependency, not a service.

The engineering counterpart is an abstraction layer thin enough that the model is a configuration value — provider-agnostic code and model feature flags — plus an acceptance suite that can be run on demand. Both are cheap at the start and impossible to retrofit under a live contract.

Your logs are records

Everywhere else in this cluster, logging is a design choice with a privacy cost. In a public body it is something else: material created in the course of official business is frequently a record, subject to retention schedules and potentially to disclosure on request. That cuts in both directions at once and the combination is unusual.

Prompts and outputs may need to be retained — for a scheduled period, in a form that can be produced — which forbids the ephemeral logging that privacy engineering would otherwise recommend. And they may need to be disclosable, which means a caseworker’s free-text query about a named citizen might one day be read by someone else. Both consequences argue for the same design: log deliberately and structurally rather than dumping raw text, keep personal data out of prompts where the task does not need it, and separate the operational telemetry you need for reliability from the record of what was decided. See what to log, PII in logs and audit logging. The retention period itself is a question for the body’s records officer, and it is not the same question in two jurisdictions.

The rules applied are the rules on the date

Public services administer rules that come from statute, regulation and published guidance, and those rules have commencement dates. An application is decided under the rules in force when it was made, or when the circumstances arose, not under whatever the website says today. A retrieval system that indexes the current guidance and answers questions about a case from last year is confidently applying the wrong law.

The design that handles this is point-in-time retrieval: every document chunk carries a validity interval, queries carry an effective date, and the filter is applied before ranking rather than hoped for in the prompt. Superseded guidance stays in the index with its interval closed rather than being deleted. This is ordinary metadata filtering, but the metadata has to be captured at ingestion, and for decades-old guidance it frequently has to be reconstructed by hand. Budget for that; it is the real cost of the project.

Never tell someone they are not eligible

Assistants that help people work out whether they qualify for a benefit, a permit or a service have a strongly asymmetric error cost, and it is asymmetric in a direction that does not show up in an accuracy metric.

A wrong “you may be eligible, apply” costs an application that is refused — some staff time, some disappointment, and a decision the person can appeal. A wrong “you are not eligible” costs someone a benefit they were entitled to, they do not apply, no decision exists, so there is nothing to appeal, and nobody ever finds out. The people most likely to accept that answer without challenge are the people least able to afford it.

So the output space should not contain the negative. The system explains the criteria, indicates which ones the described circumstances appear to meet, and routes to the application in every case where the answer is not a clear yes. It is a small design decision and it is the difference between a helpful front door and a machine that quietly suppresses take-up.

Accessibility and language are the delivery

A public service has to work for everyone who is entitled to it, which makes two things that are afterthoughts elsewhere into requirements here.

Streaming chat interfaces are a specific accessibility problem. Token-by-token rendering into a live region makes a screen reader announce fragments continuously, which is unusable; the fix is to buffer to sentence or paragraph boundaries for assistive technology, keep the response focusable and re-readable after it completes, and never rely on a transient status message to convey state. That is a front-end decision made once, and how streaming works explains what you are buffering.

Language access is the other. Where services must be available in several languages, machine translation of an official notice is a publication in that language and carries the same weight as the original — an error in the translated version of a deadline is an error in the service, not a quality issue. The workable pattern is machine translation with human review for anything that states an entitlement, a deadline or an obligation, and unreviewed translation only for navigational text. Translation quality covers how to decide which is which.

AI in Government and Public Services · Multigrid