Most governance advice aimed at public bodies fails in the same way: it is written for an organization with a compliance department, a policy team and time. The result is a framework that is genuinely good and that a county with four IT staff will never implement, so nothing gets implemented at all.
What follows is sized for organizations that do not have those things. It is deliberately small, because a governance position that exists and is followed is worth more than a comprehensive one that sits unread, and because the first version can be written in an afternoon.
If you are a business rather than a public body, AI governance for small and midsize businesses covers the same ground without the parts below that only apply to public organizations.
What makes public-sector governance different
Four things, and every recommendation on this page follows from one of them.
There is a governing authority. A council, a board, a commission or an elected executive will eventually ask what the position is, and the answer needs to be a document rather than a practice. That raises the bar on writing it down and lowers the bar on how elaborate it needs to be.
Decisions are disclosable. What was decided, by whom and on what basis may be subject to public records law. That is a reason to keep records deliberately rather than a reason to keep fewer.
Procurement must be defensible. A purchase needs a basis that survives being examined a year later by somebody who was not there.
The people affected did not choose you. A resident, a student or a patient cannot take their business elsewhere if an automated process treats them badly. That is the strongest argument for human oversight, and it is an argument about obligation rather than risk.
Start with an inventory, because you already have one
Before writing any policy, find out what is in use. Ask staff directly, without consequence attached, which AI tools they use for work.
The answer is always larger than expected and it is not a discipline problem. People adopt tools that make their work easier, and the absence of an approved route is an organizational failure rather than an individual one. An inventory turns an anxiety into a list, and a list can be governed.
Record, per tool: who uses it, for what, what information goes into it, whether the organization pays for it, and whether anyone approved it. That table is the foundation of everything below, and producing it usually reorders your priorities on its own.
Name an owner, and give them the power to say no
One named person or a small group must be able to approve a new AI tool and to decline one. Both halves matter. An approver who cannot decline is an administrator of a process, not an owner of a decision.
In a small organization this is one person, usually the technology lead, with an escalation route to the executive for anything touching sensitive records or decisions about individuals. In a larger one it is a standing group with representation from technology, records, legal and the service areas. What it should not be is a committee that meets quarterly, because the pace of requests will simply route around it.
Write down what they consider. Four questions is enough to start: what information would go into it, what would a wrong output affect, who is accountable for the result, and can we stop using it cleanly.
An approved list, and a route onto it
Publish which tools are approved and for what. Then publish how to ask for another one, and answer those requests quickly.
The second half is what makes the first half work. A list without a route becomes a list of things nobody uses, and the actual work continues on unapproved tools where you cannot see it. An organization that answers a request in a week will get requests; one that takes a quarter will not, and will believe it has no shadow AI.
Be explicit that the list has tiers. A tool approved for drafting internal correspondence is not thereby approved for anything touching personal records, and stating that once in the list is cheaper than adjudicating it repeatedly.
Decide what data may go in, in writing
This is the single most valuable page of the whole exercise, and it is the one staff will actually consult.
State which categories of information may be entered into an external AI service and which may not. Use the classification you already have if you have one, and three categories if you do not. Public bodies should expect to draw a hard line around anything identifying an individual, anything with a statutory confidentiality obligation attached, anything under active legal hold, and anything security related about your own environment.
Write it as a rule a person can apply without asking, because the alternative is that they guess. "If it names a resident, a student or a patient, it does not go in an external tool" is a workable rule. "Exercise appropriate judgment" is not.
Access, because AI inherits permissions
An AI service can reach exactly what the account running it can reach. If access has accumulated over years, which in most public organizations it has, then introducing an assistant grants it that accumulation in one step.
The governance requirement is that access is reviewed before a tool is deployed against a system rather than after, and that the review is recorded. This is ordinary access management and most organizations know they should do it; what is new is that AI makes the consequences of not doing it immediate and hard to detect, because the tool will simply answer questions using material the asker should not have seen.
Supplier review: five questions to add
You already review suppliers who handle your information. Add five questions rather than building a separate AI process.
- Where is our data processed and stored, and by which subprocessors.
- Is our content used to train models, by default or at all, and how is that turned off.
- What is retained, for how long, and can we delete it on our schedule rather than yours.
- Can we export or produce our content on request, in a usable form.
- What happens to our data on termination, and how long does that take.
Ask for the answers in writing and read the linked policies rather than the summary, because the substantive answer is usually in a document referenced by the agreement rather than in the agreement. A supplier who will not answer question two in writing has answered it.
Human oversight, and where it must be real
Decide which outputs require a human judgment before they take effect, and record the decision.
The threshold that works for public bodies is consequence to a person. A draft of a routine letter needs no gate. Anything bearing on eligibility, enforcement, discipline, employment, grading, benefits, safety or a permit does, and the person exercising that judgment must be identifiable afterwards and must have both the information and the authority to disagree with the output.
That last clause is the one that is usually missing. A reviewer who cannot in practice overturn a recommendation is a rubber stamp, and describing them as human oversight in a policy is worse than not claiming oversight at all.
Records, disclosure and retention
Two questions your records officer needs answered, and they are technical questions with organizational consequences.
First, what does the tool retain: the output, the instruction that produced it, the conversation history, for how long, and under whose control. Second, can you produce that on request and dispose of it on schedule. A tool that cannot do either is a records management problem however useful it is, and the time to find that out is before deployment.
Decide separately whether the public will be told when AI has been used in preparing a document or a response. There is no single right answer, and jurisdictions are moving in different directions, but a decision made deliberately is defensible and one made by omission is not.
Frameworks worth referencing, and what they are not
The NIST AI Risk Management Framework is the reference a governing body is most likely to have heard of, and its Generative AI Profile is the more directly applicable companion for the tools most organizations are actually adopting. CISA publishes guidance oriented to critical infrastructure and government.
Two things to be clear about. These frameworks are voluntary guidance, not regulation, and adopting them does not make an organization compliant with any statute, contract or state requirement. And referencing one in your policy is useful mainly because it gives a governing body a recognized point of comparison. Neither this page nor a supplier can tell you what your legal obligations are; that is a question for your counsel, and any vendor claiming their product delivers compliance is describing something no product can deliver on its own.
What to do in the first month
In order, because the order is what makes it achievable.
- Week one: run the inventory. Ask, do not audit.
- Week two: name the owner and agree the escalation route.
- Week three: write the data rule and the one-page acceptable-use position.
- Week four: publish the approved list and the request route, and set a review date.
Supplier questions and access review follow once there is something to apply them to. Deferring the first four weeks until the whole framework is ready is how organizations end up with nothing.
How this fits the wider picture
Governance is one of the seven dimensions of AI readiness, and it is the one organizations score lowest on and are most surprised to learn matters this early. It is also the cheapest to improve.
To see where you stand across all seven, the AI Readiness Self-Assessment takes about eight minutes, and the public-sector readiness checklist is the version to work through with your own team.
Where a governing body needs something more substantial than a self-assessment, AI readiness assessment and consulting produces a written position with the evidence behind it. Members buying through a cooperative contract will find the route on the TIPS page, or talk it through with us first.