artigosarticles
6 min

Aferia: automação em que cada passo declara o que éAferia: automation where every step declares what it is

Do trabalho observado à automação rodando: como o Aferia mede o que vale automatizar e separa o que é regra fixa do que é decisão de IA — que pode dizer “não sei”.From observed work to running automation: how Aferia measures what's worth automating and separates fixed rules from AI decisions — which are allowed to say “I don't know”.

#ia#automação#produto #ai#automation#product

Em junho escrevi sobre por que tantos projetos de IA fracassam: quase sempre, colocamos uma ferramenta probabilística para fazer um trabalho que exige exatidão. O Aferia é o meu jeito de levar essa ideia a sério num produto de automação de processos.

O problema começa antes da automação

Empresas sabem que têm trabalho manual caro. O que elas raramente têm é uma descrição precisa desse trabalho — precisa o suficiente para automatizar. O levantamento tradicional (entrevistas, workshops, alguém olhando por cima do ombro) é lento, depende da memória de quem executa e fica desatualizado quase na mesma semana.

O Aferia começa observando. Um app para Windows captura eventos, não vídeo: qual campo foi preenchido, qual botão foi clicado, em qual aplicativo — a partir da UI Automation do próprio sistema, com screenshots seletivos e narração por voz quando faz sentido. Isso é mais útil para a IA e muito menos invasivo para quem está sendo observado. Não guardamos tudo o que passa na tela; guardamos o que aconteceu.

Perguntar em vez de inferir

A maior fonte de erro em mineração de tarefas é deduzir intenção a partir de cliques. Por que o operador pulou aquele cliente? Foi exceção ou é regra? A IA pode chutar uma resposta plausível — e errar com muita confiança.

No Aferia, quando a dúvida aparece, a IA pergunta. Na sessão pareada — uma call de levantamento com consultor e cliente juntos — isso acontece ao vivo: a análise roda enquanto o cliente demonstra o processo, sugere perguntas ao consultor e pede ao cliente que mostre de onde vem um dado. A resposta vira documentação na hora. No modo solo, as dúvidas saem da análise ao fim da sessão. Ninguém precisa lembrar, semanas depois, por que fez o que fez.

O que vale automatizar, em reais

Uma sessão gera um mapa de processo. Um cliente gera dezenas de sessões, e cada uma aponta candidatos a automação — muitos deles a mesma coisa descrita de jeitos diferentes. A IA consolida esse acervo num backlog de oportunidades: agrupa o que é igual, soma as evidências e pontua cada item em horas por ano e reais por ano, a partir de frequência, duração e número de pessoas afetadas.

Os números são medidos na captura, não opinados numa reunião — e, ainda assim, ficam editáveis na frente do cliente, porque a frequência mensal é extrapolada de uma amostra. Cada linha do backlog desce até a sessão e o trecho que a originaram. A conversa deixa de ser “eu acho que isso toma tempo” e passa a ser “isso custou tantas horas no período observado; ajusta se não bate”. A Jornada leva isso para períodos mais longos de trabalho autorizado, com análise em lote, para encontrar as próximas oportunidades.

Cada passo declara o que é

Aqui entra a ideia de junho. Quando uma oportunidade é aprovada, a IA constrói a automação — o pacote com os passos, o código e um procedimento em português que o cliente consegue ler. Mas quem executa, na máquina do cliente, é um runner que nunca chama um modelo de IA diretamente.

Cada passo do fluxo declara a sua natureza. Os passos de requisição, navegador e script são determinísticos: fazem sempre a mesma coisa. Quando existe uma decisão que não cabe numa regra — classificar um documento ambíguo, por exemplo —, ela vira um passo do tipo ai, marcado no fluxo, com justificativa. Esse passo tem uma obrigação que nenhum outro tem: pode, e deve, dizer “não sei”. E “não sei” nunca vira chute; vira uma pergunta para uma pessoa.

Algumas regras são travadas por validação, não por boa vontade. Um passo de IA que leva a uma escrita irreversível só pode existir em modo de aprovação, com a prévia na frente de alguém. A automação só roda em produção depois que o cliente leu e aprovou aquela versão. E o produto não automatiza login: quem entra no sistema é a pessoa; a automação reaproveita a sessão.

Quando a automação não compensa, o produto diz

O risco da automação assistida é entregar algo que interrompe tanto que ninguém usa. O Aferia mede isso. Toda vez que uma execução pede ajuda humana, o tempo de espera é cronometrado. Se ela precisou de gente mais de três vezes, ou passou mais de 30% do tempo esperando alguém, recebe um veredito explícito — nao_compensa_ainda — e volta para o consultor com os números na mão.

Dizer “ainda não compensa” com evidência vale mais do que entregar algo que vai ser abandonado em silêncio. E essas interrupções medidas voltam para o backlog: “eliminar o login manual do portal do fornecedor” deixa de ser opinião e vira uma linha com horas e reais.

O cliente conserta sem abrir chamado

Duas semanas depois de qualquer automação entrar no ar, aparece o caso que ninguém previu. O caminho normal — chamado, fila, call, reprodução, ajuste — leva semanas, e nesse meio-tempo o operador volta a fazer à mão.

No Aferia, o cliente escreve o problema na página da automação, em português: “errou nos boletos que já estavam pagos”. A IA junta o que de fato aconteceu — a versão que rodou, o log e os artefatos daquela execução — e devolve uma versão corrigida em rascunho, com a explicação do que muda em linguagem de negócio. Nada vai para produção sozinho: alguém revisa e aplica, e a versão nova entra no histórico com o diff contra a anterior.

Onde ele está

O Aferia está no ar em aferia.tech, com app para Windows 10 e 11, em português e inglês, construído sobre o Claude e com a LGPD como parte do desenho, não como remendo. Ele sustenta um modelo de consultoria de automação: o consultor conduz o diagnóstico e revisa o que a IA propõe, em vez de começar tudo do zero.

A tese é a mesma de junho, agora em código: a IA trabalha onde brilha — entender, organizar, propor, construir — e a execução fica com o que é previsível. Onde a IA precisa decidir, a decisão é marcada, justificada e tem permissão para parar.

In June I wrote about why so many AI projects fail: almost always, we put a probabilistic tool on a job that demands exactness. Aferia is my way of taking that idea seriously in a process-automation product.

The problem starts before the automation

Companies know they have expensive manual work. What they rarely have is a precise description of that work — precise enough to automate. Traditional discovery (interviews, workshops, someone looking over a shoulder) is slow, depends on the memory of whoever does the job and goes stale almost within the week.

Aferia starts by observing. A Windows app captures events, not video: which field was filled, which button was clicked, in which application — through the operating system’s own UI Automation, with selective screenshots and voice narration when it makes sense. That’s more useful to the AI and far less invasive for the person being observed. We don’t keep everything that crosses the screen; we keep what happened.

Asking instead of inferring

The biggest source of error in task mining is deducing intent from clicks. Why did the operator skip that customer? Was it an exception or the rule? The AI can guess a plausible answer — and be wrong with great confidence.

In Aferia, when a doubt shows up, the AI asks. In a paired session — a discovery call with the consultant and the client together — this happens live: the analysis runs while the client demonstrates the process, suggests questions to the consultant and asks the client to show where a piece of data comes from. The answer becomes documentation on the spot. In solo mode, the questions come out of the analysis at the end of the session. Nobody has to remember, weeks later, why they did what they did.

What’s worth automating, in money

One session produces a process map. One client produces dozens of sessions, and each points at automation candidates — many of them the same thing described in different ways. The AI consolidates that collection into an opportunity backlog: it groups what’s the same, stacks up the evidence and scores each item in hours per year and reais per year, from frequency, duration and the number of people affected.

The numbers are measured in the capture, not voiced in a meeting — and even so they stay editable in front of the client, because the monthly frequency is extrapolated from a sample. Every backlog line drills down to the session and the excerpt it came from. The conversation stops being “I think this takes a while” and becomes “this cost this many hours in the observed period; adjust it if it doesn’t match”. Journey (Jornada) extends this to longer stretches of authorized work, with batch analysis, to find the next opportunities.

Every step declares what it is

This is where June’s idea comes in. When an opportunity is approved, the AI builds the automation — the package with the steps, the code and a plain-language procedure the client can read. But what runs it, on the client’s machine, is a runner that never calls an AI model directly.

Every step in the flow declares its nature. Request, browser and script steps are deterministic: they always do the same thing. When there’s a decision that doesn’t fit a rule — classifying an ambiguous document, say — it becomes an ai step, flagged in the flow, with a justification. That step has an obligation no other step has: it can, and must, say “I don’t know”. And “I don’t know” never becomes a guess; it becomes a question for a person.

Some rules are locked in by validation, not goodwill. An AI step that leads to an irreversible write can only exist in approval mode, with the preview in front of someone. An automation only runs in production after the client has read and approved that version. And the product doesn’t automate logins: the person signs in; the automation reuses the session.

When automation isn’t worth it, the product says so

The risk with assisted automation is shipping something that interrupts so often nobody uses it. Aferia measures that. Every time a run asks for human help, the waiting time is clocked. If it needed a person more than three times, or spent more than 30% of its time waiting on someone, it gets an explicit verdict — nao_compensa_ainda, “not worth it yet” — and goes back to the consultant with the numbers in hand.

Saying “not worth it yet” with evidence is worth more than shipping something that will be quietly abandoned. And those measured interruptions flow back into the backlog: “eliminate the manual login to the supplier portal” stops being an opinion and becomes a line with hours and money.

The client fixes it without opening a ticket

Two weeks after any automation goes live, the case nobody foresaw shows up. The usual path — ticket, queue, call, reproduction, fix — takes weeks, and meanwhile the operator goes back to doing it by hand.

In Aferia, the client writes the problem on the automation’s page, in plain language: “it got the invoices that were already paid wrong”. The AI gathers what actually happened — the version that ran, the log and the artifacts of that run — and returns a corrected version as a draft, with an explanation of what changes in business terms. Nothing goes to production on its own: someone reviews and applies it, and the new version enters the history with a diff against the previous one.

Where it stands

Aferia is live at aferia.tech, with a Windows 10 and 11 app, in Portuguese and English, built on Claude and with Brazil’s data-protection law (LGPD) as part of the design, not a patch. It backs an automation-consulting model: the consultant leads the discovery and reviews what the AI proposes, instead of starting everything from scratch.

The thesis is the same as in June, now in code: AI works where it shines — understanding, organizing, proposing, building — and execution stays with what’s predictable. Where the AI has to decide, the decision is flagged, justified and allowed to stop.