AI Governance in Practice: A Tiered Model

AI governance in practice comes down to three things. A way to sort agents by risk. A short form that tells you which bucket an agent belongs in. A named person who approves each bucket.

Everything else is detail. If a team has to wait six weeks for a committee to say “looks fine,” they will skip you. That is how you end up with shadow AI and a policy nobody reads.

This post is the working model I’d use. It builds on the argument in the AI governance gap and turns it into forms, tiers, and dates.

Governance that blocks versus governance that ships

Most governance programs fail in one of two ways.

The document. A policy PDF, a training video, no mechanism. Surveys suggest this is common. In a 2025 Pacific AI survey of 351 practitioners, 75% of organizations had AI usage policies. Only 54% had an AI incident response playbook, and 59% had a role or office for AI governance. It is a small, vendor-run survey, so treat the numbers as directional. The shape is the point: policy first, operations later.

The gate. One review board, one queue, one standard for everything. A read-only summarizer gets the same scrutiny as an agent that issues refunds. The queue grows. Teams route around it.

Governance that ships has one property: the amount of review matches the amount of damage the agent can do. NIST makes the same point in its AI RMF playbook. Organizations typically give higher-risk systems a larger share of risk management resources and lower-risk systems less.

The stakes are not abstract. IBM’s 2025 breach report found 13% of organizations had reported breaches of AI models or applications. Of those, 97% said they lacked proper AI access controls. The missing piece was basic control, not exotic defense.

Three risk tiers

Sort by what the agent can do, not by which model it uses. Three questions decide the tier:

What data does it touch?
What actions can it take?
Can you undo those actions?

This lines up with where OWASP puts the root causes of excessive agency: excessive functionality, excessive permissions, and excessive autonomy. Those are the three dials you are checking.

	Tier 1: Low	Tier 2: Medium	Tier 3: High
Data	Public or non-sensitive internal	Confidential internal, some customer data	Regulated, financial, health, employee or credit data
Actions	Read, summarize, draft for a human	Writes to internal systems, creates tickets, updates records	Moves money, sends external messages, changes access, deletes
Reversible?	Yes, trivially	Yes, with effort	No, or only at real cost
Autonomy	Suggests only	Acts, a human reviews after	Acts only after human approval, or decisions about people
Example	Meeting summarizer for one team	Agent that updates CRM fields from emails	Agent that approves refunds or posts payments

One rule keeps this honest: the highest answer wins. If an agent reads only public data but can send email to customers, the action answer makes it Tier 3.

The tiers are close cousins of the risk levels in the EU AI Act, which sorts systems into unacceptable, high, limited, and minimal risk. If you operate in the EU, your Tier 3 should include anything that could land in the Act’s high-risk categories, such as employment or essential services. Those carry duties like risk assessment, logging, documentation, and human oversight. Check with counsel for your case. I’m not a lawyer.

Rules for moving between tiers

An agent can move up at any time. A new tool, a new data source, or a switch from “suggest” to “act” re-tiers it.
An agent moves down only after a review and a clean run. Never by request alone.
If nobody can answer a question on the form, assign the higher tier until someone can.

The one-page intake form

If the form is longer than one page, teams will fill it in badly or not at all. Cut anything you will not act on.

Here is the template.

1. Identity

Name of the agent and the workflow it supports
Business owner (a named person, not a team)
Technical owner

2. Purpose and metric

What problem does it solve?
What number will tell you it works? (One metric.)

3. Data

Which systems and data classes can it read?
Which can it write to?
Where does data go when the model runs? (Which vendor, which region, any retention.)

4. Actions

List every tool or action it can call.
For each: read or write? Reversible?
Can it send anything outside the company?

5. Autonomy

Suggests, drafts, acts with approval, or acts alone?
Which actions need a human click first?

6. Worst case

In one sentence, what is the worst thing it could do on a bad day?
Who would notice, and how fast?

7. Evidence

How was it tested? Attach the test set and results.
Where do logs go?
Who can turn it off, and how?

8. Review date

When does the owner re-attest?

Questions 3, 4, and 5 compute the tier. The rest is context for the approver. If you use a ticketing tool, build the form there and let the tier calculate itself from the answers. That removes a whole class of argument.

For question 4 and 7, tie your answers to the controls in least-privilege permissions for agents. The form is where those controls get declared, so the approver has something concrete to check.

Approvers per tier

The question I get most is “who approves what?” Here is my recommendation. The service levels are my suggestion, not a standard. Adjust them to your org.

Tier	Approver	Also involved	Target turnaround
1: Low	The business owner, self-serve against a checklist	Security gets a copy of the form	Same day
2: Medium	Business owner plus one security reviewer	Data owner of any system it touches	2 business days
3: High	A named executive sponsor plus security	Legal or compliance, and the process owner	Up to 10 business days

A few rules make this work:

Tier 1 is self-serve. If the owner can confirm “read-only, non-sensitive, nothing leaves the company,” they approve their own form. Security audits a sample later.
Tier 2 needs one reviewer, not a committee. One person with a checklist and a deadline. If they miss the deadline, escalate to their manager. Do not let silence block the team.
Tier 3 gets a real review. Test evidence, a human approval step on consequential actions, a tested way to shut it off, and a named sponsor who owns the outcome.
The sponsor signs, not the committee. Committees diffuse blame. A named person owns the decision.

This lines up with what Singapore’s regulator published for agents in January 2026. Its Model AI Governance Framework for Agentic AI says to bound risk upfront by limiting agents’ autonomy and access to tools and data. It also says to define checkpoints where human approval is required. That is the tier table in regulator language.

Review cadence and evidence

The common mistake is a heavy review at launch and nothing after. Agents, prompts, and models change. A tier set in April may be wrong by August.

Use quality gates over audits wherever you can.

A quality gate is a check that runs before something ships or changes. Did the test set pass? Did the permission list change? Are logs turned on? A gate is automatic and fast. It blocks a bad release before it exists.
An audit is a look back. Someone samples what happened and checks it against the rule. It finds problems after the fact.

You need both, but gates carry most of the load. They scale. Audits do not.

Tier	Gates at release and change	Ongoing review
1	Intake form complete, owner named	Owner re-attests once a year
2	Above, plus test set passed, permission diff reviewed	Quarterly check of logs and incidents
3	Above, plus sponsor sign-off, shutoff tested, approval step verified	Monthly for the first 90 days, then quarterly

Any of these re-opens the review:

A new tool or write permission
A new data source
A model or vendor change
A move from “suggest” to “act”
An incident

Tie each re-review to evidence, not a meeting: test results, log samples, and the incident list.

What to log and keep

Keep what you would need to answer one question: “Why did the agent do that, and who said it could?”

For each agent, keep:

The completed intake form, with the tier and the approver’s name and date
The model and vendor, and the version where you can get it
The prompt and configuration versions, with change dates
The tool and permission list at each point in time
Test results from each release
Human approval records for Tier 3 actions
Incident reports and what changed afterward
Re-attestation records

Each run of the agent should also log what it was asked, which tools it called, and what it returned. Keep those logs long enough to cover your regulatory and contractual needs. Ask your counsel for the number. I’d rather you hear it from them than guess.

Rolling it out in 30 days

Days 1 to 5: Pick the owner and publish the tiers. One person owns the process. Put the three-tier table, the form, and the approver list on one internal page. Announce an amnesty: anyone running an agent today can file a form now without penalty.

Days 6 to 12: Build the inventory. Ask every team lead to list agents and AI automations in use. Check expense reports and SSO logs for tools nobody mentioned. Expect the list to be longer than anyone guessed.

Days 13 to 20: Tier what already exists. This is the answer to “how do I handle agents already in use?” Do not shut everything down. Tier them. Run Tier 3 first, because that is where the risk lives. Give owners 30 days to file a form. Anything with no owner after that gets paused until someone claims it.

Days 21 to 30: Run the real process on new requests. Pick two or three new agents and push them through the form, the tier, and the approval. Time every step. Fix the slow one.

Then measure two numbers: the median days from request to approval by tier, and the share of known agents with a current form. If Tier 1 takes more than a day, your process is too heavy.

How to keep governance from slowing everything down

Pre-approve patterns. If a read-only summarizer pattern passed once, the next one reuses it.
Set a turnaround time and enforce it on the reviewers, not just the requesters.
Put the heaviest review where the damage is. For a Tier 3 case with agent attack surface, see the enterprise AI security checklist. For a worked example of the risks a powerful, loosely bounded agent brings, read OpenClaw security risks.

Bottom Line

Three tiers. One form. A named approver for each tier.

Tier by what the agent can do, and let the highest answer win. Make Tier 1 self-serve, and put real review only on Tier 3.

Start this week: publish the table, announce the amnesty, and tier the agents you already have.

FAQ

How do you operationalize AI governance? Turn policy into a process people can finish. Sort agents into three risk tiers, collect a one-page intake form, route each tier to a named approver, and re-review on a schedule. Add quality gates so checks run automatically at release and on change.

What goes on an AI intake form? Owner, purpose and one success metric, data read and written, every tool the agent can call, autonomy level, worst-case failure, test evidence, logging, who can shut it off, and a review date. Keep it to one page. The data, action, and autonomy answers set the tier.

Who approves what? Tier 1 is approved by the business owner against a checklist. Tier 2 needs the owner plus one security reviewer. Tier 3 needs a named executive sponsor, security, and legal or compliance. These are my suggested defaults. Change them to fit your org chart.

How do I keep governance from slowing everything down? Match review to risk, pre-approve common patterns, calculate the tier from the form, and set turnaround times that bind the reviewers. Track median approval time by tier. If Tier 1 takes more than a day, simplify.

How do I handle agents already in use? Run an amnesty, build an inventory, and tier what you find, starting with Tier 3. Give owners 30 days to file a form. Pause anything that still has no owner. Do not start by banning tools, because that drives usage underground.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect

AI Governance in Practice: A Tiered Model That Ships