De cinco dias para trinta minutos: IA numa esteira de ETL

Quando assumi a operação de dados na Liquid AI, receber a base de um cliente e entregá-la pronta na pipeline levava em torno de cinco dias. Quando saí, em setembro de 2026, levava até trinta minutos.

Esse número costuma provocar a pergunta errada: “qual modelo vocês usaram?”. O ganho não veio de um modelo. Veio de tirar o trabalho manual do caminho, pôr a IA onde ela de fato ajuda, cercar com testes o que ela pode errar e transformar o prazo numa regra do sistema, e não numa planilha.

Este texto conta como foi, sem nomes de cliente e sem dados. O que importa aqui é a arquitetura e as decisões.

O problema

A esteira transforma bases de incorporadoras em indicadores de financiamento imobiliário dentro dos produtos da empresa. São mais de vinte clientes, e cada um manda seus dados do seu jeito: formatos diferentes, colunas com nomes diferentes, convenções diferentes para a mesma informação.

Antes, cada base era um pequeno projeto. Alguém recebia o arquivo, quase sempre uma planilha, entendia o formato daquela vez, tratava os dados à mão e só então colocava na pipeline. O tratamento era um conjunto de notebooks rodados um cliente de cada vez, e o conhecimento de “como a base do cliente X costuma vir” morava na cabeça de quem já tinha feito.

E o controle de tudo isso vivia numa ferramenta de terceiros, desconectada do trabalho. Saber em que fase estava cada base, quem era o responsável e se ia atrasar dependia de alguém atualizar um quadro.

Cinco dias não eram cinco dias de processamento. Eram cinco dias de fila, de espera e de retrabalho.

Primeiro, a automação. Depois, a IA

A tentação, em 2026, é começar pela IA. Eu comecei pelo contrário: automatizar tudo o que era previsível.

A leitura e a preparação dos dados viraram serviços, disparados por chamada e não por pessoa. O desenho separa o que muda do que não muda: o jeito de ler a base de cada cliente fica nas bordas, e a regra que prepara os dados fica estável no meio. Cliente novo vira uma peça nova na borda, não um if a mais no meio da regra. (O nome disso é arquitetura hexagonal; a engine é escrita em Python e roda no Google Cloud.)

A IA entra depois, ajudando naquilo que é ambíguo: o que uma regra fixa não resolve bem, porque cada cliente descreve a mesma coisa de um jeito. Ela acelera a parte que antes exigia uma pessoa interpretando o arquivo. O que é previsível continua em regra fixa.

Essa ordem importa. IA em cima de um processo manual só deixa o processo manual mais rápido de errar. IA em cima de um processo automatizado resolve a sobra que a automação não alcança.

A operação ganhou um produto

O segundo movimento foi tirar o controle da ferramenta de terceiros e trazer para dentro de casa. Construí o Play Manager, um produto interno que virou a fonte da verdade da operação: fase, responsável, prazo e saúde de cada base, num lugar só, para o time e para a liderança. (Por baixo, React 19 e uma API própria em Hono sobre Firebase, com controle de acesso por papel e um editor de insights assistido por IA.)

O passo que fez diferença foi levar a automação para dentro dele. A preparação dos dados passou a ser disparada pela própria tela, e não por alguém rodando um script. Três propriedades sustentam isso:

• Fila. Cada base entra numa fila em vez de competir por atenção, e nada se perde porque alguém esqueceu.
• Repetir não estraga. Disparar duas vezes a mesma etapa não duplica o resultado. Parece detalhe até alguém clicar duas vezes num botão, ou até uma etapa falhar no meio e precisar ser refeita. (Em engenharia, isso se chama idempotência.)
• Uma etapa puxa a próxima. Quando uma etapa termina, a próxima entra na fila sozinha. A esteira anda sem alguém empurrar.

É aqui que boa parte dos cinco dias desaparece. Não porque algo processa mais rápido, mas porque a base não fica parada esperando a próxima pessoa.

Como as peças se conectam

Os dados continuam chegando em vários formatos, e quase sempre sobem pelo próprio card da base. Dali em diante, nada depende de alguém lembrar: todo trabalho entra numa fila, cada etapa concluída avança o card e põe a próxima na fila, e uma base com problema não segura as outras. Quando algo sai do esperado, o card mostra um alerta em vez de travar a esteira. O controle é a ação aparecer só quando dá para executá-la, em vez de um bloqueio que alguém precisa destravar.

O prazo virou regra do produto

Prazo em planilha é uma intenção. Descobre-se o atraso depois que ele aconteceu.

No Play Manager, o prazo de entrega é regra do sistema. Cada fase tem um orçamento de tempo, e cada base é classificada automaticamente em uma de três situações: no prazo, em risco ou atrasada.

Cada fase tem dono: preparar a base é do time de dados, e daí em diante é dos analistas. O responsável troca sozinho quando a base muda de fase, então ninguém precisa lembrar de passar o bastão.

A diferença entre “em risco” e “atrasada” é o ponto todo. Com ela, a gestão vê o atraso chegando enquanto ainda dá para agir, em vez de constatá-lo depois do vencimento. A conversa deixa de ser “por que atrasou?” e vira “o que fazemos com essa que está em risco?”.

Onde a IA pode errar, testes

Uma esteira de dados tem um modo de falha cruel: ela não quebra, ela entrega errado. Um número preparado de um jeito sutilmente diferente passa por todas as etapas, chega ao indicador e ninguém percebe.

Por isso a velocidade veio junto com uma rede de testes:

• A engine de preparação é sustentada por mais de 4.800 testes automáticos. Os que mais importam numa mudança assim são os que comparam o resultado de antes com o de depois, para garantir que uma alteração não muda o que deveria continuar igual.
• Dois pipelines que já rodavam em produção não tinham nenhum teste automatizado. Escrevi 920 testes, levei a cobertura de 0% para 84% e 92%, e o deploy passou a ser bloqueado sempre que a suíte falhava.

Com IA no meio do processo, isso deixa de ser boa prática e vira requisito. O teste é o que permite deixar a IA ajudar sem ter que conferir cada saída à mão. Vale para o código também: o que eu escrevia com IA passava por teste antes e por portões antes de cada commit, e contei esse fluxo em Fluxo RPI com três agentes.

A virada sem trauma

Ferramenta nova costuma falhar por um motivo que não é técnico: o time precisa reaprender a trabalhar.

Conduzi a migração replicando no Play Manager os padrões de interação que o time já dominava na ferramenta anterior. Quem usava o sistema antigo encontrava no novo os mesmos caminhos. A carteira inteira migrou sem nenhuma divergência que bloqueasse a operação.

Não foi a parte mais interessante tecnicamente, mas foi uma das que mais pesaram no resultado. Um produto melhor que ninguém adota não reduz prazo nenhum.

O que fica

Se eu tivesse que resumir em três decisões:

1. Automatizar antes de pôr IA. A IA resolve a sobra ambígua; o que é previsível vira código.
2. Tirar a fila da cabeça das pessoas. Fila, repetição segura e uma etapa puxando a próxima fazem a base andar sozinha.
3. Transformar intenção em regra. Prazo com orçamento por fase, deploy bloqueado quando o teste falha. O que depende de alguém lembrar acaba esquecido.

Os cinco dias não sumiram porque um modelo ficou mais esperto. Sumiram porque o trabalho parou de esperar.

sys.exit(0)