Public sector AI governance: sovereignty, disclosure, and records.

Why public sector AI governance is a different problem.

Enterprise governance exists to protect the organization: its data, its decisions, its evidence. Government governance has to do all of that and then answer to people who never agreed to be subject to the system. A citizen cannot opt out of the tax authority or churn to a competing permit office. That asymmetry is why the public-sector version comes with obligations the enterprise version treats as optional: records law applies to the outputs, freedom-of-information regimes apply to the workings, and auditors general exist specifically to ask the questions a private board might let slide.

The four layers of a standard framework (classification, approval, oversight, audit trail) still apply, but three pressures bend them into a different shape: sovereignty constrains where anything may run, disclosure constrains how quietly you may run it, and records law constrains how much of it you may forget. Each gets a section below.

Data residency and sovereignty: where AI is allowed to run.

Residency and sovereignty get used interchangeably and are not the same thing. Residency is geography: the data is stored and processed inside the country. Sovereignty is control: whose law applies, who can compel access, and whether the government could keep operating the system if the vendor relationship ended tomorrow. A model hosted in-country by a foreign provider satisfies residency and may still fail the sovereignty test, because the questions that matter are about jurisdiction and control, not datacenter coordinates.

The workable approach is the same classification-first move we recommend everywhere, with a hosting column added: every data class maps to an allowed deployment pattern. Public material can usually go through approved commercial tools, internal and confidential classes typically need in-country hosting on government terms, and the most sensitive classes need infrastructure the government controls, which is where open-weight models earn their place: they are the only kind you can run entirely inside your own boundary. Before any vendor gets a sensitive class, four questions need written answers:

The UAE case: when the national privacy law is not your frame.

Sovereignty rules are written at surprising levels of government, and assuming the national privacy law covers you is a common mistake. The UAE is the clean example: the federal data protection law (PDPL, Federal Decree-Law No. 45 of 2021) explicitly excludes government entities and government data from its scope, so for a ministry or authority the binding rules are emirate-level and entity-level instead. We wrote up the operating reality in AI for UAE government, and we do this work on-site through our UAE consulting practice.

The general lesson travels: before writing your own rules, map which instruments actually bind your entity. The list is usually shorter and stranger than the org chart suggests, and it decides everything downstream, from usable cloud regions to which models can be accredited at all.

Disclosure: telling people when AI is in the loop.

For a company, disclosing AI use is mostly a trust decision. For a government it is increasingly a legal one, and the table below names three regimes that already bind. Whichever applies to your entity, the same three conventions are worth deciding centrally before a deadline decides them for you:

• Separate assistance from authorship. A human-reviewed internal draft is a different disclosure case from a chatbot answering citizens on its own. Most of the regimes below draw roughly this line; your conventions should draw it explicitly.
• Write the exact words down. When AI involvement is flagged, in which phrasing, and who approves exceptions. The failure mode is each department improvising its own answer under deadline pressure, which produces inconsistency and, eventually, a story about the inconsistency.
• Publish the inventory before someone requests it. A use-case register you publish on your own terms reads as competence. The same register extracted through a records request reads as concealment.

Human oversight when the output affects a citizen.

The US federal definition of high-impact AI is a useful test anywhere: AI whose output serves as a principal basis for decisions with legal, material, or significant effects on rights or safety. Anything meeting that test needs oversight designed into the workflow, not a review step bolted on. The tiers we install:

• Internal work product (drafts, summaries, research). The civil servant using the tool is the review. Governance here is only the data rules and the log.
• Citizen-facing content that informs (service answers, published guidance). A named reviewer approves before publication, and the approval is recorded. Wrong information from a government source does harm even when no decision rides on it.
• Outputs feeding decisions about people (eligibility, enforcement, permits). A qualified official makes the decision with AI as one input, records their reasoning, and holds real authority to decide the other way. If the official cannot realistically depart from the recommendation, the oversight is decorative, and a court may eventually say so.
• Everywhere: a manual path that works. In the private sector a fallback is continuity planning. In government it is also the channel for people the automated path fails, so it has to be staffed and real, not a phone number that loops back to the chatbot.

Records: assume every output becomes a public record.

Government work is subject to records law and freedom-of-information regimes, and AI-assisted work is still government work. The operating assumption that keeps you safe: any output, and the trail behind it, may one day be read by an auditor, a tribunal, or a journalist. That sets the logging requirement. For every production workflow, the record has to support reconstruction: this output, on this date, came from these inputs and sources, through this model and version, under this workflow version, and was approved by this person.

Two additions distinguish this from the standard enterprise audit trail. First, retention: AI logs belong in the entity's records schedule with a defined retention class, because a log deleted on your own initiative is indistinguishable from a log deleted to avoid disclosure. Second, the record itself must be readable by a records officer or an auditor, not only by the engineer who built the pipeline. A reconstruction that needs the original developer to interpret it fails at exactly the moment it is needed.

Standing it up, in order.

1. 01:

   Inventory what already runs

   Including the unofficial usage on personal accounts, which every entity has and few admit. An amnesty surfaces more of it than a prohibition does.

2. 02:

   Map the instruments that bind you

   National, state or emirate, and entity-level. This list, not a generic framework, decides your hosting constraints and disclosure duties.

3. 03:

   Extend the data classification with a hosting column

   Each class maps to an allowed deployment pattern, from approved commercial tools down to government-controlled infrastructure. Decided once, inherited by every workflow after.

4. 04:

   Write the disclosure conventions

   When AI involvement is flagged, in what words, and who signs exceptions. One page, decided centrally, before the first citizen-facing system ships.

5. 05:

   Tier the oversight and name the people

   By effect on the citizen, not by how impressive the technology is. Every workflow gets a named reviewer or deciding official, and the high-impact tier gets a working manual path.

6. 06:

   Wire the records in and set the re-review calendar

   Logs into the retention schedule, workflows onto a re-evaluation cadence, model changes treated as a standing category of work. NIST's AI Risk Management Framework (AI RMF 1.0, January 2023, voluntary) is a sound checklist to validate the result against.

Do it yourself, or bring us in.

None of this requires a transformation program. A capable operations lead with real authority can stand up the inventory, the classification extension, the conventions, and the logging in a quarter. The honest failure mode is afterward: the inventory stops matching reality, a model deprecation forces a migration nobody budgeted, re-review dates pass silently, and the framework ends up describing an estate that no longer exists.

That afterward is the part we sell. Under managed AI operations the registers, logs, evaluations, and re-reviews are maintained alongside the systems they govern, inside your rules. If you do not yet know what your estate contains, a fixed-scope audit is the right first contract; it produces the inventory and the risk map everything above builds on.

Frequently asked questions.

Keep reading.