Reduzindo a Entropia: Como a Engenharia da Enter Processa o Caos Jurídico
Veja como o squad de Monitoring transforma ruído processual em sinal limpo.
Na Teoria da Informação, a Entropia de Shannon1 quantifica a incerteza ou o grau de "surpresa" contido em uma fonte de dados. Sem dúvida nenhuma, o ecossistema judiciário brasileiro é um canal de altíssima entropia.
Com mais de 90 tribunais operando de forma descentralizada, o desafio não é a falta de regras, mas a alta variância técnica: sistemas heterogêneos, padrões de dados inconsistentes e instabilidades de sinal que tornam a captura de informações um problema complexo.
Esse blog post é o primeiro da série sobre como são divididos os squads de engenharia da Enter. Nele abrimos o capô do time de Monitoring. Nosso papel técnico vai além de mover bits; atuamos como um mecanismo de redução de entropia na origem.
Nesta primeira etapa do nosso loop de produto, processamos o sinal ruidoso do mundo externo para transformá-lo em informação estruturada e previsível.
A Escala do Input: 75 Processos por Minuto
Para entender a arquitetura do squad, precisamos olhar para os números. Segundo o relatório Justiça em Números 2025 (CNJ)2, ingressaram cerca de 39,4 milhões de novos processos nos tribunais brasileiros em 2024.
Isso significa que o Judiciário brasileiro publica aproximadamente 75 novos processos a cada minuto.
O squad de Monitoring é responsável por capturar, classificar e ingerir esse fluxo contínuo. Mas a complexidade não para no dado público. Operamos em um modelo híbrido, conectando-nos também aos "sistemas nervosos" das empresas (também conhecidos como ERPs).
Para domar essa complexidade, separamos nossa engenharia em dois motores distintos com padrões de projeto específicos: Public Discovery e Private Integrations.
1. Public Discovery: A Estratégia do Controller
O maior risco para nossos clientes é o "ponto cego": um processo que foi distribuído contra eles, mas do qual eles ainda não têm ciência. No front de dados públicos, nosso desafio é a descoberta.
Como monitorar algo que ainda não tem um ID conhecido na nossa base?
Para resolver isso, implementamos um Controller Strategy. Imagine o Controller como um orquestrador de um radar de longo alcance. Ele não executa a varredura bruta, mas gerencia inteligentemente quem, quando e onde devemos buscar.
- Abstração de Complexidade: Embora utilizemos parceiros estratégicos para lidar com a camada de conectividade bruta dos tribunais (resolvendo a instabilidade de ponta), a inteligência de orquestração reside no nosso Controller.
- Gestão de Targets: O sistema gerencia dinamicamente listas de "alvos" (CNPJs e Razões Sociais), decidindo a frequência de varredura com base em heurísticas de risco e relevância.
- Filtro de Ruído: O Controller atua como a primeira barreira de entropia. Ele ingere o dado bruto, realiza a Deduplicação (garantindo que não estamos processando o mesmo evento vindo de fontes diferentes) e prepara o objeto para o próximo estágio.
2. Private Integrations: O Provider Pattern
Enquanto o lado público lida com volume e descoberta, o lado privado (Integrações com Clientes) lida com Conectividade e Protocolo.
Grandes corporações possuem ecossistemas de tecnologia legados complexos, de gigantes como Salesforce e Benner a sistemas jurídicos proprietários on-premise. Para a Enter, esses sistemas são fontes ricas de contexto (provisões financeiras, documentos internos), mas integrá-los continua sendo um desafio clássico de engenharia de software.
Aqui, adotamos o Provider Pattern.
Criamos uma interface unificada (ProviderProtocol) que abstrai a complexidade do sistema externo. Para o "core" da plataforma Enter, não importa se o dado vem de uma API REST moderna, de uma query SOAP antiga ou de um banco de dados legado. O Provider específico daquele cliente é responsável por traduzir esse dialeto local para a linguagem universal da plataforma.
O Futuro: Agentes Autônomos de Integração — Até recentemente, muitos desses conectores exigiam manutenção constante de scripts de crawlers. Atualmente, estamos investindo pesado na evolução desses Providers para Agentes de IA Autônomos. Em vez de scripts rígidos que quebram com mudanças de layout no ERP do cliente, estamos treinando modelos capazes de navegar, interpretar e extrair dados desses sistemas de forma resiliente. (Mas isso é assunto para um próximo post).
O Grande Desafio: Merge e Consistência
Onde esses dois mundos colidem? No momento do Merge.
Frequentemente, recebemos sinais conflitantes sobre o mesmo processo.
- Fonte A (Informação do Tribunal vinda da fonte X): Diz que o prazo é dia 15.
- Fonte B (ERP do Cliente): Diz que o prazo é dia 12.
- Fonte C (Informação do Tribunal vinda da fonte Y): Diz que o prazo é dia 14.
Se tratássemos isso de forma simplista, teríamos dados duplicados ou, pior, incorretos. Nossa camada de Data Consistency atua aqui para criar uma "Single Source of Truth".
Utilizamos lógicas de reconciliação que empregam modelos de linguagem para classificar e deduplicar eventos capturados de diversas fontes. Validamos a hipótese de que modelos de linguagem demonstram excelente desempenho em zero-shot learning, mesmo em domínios difíceis de controlar. No entanto, testes realizados com datasets internos em vários modelos revelaram uma diferença mínima de performance entre modelos grandes e pequenos. Consequentemente, conseguimos reduzir custos ao utilizar modelos menores, mantendo uma performance satisfatória. Apesar disso, não depositamos confiança cega em nenhum modelo.
Nesse contexto é crucial manter humanos no loop. Validadores especializados asseguram a integridade em casos ambíguos, criando um feedback loop que usamos para refinar nossos hiperparâmetros usados nos modelos para serem cada vez mais precisos na resolução de conflitos.
No seu artigo de 19481, Shannon afirmou que o problema fundamental da comunicação é o de reproduzir em um ponto, de forma exata ou aproximada, uma mensagem selecionada em outro ponto". Além disso, para Shannon, informação é o que reduz a incerteza. Se eu te digo algo que você já sabia, a informação é zero (pois não reduziu sua incerteza). Se eu te mostro um dado que elimina 50% das suas dúvidas, eu te dei 1 bit de informação.
Para o squad de Monitoring, esse "outro ponto" é um ecossistema de 90 tribunais com milhões de eventos e sem padrões óbvios. Nossa engenharia existe para transformar o ruído processual em sinal limpo. Ao reduzir a entropia do dado bruto estamos garantindo que, no final da linha, nossos clientes recuperem aquilo que Shannon definiu como a essência da informação: a liberdade de escolha baseada na certeza.
Ser engenheiro no squad do Monitoring significa entender que o código é um meio para reduzir a entropia do mundo real. Preferimos lidar com o custo computacional de processar um dado ruidoso do que assumir o risco jurídico de ignorar um evento crítico. Sem a nossa camada de ingestão híbrida a IA generativa seria apenas um cérebro brilhante operando no escuro.
Footnotes
-
Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423. https://ia803209.us.archive.org/27/items/bstj27-3-379/bstj27-3-379_text.pdf ↩ ↩2
-
Conselho Nacional de Justiça. (2025). Justiça em Números 2025. https://www.cnj.jus.br/pesquisas-judiciarias/justica-em-numeros/ ↩