Autonomy is a dial, not a switch
The question is never whether to let software decide. It is which classes of decision, under what evidence, with what recourse when it is wrong.
Every conversation about autonomous operations eventually arrives at the same badly-framed question: do you trust the system to decide? Framed that way it has no good answer. Nobody trusts a system in general. People trust a system to do specific things, within bounds, with a way to catch it when it fails.
Decision classes, not decision volume
The useful unit is the decision class. Approving a purchase order under a threshold from an approved supplier with a matching receipt is a class. Approving an exception to a payment term is a different class, with different evidence and different consequences for being wrong. Lumping them together as 'procurement decisions' guarantees you will either over-delegate or under-delegate, and usually both at once.
Once decisions are classified, autonomy becomes a per-class setting rather than an organisational posture. Most companies end up with a long tail of classes running fully autonomously and a short head of consequential ones that always see a human. That distribution is healthy. It is also invisible if you never did the classification.
Start closed
The deployment pattern that works: gate everything, then open selectively. For the first weeks Cortexia proposes and a human disposes. Every proposal is logged with its evidence and the policy it applied. What you are building in that period is not training data but an evidence base about the system's judgment, in your context, on your decisions.
After a few hundred decisions in a class, the question stops being philosophical. You can see the disagreement rate. You can read the cases where the human overrode it and ask whether the override was right. Releasing autonomy on that basis is an operational decision with numbers behind it.
Recourse matters more than accuracy
A system that is right 99% of the time with no way to catch the 1% is worse than one that is right 95% of the time with fast, complete rollback. This is not intuitive to people who come at it from a model-evaluation background, where accuracy is the whole game.
In operations, the cost of an error is dominated by how long it takes to notice and how hard it is to unwind. That is why every action carries a reversal path, and why the audit trail is immutable rather than merely thorough. You are not trying to eliminate error. You are trying to make error cheap.
The gate is a feature
There is a temptation to treat approval gates as friction to be engineered away. They are not. A gate is the mechanism by which a company retains the ability to say no, and the moment it becomes a rubber stamp is the moment the whole structure is decorative. Gates should be few, real, and slow enough that someone actually reads them.