Companies often treat AI autonomy as a setting.
The system can act, or it can’t. Leadership decides how aggressive it wants to be, Legal adds restrictions, and the technology team configures the permissions.
I don’t think autonomy should be a general position a company takes on AI. It should be a conclusion reached about a specific piece of work.
A system should receive more responsibility only after it proves that it can perform a defined task, using trusted information, under known conditions, with acceptable consequences when something goes wrong.
AI should earn autonomy one workflow at a time.
Trust depends on the work
Asking whether someone trusts AI doesn’t tell you very much.
The same person may be comfortable using AI to summarize a meeting but unwilling to let it issue a refund. They may trust it to find a discrepancy in a contract while still expecting Finance to decide what to do about it.
There’s nothing inconsistent about that. Trust depends on the task, the information available, the cost of an error, and the controls surrounding the system.
The more useful question is: Do we trust this system to perform this task, with this information, under these conditions?
That question gives us something we can test.
Start where mistakes are easy to catch
Suppose an employee spends two hours preparing the same analysis every week.
I wouldn’t begin by handing the work over to AI. I’d let the system produce the analysis independently while the employee continues with the existing process. Then I’d compare the results.
Did the system retrieve the right information? Where did it make assumptions? How did it handle missing data? Did it recognize an unusual case? What did the employee have to correct?
Most importantly, would a mistake have been easy to notice and reverse?
If the system performs badly, that’s useful information. It may expose a problem with the instructions, the underlying data, or the assumption that the work was predictable in the first place.
If it performs well, the next step might be letting it prepare the analysis while the employee reviews the entire result. Over time, the company can track corrections, failures, time saved, and the conditions that tend to produce reliable work.
The system begins as an assistant. Its responsibility expands only when the evidence supports it.
Move responsibility in stages
In practice, I think about autonomy as four levels.
At the first level, the work stays entirely human. The information may be too sensitive, the judgment may be difficult to define, or the cost of a mistake may simply be too high.
At the second level, AI assists. It retrieves information, summarizes, drafts, classifies, or recommends. A person still makes the decision and takes the action.
At the third level, AI performs more of the workflow while people supervise it. A person may approve important actions before they happen, review uncertain cases, or monitor performance while the system handles routine work.
At the final level, the system operates on its own within narrow, defined boundaries. Exceptions still have somewhere to go. Performance is still monitored. A person is still accountable for the outcome.
Not every workflow should reach that final level. Some work will always require human judgment. Some actions are too difficult to reverse. In other cases, the volume of unusual situations may make supervision more useful than full automation.
The point is to assign the right amount of responsibility to each part of the work.
Automate the cases you understand
A contract-reconciliation workflow offers a useful example.
In one company, 89% of contracts reconciled automatically end to end. Work that had taken about a week of manual reconciliation became a much smaller exercise in reviewing exceptions.
That result didn’t prove that AI could handle contracts. It proved something narrower and more useful: the system could resolve a defined set of cases when the required information was present and the records met known conditions.
Those trusted cases could move through the workflow with far less manual review. Contracts with missing information, unusual terms, conflicting records, or decisions requiring judgment stayed with Finance.
Requiring someone to review every clean match would have spent valuable expertise on predictable work. Allowing the system to resolve every contract would have ignored the difference between a routine match and an uncertain decision.
The right boundary became visible because the workflow was tested case by case.
Define the boundary before granting authority
A system can’t earn autonomy if nobody has defined what good performance looks like.
Before increasing its responsibility, the business needs to know which information is authoritative, which rules apply, what outcome is expected, and which failures are acceptable.
Permissions should follow the same logic. A tool allowed to draft a customer response doesn’t automatically need permission to send it. A system that identifies a billing discrepancy may not need the authority to change an invoice.
Reversibility matters too.
A poorly routed internal request may be easy to correct. An incorrect payment, customer message, contract decision, or account restriction may be much harder to undo. The harder an action is to reverse, the stronger the evidence and controls should be before the system can take it alone.
This means a single workflow may contain several levels of autonomy.
A customer-support system might classify common requests automatically, retrieve account history without approval, draft a response for an employee, and require explicit authorization before changing an account. A few high-volume cases may eventually become reliable enough for automatic resolution. Sensitive, incomplete, or unusual cases can continue to go to a person.
That’s more precise than deciding whether the entire support operation is autonomous. It also allows the company to expand responsibility where performance is strong without granting broader authority everywhere else.
Keep a person accountable
Autonomy doesn’t remove ownership.
Someone still needs to define the boundaries, monitor performance, investigate failures, maintain the information the system relies on, and decide whether its responsibility should change.
That change can go in either direction.
If the data shifts, performance declines, or the workflow begins encountering new conditions, the system may need closer review again. Reducing autonomy in response to new evidence isn’t a failed AI strategy. It’s responsible operations.
A system shouldn’t be allowed to act because the model is impressive or because the company wants to move quickly. It should be allowed to act because it has demonstrated reliable performance in the specific part of the workflow where that authority will be used.
Choose the work. Define the boundary. Test the system under controlled conditions. Keep people responsible while the evidence develops.
Then let the system earn more responsibility, one well-understood step at a time.