AI process automation pays off when volume is high, exceptions are rare, rules are stable and the decision is reversible. It fails when any one of those four does not hold, and the cost shows up in maintenance rather than in the initial budget.
Before that, one distinction decides the project. Automating a task and orchestrating a process are different things. The first replaces clicks. The second coordinates systems, people and decisions end to end, and that is where the durable return sits.
The European Commission Digital Decade country report for Portugal, COM(2026) 288 final of 17 June 2026, records that the 2026 to 2027 National Digital Strategy Action Plan advances a Sovereign Cloud Strategy, and warns that the effort may be held back by slow uptake of cloud and AI by Portuguese enterprises. The same report notes that 7.40% of Portuguese enterprises recruited or tried to recruit ICT specialists, on 2024 data, against an EU average of 9.55%. The pressure to automate is real and internal capacity is scarce, and that combination is what produces projects bought in a hurry and abandoned soon after.
AI process automation: automating a task or orchestrating a process?
It is the distinction that confuses most projects, and confusing it costs money because it leads to buying the wrong tool.
They are not alternatives. RPA has a legitimate place: it is the way to reach legacy systems that expose no API and cannot be dismantled. The pattern that works is using it as one task inside an orchestrated process, not as the whole process. Modern orchestration platforms ship connectors for the common RPA tools for exactly this reason. Where the underlying systems are ours to change rather than to work around, custom development is usually cheaper than automating an interface.
Which six criteria decide whether AI process automation is worth it?
We apply these six to any process before quoting for AI process automation. They are not published research, so we present them as what they are, our triage criteria.
It is a process where you will build the automated path, maintain the manual path, and add the work of deciding which of the two each case enters. The exception rate kills more projects than anything else and nobody measures it before starting.
Where does AI add something conventional software does not?
In three specific places. Unstructured inputs, such as documents, messages, forms filled in by people and files from four hundred suppliers each with its own format, and this is where the difference is largest and most defensible. Classification with fuzzy boundaries, such as routing a request or detecting that something is atypical, cases where the rule exists but nobody can write it out completely. And preparing a human decision, gathering context and summarising so a person decides faster, noting that here the AI does not decide, and it is frequently the design with the best return and the least risk. Our note on implementing AI in Portuguese companies covers where that return shows up first.
And where it adds nothing. If the process is a sequence of deterministic rules over structured data, the answer is a process engine and some decision tables. It will run faster, cost less and be explainable without effort. Buying AI for that is paying for unpredictability and receiving nothing in return.
Which sequence works?
After that, automate the main path and design the exception path with the same care, because the second is where the credibility of the system lives. And define the promotion criterion before starting the pilot: which metric, what value, measured over how long, decided by whom.
What stays in your house at the end?
A question to ask at the start, not the end. Automation is infrastructure, and infrastructure that cannot be maintained internally or transferred is a dependency. What should stay with you: the process and decision models in standard notation, readable without a proprietary tool. The code of the services the process invokes, and the infrastructure definitions. The execution data and history, because that is where the proof of return lives. And documentation of what was decided and why, including what was decided not to automate.
On that last point: the list of exceptions deliberately left un-automated is one of the most useful documents such a project produces, and it is almost always the only one nobody writes. We also cover what to ask an AI agency before you sign, and the case studies page has examples of process platforms we have built and still maintain.
What makes an AI process automation project get stuck in pilot?
Four things, and none is technical. There is no promotion criterion, so the pilot is permanent by default. Nobody owns the process, because the project has an IT sponsor and no business owner able to decide that an exception stops being handled by hand. Failure behaviour was never designed, and if the answer to "what happens when the system does not know" is "someone will look at it", there is no process, there is a queue. And measurement compares against the ideal rather than the before, which guarantees arguments about results that kill projects that work.
Frequently asked questions
When AI process automation pays off
When is it worth automating a process with AI?
What is the difference between RPA and process orchestration?
BPMN and pilots
What is BPMN and why should a buyer care?
Why do automation projects get stuck in pilot?
Exceptions and ownership
Does a 30% exception rate mean 70% is automatable?
What should stay with the company at the end of an automation project?
