Governed AI for Operators Governance and risk
Risk tiers and approval gates
Not every AI action carries the same weight, and treating them as if they do is how governance fails in both directions. Put a heavy human review on every trivial task and people route around the controls because they are slowing real work down. Put no review on a consequential action and you find out about the problem from a customer or a regulator. The fix is to sort AI use by how much damage a wrong action could do, then match each level of damage to a proportionate gate. That is what risk tiers and approval gates are for.
The goal is not maximum caution. It is calibrated caution: friction where the stakes justify it, and none where they do not. A good tiering scheme lets the low-risk work run fast and reserves human attention for the decisions that actually need it.
Two questions decide the tier
You can place almost any AI action into a tier by answering two questions.
The first is about data sensitivity. What is the AI touching? Public, non-sensitive information sits at the bottom. Internal business data sits in the middle. Regulated or personal data, protected health information, financial records, attorney-client material, anything covered by a law or a contract, sits at the top. The more sensitive the data, the higher the floor on the tier.
The second is about cost of a wrong action. If the AI does the wrong thing here, what does it cost before anyone catches it, and can it be undone? An action that is easy to spot and easy to reverse is low cost. An action that reaches a customer, moves money, alters a record, or makes an assertion someone will rely on is high cost, because by the time you notice, the damage is already outside the building.
Take the higher of the two answers. Sensitive data with a reversible action is still elevated. A cheap action on regulated data is still elevated, because the data alone raises the floor. You are not averaging the two. You let whichever one is more dangerous set the tier.
Three tiers
Three tiers is enough for most organizations. More than that and people cannot remember which is which, which defeats the purpose.
- Low. Non-sensitive data, and a wrong action is cheap and easily reversed. Internal drafting from public information, summarizing a document the model already has access to, suggesting tags on a low-value record. A mistake here is caught quickly and costs little.
- Elevated. Either the data is internal-but-sensitive, or a wrong action would be meaningfully expensive or hard to reverse. Anything that drafts content a customer will eventually see, touches internal financials, or proposes a change to a system of record. A mistake here is recoverable but not free.
- High. Regulated or personal data, or an action whose error is severe, irreversible, or both. Anything that sends an assertion to a regulator, moves money, alters a patient or legal record, or makes a commitment on the company’s behalf. A mistake here can cost a relationship, a penalty, or worse.
The point of naming the tiers is not the labels. It is that each tier maps to a specific, predetermined level of human involvement, so nobody has to improvise that decision in the moment.
Matching gates to tiers
An approval gate is the rule about when a human has to be involved before an AI action takes effect. Three gate types cover the three tiers.
- Auto-allow. The action runs without a human in the loop. The human role is oversight after the fact: sampling outputs, watching the logs, catching drift. This is the right gate for the low tier. If a person had to approve every low-risk action, the AI would save no time and people would disable the controls. Auto-allow is not “no governance.” It is governance by logging and sampling instead of by per-action review.
- Human-in-the-loop review. The AI proposes, a qualified person reviews, and nothing takes effect until that person approves. The model does the slow drafting work; the human keeps the decision. This is the workhorse gate for the elevated tier, and it is where most of your governed AI value will actually live. The draft lands in a queue, not an outbox.
- Hard stop. For the high tier, the AI is not permitted to take the action at all. It can prepare material, surface options, and assemble the inputs, but the action itself stays fully human. A hard stop is not a failure of the system. It is the system correctly refusing to let accountability move to a model on a decision that requires a named person to stand behind it.
Notice the progression. As the stakes climb, the human moves from watching, to approving, to deciding. The model’s role shrinks from actor, to assistant, to researcher. That progression is the whole design.
A concrete tiering example
Take a mid-market firm using AI across its customer operations. Here is how a handful of actions sort.
Drafting an internal summary of a public help article is low, auto-allow. The data is public, and a bad summary is caught and fixed in seconds. Let it run.
Drafting a reply to a routine customer support ticket is elevated, human-in-the-loop. The data is internal and the output will reach a customer, so a person reads the draft before it sends. The AI absorbs the typing; the agent keeps judgment over what the company says to a customer.
Updating a customer’s billing record based on a request is high, hard stop on the write. The AI can read the request, draft the change, and lay it out for confirmation, but it does not write to the billing system itself. A person makes the change, because a wrong write to a financial record is expensive and not always reversible.
Generating an appeal letter that asserts clinical justification to an insurer is high, hard stop on the send. Regulated data and a consequential assertion put this at the top on both axes at once. The model drafts; a qualified specialist reviews, edits, and sends. The send is never automated.
The same model, the same week, sits behind three different gates depending on what it touches and what a mistake would cost. That is calibrated caution working as designed. The tier is a property of the action, not of the tool.
What a good gate looks like in practice
A gate is only real if it cannot be skipped and it leaves a record. A few things separate a gate that works from one that exists only on paper.
- It blocks by default. The action cannot proceed until approval is given. A gate that asks for approval but lets the action through while it waits is not a gate. It is a notification.
- The reviewer is qualified and has the context. The person at the gate can actually judge the output. They see what the model saw, the draft it produced, and enough surrounding information to catch an error. A reviewer rubber-stamping things they cannot evaluate is worse than no gate, because it manufactures false confidence.
- It is fast enough to survive. A gate that adds hours to routine work will be circumvented within a month. Match the weight of the gate to the tier so the elevated-tier reviews are quick and only the high-tier ones carry real ceremony. Friction has to be proportionate or people route around it.
- It is logged. Every approval records what was proposed, what was approved, who approved it, and when. If you cannot reconstruct a gated decision weeks later, the gate gave you a delay without giving you defensibility.
- It fails closed. If the system is unsure which tier an action belongs to, it escalates to the stricter gate rather than the looser one. Ambiguity should cost a little time, never an unreviewed high-risk action.
Set the tiers once, write them down, and wire each one to its gate before you deploy, not after the first incident forces the question. The alternative is deciding how much review a regulated, irreversible action needed at the moment it has already gone wrong, which is the most expensive time to be having that conversation.
You are on the early-access list.
Thanks. You will be first to hear when the full course opens.