Agent Governance for Public Sector and GLCs: A Controls Framework to Set Up Before You Automate

Why agents need controls before they get useful

A division drafts an agent that reads incoming citizen enquiries, tags them and routes them to the right unit. It works in the demo. Six weeks later someone asks who approved the routing rules, which data the agent reads, and what happens when it mislabels a complaint. Nobody can answer cleanly, so the pilot quietly stops.

That pattern is common in public sector and GLC settings, and it rarely comes from bad technology. It comes from deploying an agent before the accountability, inventory and review structure exists. Agents differ from earlier automation because they take sequences of actions — retrieving, deciding, drafting, triggering a downstream step — rather than executing one fixed rule. In an institution that answers to auditors, a parliamentary committee or a ministry, that means the governance has to be designed first.

What follows is a setup sequence: assign owners, build an inventory, tier the risk, set oversight thresholds, prepare procurement questions, and gate the move from pilot to production. It is planning guidance, not legal or regulatory advice. Confirm obligations with your legal, audit and compliance functions.

Who is accountable when an agent acts?

Most agencies can name the project sponsor. Far fewer can name the person accountable for the agent's behaviour in production. Those are different roles, and the second one gets skipped.

Assign three distinct owners before build begins:

• Business owner — a named director-level officer accountable for the outcome the agent supports, and for its accuracy ceiling in their function.
• Technical custodian — the officer or unit responsible for configuration, integration, logging and change control.
• Risk and compliance reviewer — the function that signs off data handling, records retention and human review points.

Write these into a one-page accountability note per agent. If a name is missing, the agent is not ready for pilot.

What belongs in an agent inventory?

The inventory is the single artefact auditors will ask for, and the one most institutions lack. Build it in a spreadsheet before you build the second agent — not after the fifth.

Minimum fields per entry:

1. Agent name, purpose and the process it touches
2. Business owner, technical custodian, risk reviewer
3. Systems and datasets the agent can read or write
4. Whether it takes action or only drafts (a hard distinction)
5. Data classification of everything in scope
6. Risk tier and oversight level
7. Approval date, review date, current status (pilot, live, paused, retired)

Keep the inventory maintained by one named function — usually a digital or transformation office — and review it monthly. An inventory that is updated once and forgotten gives false comfort.

How should you tier agents by decision impact?

Not every agent deserves the same scrutiny. Tiering keeps review proportionate and stops the governance process from becoming the reason pilots stall. A four-band model works well in institutional settings:

Tier	Typical agent	Decision impact	Minimum oversight
1	Drafting assistance — summarising meeting notes, drafting first-cut responses	None; human sends	Human review of every output
2	Retrieval and recommendation — SOP lookup, policy Q&A, file triage suggestions	Advisory; human decides	Sampled review plus escalation path
3	Action-taking in internal workflows — routing approvals, generating notifications, updating case records	Affects internal process	Named approver, logging, rollback plan
4	Citizen-facing or financially material — eligibility pre-checks, public-facing responses, payments-adjacent steps	Affects external parties or funds	Documented approval, audit trail, human sign-off gate

Tier 4 arrangements in particular need your legal and audit functions involved, because the obligations that attach will depend on your institution and the data involved.

Where should human oversight thresholds sit?

The useful question is not "does a human review this?" but "what specifically triggers mandatory escalation?" Define thresholds by consequence, not by convenience.

Practical thresholds to formalise:

• Confidence or completeness — the agent must escalate when source material is missing or contradictory.
• Value — any action above a defined monetary or entitlement threshold requires human approval.
• Sensitivity — requests involving sensitive personal data, complaints, appeals or legal matters route to a person by default.
• Sentiment and escalation risk — public-facing agents route complainants and repeated contacts to staff.
• Novelty — cases that do not match known categories go to a human, not a best guess.

The technical counterpart matters: an agent should log the inputs, the action taken and the escalation reason for every case. Without that, oversight is a claim rather than a control.

What should you ask vendors and integrators?

Procurement is where governance quietly gets outsourced. Ask these before signing, and get the answers in writing. For the wider tender structure, the AI procurement tender spec framework for Malaysia covers clause-level detail.

• Can we see the full audit log, and can we export it to our own records system?
• Where does data reside, and what is retained after the engagement ends?
• What are the escalation and override controls, and who can change them post-deployment?
• How are model or configuration changes notified to us?
• What happens at contract exit — can the agent and its knowledge base be removed cleanly?
• Who is liable for an incorrect action, and under what terms?

If a vendor cannot answer the audit-log and exit questions, that is a governance signal regardless of how good the demo looked.

How do you move from pilot to production?

Use explicit gates. Each gate has an owner, a set of evidence and a decision — and a failed gate returns the pilot to the team rather than escalating it anyway.

• Gate 1 — Scope: accountability note signed, inventory entry created, data classification documented.
• Gate 2 — Pilot: tier assigned, oversight thresholds defined, logging live, escalation path tested with real cases.
• Gate 3 — Limited deployment: defined user group, measured performance over a fixed period, review of every escalation, incident log reviewed by the risk function.
• Gate 4 — Scaled deployment: change control and periodic review scheduled, staff trained on override and reporting, retirement criteria agreed.

The gate model is also the cheapest way to keep momentum. Teams know what evidence closes a gate, so approvals stop depending on who happens to be in the room.

Two supporting capabilities make the gates hold: staff who understand agent behaviour well enough to override it, and a way to identify which processes are worth automating in the first place. Role-based AI agents training helps officers read agent output critically, and a structured AI innovation bootcamp is a practical way to audit workflows before committing to build. For a broader view of where agents fit, see the guide to AI agents for business.

AIHQ has worked with public sector bodies, GLCs, regulated organisations and professional institutions, and has trained and engaged over 9,000 professionals. Where an agency needs something beyond off-the-shelf tools, custom AI solutions can be scoped with governance built in rather than bolted on. For teams building internal governance capability, a responsible AI and governance workshop is a practical starting point.

What are the most common setup mistakes?

Five recur often enough to plan against:

• Governance arrives after the pilot succeeds. Then it looks like an obstacle rather than a design input.
• One policy document covers every agent. Tiering is skipped, so low-risk drafting tools get buried in Tier 4 review and stall.
• No owner for the inventory. It decays within a quarter.
• Oversight is assumed, not logged. Nobody can demonstrate review happened.
• Pilots scale by default. Without a gate, a successful demo becomes a live process by attrition.

None of these are technology problems. All of them are addressable in the first two weeks of a programme, which is why the setup order matters more than the tool choice.