AI workflow automation: what it is and isn’t
Which steps of a workflow run on rules, which need a step that reads text, and which stay with people? Use cases, personal data, costs and a first pilot.
AI workflow automation means adding a model to a rule-based workflow only at the steps where rules run out, so that it reads text and proposes something: sorting an incoming request by topic, summarising a long thread or drafting a reply. The rest of the flow stays rule-based, and every decision that leaves the business passes a person’s approval.
How does a rule-based flow differ from a step that reads text?
A rule-based flow gives the same result for the same input every time: if the form field says “quote”, the request goes to sales. A step that reads text interprets free writing and proposes something, which is usually right but not always. That is why the two are designed, checked and paid for differently.
In practice, most of a workflow is solved with rules: opening a record, assigning an owner, sending a reminder, moving information between two systems. The step that reads text only comes in where the input has no structure, when someone has to understand what an email, a message or a document is actually saying.
A quick way to tell whether a step needs to read text at all: if you can turn the input into a choice or a required field, a rule is enough. Changing the form is often cheaper and more reliable than interpreting what people write. The table below sets the two side by side.
| Aspect | Rule-based step | Step that reads text |
|---|---|---|
| Input | Structured fields: a choice, a date, a product code | Free text: an email, a message, a document |
| Output | The same result every time | A proposal based on likelihood |
| How it fails | A missing rule stops the flow, visibly | A confident but wrong proposal |
| Oversight | The rule itself is tested | Regular checks on a sample set, and human approval |
| Running cost | Largely fixed once built | Grows with the volume of text processed |
Which steps does it actually help with?
The step that reads text shortens the reading and sorting that takes a person minutes; it prepares a decision rather than making one. It helps most with work that repeats every day and starts with something written. The examples below are implementation scenarios, not client projects; in each, the step proposes and a person has the final say.
What they share is simple: the step’s output is a proposal for the next step. If the proposal is wrong, the flow does not stop; a person corrects it and the rule-based part carries on. Once corrections are recorded, it also becomes clear where the step struggles. Five typical uses:
- Sorting incoming requests: tagging an email or form message by topic and urgency and proposing the right queue.
- Summarising a thread: reducing a long customer conversation to a few lines for whoever takes it over.
- Proposing fields from a document: reading an invoice, an order or an application and suggesting what to fill in; a person checks and approves.
- Drafting replies: writing a draft for common questions from the company’s own information; sending always stays with a person.
- Turning notes into records: pulling the fields for a customer record out of meeting notes.
Which work should not be automated?
Work that should not be automated falls into four groups: processes whose rules are not settled yet, tasks where a single mistake is expensive, decisions that turn out against a person, and communication where tone matters as much as content. In these, the preparation can speed up; the decision and the final word stay with people.
If a process runs differently every time, write down how the work should go first; automation does not resolve uncertainty, it only speeds it up. Where one error is costly, such as approving a payment, committing to a contract or granting a price exception, the step prepares at most. Türkiye’s personal data protection law (KVKK) also gives people the right to object when analysis carried out solely by automated systems produces a result against them, so decisions such as hiring or turning down an application should pass through a person’s judgement.
Where tone decides the outcome, such as answering a complaint or writing to a sensitive customer, a draft can help, but sending is a person’s decision. Rarely performed tasks are usually not worth automating either: building and maintaining the flow costs more than the time it saves.
Personal data: where does it sit, and does it leave Türkiye?
A step that reads text usually handles writing that contains personal data: a customer’s name, phone number and the details of their request. So before the flow is built, a data map should record which step sends which data to which service, where the data is stored and for how long it is kept.
The rule is simple: send the step only what it needs to do its job. Sorting a request by topic does not require the customer’s phone number; identifying details can be removed or masked before anything is sent. If the service that processes the text is abroad, transferring personal data falls under the law’s rules on transfers abroad: as a rule it needs an adequacy decision or one of the appropriate safeguards the law lists, and the privacy notice should say so plainly.
Keep a record of every run, but not the full text: which step ran when, what it proposed and who approved it. The step should be switchable off; when it is off, the flow carries on with its rule-based part and by hand. This section is a general framework, not legal advice; check your own situation with a legal adviser.
What drives the setup and the monthly running cost?
The cost has two parts: a one-off setup and a monthly running cost. Setup depends on the number of steps in the flow, the systems to connect and the exceptions to define; running costs depend on tool licences, the volume of text processed and maintenance. Seeing each item separately in a proposal prevents surprises.
The text-reading step is usually charged per use: the more text, and the longer it is, the higher the bill. When you ask for a quote, share a rough estimate of your monthly volume and ask whether the service can run with a spending cap. The exact amount depends on scope, but two decisions lower the running cost in every case: running the step only where it is needed, and giving it short, cleaned-up input.
When comparing proposals, ask for the setup fee separately from the monthly costs. Put in writing whose name the licences are opened in, whether the data can be exported and how the flow moves if a tool changes; dependence on a single tool is an easily overlooked cost.
| Item | Depends on | How to limit it |
|---|---|---|
| Flow design and setup | Number of steps, exceptions, acceptance criteria | Keep the first version to one flow |
| System connections | What your tools can connect to, and access rights | Use each tool’s own features first |
| Use of the text-reading step | Volume and length of the text processed | Run it only where needed, on short input, with a spending cap |
| Tool licences | Number of users or operations | Choose licences by actual use |
| Maintenance and monitoring | Connection changes, regular sample checks | Name an owner and a failure alert from the start |
How do you set up a first pilot?
A first pilot starts with one flow and one text-reading step, and its success is tied to a criterion written down in advance. It runs on an anonymised sample set instead of real customer data; for a while the step’s proposals are only observed, then they join the flow behind an approval point.
Bring the current steps, the tools you use, a few anonymised sample messages and a rough monthly volume to the first meeting; you do not need to share passwords or real customer data. If you have not yet chosen which process to start with, our guide to business process automation covers that choice. Then draw the pilot’s boundary with these five points:
- One flow, one step: the pilot has a single step that reads text.
- A sample set: test with anonymised messages that include the exceptions, not with real data.
- An approval point: every proposal that leaves the business passes a person.
- An off switch: with the step turned off, the flow continues with its rule-based part and by hand.
- A correction rate: track how many proposals get corrected, and widen the scope on that basis.
Write the rule first; let the model start only where the rule ends.SHIBAGENCY
Source and further reading
Turkish Personal Data Protection Law (official text, in Turkish) — Mevzuat Bilgi Sistemi
Define the scope for your business
Explore the service scope, then share your current situation, the outcome you need and any target date to begin.
