The main question: where exactly intelligence is needed
Break the process down into steps and ask of each one: does this step require understanding meaning, or only following rules? Moving data from one system to another, checking against a list, calculating by a formula — these are rules. Working out what an email is about, extracting the substance of a document, matching a customer’s wording to the catalogue — that is meaning.
AI is needed exactly at the steps that involve meaning. Everything else is cheaper, faster and more reliable in ordinary code — and that is how working systems are built: a deterministic frame with AI at the nodes that cannot do without it.
Which processes go first
A good first process has five traits:
- It is frequent: hundreds of operations a month, not a dozen.
- It is uniform in its goal but varied in the form of its input — this is exactly where rules stop coping.
- Its result can be checked: there is a way to confirm it was done right.
- A mistake is reversible or caught by a check — at the start, processes with irreversible consequences are not taken on.
- The data for it already exists in digital form.
Typical working candidates
- triaging incoming enquiries: classification, extracting the substance, routing;
- checking documents against requirements, with the discrepancies pointed out;
- preparing drafts of replies and commercial documents from the company’s templates;
- matching data from different sources where the wording does not coincide word for word;
- a first search of the internal knowledge base instead of asking a colleague.
What not to automate with AI
- Processes with no criterion of correctness: if two experts argue about what is right, the system will not learn.
- Rare operations: the preparation will take longer to pay back than the process itself lives.
- Strictly regulated calculations: they need reproducibility, not flexibility.
- Processes the company plans to change: it makes sense to automate what is stable.
- Processes whose data is not in digital form: collection first, AI after.
Why redesign comes before automation
Many processes are badly built for historical reasons: extra approvals, duplicate data entry, checks invented for a problem that disappeared long ago. Automating such a process makes it fast and still bad — and also fixes it in code, so changing it becomes more expensive.
So the first stage is an analysis of which steps are needed at all. It regularly turns out that once two unnecessary steps are removed, what remains is covered by an integration with no AI at all. That is a normal outcome of the work — and it saves the client money.
What implementation looks like, step by step
- Process analysis: steps, volumes, time, errors, who does what by hand.
- Data check: does it exist, in what form, who owns it, can it be used.
- Choosing the nodes for AI and the rules for everything else.
- A pilot on a limited part of the process, with a metric fixed before the start.
- Integration into working systems — usually the longest part, and the model is not the reason.
- Gradually widening autonomy as quality statistics accumulate.
What to measure
- the share of operations completed without a human;
- the end-to-end time of an operation;
- the share of corrections made after the system;
- the cost of one operation, including running and review;
- the number of cases where the system correctly declined and handed over to a human.
The last metric is underrated: a system that can recognise its own limits is safer than one that always produces an answer.