Most published AI policies in the public sector describe values. Values are necessary and insufficient. A finance department needs a document that a deputy director can consult on a Tuesday afternoon to determine whether a specific proposed use is permitted, who has to approve it, and what has to be logged. That document is short.
The five questions a policy must answer
1. What counts as a covered system?
Scope creep in both directions is the most common drafting failure. Define coverage by consequence, not by technology. A policy that covers "artificial intelligence" invites arguments about whether a regression is AI. A policy that covers "any automated process whose output materially influences a financial decision, an eligibility determination, or an audit conclusion" covers the spreadsheet macro that matters and excludes the spell-checker that does not.
2. What is the risk tier and who approves each tier?
Three tiers are usually enough.
| Tier | Description | Examples | Approval |
|---|---|---|---|
| Low | Output is advisory; a human independently reaches the decision | Document summarisation, drafting, search ranking | Department head |
| Moderate | Output determines what a human reviews or in what order | Transaction triage, exception queues, lease-term extraction | Finance director + internal audit |
| High | Output blocks, delays, or determines an outcome affecting a third party | Payment holds, vendor scoring, eligibility screening | Governing body, with published notice |
The tier is a property of the deployment, not the vendor. The same model used advisorily is low tier; used to block a payment it is high tier. Policies that tier by product rather than by use are gamed within a month.
3. What data may enter the system, and where does it go?
For public entities this is the clause that most often needs legal review. It should state, in plain terms: which classes of data may be sent to a system operated by a third party; whether that third party may retain or train on the data; how records-retention and public-records obligations apply to prompts and outputs; and what happens to the data when the contract ends. If the answer to "may the vendor train on our data" is not "no, in writing", the policy should say what compensating controls apply.
4. What must be logged?
A minimum log for a moderate-tier system: the version of the model and rule set in force, the inputs, the output, the identity of the reviewer, the disposition, and — critically — every override, with a reason code. Override data is the single most valuable artefact a deployment produces. A model whose recommendations are overridden eighty per cent of the time is not being used; it is being tolerated, and the log is how you find that out before the annual report says otherwise.
5. How is it re-evaluated?
Set a fixed cadence — annually is defensible for most finance applications — plus event triggers: a change of ERP, a change of chart of accounts, a material change in the vendor's model, or a pattern of overrides above a threshold. Re-evaluation means testing against a labelled sample, not asking the vendor whether anything changed.
The clause worth adding that most policies omit
A sunset. Every moderate- and high-tier deployment should carry an expiry date at which continued use requires an affirmative renewal decision supported by evidence of value. Without a sunset, pilots become permanent by inertia, and nobody ever has to defend the tool on its merits a second time.
Procurement clauses that carry the policy
A policy that is not reflected in the contract is a memo. The provisions that do the actual work are unremarkable and are frequently negotiated out:
- Data use and training restrictions, with a survival clause after termination.
- Model change notification — advance written notice of material changes to model behaviour, with a right to re-test.
- Audit access — the entity's auditors may inspect logs, configuration and evaluation results.
- Exit and portability — the entity's data, configurations and decision logs are exportable in a documented format at no additional charge.
- Performance evidence — the vendor supplies evaluation results against the entity's own data, not published benchmarks.
The last one is the sharpest test of a vendor. Anyone unwilling to be measured on your ledger is asking to be trusted on someone else's.
Public communication
Publish a plain-language summary of where automation is used in the finance function. Two paragraphs is enough. The reason is not transparency theatre; it is that the alternative — a resident discovering it through a records request — converts a routine internal control into a story about concealment. Entities that publish first find that the conversation is short and largely uninterested.
This publication is general information and is not legal, accounting, audit or financial advice. See our Disclaimer. Found an error? Write to [email protected] — we correct in place and note what changed.