The Boundary Between Automation and Autonomy

In most organizations, responsibility for AI has two dimensions that rarely meet in one place.

The first is formal. Someone is listed in a register as the system owner. The field exists and is usually filled. From time to time, however, the person whose name appears there learns about this role only during an audit.

The second dimension is decisional. When a system makes a decision the organization did not intend, someone must be accountable for that decision. At that moment, people in the room usually look at one another.

These are two dimensions of the same issue. The register field organizes the first. The second waits elsewhere.

The field is the starting point

Assigning an owner in the system record does one important thing: the question who is responsible has an answer in one place. In the record itself, not in emails, last year’s presentations, or reconstructed conversations with a former project manager.

That matters. Many organizations have not reached this step yet.

But the field only organizes the inventory layer. It shows who is listed as the owner. Silence remains around the question of what that owner is actually responsible for.

And it is in that silence that risk takes shape.

Which AI Are You Already Using?

What must be assigned

Responsibility for an AI system is different from responsibility for its existence. It is responsibility for the scope of decisions the system makes on behalf of the organization. 

A system classifies requests, recommends prices, and decides which cases to escalate. Each of these decisions has a scope: boundaries within which the system acts independently, and points where it should stop and wait for a human. 

Someone must approve those boundaries. That person is the owner. 

What happens when this layer is missing

At first, everything looks fine.

Systems operate within the scope defined at the project stage. Incidents do not occur, so no one asks questions. The owner field is filled, and the auditor checks the box.

Over time, the scope shifts. Models are retrained, policies evolve, and new cases enter production through operational channels. The system covers an increasingly broad decision space, at a pace no one consciously approved.

This becomes most visible during an incident.

The question arises: who authorized the decision scope in which the system acted? The answer usually leads back to the project stage. The person listed as the owner today did not work there at the time. The person who did has moved to another team and remembers only the general direction.

The organization has an owner on paper. Operational responsibility has fallen behind.

One AI. Different Rules.

What moves responsibility from paper into action

Three elements.

First, the system’s autonomy scope lives where the system itself lives. In its record, next to the owner field. Anyone who wants to know where autonomy ends can find it in one place.

Second, a change in scope is a decision, not a configuration. Moving the system into a new category of cases, a new user group, or a higher level of autonomy requires owner approval. Each such change leaves a trace: author, date, and decision basis.

Third, the organization retains a real ability to intervene. The system can be stopped, its scope reduced, or rolled back to a previous state as a standard operation. The owner receives tools, not just a title.

These three elements meet in one place. The field, the scope, the change history, and the intervention mechanism, all in the same record. Together.

The difference that only appears in an incident

That is when boards, insurers, or regulators ask very specific questions. Who authorized the scope. At what moment. On what basis. Whether someone monitored whether the scope remained appropriate. Whether someone could have stopped the system before damage began to accumulate.

In one scenario, the organization answers by pointing to the record. In the other, it launches an investigative project that takes weeks.

The difference is organizational, not technical. In the first scenario, the organization operates with autonomy. In the second, with automation that it happened to call autonomy.

Automation works as long as it works. Autonomy works as long as someone is accountable for it.