How to Decide Whether a Business Process Is Suitable for AI

Repetition is a reason to examine a business process. It is not evidence that AI is the right intervention.

A useful suitability assessment looks beneath the process name and examines the units of work inside it. It considers boundaries, input quality, variation, judgement, exceptions, error consequences and feedback before a product or model is selected.

The result may be AI assistance, bounded agentic action, a rules engine, a system integration, process redesign or no automation at all.

Why repetitive work can produce a misleading business case

The arithmetic behind many automation proposals begins with frequency and duration. A task takes 15 minutes, occurs 2,000 times each month and therefore consumes 500 hours.

That calculation may describe the current workload, but it says little about how much of it can be removed.

The 15 minutes may include several different activities. The normal case may take three minutes while exceptions take an hour. People may be compensating for missing information, checking a commercial risk or waiting for another team. Review work may remain after the automated output is produced.

Multiplying average time by volume can therefore turn a process label into an assumed saving.

Before estimating the benefit, establish what one unit of work contains and which parts could change.

Assess tasks and decisions, not job titles

"Proposal writing" can include:

• Qualifying an enquiry
• Gathering current customer and asset data
• Reading survey notes and specifications
• Resolving contradictory information
• Selecting rates and applying discounts
• Drafting scope and exclusions
• Assessing commercial risk
• Obtaining approval
• Producing and sending the final document

These activities do not have the same suitability for AI.

Gathering structured records may need an integration. Approval thresholds may belong in fixed rules. Language models may help interpret notes and draft text. Commercial exceptions may need an accountable manager.

Breaking the process down prevents one promising task from being used to justify automating the whole chain.

A six-part AI suitability assessment

1. Task boundaries

Define the event that starts the task, the result that completes it and the owner responsible for that result.

Compare the written process with recent examples of the work. If the boundaries or expected output vary between teams, find out why. The difference may reflect valuable local judgement, an undocumented policy or an avoidable inconsistency.

AI should not be asked to resolve an ownership or policy question that the organisation has left unsettled.

2. Inputs and evidence

List every data source, document and piece of context used by an experienced person. Then inspect how often each input is present, current, accessible and internally consistent.

Language models can interpret varied formats and imperfect prose, but plausible output can disguise missing evidence. A source that is unavailable to the system does not become irrelevant to the decision.

The assessment should identify:

• Mandatory and optional inputs
• Conflicts between systems or documents
• Information people obtain through informal channels
• Rules for deciding which source is authoritative
• Personal, confidential or commercially restricted information
• Records needed to explain the result later

This work often identifies a data or integration project that must happen before AI can be tested fairly.

3. Variation and exceptions

Separate superficial variation from variation in meaning.

Different document layouts, writing styles and terminology may be suitable for a language model. Different policies, customer commitments and approval routes create another problem.

Review a sample of recent cases that contains normal work, rejected work, corrections and unusual cases. Record the exception categories and what an experienced person does with them.

An exception does not always need to be automated. A good design may identify it reliably and route it to the right person.

4. Judgement and authority

Describe the judgement used in operational language.

Is the person matching evidence to an established rule, interpreting ambiguous wording, estimating an unknown value, choosing between competing objectives or accepting risk for the organisation?

Then separate producing a recommendation from holding the authority to act on it.

An AI system may draft a scope or identify a policy clause without being authorised to set a price, waive a condition or commit the organisation. This boundary should be designed into the workflow rather than left to a general instruction in a prompt.

5. Error and recovery

An accuracy percentage does not describe business risk on its own.

For each plausible error, record:

• The consequence for customers, employees, suppliers and the organisation
• How likely the error is to be noticed
• When it is likely to be noticed
• Whether the decision or action can be reversed
• The work and cost required to recover
• The person authorised to intervene

A lower-accuracy drafting tool with review may present less risk than a high-accuracy system that takes an irreversible action without approval.

6. Feedback and measurement

Identify how the organisation will know whether the output was good.

Some results can be checked against a known answer. Others need a domain reviewer or later business outcome. Feedback may arrive through corrections, customer responses, rework, appeal, financial reconciliation or operational incidents.

The time between action and feedback matters. If weak decisions are not visible for months, a system can repeat them at scale before the problem is detected.

The NIST AI Risk Management Framework Core covers many of these questions through its Map and Measure functions. It asks organisations to define knowledge limits and oversight, assess data suitability, examine benefits and error costs, and test systems under conditions that reflect their intended use.

The UK Government AI Playbook also asks teams to begin with business and user needs, consider conventional approaches and focus AI on work where it provides a material advantage.

Do not let the average hide the risky cases

Process averages are useful for capacity planning, but they can hide concentrated risk.

An AI assistant might draft most proposals correctly while struggling with the small number that contain unusual liability wording, conflicting equipment counts or non-standard discounts. Those cases may carry more commercial consequence than all the routine work combined.

Segment the evidence by case type, customer group, input source and exception. The team can then decide which groups are suitable for assistance, which need mandatory review and which must remain outside the system.

This also makes human oversight testable. The design should say who reviews, when the review occurs, what evidence is shown, how much time is allowed and whether the reviewer can reject or reverse the action.

"Human in the loop" without those details is a label, not a control.

Match each task to the intervention

The process may need several different interventions:

This mixed design avoids making one technology responsible for work it is poorly placed to perform.

It may also expose steps that can be removed. If the same data is re-entered because two systems are disconnected, resolving that hand-off could deliver value without adding AI.

Create a suitability sheet before selecting a tool

For each unit of work, produce a short record containing:

• Start, finish and accountable owner
• Inputs, sources and known quality problems
• Normal variation and exception categories
• Decisions and required authority
• Rules, examples and reference material
• Error consequences, visibility and recovery
• Feedback and measurement method
• Suitable conventional interventions
• Proposed role for AI
• Excluded cases and mandatory review points

Use operational evidence rather than a workshop vote. Recent work, corrections, complaints, exception logs and reviewer comments will reveal more than the ideal process map.

The suitability sheet should support a decision, not manufacture approval. A credible outcome may be that AI fits one small section of the work, that the process needs repair first or that the project should stop.

The next stage is to assess the proposed project around the task. Even suitable work can fail to justify investment when the expected value, risk and organisational readiness are examined together.