How to automate business processes with AI

Many AI initiatives in companies start with a question like “where can we use this tool?”. The more useful question is a different one: which process today consumes time, generates errors or delays customers, and which part of it can be done by a machine safely?

This article is a practical roadmap for answering that question. It covers how to choose processes, how to map them, where AI fits alongside traditional automation, where to keep a person in the loop and what personal data and operational precautions you need to take. To find out whether the project is worth what it costs, see the companion article on how to calculate the return on investment in AI.

Start with the process, not the tool

A business process is a repeatable sequence of steps that turns an input (an order, an email, an invoice) into a result (a completed registration, a reply sent, a payment approved).

Automating means transferring steps of that sequence to software. AI is just one of the possible kinds of software. In many cases, the part that pays off most requires no AI at all.

McKinsey’s annual survey on AI reinforces this point, with the caveat that it is an opinion survey of executives and professionals. In the edition published in August 2026, with 1,719 respondents from 97 countries, the group the consultancy calls “high performers” (about 6% of the sample) stands out for redesigning workflows around AI, rather than just fitting the tool into the old workflow. Almost three quarters of that group say they have fundamentally redesigned workflows, compared with a quarter of the rest (McKinsey, The state of AI in 2026). This is a correlation reported by the respondents themselves, not proof of cause. But it is consistent with the idea of looking at the whole process before choosing the technology.

How to choose candidate processes

Before opening any tool, list the processes that cause friction and put each one through five questions.

1. Volume. How many times a week does it happen? Automating something that occurs three times a month rarely justifies the effort of building and maintaining it.
2. Standardization of inputs. Are the cases similar to one another? Structured forms are easier than free-form emails, which in turn are easier than phone conversations.
3. Verifiability. Can you know, objectively, whether the result is right? A ticket classification can be checked. A “good reply” to a customer is harder to assess.
4. Cost of error. What happens if the machine gets it wrong? A wrong label on an internal ticket is cheap. A wrong credit refusal directly affects the customer and can have legal consequences.
5. Available data. Is the necessary information accessible, in systems the automation can read, and do you have a legal basis to use it?

Processes with high volume, similar inputs, a verifiable result and cheap errors are the best first candidates. Processes with costly errors are not off-limits, but they call for more human control and more documentation, as we will see below.

An editorial article by information systems researchers describes a useful phenomenon here: the “long tail of work”. A few types of case account for most of the volume and are usually automated first; many rare types end up handled manually, with people acting as the “glue” between systems (van der Aalst, Bichler and Heinzl, 2018). The authors note that the end of this tail still needs people. In practice, expect to automate most cases, not all of them.

Map the process before automating

Mapping means drawing how the process works today, honestly. You do not need special software: a spreadsheet or a board with steps will do. Record:

• Trigger and input. What starts the process and in what format the information arrives.
• Steps and owners. Who does what, in which system.
• Decisions. Where someone chooses between paths, and on what basis. Separate decisions that follow a written rule from those that depend on judgment.
• Exceptions. The cases that fall outside the norm and what is done with them. They tend to be few in volume and many in time.
• Personal data involved. Which data, whose and for what purpose.
• Current numbers. Volume, time per case, error or rework rate, time to completion.

The last item is the most often forgotten and the most important. Without a baseline (the measure of how the process works before the change), you cannot later prove that the automation improved anything. The AI risk management framework from NIST, the US standards institute, lists precisely the absence of a baseline for comparison with human performance as one of the difficulties in measuring AI systems that replace or augment human activities (NIST AI RMF 1.0, 2023).

Rules, RPA or AI: where each one fits

Once you have the map, look at each step and ask which type of automation suits it.

Type	What it does	Works well when	Weak point
Rules and integrations (APIs, workflows)	Runs fixed “if this, then that” logic between systems	Structured data and a stable rule	Cannot handle free text or variation
RPA	Software robots operate other systems’ interfaces as a person would	Legacy systems without integration, simple repetitive tasks	Can fail or make mistakes when screens and context change
Generative AI (LLMs)	Reads and produces text, extracts fields, classifies, summarizes, suggests replies	Varied natural-language inputs, tasks with room for judgment	Can be confidently wrong; results vary

RPA (robotic process automation) deserves an explanation. The article by van der Aalst and co-authors defines it as an umbrella term for tools that operate other systems’ interfaces the way a human would, without changing those systems. The same authors warn of a risk that also applies to AI: robots that imitate people may start making wrong decisions when the context changes, and this may go unnoticed for some time.

Generative AI, in turn, is based on large language models (LLMs), which generate text by predicting the most likely continuation (see what LLMs are). This makes them useful for dealing with what rules cannot reach, such as a free-form email. It also makes them prone to hallucinations, that is, false answers presented with confidence.

In the editorial team’s assessment, the most robust design usually combines all three: rules and integrations for what is predictable, AI to interpret the variable part, and automatic validations between one step and the next. A hypothetical example from the editorial team: in an accounts payable process, AI extracts the supplier, amount and due date from PDF invoices; a fixed rule checks whether the supplier is registered and whether the amount matches the purchase order; only the discrepancies go to a person.

When AI starts carrying out actions in sequence, using tools and systems, we are talking about agents (see what AI agents are). They expand what can be automated and also expand the possible damage from an error.

Where to keep a person in the loop

Human-in-the-loop is the design in which a person reviews, approves or corrects the machine’s result before it takes effect. NIST describes a spectrum of configurations between fully autonomous and fully manual: the system can decide on its own, refer the decision to an expert or serve as a second opinion for the decision-maker. Some systems need no human oversight; others require it (NIST AI RMF 1.0).

A rule of thumb for deciding the level:

• Automatic, with sampling. Cheap, reversible errors, such as labeling internal tickets. A person checks a periodic sample.
• Automatic with an exceptions queue. The system resolves the clear cases and sends those with low confidence or that fail a validation to review.
• Suggestion with approval. Actions with external effects or that are hard to undo, such as sending a message to a customer, paying, deleting data or changing a record. The machine prepares; the person approves.

The list of risks for LLM applications from OWASP, a reference community in software security, recommends exactly this kind of human approval for high-impact actions. In the 2025 edition, it treats excessive agency as a vulnerability: giving the system more functions, permissions or autonomy than the task requires (OWASP LLM06:2025).

Human review only works if it is real. NIST suggests collecting data on how often and why people override the system’s result. If no one ever disagrees, the review may have become a rubber stamp.

There is also evidence that the human role changes but does not disappear. In a study of more than 5,000 support agents, access to an AI assistant increased the number of tickets resolved per hour by about 15% on average. The gain was greatest among the least experienced; among the most experienced, there was a small gain in speed and a small drop in quality (Brynjolfsson, Li and Raymond, revised version of 2024). The result applies to that context and that tool, not as a general promise. For customer service specifically, see AI in customer service.

Personal data and the LGPD

If the process involves people’s data, the LGPD (Brazil’s General Data Protection Law, Law No. 13,709/2018) applies to automation as it does to any other processing. Four points deserve attention (consolidated text of the LGPD):

• Purpose and necessity (Article 6). Use data for legitimate purposes disclosed to the data subject, limited to the minimum necessary. Sending a customer’s full history to an AI model when the task only needs the order number goes against this principle.
• Automated decisions (Article 20). The data subject may request a review of decisions made solely on the basis of automated processing that affect their interests, including those that define consumer and credit profiles. The controller must disclose, when requested, the criteria and procedures used, subject to commercial and industrial secrecy.
• Security by design (Article 46). Technical and administrative protection measures must be observed from the design phase of the product or service.
• Vendors. If the AI model runs on an external service, that vendor processes data on your behalf. Check the contract, processing location and data retention before sending any personal information.

The ANPD, Brazil’s national data protection authority, recommends preparing a personal data protection impact report (RIPD) when processing may pose a high risk, preferably before starting. As a benchmark, the ANPD’s page indicates high risk when there is at least one general criterion (such as large scale) and one specific criterion. The specific ones include the use of emerging or innovative technologies and decisions made solely on the basis of automated processing (ANPD, page on the RIPD, updated in September 2026). Large-scale AI automation over customer data tends to fit this profile. This article is not a substitute for legal advice on your case.

Operational risks and how to contain them

Beyond personal data, AI automation brings operational risks. The main ones:

• Errors that look correct. The model may invent a field that was not in the document. Contain this with automatic validations (does the CNPJ, Brazil’s company registration number, exist? does the amount match?) and with reviewed samples. See how to evaluate AI responses.
• Instruction injection. When the system reads external content, such as emails, attachments or web pages, someone can hide instructions there that change the model’s behavior. OWASP calls this prompt injection and states that no defense is foolproof. The recommended measures are least privilege, human approval for sensitive actions and clear separation of untrusted content (OWASP LLM01:2025).
• Overly broad permissions. Give the automation read-only credentials when it only needs to read, and have actions run with the identity and limits of the person using it, as OWASP recommends.
• Silent change. Screens change, vendors update models, the kind of request changes. Monitor quality indicators continuously, not just at launch.
• No way out. NIST recommends having defined mechanisms and owners to suspend or deactivate a system that produces results outside its intended use. In practice: know how the process goes back to being manual if needed, and who decides that.

A six-step roadmap

1. Choose a process with high volume and cheap errors, using the five questions.
2. Map and measure the current situation: steps, exceptions, personal data and baseline.
3. Redesign the workflow, deciding step by step between rule, RPA, AI or person.
4. Define controls: level of human review, minimal permissions, validations, decision logging and, if there is a high risk to personal data, the RIPD.
5. Run a pilot with limited scope and compare the numbers with the baseline. The article on AI ROI in business details how to design this comparison.
6. Scale up gradually, keeping monitoring and the plan to return to manual.

If you want to understand why so many projects stall at the pilot stage, see why AI projects fail.

Takeaways

• Choose processes by volume, standardization, ease of verifying the result and cost of error, not by the novelty of the tool.
• Map and measure before changing. Without a baseline, there is no way to know whether the automation improved anything.
• Use rules and integrations for the predictable and AI for the variable, with validations between steps.
• Match human review to the cost of error and manually approve actions that are hard to undo.
• Handle personal data with a clear purpose and the minimum necessary, assess whether an RIPD is needed and always have a way back to the manual process.