In a well built AI workflow, the software records for every process step what the model is allowed to do. The model reads, sorts, and proposes. A person approves anything that touches money, customers, or commitments, anything outside a preset threshold, and every exception. Each proposal and each decision is logged and can be reversed.
AI has moved into ordinary business processes. Across the EU, the share of enterprises with 10 or more employees using AI rose from 13.5% in 2024 to 20.0% in 2025, according to Eurostat. In the Netherlands, where we're based, 45% of companies with 50 to 250 employees used AI in 2025, and 32% of AI users apply it to administration or management tasks. That puts models inside order processing, invoices, support tickets, and applications, exactly where a mistake has direct consequences.
At Isatis we start from a simple split: AI works best when people stay close to it. The model proposes, a person approves. Below you'll read how to choose that split per process step, and how to build thresholds, exceptions, logging, and rollback into the software itself.
What an AI workflow is and where the model fits
An AI workflow is a business process in which one or more steps are carried out by a language model or other AI model, while the order of the process is fixed in regular code. The model might read an incoming invoice and fill in the fields. The software decides what happens next.
Anthropic, the company behind the Claude models, draws the same line in its engineering guide to building agents, separating a workflow from an agent that chooses its own route:
"Workflows are systems where LLMs and tools are orchestrated through predefined code paths."
For an order process or an invoice flow, that fixed route is the sensible choice. You know which step the model performs, which data it sees, and where the result goes.
The distinction matters because expectations are climbing fast. In June 2025, Gartner predicted that by 2028 at least 15% of day to day work decisions will be made autonomously by AI agents. The same release predicted that over 40% of agentic AI projects will be canceled by the end of 2027, partly because of inadequate risk controls. Setting the boundaries in software up front is how you stay out of that second group.
Three levels per process step: propose, approve by exception, autonomous
It helps to give every step in the process a level. We work with three, and each level is a setting in the software that you can change per step.
| Level | What the model does | What the person does | Example |
|---|---|---|---|
| Propose | Reads and fills in a draft | Checks, edits, and approves | Coding an invoice to a general ledger account |
| Approve by exception | Acts on its own within the threshold | Reviews only what falls outside it | An order from a known customer for known items |
| Autonomous | Acts and records the result | Spot checks afterwards | Tagging a support ticket and routing it to the right team |
Most steps start at the first level. A step moves up only when you can show with numbers that the model's proposals for that step are almost always accepted as they are. Steps with large or permanent consequences stay at the first level, however well the model scores.
How to decide who approves each process step
The choice per step follows from a handful of questions you answer for each step separately.
- What does a mistake cost? A wrong tag on a ticket costs a minute. A payment to the wrong bank account costs money you may never recover.
- Can the step be reversed? A draft order can be deleted. An email sent to a customer or a payment order sent to the bank can't.
- How often does the step occur? A task that happens a thousand times a month pays back automation far sooner than one that happens ten times.
- How good is the source data? A structured message from a customer portal is more reliable than a scanned PDF with handwritten notes.
- Can you measure quality? Without a comparison against what an employee would have done, you can't tell whether the model is getting better or worse.
Organizations that get real value from AI are more likely to have settled this explicitly. In McKinsey's State of AI survey from November 2025, 65% of AI high performers said they have defined processes for when model outputs need human validation. Among other organizations, that figure was 23%.
Building thresholds and exceptions into the software
A threshold belongs in your application's configuration. Never rely on the instruction to the model alone. A model can ignore or misread a rule in a prompt, while a check in code can't. An administrator should be able to adjust the threshold without a new release, and that change is logged as well.
Common thresholds and exceptions in an AI workflow include:
- an amount limit per invoice or order, above which a person always approves
- a model confidence score below a set value
- a mismatch with the purchase order, such as a different quantity or price
- a new customer, new supplier, or changed bank account number
- a field the model couldn't fill or that conflicts with master data
Be careful with confidence scores. The score a model reports about itself isn't automatically reliable. First measure on a sample with known outcomes at which score the proposals actually hold up, then set the threshold based on that measurement. Checks that need no AI, such as validating a VAT number, an IBAN, or an item code against the ERP, belong in plain rules in the code.
The approval screen: what the reviewer needs to see
An approval step only works if the reviewer can see in a few seconds what the model proposes and why. A screen with nothing but an "approve" button invites blind clicking. A good approval screen shows at least:
- the source document, such as the original invoice, email, or application
- the model's proposal, field by field
- the reason this step landed with a person, for example "amount above threshold" or "new bank account"
- the differences from master data or the purchase order, highlighted
Give the reviewer three choices: approve, edit, or reject. Ask for a short reason when they edit or reject. Those corrections become your best test material later, because they show exactly where the model got it wrong.
The approval screen should preferably sit in the application the employee already uses. A separate portal next to the ERP or ticketing system quickly gets skipped. That usually means integrating with your existing systems, so the proposal and the approval live in the same place as the rest of the work.
Building in logging and rollback
Every decision in the AI workflow must be reconstructable afterwards. For each proposal, record at least:
- the input the model received and where it came from
- the model version and the version of the instruction
- the proposal and its confidence score
- who approved, edited, or rejected it, with timestamp and reason
- which action the software then carried out, and in which system
Rollback starts with the design. Let the model write to a draft or a staging layer, and let the software post to the ERP or send to the customer only after approval. For steps that do run through directly, build a reversing entry or recovery action that restores the original state in one move. Also add a switch per process step in the configuration that sets the step straight back to the propose level. If quality drops after a model update, an administrator flips that switch and the process keeps running, with a person in charge.
Test all of this the way you test any other feature. A fixed set of sample documents with known outcomes, rerun for every new model version or instruction, shows whether a change actually improves things. That fits the same approach to QA and testing you use for the rest of your software.
Start small and move the boundary based on measurements
Start with one process step that occurs often and is easy to measure. Let the model run alongside for a few weeks without its proposal doing anything: the employee works as usual and the software compares afterwards. Then set the step to propose and measure how often a proposal is accepted unchanged. Only when that rate is high and stable over a longer period does the step move up to approve by exception.
It's the same step by step route we describe in our article on business process automation: map the process first, then tackle the step with the most manual work, and only then expand.
Isatis has built software for more than 30 years for processes in which every change must be traceable, from aviation maintenance (MRO) software to a subsidy administration platform and RFID product data across the supply chain. With 30+ engineers in Nijmegen and Sarajevo, 100+ projects, and ISO 9001 and ISO 27001 certification, we build custom software with approval, logging, and rollback in place from the first version. Read more about our approach to data and AI, or book a conversation about the process step you want to start with.
Frequently asked questions
What is an AI workflow?
An AI workflow is a business process in which an AI model carries out one or more steps, such as reading an invoice or tagging a ticket, while the order of the process is fixed in software. The software decides which steps the model may complete on its own and which a person approves first.
Which process steps should always require human approval?
Steps with financial consequences above a threshold, steps that can't be reversed such as payments and messages to customers, changes to master data such as a bank account number, and any situation that falls outside the defined rules. Those steps stay at the propose level, even when the model handles them well.
How do you set a good threshold?
Run the model on a sample with known outcomes and check at which confidence score and which amount the proposals hold up in practice. Store that threshold in the application's configuration, so an administrator can adjust it and every change is logged.
Can an AI model act on its own in an existing ERP?
Technically, yes, through an integration. We recommend letting the model write to a draft or staging layer first and posting only after approval. For steps that run autonomously, build a recovery action and a switch that sets the step straight back to human approval.
