Should this business process use AI at all?

Capability is not permission

Modern models can draft, classify, summarise, reason across documents and call tools. That makes many business tasks technically possible to automate. It does not make every one of them sensible to delegate.

A process can be technically achievable and still be the wrong candidate because the underlying work is poorly understood, the consequences of an error are too severe, the required authority is too broad, or a deterministic workflow would do the job more reliably.

The useful distinction is between what AI can do and what the organisation should allow it to do in this process, with this data, against these systems and under these controls.

Start with suitability, then readiness, then authority

Jumping straight to implementation usually collapses several different decisions into one. A better sequence is suitability, readiness and authority.

Suitability asks whether the work should be automated and whether AI adds anything that ordinary software cannot provide. Readiness asks whether the real process, data, ownership and controls are good enough to support the change. Authority asks what the resulting system may actually do.

• Should this work be automated at all?
• If it should, is the problem deterministic or does it genuinely benefit from probabilistic reasoning?
• Is the real process sufficiently understood, including exceptions and workarounds?
• Are the data, systems of record, permissions and ownership clear enough?
• What may the system read, recommend or change?
• Which decisions or side effects still require human approval?
• How will the organisation measure, review, constrain or revoke that authority?

AI and automation are not the same decision

Some processes are valuable automation candidates precisely because they do not need AI. If the rules are knowable, stable and testable, deterministic automation can be cheaper to operate, easier to explain and easier to control.

AI becomes useful where language, ambiguity, classification, interpretation or contextual reasoning creates value that a fixed rule set cannot provide economically. Even then, the AI component does not need to own the whole process.

A single workflow may sensibly combine deterministic validation, AI classification, human judgement and conventional system integration. The model is a component of the architecture, not the architecture itself.

Think in levels of authority

It helps to separate assistance from action. Generating a draft is not the same control problem as changing a customer record, issuing a payment or making a commercial commitment.

A useful process can therefore be split into different treatments rather than being labelled simply automated or not automated.

• Simplify or remove unnecessary work before adding technology.
• Use deterministic workflow where predictable rules are sufficient.
• Use AI for assistance, classification, drafting or recommendation.
• Require approval before defined AI-prepared actions are executed.
• Allow bounded autonomous action only where authority, failure handling and observability justify it.
• Keep work human-only where judgement, accountability or consequence cannot sensibly be delegated.

Systems of record and side effects change the risk

Reading information is fundamentally different from changing authoritative business state. The point at which an AI-enabled process can send, approve, purchase, delete, update or commit is where architecture and control become much more important.

That boundary should be explicit. Permissions should be narrow, policy should be enforceable outside the model where possible, actions should be observable, and failure or rollback paths should be understood before autonomy is increased.

The same reasoning applies to ordinary automation, but probabilistic decision-making makes the boundary easier to overlook because a model can appear competent across a wide range of situations right up until it encounters one the process has not considered.

Human involvement is not failed automation

There is a tendency to treat every human approval as temporary friction that should eventually be removed. Sometimes it is. Sometimes that approval is the point at which commercial responsibility, negotiation, ethics or contextual judgement properly sits.

A good architecture can deliberately keep that decision with a person while automating everything around it. The result may still remove substantial delay and administration without pretending responsibility can be delegated safely.

The right end state is the one that improves the operation of the business. AI adoption and autonomy levels are means, not outcomes.

A sensible first engagement is one real process

Instead of beginning with an enterprise-wide AI programme, start with one process that is slow, manual, expensive, error-prone or difficult to scale. Discover how it actually works, including the awkward exceptions, then decide what should change.

The answer might be AI. It might be integration, deterministic workflow, process simplification or better ownership. It may also be that part of the process should remain exactly as it is.

That is not a disappointing AI outcome. It is a useful business decision.