A system that acts on your behalf needs an owner

Autonomy is a design decision, not a setting

The question is never whether a system should act on its own. It is which actions, on which records, under whose authority, and what happens when it is wrong.

That gets decided at design time, with the people who currently hold that authority, and it is written into the blueprint before anything is built.

Where the approvals sit

Wherever your team wants them. Some actions are safe to take and easy to reverse. Others are drafted and held for a person, and the system's job is to arrive with the work already done and the reasoning attached.

The rule we keep is simple: nothing leaves the building without a person, unless the client has decided otherwise in writing.

What the audit trail has to hold

Every action logged against the record it touched, with what the system read, which rule it applied, and who approved it. Not a log of API calls, which answers a different question.

That gives reviewers a basis for examining the system and helps explain a particular case when someone asks about it later.

It also has to be readable by somebody who was not there. An audit trail only an engineer can interpret is not an audit trail.

Who is accountable

Inside the business

A named owner inside the business needs authority over the system. Without ownership, changes in the business can leave its decisions and boundaries unclear.

And on our side

On our side, the same engineers who scoped and built it operate it. When something breaks in production it is ours until it is fixed.