When Does Process Automation Actually Need AI?

At Vanity, roughly 100,000 leads a year had to reach the right sales representative. Enquiries came from different countries, languages, and time zones. The team routed them manually in Google Sheets, and each assignment could take 5–15 minutes.

Country, language, shift, leave, capacity, and previous ownership all affected the decision. The rules were complicated, but the decision itself was not ambiguous. We knew what should happen in each case.

That is why the real-time lead management system we built for Vanity did not ask AI to make the initial assignment. Software applied the rules and passed the result to the CRM. Routing became real time, and accuracy rose above 99%.

Today, the same problem could easily be pitched as an AI project. AI would not have improved the solution. What we needed was software that applied known rules consistently.

Complexity and uncertainty are different problems

Suppose a team wants to use AI in customer support because customers are waiting too long. The delay could have several causes. If agents struggle to interpret irregular customer messages, a language model may help. If the correct answer already exists but agents cannot find it, better search may be enough. If the decision has been made but cannot reach the order system, the problem is integration.

From the outside, all three cases look the same: the customer waits. The right intervention changes with the reason for the delay.

Google's guide to framing machine-learning problems recommends defining the desired outcome without referring to machine learning, then comparing the proposed system with the current method or a simple rule. If the problem cannot be explained without mentioning AI, the description is probably still centred on the solution.

AI earns its place when the work requires interpreting irregular information or making a judgment that does not fit fixed rules. When the job is to apply rules we already know or move data between systems, conventional software is usually the better tool. Adding a model to a predictable task can make the result needlessly variable.

AI had a narrow but necessary job in REDAR

REDAR is an AI-assisted financial product that monitors KAP disclosures and open sources. Because of data-licensing constraints, it remains a private system used by a friend and me rather than a public platform. It extracts important information and delivers it through a web interface and Telegram.

REDAR can parse standard KAP data with deterministic rules. Those rules stop working when a disclosure or an open-source article arrives as irregular text. That is where we use a language model to extract the information we need and prepare a summary.

We did not hand the entire workflow to an LLM. Structured content follows a deterministic path. The model enters where uncertainty increases. Telegram delivery matters as much as the model: a good summary has little value if it does not reach the right person at the right time.

We faced a different problem when we wanted bank transactions inside an internal finance dashboard. Instead of integrating with each bank separately, we used an integration provider. Connecting to one bank was not the real burden. The burden was keeping 30–40 different bank connections running as their interfaces changed. We needed a provider willing to own that maintenance, not a model.

Vanity needed explicit rules. The finance dashboard needed a maintained integration. REDAR needed a language model for irregular text. All three used technology; only one needed AI.

A recommendation and an action carry different risk

Misclassifying a customer message is not the same as initiating the wrong money transfer. What the system is allowed to do determines which errors the business can tolerate.

The NIST AI Risk Management Framework asks the same practical questions: where will the model be used, and what happens when it fails? An error may be caught and corrected when a model only prepares information. The same error becomes an operational event when the system sends a customer reply, starts a payment, or rejects an application.

The system boundary therefore belongs at the beginning of the design. Irreversible actions, autonomous execution, and situations where a person cannot intervene in time require tighter controls.

Saying “a human approves it” is not enough. If the reviewer merely clicks through the model's decisions, the approval step may provide no real control. A person without the information, time, or authority to challenge the recommendation is not an effective safeguard. The process has only moved responsibility elsewhere.

Solve the problem before choosing the model

Write down the business outcome that should change. Then test whether an integration, SQL query, explicit rules, or conventional software can solve the problem. If AI is still necessary, define which data the model may use, what happens when it is wrong, and which actions it may take on its own.

Eliminating AI at this stage is not a bad result. It was the right decision for Vanity. In REDAR, the same process left the model with a narrow but valuable job.

Model selection comes after that. I explain the broader reason in Start With the Business Problem, Not the AI Model.