Just Because AI Can, Should It?

Picture an agent being demoed to an account team. It notices a customer relationship is slipping, pulls together the evidence, recommends a response, and drafts a message for the account leader. It can also create a follow-up task and send the message on its own. Because every step works, the last one starts to feel like the natural conclusion of everything before it.

But those steps aren’t really the same decision. Flagging a concern is different from deciding how the company should respond. Drafting a message is different from sending it on someone else’s behalf. The technology moves smoothly from one to the next. The authority to act doesn’t.

The first article in this series asked which work actually deserves to change. Once that’s clear, the next question is how far you let intelligent participation go. A simple yes-or-no policy on AI can’t answer that. The organization has to spell out what the system is allowed to do in this specific piece of work, under what conditions, and under whose authority.

Authority is a continuum, not a switch

An intelligent system can participate in work in a lot of different ways. It can read information, reason across it, recommend a response, prepare an action, kick off a process, or execute an outcome within set boundaries. Those distinctions aren’t just semantics. Each one changes the relationship between what the system is contributing and what the organization has actually handed over to it.

Go back to the customer example. Spotting the deteriorating sentiment is analysis. Recommending that the account leader step in adds a proposed response. Drafting the message is preparation. Creating the follow-up task initiates a process. Sending the communication executes an external action. The same model and the same information can support every one of those steps, but that doesn’t mean they should all live under one permission.

An agent doesn’t need the same authority for every part of the work, either. It might be allowed to update an internal record automatically but still need approval before it contacts a customer. It might execute a routine transaction within a defined tolerance, but only recommend a course of action when something looks unusual. A single label like “autonomous” or “human-controlled” isn’t actually useful here. What works is an explicit boundary around each form of participation, one shaped by the user, the circumstances and the consequence.

The boundary follows consequence

How much authority is appropriate has less to do with how impressive the technology looks and more to do with what happens when it’s wrong. A weak internal summary wastes a few minutes. An incorrect payroll action, a bad employment recommendation, or an ill-advised message to a customer creates a very different kind of problem. Similar technology doesn’t mean similar permission.

The design needs to account for how bad a mistake could be, how easily it can be undone, who it could affect, and how quickly anyone would even notice. Ambiguity and the quality of the underlying information matter too. A capability that performs well under normal conditions might deserve a tighter boundary once the evidence gets thin or the circumstances turn unusual.

Scale and speed change the math too. A system can be right almost all the time and still create real exposure if it’s acting thousands of times before anyone catches the exceptions. None of this calls for some elaborate autonomy score for every use case. It calls for proportionate authority: more freedom where the consequences are limited and well understood, tighter boundaries where mistakes are costly, hard to undo, or hard to even spot.

Inference is also a form of authority

Part of that boundary matters before the system ever takes an action. Conventional access controls are mostly built around information that’s already on record: who can view a worker’s file, a compensation field, a customer account, a transaction. AI can take permitted information and combine it into a conclusion that was never stored anywhere to begin with. Just because there’s no record of it doesn’t make that conclusion harmless.

A manager might be authorized to see several pieces of employee data, even though the organization has never actually decided whether that manager should get an AI-generated read on whether someone looks underpaid compared to their peers. A system might infer elevated flight risk just from tenure, manager changes, career progression and engagement patterns, even though no field called “retention risk” exists anywhere in the source systems.

That kind of inference can end up more sensitive than any single input that fed into it. It might also rest on the wrong comparison group, missing context, or assumptions the recipient never sees. Before that conclusion ever surfaces, the organization needs to decide who should actually receive it, how to present the uncertainty around it, whether it gets stored, how long it sticks around, and what it’s allowed to trigger.

Human review has to add judgment, not just presence

When authority feels uncertain, the default answer is often to keep a human “in the loop.” That can work. But the phrase really just describes a spot in a workflow, not the quality of judgment actually happening there. Someone can be fully present and still barely contribute to the decision.

Picture a system recommending approval on hundreds of routine transactions. The reviewer sees the same recommendation over and over, has no extra information to go on, and rarely runs into an actual error. Attention drifts. Eventually, review becomes rubber-stamping. The organization keeps the approval step but loses the challenge that was supposed to make that step worth having.

The opposite extreme doesn’t work any better. Requiring approval for every single AI-assisted action can pile on so much delay and coordination that the capability barely changes anything about the work. Stacking more people between the intelligence and the outcome doesn’t automatically improve control. Human involvement needs to add something specific: context, real judgment, the ability to push back on an assumption, or accountability for a trade-off the organization hasn’t handed over.

That contribution has to be designed on purpose. The reviewer needs to know what to look for, have the evidence to actually look at it, and have the time and standing to disagree, escalate, or stop the action outright. Depending on the stakes, that might mean approval before anything happens, review of exceptions only, monitoring after the fact, or periodic sampling. These are genuinely different forms of control. They’re not interchangeable ways of saying “a human was involved.”

Control can concentrate on the exceptions

A lot of enterprise processes maintain control simply by routing every transaction through the same set of reviews. Requisitions, invoices, compensation changes, customer updates, they all follow an established path, mostly because a common route is easier to define than a judgment call about which cases actually deserve attention. AI opens up a chance to rethink where some of that attention should go.

Where a capability can reliably validate normal conditions, apply policy, and spot anomalies, routine work can move forward within clear boundaries while the unusual, ambiguous, or consequential cases get routed to people. That’s not removing control. It’s reallocating it, with a clearer reason for the human to be there. It still depends on real evidence that the system can tell ordinary cases apart from ones that need a person.

That changes the human role, too. Once the easy cases stop reaching the reviewer, what’s left isn’t necessarily smaller. It’s harder. Exception handling needs to be treated as skilled work, with real context and real decision authority, not just whatever the machine didn’t want. How people build that judgment is a capability question. Making sure that judgment actually has a place in the work is an authority decision.

Authority can be earned and withdrawn

Delegation doesn’t have to be locked in at launch. A capability can start out just making recommendations while people review the evidence and log where they disagree. Later, it might prepare actions for approval, initiate routine cases, or execute select activity within set limits. How far it progresses should depend on what the organization actually learns, not on some assumed endpoint of full autonomy.

The evidence needed here goes beyond overall accuracy. Leaders need to know where the capability is genuinely reliable, how it behaves with incomplete information, whether it recognizes when something’s off, and which failure modes show up in everyday use. They also need to know whether more authority would actually improve the work. Cutting an approval step isn’t progress if that approval was supplying judgment the system still doesn’t have.

Authority also has to be able to move backward. A source gets less reliable, a model changes, a permission gets broadened, or the capability starts handling work outside the conditions it was originally tested on. Pulling back its authority in response isn’t an admission that AI failed. It’s just responsible delegation in an environment that keeps changing. The organization should be able to dial back participation without throwing out the useful parts of the capability altogether.

Machine participation makes ownership more important

Language can quietly let accountability slip away. “The system decided,” “the agent recommended it,” “the AI sent it,” these all describe what happened technically without saying who actually owns the outcome. As work gets split between people and machines, that question gets more important, not less.

If an AI-supported hiring process spits out a bad recommendation, the hiring process still needs an owner. If an agent misses an important customer signal, that customer relationship doesn’t suddenly belong to no one. Even when a system behaves exactly as it was configured to, someone is still responsible for that decision architecture and the authority it operates under.

That doesn’t mean pinning every technical failure on one person. It means being able to point to the business owner, the technical steward, the people who can actually change the authority boundary, and whoever is expected to respond when the design falls short. The model can’t hold organizational accountability. Only the organization can, and it needs to make ownership explicit enough to survive work that keeps getting more distributed.

Authority needs an organizational context

A boundary only works if it can actually be applied to the situation in front of it. The system needs to know who’s asking, what role they hold, how they relate to the people or transactions involved, and what decisions they’re entitled to make. The exact same request might be perfectly appropriate for a compensation specialist and completely inappropriate for a manager, even if both of them can technically access some of the same information.

Enterprise platforms already hold most of the context needed to make those calls: identity, organizational relationships, roles, security, effective dates, business process. The agent should follow that structure, not flatten it just because the technology happens to be able to connect across systems. Permission to participate has to stay tied to the organization’s real relationships and decision rights.

This also shows the limit of what an authority policy can do on its own. The organization can spell out what an intelligent system is allowed to do, but the system still needs dependable context to know when that permission actually applies. Allow sets the boundary. Anchor, the next decision in this series, builds the organizational understanding needed to apply it.

The objective is appropriate authority

Before an intelligent capability gets any real authority, leadership should be able to explain what it’s permitted to do, what consequences set the limits, and what judgment people are still expected to bring. It should also be clear what evidence would justify expanding or pulling back that authority, and who owns the work that results. Those are operating decisions. They’re not just a list of a model’s features.

Both extremes miss the point. One wraps every AI-assisted action in so much review that it preserves most of the original effort and delay anyway. The other treats technical capability as if it were permission and lets the system operate more broadly than the organization actually knows how to govern. A better design gives routine, well-understood work real freedom, and concentrates human attention where consequence, uncertainty and judgment actually require it.

The goal was never maximum autonomy or maximum control. It’s the right amount of authority for the work at hand, backed by evidence and tied to visible accountability. An intelligent system should have enough room to actually improve the outcome, without letting responsibility for that outcome quietly disappear into the technology.