Before Using AI to Speed Up a Process: Is It Ready for Automation?

One concern we sometimes hear after an AI deployment is that teams are spending more time checking and correcting outputs, while the work itself has not become noticeably easier.

Several factors may be involved.

In some cases, the model or system does not meet the process’s requirements for accuracy or reliability. In others, the procedures, decision criteria, exception handling, or reference materials were already ambiguous before AI was introduced.

The important step is not to settle too quickly on one explanation, but to distinguish problems in the AI system from problems in the process.

This article focuses on the latter and asks whether the process is ready for automation.

At MIF, we clarify the purpose of the work and the standard it must meet, then test candidate models and systems on real cases. We adjust the scope of work delegated to AI based on the results.

Process design and technical selection are not strictly sequential; they are refined iteratively.

Automation Can Scale Ambiguity Too

A useful principle is that automating a bad process can simply make the bad process faster.

The phrase is not a judgment on the people doing the work.

It describes a state in which the prerequisites for automation — purpose, procedure, decision criteria, exception handling, and accountability — have not been sufficiently worked out.

Automation does not selectively accelerate the parts of a process that are working well.

If the information provided to the system or the defined procedure contains contradictions or ambiguity, those problems can be reproduced at greater scale as volume increases.

Consider a process for preparing price quotes in which different employees check different items and handle exceptions in slightly different ways.

AI may cut the time it takes to produce a draft. If there is no shared definition of what makes a quote correct, the volume of human checking and rework can rise instead.

Improving model performance alone may not resolve inconsistent decision criteria.

The reverse can also happen: adopting AI sometimes brings differences to the surface that had been hard to see.

Recording where rework occurred and under what conditions individual judgments diverged can provide useful evidence for revisiting the process.

Without a mechanism for checking and monitoring, though, incorrect handling can accumulate before anyone notices.

Whether those problems become visible depends partly on how logging and monitoring are designed.

Three Problems That Are Easy to Miss Before Automation

The longer a process has been running, the more its current form is taken as given, and the harder its problems are to see.

Three things are worth confirming before automating.

The first is whether the work still serves its intended purpose.

Steps added in response to a past incident or temporary rule change can remain in place even after the original rationale no longer applies.

Before considering automation, it is worth asking whether the step can be retired outright, or merged into another.

The second is whether decision criteria and exception handling are shared.

One employee may treat a particular type of case as requiring approval, while another may not, without a shared rule for handling exceptions.

Where results differ by individual, the organization needs to distinguish deliberate variation — reflecting the customer or the case — from unmanaged inconsistency.

Not everything has to be reduced to a single rule. What is needed is the ability to say what counts as standard and what counts as an exception.

The third is whether authoritative reference materials and responsibility for keeping them current are clearly defined.

Day-to-day exception handling may circulate through chat or informal conversations, separately from the formal procedure, with no clear source of truth.

When pricing, product details, internal procedures, and response policies are scattered across several locations, both AI outputs and human decisions can become inconsistent.

The organization needs to decide which source is authoritative, and who updates it when something changes.

Frequency Alone Is Not Enough to Choose What to Automate

High-frequency work creates a visible burden and may look like an obvious target for automation.

However, frequency alone does not make a process suitable for automation.

MIF has previously described two measures for choosing a first target: how often the work occurs, and how serious the consequences of an error would be.

This article adds two more, giving four factors in total:

• How frequently the work occurs and at what volume
• How serious the consequences of an error would be
• Whether the quality of the result can be evaluated
• How stable the decision criteria and reference materials are

A strong initial candidate is a process that occurs frequently, produces outcomes that are easy to evaluate, and carries limited downside if something goes wrong.

By contrast, a high-frequency process with unclear criteria and hard-to-detect errors is better approached first through AI assistance or a limited pilot.

Seven Questions to Ask Before Automating

The following questions can serve as a starting point.

These questions are not a universal prescription, but one possible starting framework.

Each organization should adjust the level of detail and order of priority to the nature, scale, risk, and regulatory context of the work.

1. What does this process produce, and is that output still needed? — Check for steps that survive only because of past circumstances, or that duplicate other work
2. Can the inputs, outputs, and authoritative sources be described? — Set out what comes in, what gets produced, and which material takes precedence
3. Are the decision criteria and the acceptable range of variation clearly understood and consistently applied? — Distinguish deliberate differences from unmanaged inconsistency
4. At what point should an exception be escalated to a person? — Specify the conditions that require approval, rework, or additional confirmation
5. How will errors be detected, contained, and, where possible, reversed? — Decide on monitoring and recovery, not only throughput
6. Who updates the procedures and reference material? — Material with no named owner and no review schedule tends to go stale after go-live
7. Can the candidate AI system meet the required standard on real examples of the work? — Test the system using the organization’s own inputs, terminology, reference materials, and output formats, rather than relying only on public benchmarks

On the seventh question, it helps to break “accuracy” into pass conditions specific to the work rather than leaving it as an abstraction.

• Does it omit required information?
• Does it introduce false or unsupported information?
• Does it adhere to the required format?
• Does it follow the defined escalation conditions?
• Does quality vary widely across similar inputs?

Processing time, cost, and security requirements belong in this stage as well.

Not every question needs a complete answer.

But where the inputs and outputs, the decision criteria, and the method of detecting failure are largely unexplained, narrowing the scope or keeping a person in the loop is more realistic than automating the whole thing at once.

Automation Is Not a Binary Choice

The decision is not whether to use AI or not, nor whether to automate fully or leave the work to people.

Four options can be applied according to the state of the process:

• Retire — Remove steps that no longer serve a purpose or that duplicate other work
• Standardize — Clarify decision criteria, authoritative sources, and exception handling
• Assist — Use AI for drafting or classification while keeping judgment with a person
• Automate — Allow AI to complete work within stable, clearly defined conditions and route exceptions to a person

A process does not have to be treated as a single unit.

Gathering information can be automated while the judgment stays with a person.

Routine cases can be handled automatically while exceptions go to a named owner.

Breaking the process down by step can better reflect operational reality.

The performance of candidate models feeds into this choice as well. When a model falls short of the required standard, it can remain in an assistive role, while automation is limited to the cases in which testing has shown stable performance.

Standardization is not merely a preliminary step. In some cases, clarifying the criteria makes the process efficient enough that further automation is no longer necessary.

The Process Does Not Need to Be Perfect First

None of this means an organization must fully redesign a process before introducing AI.

Trying to redesign an entire process first can prolong planning and delay access to real-world evidence.

Writing out the inputs, procedure, decision points, exceptions, and outputs for a single representative case can reveal where the ambiguity lies.

Processes that span multiple departments or existing systems may require a broader review, including approval structures and access rights.

A practical starting point is a single, low-impact step tested against historical examples.

Set the pass conditions first — whether the required information is present, whether any false or unsupported information has been introduced, and under what conditions the work goes to a person.

Once it is running, look beyond the AI output itself: the rate of human correction, the reasons for rework, the number of cases escalated as exceptions, and processing time all belong in the review.

Those results help determine whether the next adjustment belongs in the model or system, the reference materials, or the process itself.

Process design and technical validation are not two stages arranged one after the other.

They are better treated as a loop: test on a small scale, review the results, and refine both sides.

Conclusion

Neither model accuracy nor process design explains AI adoption outcomes on its own.

Process work cannot compensate for an AI system whose performance falls short of what the work requires.

Nor can model performance alone stabilize a process whose decision criteria and authoritative sources remain unclear.

Before automating, confirm the purpose of the work, the inputs and outputs, the decision criteria, the exception-handling rules, responsibility for updates, and the method of detecting failure.

Then test candidate AI systems on real examples of the work and decide whether AI should remain in an assistive role or automate the work under defined conditions.

The appropriate choice may be to retire, standardize, assist, or automate.

Different steps within the same process may call for different choices.

Working through this short set of checks can reduce rework after deployment and make it easier to expand the scope of work delegated to AI safely.