AI governance policy: what one decision can show
A policy is a promise written before anything runs. A few of its clauses are about what will be true of a particular decision — and those are the ones somebody will eventually ask you to demonstrate.
An AI governance policy says how decisions involving AI will be made. A few of its clauses can be shown to have held for one decision. This page is about those.
What this page covers
An AI governance policy states how an organisation will use AI: which uses are permitted, who decides, who is accountable, and how an affected person can challenge an outcome. Most of its clauses are checked by reading the document and auditing the programme.
A smaller set says what will be true of a particular decision: that it was made under an approved rule, that the rule can be identified afterwards, that the account was not written after the outcome was known. Those are checked by producing something about one decision. This page is about drafting them so that is possible, and being straight where it is not.
The clauses that get tested
A policy is written once and met one case at a time. The clauses that hold up describe a record that exists. The ones that go badly are ordinary sentences whose evidence lives in two systems that were never joined.
"Made under an approved policy" is the clause most written and least shown
The document is versioned and dated. The decision record rarely carries which version governed it, so the link is made afterwards by inference, not read off a record.
"Reconstructable afterwards" describes an ability, not a record
Reconstruction is work somebody does when the question arrives, from material gathered for other purposes. It can be accurate and still not be a record written as the decision was made.
Challenge and appeal clauses promise something to someone outside the organisation
What the process hands a person or their adviser has to stand up away from your systems, without an account on them.
Retention clauses decide what is left when the question arrives
A promise to show something later is a promise about what is kept, in what form and for how long.
Which clauses a decision record can carry
“Policy” means two things here: the document this page is about, prose approved by people; and MeshQu’s policy, a versioned, approved set of rules a computer checks a decision against. A good document names the rules that carry it out; neither replaces the other.
A Decision Receipt is a signed, replayable record of how a consequential decision was made, created at the moment it happens and verifiable afterwards with the necessary verification material and trusted keys. It does not prove that the inputs were true, that the decision was correct or that the action was carried out.
For a drafter, the useful consequence is that a few clauses stop being promises about future effort and become descriptions of a record that already exists by the time anyone asks.
MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.
MeshQu does not write, review or assess a policy document. Nothing here is legal or regulatory advice.
"Made under an approved rule" becomes a recorded fact rather than an inference
A snapshot of the rules that applied is sealed into the record’s fingerprint. Which version governed a decision is read off the record, not pieced together from two systems.
"Reconstructable afterwards" becomes re-runnable
Replay re-runs the recorded context against the saved policy: the same inputs and the same policy give the same result. Your deployment can repeat it on request. Where export is enabled for your deployment, a second party can repeat it from the exported bundle.
"Approved by the right people" can travel with the decision
Where export is enabled, a reviewer can check which policy version was approved and that the rules applied are the ones it contained. This needs the approvers’ keys, supplied separately from the operator’s.
"Checkable by the person asking" can be drafted, with a condition
Where export is enabled for your deployment, one decision can be handed over as a single bundle, and the person asking can run the fingerprint and signature checks themselves with keys they trust independently. Anything missing is reported as missing, never as a pass. A clause should name that condition.
"Records are not quietly rewritten" needs two checks
The record’s fingerprint covers its content, and the signature covers the fingerprint. An edit only shows when both are checked, so a tamper-evidence clause should name both.
What it does not do
A record shows a rule was applied, not that the rule or the decision was right
It shows the record was signed by a known key and has not changed since. Whether the rules were any good, the inputs true or the outcome right is outside the record, and a clause that implies otherwise claims something the record cannot carry.
Most of a policy is not of this kind, and should not be drafted as though it were
Scope, prohibition, procurement, training and incident clauses are shown by inspection and audit of the programme, not by a decision record.
MeshQu does not verify who acted
The record notes whether a person or an automated system acted, as your systems report it. It records what it was told, not that it was true. A clause that promises more about who acted is a promise nobody can keep.
A signature shows who signed. It does not show the record is honest.
Whoever holds a signing key can sign whatever they choose. Receipts carry weight when every decision in scope must have one and, where anchoring is enabled, each is also placed in a public log. Both are governance choices the document has to make, not properties of the receipt.
A receipt is itself sensitive
A signed record of a consequential decision about a person will usually be personal data. Retention, access and disclosure clauses still have to be written and engineered.
Some checks are built but not switched on everywhere
Bundle export and public-log anchoring are built into MeshQu and enabled per deployment; neither is on by default in production. MeshQu’s signed key registry and offline verifier tool are not yet published, so independent key trust is arranged per engagement. Live checking against a co-signed log witness is not built. Do not draft a clause that depends on a feature your deployment has not enabled.
Related reading
What a Decision Receipt is
What a receipt contains, how it is checked, and what it does not prove.
Policy lifecycle: how MeshQu’s rules are versioned, reviewed and approved (opens in a new tab)
The other meaning of policy: how the rules a document points at are versioned and approved.
Verifying offline (opens in a new tab)
The two-step integrity and signature check, and what each step settles on its own.
Articles
Which policy was in force when the decision was made?
Policy-as-code evaluates a decision against the rules in force now. Showing which rules applied six months ago means capturing the decision as it is made.
When the FCA asks why one payment was cleared, what can you show?
A UK retail bank does not lack AI policy. It lacks decision proof for one cleared payment when an FCA review picks it out of a sample eight months later.
Next step
If a clause is drafted and nobody can name the record that would demonstrate it, that is the conversation worth having. Bring the clause.