Analista de Dados
& Automação

Contexto

O processo de autuação de veículos por evasão de pedágio dependia do robô de uma empresa terceirizada, com regras genéricas e pouco controle sobre o comportamento do sistema.

Problema

Taxa de sucesso de apenas 52%, custo recorrente de fornecedor externo e nenhuma visibilidade sobre por que um trânsito era ou não autuado corretamente.

Solução

Construí um robô próprio do zero: pipeline de visão computacional para ler a placa na foto do trânsito, um motor de regras de decisão em cascata (5 passos determinísticos) e integração direta com o sistema legado da concessão.

Desafios & soluções

• OCR em condições adversas (fotos noturnas, ângulos ruins) → múltiplas variantes de imagem processadas até a primeira leitura confiável.
• Múltiplos veículos na mesma foto → cruzamento de detector de veículo + detector de placa para achar o par correto.
• Ambiente Windows sem suporte a paths longos impedia instalar Torch/Ultralytics nativamente → contornado usando modelos convertidos para ONNX Runtime.
• Sistema legado não suporta sessões simultâneas → login escalonado entre workers para evitar quedas de conexão.

Contexto

Trânsitos marcados como "violação" precisavam de triagem manual antes de virarem autuação — checando isenções, TAG liberada e pagamentos duplicados.

Problema

Triagem manual levava quase duas horas por rodada e carregava risco real de autuar um trânsito com justificativa legítima não identificada a tempo.

Solução

Motor de decisão com árvore de 5 passos em ordem fixa (duplicidade → exceção de integração → isenção → TAG liberada → candidato real a evasão), que nunca grava a decisão final sozinho — casos sem exceção clara vão para fila humana.

Desafios & soluções

• Confusão de caracteres do OCR (0/O, S/5) → correção posicional baseada no formato conhecido de placa.
• TAG liberada não é garantia de pagamento → trava cruzando status de mensageria com leitura de antena.
• Bug identificado e corrigido em produção: uma regra genérica de "pagamento próximo, qualquer sentido" causou 5 cancelamentos incorretos — substituída por regra estrita (mesma praça e mesmo sentido).

Contexto

Trânsitos cujo pagamento por TAG foi perdido, ou que ficaram presos entre status de pagamento, dependiam de reprocessamento manual dentro do sistema legado de gestão de pedágio.

Problema

Receita não arrecadada por falha de pagamento não identificada, e trânsitos travados sem reprocessamento automático — além de uma API legada (ASP.NET WebForms) sem documentação alguma.

Solução

Reescrevi um robô que originalmente dependia de navegador (Playwright) para chamadas HTTP diretas — com scripts de diagnóstico dedicados para engenharia reversa do payload da API antes de codificar qualquer regra de negócio.

Desafios & soluções

• API sem documentação → script de diagnóstico dedicado para descobrir formato real de campos e respostas.
• Sessões instáveis sob concorrência → login escalonado entre workers (delay progressivo).
• Risco de duplicar uma ação de escrita → retry diferenciado por tipo de timeout (conexão vs. leitura).

Contexto

Relatórios mensais recorrentes de tráfego e receita (como o Relatório Mensal de Tráfego/VEP) dependiam de extração manual em portal legado, para múltiplas praças e tipos de relatório.

Problema

Processo repetitivo e demorado, sujeito a atraso e erro humano, repetido todo mês para cada concessão e cada variação de relatório.

Solução

Automação com Playwright rodando múltiplas instâncias de navegador em paralelo (uma por relatório), com captura resiliente de download e entrega automática no SharePoint/OneDrive corporativo, sempre no horário certo.

Desafios & soluções

• Portal sem API pública → seletores de UI com retry defensivo (scroll + clique forçado em dropdowns).
• 6-8 navegadores logando no mesmo sistema simultaneamente → atraso escalonado entre aberturas.
• Download sem evento nativo do navegador → fallback por interceptação de resposta de rede.
• Timeout duplo (máximo absoluto + ociosidade) para nunca travar indefinidamente esperando o sistema fonte processar.

Contexto

O processo de aprovação de ajuste de caixa rodava em planilhas sobrecarregadas, sem rastreabilidade formal do fluxo de aprovação.

Problema

Lentidão, dependência de intervenção manual em cada etapa e falta de governança sobre quem aprovou o quê e quando.

Solução

Desenvolvi um aplicativo de aprovação em Power Apps para a supervisão, com governança em listas do SharePoint e fluxos no Power Automate executando as regras de negócio de forma autônoma.

Desafios & soluções

Migrar um processo crítico de planilha para Power Platform sem perder nenhuma regra de negócio existente, mantendo rastreabilidade total do fluxo de aprovação.