Autonomy Levels A1–A5

Definition. Autonomy levels describe what an AI system is allowed to do for a specified decision: propose, prepare, or act under defined conditions.

An AI system might produce a convincing answer while lacking the information or authority to act on it. The A1–A5 scale makes that distinction visible. Assign a level to a decision type and its operating conditions, rather than giving a whole process one label. Routine requests and unusual exceptions can have different levels.

The five levels

These are descriptions of authority, not scores for model quality. A5 is not a target every team should pursue. In many processes, individual approval or ongoing monitoring remains appropriate.

Consider an internal support queue. At A1, the system suggests a category and an employee routes the ticket. At A2, it prepares a response, which an employee checks before sending. At A3, it prepares routine responses for a batch review while unusual requests go to a person. At A4, it may route clearly defined tickets itself while people monitor mistakes and can pause routing. The same tool could operate at different levels for different ticket types.

How to choose a level

Start with the consequence of a wrong decision. Ask whether the error can be detected quickly, whether it can be reversed, and who bears the cost. Define what information the system needs, which actions are forbidden, and which cases must go to a person. The Rulebook should make those boundaries explicit; critical limits also need enforcement in the workflow or execution system.

Name a process owner who can grant or withdraw permission. Include security, privacy, compliance or other control functions where the decision calls for them. Record the permitted decision types, limits, escalation path, monitoring and stop procedure. A label such as “A3” is not a substitute for these details.

Measure performance on cases that resemble live work, including exceptions. A Dual Run can compare proposed AI decisions with decisions made under the current process without letting the new system act. Review disagreements and outcomes, then decide whether the evidence supports changing the approval arrangement. Passing a test or reaching a date does not automatically grant authority.

Where teams lose control

Approval becomes a formality. If a person clicks approve without checking, an A2 process has less oversight than its label suggests. Make the review task realistic and inspect whether reviewers catch errors. If approval is no longer useful, redesign the control deliberately rather than pretending it still works.

One level covers every case. Routine work, complaints and exceptions may have different consequences. Define the boundaries that separate them and route ambiguous cases to a person.

Nobody owns the permission. Engineers can test what a system can do, but the process owner decides what it may do within the organisation's controls. Without that decision, the system can acquire authority by default as people come to rely on it.

The right level is the one the team can justify and operate safely for the decision at hand. It can move up, move down or stay where it is as evidence and circumstances change.