Prepare a public-sector AI trial that can be scrutinised

Begin with the service problem, not a target number of AI projects. A ministry should be able to explain why the proposed system is needed, who could be harmed and how people can obtain help without it. This guide does not promise a launch within one fiscal year or without additional staff.

Define the boundary

A summary of a published committee report is different from determining benefit eligibility. A directory of official service contacts is different from interpreting residency, tax or licence requirements. Do not label the second task low risk because it is delivered through a chatbot.

Start with a controlled document exercise using public or synthetic information. Keep decisions affecting benefits, care, employment, policing and legal rights outside a general chatbot pilot. Specialist systems require their own lawful purpose, evidence and appropriate oversight.

Prepare a decision file

1. Service need: describe the existing process, affected people and non-AI alternatives.
2. Scope: list permitted outputs, prohibited actions and data that must not enter the system.
3. Evidence: identify authoritative sources, test cases, reviewer qualifications and acceptance criteria.
4. Access: plan language support, accessibility and a non-digital or human route where needed.
5. Accountability: name the owner, incident lead, approver and people responsible for corrections and complaints.
6. Procurement: examine the exact contract, data rights, vendor dependencies, audit evidence, exit arrangements and full operating costs.
7. Launch decision: record unresolved issues and reasons to stop, narrow or proceed. A trial does not confer authority to deploy.

Use the governance guide and incident-response exercise. Allocate the time and specialist capacity the actual risks require, rather than promising a fixed-duration audit.

Bounded starting examples

• Published-document index: extract title, date and section references from committee papers; staff verify every entry.
• Approved service information: edit a current office-hours/contact sheet into plain language, with no eligibility conclusions or invented deadlines.
• Meeting action register: organise already-agreed actions from approved non-sensitive minutes without inferring consent or commitments.

Do not ask a general model to forecast hurricane tracks, choose evacuation routes or allocate relief. Weather and emergency communications should remain with competent authorities and approved procedures. Formatting a bulletin must not change its technical meaning.

Questions before approval

• What error would materially harm someone, and how was that failure tested?
• Can a person understand and challenge the result without relying on the model?
• What evidence establishes the source and version of each consequential claim?
• Can reviewers reject an output and stop the workflow in practice?
• What happens during an outage or vendor change?
• Is the proposed data use and procurement authorised under the applicable rules?
• What will be published about the system’s limits and evaluation?

Record results without promotional claims

Report completion, errors, accessibility problems, corrections and human workload, including failed cases. Distinguish a pilot from a production service and an association from a demonstrated causal benefit. Do not extrapolate a small trial to a national productivity forecast.

NIST’s voluntary AI RMF and UNESCO’s AI ethics recommendation are reference frameworks, not authorisation to operate a public service. Sources checked 11 November 2026.

Created by Adrian Dunkley | MaestrosAI | maestroailabs.com | ceo@maestrosai.com. Editorial review: 11 November 2026.