The AI
Authority Ladder

AI is not one thing.

People often describe AI as if it has a single setting: on or off, trusted or not, safe or risky, pilot or production. In reality, AI interacts with work along a spectrum of roles — and each role requires different expectations and controls.

Sometimes AI is simply helping someone work faster. It summarizes a case, drafts a response, finds a policy, or pulls key points from a document. A person is still clearly in charge.

Sometimes AI recommends something. It suggests a next step, a risk rating, a routing path, or a response. A person still decides, but AI is beginning to influence that decision.

Sometimes AI makes the decision. It classifies a request, prioritizes work, determines eligibility, or approves something within defined boundaries.

And sometimes AI acts. It creates a record, updates a system, sends a communication, triggers a workflow, or starts a downstream process.

Those are very different relationships between AI and the enterprise. Yet we often govern all of them under one broad heading: AI.

The question isn't only: What can AI do?
We also need to ask: What should AI be allowed to do?

Capability and authority are not the same thing.

Organizations spend a lot of time evaluating AI capability. Can the technology summarize this information? Determine the next best action? Make this decision? Execute this transaction?

Those are necessary questions, but technical capability shouldn't automatically become organizational permission.

An AI system may technically be capable of issuing a refund, modifying a customer record, approving an exception, changing infrastructure, communicating with another system, or initiating a purchase. That doesn't mean it should have the authority to do those things.

The architecture conversation should be asking: What authority are we willing to delegate to AI?

Introducing the AI Authority Ladder

Over the past several years, I've watched the AI conversation shift quickly. We started by asking what AI could do. Now organizations are beginning to face a harder question: what should we allow it to do?

That distinction led me to create the AI Authority Ladder — a simple framework for describing the authority an organization delegates to AI.

Assist. Recommend. Decide. Act.

The framework is intentionally simple. The goal isn't to create another complicated AI taxonomy. It's to give business, technology, architecture, risk, and governance teams a common language for making better decisions about AI authority.

The Ladder is not a maturity model.

The goal isn't to move every AI use case up the Ladder. More authority doesn't automatically mean a better or more mature solution.

Some use cases may always belong at Assist, and that may be exactly where they create the most value. Others may be ready to Recommend but not Decide. And for the right kind of work — narrow, low-risk, well understood, and easy to reverse — Act may make perfect sense.

There is no prize for reaching the top. The point is to choose the level of authority that makes sense for the work.

Authority changes the architecture.

As authority increases, several parts of the architecture conversation change with it.

Risk changes as authority increases.

Not every Assist use case is low-risk, and not every Act use case is dangerous. Context matters. But the nature of the risk changes. At Assist, the concern often centers on whether a person can verify the output. At Recommend, influence becomes important. At Decide, accountability becomes more significant. At Act, impact becomes central.

The controls should match the authority.

Data readiness changes too.

AI authority and data readiness belong in the same conversation. A use case may be ready for AI without being ready for the authority people want to give it.

AI may be ready to summarize supplier documentation but not approve supplier risk. It may be ready to recommend case routing but not close customer cases automatically. It may be ready to explain policy but not determine employee eligibility.

A use case can be ready for AI without being ready for the authority people want to give it.

Explainability matters more as authority increases.

People don't need to understand every technical detail behind an AI model, but they need enough information to trust, challenge, and govern what it is doing. As authority increases, “the AI did it” becomes a less acceptable answer.

Authority has to be designed into the work.

Organizations frequently respond to AI risk by saying, “We'll keep a human in the loop.” It sounds reassuring, but it doesn't tell us much about what that person is actually expected to do.

A human can technically be in the loop while providing almost no meaningful oversight. Someone clicking Approve hundreds of times a day without enough information or time to evaluate the recommendation isn't really exercising judgment. They've become a rubber stamp.

The more useful question is: Where does human judgment actually matter?

At Assist, that may mean reviewing and editing AI-generated work. At Recommend, the person needs to evaluate the recommendation, make the final choice, and override it when necessary. Once AI begins to Decide, human involvement may shift toward exceptions or higher-impact decisions. At Act, people may approve sensitive actions, monitor outcomes, or intervene when AI reaches a boundary.

“Human in the loop” isn't really a control design. We have to design the loop.

The same is true for governance. AI controls shouldn't live only in a policy document or governance meeting; they need to show up in the way the work actually happens. Source visibility, thresholds, approvals, exceptions, permissions, logging, monitoring, and the ability to reverse an action all become part of the workflow as AI gains authority.

AI governance cannot just be a meeting. It has to become design.

Start with the problem, not the AI.

The Authority Ladder helps determine the right level of authority when AI is the right solution. It doesn't mean AI is always the right solution.

Sometimes a clearer form solves the problem. Sometimes it's better integration, a business rule, cleaner data, a simpler policy, or removing an unnecessary step altogether.

Consider a customer service organization that wants to “use AI to improve case resolution.” At first, that sounds like a single AI use case. Through the Ladder, it becomes several very different possibilities.

The business outcome hasn't changed. The technology may even be the same. What changes is the authority we've given it — and that creates four very different architecture, risk, and governance conversations.

More authority should be earned.

There will be cases where moving up the Ladder makes sense. But that decision should be based on what we've learned, not simply on what the technology is capable of doing next.

If those foundations aren't there yet, the answer isn't necessarily to abandon the use case. It may simply mean this is the right place on the Ladder for now.

There is nothing wrong with staying at Assist or Recommend when that is where the use case creates the most value with an acceptable level of risk. Moving up should happen because the evidence supports giving AI more authority — not because Act is somehow the destination.

Don't ask whether AI can move up the Ladder. Ask what would need to be true before it should.