Sistemas de AI que fazem o trabalho repetitivo do negócio

Fala-se de AI numa empresa e vem logo um chatbot à cabeça. A versão valiosa é um sistema que pega numa tarefa repetitiva que consome uma semana de uma pessoa, lê a entrada desorganizada, faz o trabalho, e devolve um resultado em que se pode confiar. O ganho mede-se em horas que desaparecem e margem que aparece, não na tecnologia. Este guia cobre o que estes sistemas fazem de facto, onde acaba o modelo e começam as regras, como saber onde compensam, e como se compra um sem o transformar num projeto de software.

O que conta como um sistema que faz o trabalho

Um sistema de AI útil pega num trabalho que uma pessoa faz da mesma maneira todas as semanas e faz a primeira passagem, de ponta a ponta. Lê uma entrada que chega sem formato fixo, transforma-a em algo estruturado, aplica as regras do próprio negócio, e produz um resultado que um humano pode aprovar ou enviar. A pessoa passa de fazer a tarefa a verificá-la, que é um trabalho diferente e muito menor.

As tarefas que vale a pena atacar têm um formato comum. São de volume alto, repetitivas, presas a regras, e prendem hoje o tempo de pessoas que se preferia a fazer outra coisa. Ler pedidos que chegam e encaminhá-los. Tirar campos de documentos e escrevê-los noutro sistema. Monitorizar algo em muitas fontes. Produzir o mesmo relatório todas as segundas. Nenhuma destas precisa do juízo de uma pessoa a maior parte do tempo, que é precisamente porque a pessoa detesta fazê-las, e precisamente onde um sistema bem construído recupera o seu custo.

Onde acaba o modelo e começam as regras

Esta é a decisão de desenho mais importante, e a que separa um sistema em que o negócio confia de uma demonstração engraçada que se deixa de usar em silêncio. Um modelo de linguagem é muito bom a ler texto desorganizado e a escrever uma resposta limpa. É a coisa errada a quem entregar uma decisão, porque não é consistente, não é auditável, e não explica o mesmo da mesma forma duas vezes.

Por isso, nos sistemas que construímos, o modelo lê e escreve, e as regras decidem. O modelo transforma um pedido em texto livre em campos estruturados. Depois, uma tabela de regras de negócio explícitas, em código, decide o que acontece: aceitar, declinar, referir, pedir mais. Quando um pedido é recusado e alguém pergunta porquê, há uma resposta concreta, uma regra com nome e condições, em vez de “a AI achou”. A mesma entrada produz sempre a mesma decisão, seja quem for a submetê-la ou como a escreva. E o cliente é dono dessas regras e altera um limiar sem chamar um programador.

Esta divisão importa por uma razão que vai além da arrumação. É o que torna o resultado defensável, consistente e controlável, que são as três coisas de que um negócio precisa antes de deixar software tocar num processo real. Um sistema que não se explica é um sistema que se desliga na primeira vez que é posto em causa.

Duas regras que mantêm estes sistemas honestos

Nunca preencher uma falha com um palpite

Quando um campo obrigatório não está na fonte, o sistema assinala-o como em falta em vez de o estimar. Um valor inventado plausível é pior do que um espaço em branco, porque o branco é apanhado e um número errado com ar de certo não é. O trabalho do sistema é estar certo ou dizer que não sabe, nunca estar suavemente errado.

Manter um humano nas decisões que importam

O sistema faz a primeira passagem; uma pessoa mantém a decisão final sobre tudo o que tenha consequências. O desenho que funciona é uma fila de revisão: tudo aquilo em que o sistema tem confiança e que passa todas as verificações segue em frente, e tudo o que falha uma verificação ou fica abaixo de um limiar de confiança sobe para um humano, com o motivo explicado em linguagem simples. “Erro de validação” deixa quem revê a adivinhar. O alerta deve dizer “as linhas somam 1.845,00 € mas o documento indica 1.854,00 €, uma diferença de 9,00 €, provável troca de dígitos”. Quem revê confirma em segundos em vez de procurar o problema.

Como são estes sistemas na prática

Quatro exemplos de sistemas que construímos, descritos em termos gerais porque os clientes ficam anónimos.

Os dois sistemas abaixo, triagem de pedidos e extração de documentos, estão tratados a fundo nos seus próprios guias: como automatizar a triagem de pedidos e como automatizar a extração de dados de documentos.

Uma mesa de subscrição para seguros comerciais

Um pedido de seguro comercial nunca chega como formulário. Chega como um email do cliente, a mensagem de um colega, as notas de uma chamada. Alguém experiente tem de o ler, perceber que risco é aquele, verificar se cabe nos critérios acordados com as seguradoras, e responder. Construímos um sistema que faz a primeira passagem: lê o texto livre para uma ficha de risco estruturada, confronta-a com os critérios de subscrição da corretora, e prepara a resposta. Se faltar informação, redige o email a pedir exatamente o que falta, um elemento por linha. Se a atividade estiver fora de apetite, declina com clareza e oferece encaminhamento, em vez de fazer o cliente reunir documentos para um “não”. Se o risco é bom mas excede o limite de aceitação automática, encaminha para um subscritor com uma nota telegráfica do que há a decidir. A decisão fica com a pessoa; a leitura, a triagem e a redação deixam de consumir o dia.

Extração de documentos para um escritório de advogados

As faturas e os contratos chegam por três vias que não falam entre si: anexos de email, papel, digitalizações. Alguém abre cada um, lê os campos que interessam, e escreve-os outra vez no sistema de contabilidade. O custo real não é a digitação, é o que corre mal por baixo: um NIF com dois dígitos trocados que a contabilidade rejeita semanas depois, uma fatura que entra duas vezes e é paga duas vezes, um contrato que se renova sozinho porque ninguém reparou que o prazo de denúncia acabou. Construímos um sistema onde o documento entra, os campos são extraídos com um nível de confiança cada, e o resultado passa por validação determinística antes de chegar a olhos humanos. A validação não usa modelo nenhum: é aritmética e verificação de formato, o dígito de controlo do NIF, a soma das linhas contra a base, a base mais o IVA contra o total. Em Portugal, o QR obrigatório nas faturas desde 2022 traz dados já estruturados e certificados (NIF, total, decomposição do IVA, ATCUD), por isso ler o QR primeiro e usar o modelo só para o que sobra muda a economia do problema. Um documento que passe todas as regras com confiança alta é lançado sem intervenção; o resto sobe para revisão com o motivo explicado. Nos contratos, o campo que mais valor gera é o prazo de denúncia, porque alimenta os alertas de renovação, e é o mais traiçoeiro: quando um contrato diz uma coisa numa cláusula e outra noutra, o sistema assinala a contradição em vez de escolher uma.

Monitorização de preços da concorrência para um retalhista

Um retalhista precisava de acompanhar preços em cerca de cinquenta mil referências de sete concorrentes. Feito à mão, era uma semana de uma pessoa, todos os meses, e estava desatualizado assim que ficava pronto. O sistema faz o mapeamento de forma contínua, o que devolve essa semana e transforma uma fotografia mensal em informação atual pela qual o negócio consegue de facto orientar os preços.

Uma plataforma de gestão para um negócio de fitness

Um personal trainer geria o negócio à volta dos treinos: agenda, marcações, pipeline de vendas, faturação, seguro anual. Construímos uma plataforma que junta tudo isto num só sítio e usa AI para ler os dados e sugerir decisões sobre tipos de aula, horários e preços. O resultado prático foi que o negócio deixou de precisar de um apoio a part-time para manter a parte administrativa a andar, e o personal trainer voltou a dedicar-se a full-time àquilo em que é bom.

Onde é que a AI compensa de facto?

Não em todo o lado, e a resposta honesta a “devíamos usar AI aqui” é muitas vezes não. Começar pela ferramenta em vez da tarefa é a razão por que a maioria dos projetos de AI falha, e para um negócio mais pequeno o mapa do que vale a pena é mais estreito do que o hype sugere, tema de AI para PMEs. Uma tarefa é boa candidata quando é repetitiva, de volume alto, presa a regras, e feita hoje por uma pessoa cujo tempo vale mais noutro sítio. É má candidata quando é rara, exige juízo real de cada vez, ou quando o custo de um erro é alto e difícil de verificar. Passar meses a automatizar algo que acontece duas vezes por mês é como os projetos de AI perdem dinheiro.

É por isto que o trabalho começa por um diagnóstico e não por um build. Antes de escrever código, mapear os processos, encontrar onde o tempo humano está preso em tarefas repetíveis, e ordenar os candidatos por esforço face às horas e à margem que devolveriam. O output é uma lista curta de cinco a oito oportunidades ordenadas por retorno, e às vezes a linha mais útil dessa lista é a que diz que uma dada tarefa ainda não vale a pena automatizar. A Klevie corre isto com a mesma disciplina de diagnóstico do resto do negócio, o Growth Engine, para um sistema de AI ser construído porque os números o suportam, e não porque a AI está na moda.

Como se compra um sem começar um projeto de software

Há um risco real neste tipo de trabalho: derivar para um projeto de desenvolvimento, medido em scope e sprints, e cobrado à hora como uma dev shop. Isso não serve ninguém. A forma como o estruturamos mantém o foco no resultado.

Corre em três degraus, e expomos a abordagem toda em como comprar AI sem começar um projeto de software. Primeiro, um diagnóstico: um trabalho curto e pago que mapeia onde vive o trabalho repetitivo e quanto vale removê-lo, a terminar numa lista priorizada. Segundo, um sprint de implementação: seis a dez semanas, um ou dois sistemas em produção, âmbito fechado e entrega real. Terceiro, operação e evolução: o sistema é mantido a correr e melhorado à medida que o negócio muda. O preço segue o valor para o negócio, uma fee que cobre o custo operacional mais uma performance fee ligada ao resultado, em vez de uma fatura por horas de build. Compra-se horas removidas e margem recuperada, não linhas de código.

As partes que não são técnicas

As perguntas mais difíceis nestes projetos não costumam ser o modelo. Quando um sistema trata os documentos de clientes de um escritório de advogados, ou os dados de clientes de uma corretora, três coisas têm de ficar resolvidas antes do código, não depois: onde ficam alojados os dados e sob que condições de subcontratação, quem pode ver e aprovar o quê, e durante quanto tempo os originais são guardados e o que acontece quando esse prazo passa. Para trabalho regulado ou confidencial, isto significa alojamento na União Europeia, um contrato de subcontratação em condições, e um fornecedor de modelo com retenção zero. Tratar isto como parte do build, e não como reflexão tardia, é a diferença entre um sistema que pode ir para produção e um protótipo que nunca sai da demonstração.

Como saber se está a funcionar

Uma métrica interessa acima das outras: a percentagem de trabalho que o sistema completa sem intervenção humana. Tudo o resto é secundário. E uma métrica comum engana em silêncio: a precisão média da extração. Um sistema com 95% de precisão média pode ser inútil se os 5% de erro estiverem espalhados por documentos que parecem corretos, porque então não há fila de exceções, há erros silenciosos a entrar na contabilidade. O objetivo é o contrário. Errar pouco, e quando erra, saber que errou, para cair na fila de revisão em vez do lançamento. Um sistema em que se confia é um que é honesto sobre o que não sabe.

Essa honestidade é também a prova de que a casa constrói o que vende. O próprio sistema de diagnóstico da Klevie, o Atlas, foi construído sobre os mesmos princípios: o modelo lê e estrutura, o framework e a revisão humana decidem. Não comprámos a capacidade para falar dela. Construímos a nossa com ela.

Perguntas frequentes