The short answer
To automate processes with AI, start with the repetitive task that eats up your team's hours, measure what it costs today and run a small pilot with human review before any action. Use rules where the input has a fixed format and AI where free text has to be read, classified or summarized.
The rest is discipline: handling data in line with Brazil's data protection law (LGPD) from the design stage, recording what the AI suggested and who approved it, and only scaling up when the accuracy rate, measured with data from your operation, shows the gain is real. Automation that isn't measured becomes opinion, and opinion doesn't support the decision to invest in the next step.
Start with the task, not the technology
A good automation doesn't start with the trendy tool. It starts with the task that takes up hours of your team's time every week and doesn't call for judgment each time. When the conversation starts with the AI model, the project ends up looking for a problem to fit the solution.
The tasks that tend to pay off look alike in almost every company:
- Typing and retyping. Data that arrives by email, PDF or spreadsheet and has to be entered into another system, one by one.
- Manual checking. Cross-checking reports, verifying records and hunting for discrepancies, line by line.
- High-volume reading. Documents, tickets and messages that someone has to read just to classify, summarize or route.
- Reports built by hand. Metrics that depend on someone pulling numbers together from different sources at the end of the month.
A good test is to ask the team which task they would like to stop doing by hand. The answer usually points to the automation with the biggest gain and the least resistance. If there is more than one candidate, the guide on which processes to automate first shows how to compare and choose.
Step by step to automate a process with AI
The approach we follow has five steps. It works for a simple rule-based automation and for a flow with AI, because the logic is the same: understand, measure, test small and only then grow.
- Map. Work out with the people who do the task how it really happens: where the information comes from, who touches it, where it goes and where errors show up. The real flow is almost never the one in the manual.
- Measure. Record how things stand today: how many times the task happens per week, how long each one takes, how many come back for correction. Without that number, there is no way to prove the gain later.
- Choose. Decide what to automate first based on the effort saved and the risk involved, and define for each step whether it calls for a rule, an integration between systems or AI.
- Pilot with human review. Build a single automation, test it with data from your operation and keep a person checking every suggestion before it turns into action. The pilot exists to measure the accuracy rate, not to impress.
- Scale up. When the result holds, increase the volume, reduce review in the cases where the AI is comfortably accurate and move on to the next task on the list. Monitor in production and adjust when the process or the data change.
This short cycle is the same one we use in software projects: deliver something that works, test it with the people who use it and adjust course based on what real use shows. The details of each stage are in how we work.
Rule-based automation or AI: when to use each
Much of automation doesn't use artificial intelligence at all. Clear business rules, such as "if the amount matches, record it; if it doesn't, flag it", become system routines, with a record of who did what and when. API integrations let data be entered once and reach the other systems on its own, with no retyping.
AI comes in where free text has to be read: language models read documents and messages, extract the fields and suggest a classification for a person to confirm. The table sums up the difference:
| Criterion | Rule-based automation | AI-based automation |
|---|---|---|
| Input | Fixed format: standardized spreadsheet, form, data coming from another system | Free format: email, PDF, message, scanned document |
| Example | Checking whether the invoice amount matches the order and recording it | Reading a bill sent by email and extracting supplier, amount and due date |
| How it fails | Always fails the same way, when the rule is wrong or the case wasn't anticipated | Fails in varying ways, sometimes with a convincing but wrong answer |
| How to check it | Testing with known cases before going live | Human review and an accuracy rate measured with data from your operation |
| When to prefer it | Whenever the rule can be written down | When writing the rule is impossible or too costly |
In practice, the best flows combine the two. The AI reads the email and extracts the fields, the rule checks the amount against the order, and the integration posts the record to the finance system. Separating what is a rule from what is reading makes the automation cheaper to maintain and easier to audit. When the bigger challenge is getting systems to talk to each other, the article on how to integrate systems goes deeper.
In most cases, there is no need to replace the systems the company already uses. In the beacon monitoring we built for a healthcare facility, attendance numbers reach the dashboards management already used through an API, with no extra system for the team to open.
Where to put human review
In every flow we build there is a person responsible for the result. The practical question is at what point they step in. We use three criteria:
- Money, contracts or someone's rights. Every action that touches these goes through approval before it happens.
- What leaves the company. Every AI suggestion that goes outside, such as a reply to a customer, is reviewed before it is sent.
- Above the agreed limit. Actions above an amount or quantity agreed with the company become approval requests instead of being carried out.
The AI agent doesn't work on its own. It runs inside an environment set up for the company, with the instructions, the tools it can use and the rules it cannot break. This environment has a technical name: harness. If the rule says the agent doesn't make payments, an attempt becomes an approval request for the person in charge, not a transaction. The article on what AI agents are explains this design in detail.
Review doesn't have to stay the same forever, either. At first, the person checks everything. Once the accuracy rate is measured, simple cases can be spot-checked and full review kept where an error is costly.
LGPD in AI automation
Data protection isn't an item for the end of the project. The LGPD requires that the processing of personal data have a defined purpose, use only what is necessary for that purpose and be transparent to the data subject. In automation, this turns into concrete decisions before the first line of code: what can be sent to an AI model, what needs to be anonymized first, how long the data is kept and where it is processed.
It is also worth looking at the model provider. If text leaves your environment for an external service, you need to know what that service does with the data and whether the contract allows that use. And when a decision affecting someone is made solely by automated means, the law gives that person the right to request a review. Keeping a responsible person in the flow and recording who approved each decision helps answer that request.
We apply the same rule to our own work: client information only goes into authorized tools, handled in line with the LGPD, and the client knows in which stages and tasks AI was used. Sensitive information doesn't leave the environment without an explicit rule. For the specific precautions, see the article on LGPD and artificial intelligence.
How to measure the results of automation
AI models make mistakes, and the mistake isn't always obvious. That is why measurement starts before the pilot, with today's number, and continues after the automation goes into production. The indicators that help most with decisions are few:
- Time per task. How much time the team spent before and how much it spends now, including review time.
- Accuracy rate. In how many cases the AI's suggestion was approved without changes, measured with data from your operation and not with hand-picked examples.
- Correction rate. How many times the person had to correct or redo the work, and in what kind of case that happens.
- Errors that slipped through. How many problems showed up after approval, which are the ones that really cost money.
- Response time. How long the customer, the supplier or the other department waits for the result.
If the accuracy rate drops, something has changed: the document format, the type of request, the business rule. The record of what the AI suggested and what was approved shows where the deviation is and what to adjust. Without that record, the team notices things got worse but doesn't know why.
Does AI replace the team?
That isn't the design. AI takes over the repetitive reading and typing, and the team keeps the analysis and the decision. The gain we aim for is fewer errors, less rework and faster responses, with the same person responsible for the result.
If your team has a task they would like to stop doing by hand, tell us about it. The conversation alone helps separate what calls for a rule, an integration or AI. See also how our automation and artificial intelligence work is done.