From Automation to Autonomy: Where Should Enterprises Draw the Line?

Ritesh Kapadia, SVP & Field CTO, iLink Digital

Ritesh Kapadia is the CTO at iLink Digital, where he leads the company's AI innovation and data-driven solutions strategy. A serial entrepreneur, he co-founded and scaled a technology startup to a successful acquisition before turning his focus to enterprise AI. At iLink Digital, he has driven the architecture and delivery of 150+ AI-led transformation projects, combining strategic vision with hands-on technical execution. His work centers on using data analytics and engineering to help businesses unlock actionable intelligence and operationalize AI at scale.

Ritesh Kapadia, SVP & Field CTO at iLink Digital, argues that the shift from traditional automation to AI autonomy requires a deliberate, evidence-based control model to navigate the shift from predictable, scripted workflows to adaptable, probabilistic decision-making. 

Word Count - 1440 Over the last two years, most enterprises have stopped asking whether AI belongs in their operations. That question has been settled by results. The question I now hear in almost every architecture review and steering committee is sharper and considerably harder to answer: how much decision-making are we prepared to hand over, and to what?

This is the shift from automation to autonomy, and it is not a linguistic distinction. Automation executes a process that someone has already decided. Autonomy decides. An automated workflow follows the path you designed for it; an autonomous agent selects a path, calls tools, adapts to what it finds, and produces an outcome that was not scripted in advance. The engineering is adjacent. The risk profile is not.

Enterprises that treat this as an incremental upgrade to their existing automation estate tend to discover the difference the hard way. The organisations getting it right are the ones drawing the line deliberately, documenting where they drew it, and revisiting it as evidence accumulates.

What actually changed

Traditional automation gave us determinism. Given the same input, a rules engine or an RPA bot produces the same output, every time. When it fails, it fails visibly and in a way you can trace. That predictability is why automation scaled into finance, claims processing, and supply chain execution with relatively modest governance overhead.

Agentic systems trade determinism for adaptability. They handle ambiguity, unstructured inputs, and exceptions that would have broken a rules engine. In exchange, the same input may produce different paths on different days. The system can be right for the wrong reasons, and wrong in ways that look entirely plausible. That trade is often worth making. Exception handling is where most enterprise process cost actually sits, and it is precisely where deterministic automation runs out of road. But it means the control model has to change alongside the technology. You cannot govern a probabilistic system with the assurance methods built for a deterministic one.

A practical test for where the line sits

In my experience, the debate becomes tractable when teams stop arguing about AI capability and start assessing the decision itself. Four questions do most of the work.

How reversible is the outcome? A drafted response, a proposed reconciliation, a suggested schedule - all can be undone at near-zero cost. A payment released, a contract counter-signed, a production configuration changed, a patient record updated: these are not easily walked back. Reversibility is the single most useful variable in the entire discussion, and it is the one most often skipped.

What is the blast radius? An agent that manages one team's ticket queue and an agent with write access to the ERP occupy different universes of risk, regardless of how well either performs in evaluation. Scope the permissions before you scope the ambition.

Can the decision be explained after the fact? Not "does the model produce a rationale" - models are fluent at producing rationales. Can you reconstruct what data the agent saw, which tools it invoked, and why it converged where it did? If a regulator, an auditor, or a customer asks in six months, the answer has to exist in a log, not in a reconstruction.

Is the underlying data ready? This is the constraint that quietly determines everything else. Autonomy amplifies whatever your data foundation actually is. If entity resolution is inconsistent, if lineage is undocumented, if access controls were designed for humans who exercise judgement about what they read, an autonomous system will operate confidently on top of those flaws and propagate them at machine speed.

Where a decision is reversible, narrow in scope, observable, and sits on trustworthy data, autonomy is usually justified. As those conditions weaken, the appropriate level of human involvement rises.

Autonomy is a dial, not a switch

The most damaging framing in this debate is binary. Enterprises do not have to choose between scripted automation and fully delegated agents. In practice, there are four workable settings, and mature organisations run all of them simultaneously across different processes.

Assisted. The system proposes, a person decides and executes. Appropriate for high-stakes judgement calls and for any new capability in its first production months.

Supervised. The system acts, but every action passes a human checkpoint before it takes effect. This is the right default for most customer-facing and financial workflows during ramp-up.

Conditional. The system acts independently within defined thresholds and escalates outside them. A refund under a set value is processed; above it, a person reviews. Most of the durable value we see lands here, because the thresholds encode institutional risk appetite in a form that is explicit and adjustable.

Delegated. The system operates end to end, with humans reviewing outcomes in aggregate rather than case by case. Suitable for high-volume, low-consequence, well-instrumented processes - and earned through demonstrated performance, not assumed at design time.

The important discipline is that a process moves along this dial based on evidence: accuracy against a held-out baseline, exception rates, cost of observed errors. Moving because a pilot looked impressive in a demo environment is how organisations end up rolling capability back six months later, at a cost to credibility that is far harder to recover than the engineering effort.

Where autonomy earns its place first

The strongest early candidates share a profile: high volume, contained consequences, rich telemetry, and a clear definition of a good outcome.

IT and infrastructure operations are a natural starting point - triage, enrichment, first-line diagnostics, routine remediation within guardrails. The environment is already instrumented, outcomes are measurable, and rollback is generally straightforward.

Software engineering workflows are another, with agents handling test generation, dependency hygiene, documentation, and migration groundwork. Code review remains the human checkpoint, which makes this an unusually well-structured supervised-autonomy problem.

Back-office operations - reconciliation, document processing, exception routing, vendor onboarding checks - is where the economics are often most compelling, because the exception volume that autonomy absorbs is the same volume that made conventional automation disappointing.

Where I would hold the line, for now

Decisions carrying legal or regulatory weight should not be delegated. An agent can assemble the file, surface precedent, and draft the recommendation. A named individual signs it. Irreversible financial and contractual commitments belong behind a human checkpoint, with thresholds that reflect actual exposure rather than convenience.

Decisions that materially affect a person's standing - credit, employment, clinical pathways, benefits eligibility - require human accountability as a matter of principle, not just compliance. The reputational cost of getting this wrong is not proportionate to the efficiency gained by getting it right.

And any process where you cannot yet reconstruct the agent's reasoning should stay supervised until you can. Observability is a prerequisite for autonomy, not a follow-on project.

The infrastructure the conversation usually skips

Organisations moving successfully into autonomy invest in a set of capabilities that rarely appear in the initial business case. Agents need identity. They should authenticate as first-class principals with scoped, revocable, least-privilege credentials - not inherit a service account with standing access to everything it was ever granted. Agents need observability. Every tool call, data access, and intermediate step should be logged in a form that supports reconstruction, not just debugging. Agents need thresholds expressed as policy, held outside application code, so that risk appetite can be adjusted without a release cycle.

Agents need a stop. A tested mechanism to halt an agent class, revoke its permissions, and fall back to a defined manual path. Every organisation assumes it has one. Considerably fewer have run the drill. And autonomy needs ownership. Every autonomous process should have a named business owner accountable for its outcomes. Diffuse accountability is where autonomy programmes fail, and it fails quietly until it doesn't.

The line will move – deliberately

I want to be clear that this is not an argument for caution as a default posture. The capability is real, the operational gains are measurable, and enterprises that spend the next two years deliberating will find themselves competing against organisations whose cost structures have already changed. The argument is for intent. The enterprises that will do well are not those that moved fastest or those that moved least. They are the ones that knew exactly where their line was, could explain why it sat there, instrumented their systems well enough to see when the evidence justified moving it, and then moved it on purpose. Autonomy is not a destination you arrive at. It is a position you hold, review, and adjust - with the same rigour you would apply to any other control that stands between your organisation and the consequences of a decision made at scale.