Build Log do AlphaJuri: Erros que Cometemos, Corrigimos e Aprendemos

Construir legal tech com IA no centro significa errar rápido e corrigir mais rápido ainda. Na Avante, documentamos cada erro relevante das nossas empresas do portfólio — não como ritual de pós-morte, mas como disciplina operacional viva que se acumula com o tempo.

Por Que Publicamos Isso

A maioria dos venture builders esconde seus erros. Publicam anúncios de marcos, não registros de falhas. A Avante faz o oposto.

O AlphaJuri é uma das nossas empresas em construção ativa. Ele opera na interseção entre inteligência jurídica e IA — um espaço onde a margem para alucinação, classificação errada e erosão de confiança é essencialmente zero. Cada erro custa credibilidade. Cada correção acumula aprendizado.

Por isso, escrevemos. Publicamente. Não porque é confortável, mas porque os fundadores e co-construtores que querem trabalhar com a Avante merecem ver como operamos de verdade — não como dizemos que operamos.

Erro #1: Deixamos o LLM Citar Cláusulas que Não Existiam

A semana mais constrangedora da curta vida do AlphaJuri foi quando nosso módulo de análise de documentos citou com total confiança o Artigo 473, Parágrafo 2º de um contrato — uma cláusula que o contrato simplesmente não continha.

O modelo estava fazendo correspondência de padrões com dados de treinamento sobre estruturas contratuais similares, em vez de ancorar a resposta no documento real enviado. A camada de recuperação estava frouxa demais. O prompt dava ao modelo liberdade demais para 'preencher' o que deveria estar lá.

O que corrigimos: Ajustamos o pipeline de geração aumentada por recuperação (RAG) para exigir atribuição estrita de fonte. Toda referência a cláusulas agora precisa ser extraída literalmente do documento indexado. Se não estiver lá, o modelo diz isso em vez de inventar.

O que aprendemos: A calibração de confiança em IA jurídica não é um problema de UX — é um problema de arquitetura. Você resolve isso na origem, não com um aviso de isenção de responsabilidade no rodapé da tela.

Erro #2: Entregamos uma Funcionalidade que o Usuário Nunca Pediu

Construímos uma visualização de comparação de contratos que mostrava diferenças cláusula por cláusula lado a lado. Interface limpa. Engenharia bem feita. Zero uso nas primeiras duas semanas.

Voltamos aos primeiros usuários. Eles não queriam comparar cláusulas. Queriam saber qual parte assumia mais exposição a risco em uma determinada cláusula — um julgamento, não uma diferença visual.

A funcionalidade respondia à pergunta errada porque construímos a partir de suposições, não de sessões de observação. Não tínhamos sentado com um advogado e observado ele revisando um contrato de verdade, em tempo real.

O que corrigimos: Substituímos a visualização de diferenças por uma camada de pontuação de risco por cláusula. O modelo agora sinaliza qual parte assume a obrigação, o que a aciona e qual é a consequência do descumprimento em linguagem simples.

O que aprendemos: Em legal tech, o trabalho a ser feito quase nunca é 'me mostre mais informação'. É 'me diga o que devo me preocupar'. São direções de produto fundamentalmente diferentes.

Erro #3: Nosso Onboarding Assumiu Sofisticação Jurídica Demais

O posicionamento inicial do AlphaJuri era voltado para advogados seniores. O conteúdo de onboarding refletia isso — denso, cheio de terminologia, com apoio mínimo ao usuário.

Então observamos uma paralegal tentando usar o produto. Ela fez o upload de um documento, viu o resultado e não soube o que fazer com ele. Não porque o resultado estava errado — mas porque a interface não dava nenhum prompt de ação. Só análise. Nenhum 'aqui está o que fazer a seguir'.

Esse é um padrão de falha comum em produtos de IA: o modelo faz o trabalho cognitivo pesado e depois abandona o usuário em uma sala vazia.

O que corrigimos: Adicionamos prompts de ação estruturados após cada bloco de análise. A interface agora apresenta três possíveis próximos passos com base no que o modelo encontrou — redigir uma resposta, escalar para revisão ou marcar como resolvido.

O que aprendemos: Resultado de IA sem integração ao fluxo de trabalho é uma ferramenta de pesquisa, não uma ferramenta de trabalho. O AlphaJuri precisa ser a segunda.

Erro #4: Ignoramos a Latência até os Usuários Começarem a nos Ignorar

Profissionais jurídicos trabalham sob pressão de tempo. Uma revisão de contrato que leva quarenta e cinco segundos para carregar não é um inconveniente menor — ela quebra o ritmo de trabalho e treina os usuários a parar de esperar que o produto seja rápido.

Tínhamos otimizado a qualidade do resultado às custas do tempo de resposta. Nosso pipeline executava chamadas sequenciais onde chamadas paralelas eram totalmente viáveis. Não tínhamos feito profiling. Assumimos que estava rápido o suficiente porque parecia rápido nos testes internos.

Não estava. Documentos reais são mais longos. Usuários reais não esperam.

O que corrigimos: Reestruturamos o pipeline para executar o chunking de documentos e a classificação de cláusulas em paralelo. O tempo de resposta caiu significativamente. Também adicionamos uma visualização de saída em streaming para que os usuários vejam resultados parciais à medida que chegam, em vez de aguardar a resposta completa.

O que aprendemos: Em produtos nativos de IA, velocidade percebida é uma funcionalidade do produto, não um detalhe de infraestrutura. Ela pertence à especificação, não ao backlog.

Erro #5: Não Definimos o que era 'Pronto' para a Camada de IA

Este é o erro mais estrutural da lista — e o que mais demorou para nomearmos.

Quando você constrói com IA, existe uma tentação persistente de continuar iterando sobre o comportamento do modelo sem declarar uma linha de base estável. A cada semana os resultados melhoram um pouco. A cada semana você resiste em entregar porque 'ainda dá para melhorar mais um pouco'.

Caímos nessa armadilha com o módulo de classificação de cláusulas do AlphaJuri. Passamos três semanas em iteração de qualidade sem um critério de aceitação definido. O time estava fazendo trabalho real, mas sem uma condição de entrega, 'bom o suficiente' não tinha significado.

O que corrigimos: Agora definimos gates de qualidade explícitos antes de qualquer componente de modelo entrar no sprint de construção. O gate tem três elementos — um piso mínimo de acurácia em um conjunto de teste com documentos reais, uma taxa máxima de alucinação e um benchmark de conclusão de tarefa observada em sessões com usuários.

O que aprendemos: Desenvolvimento de IA sem critérios de aceitação não é P&D — é deriva. Você precisa da mesma disciplina de engenharia que aplicaria a qualquer outro sistema, aplicada ao comportamento do modelo.

• Defina o gate de qualidade antes de começar a iterar.
• Separe 'trabalho de melhoria' de 'trabalho de prontidão para entrega' na estrutura do seu sprint.
• Documentos reais, não conjuntos de teste sintéticos, são sua fonte de verdade.

O Padrão por Trás dos Cinco Erros

Olhe para esses cinco erros juntos e um padrão emerge: todos eles remetem à lacuna entre o que assumimos e o que era verdadeiro de fato.

Assumimos que o modelo ficaria ancorado. Não ficou. Assumimos que os usuários queriam comparação. Queriam julgamento. Assumimos que advogados fariam o onboarding com facilidade. Paralegais não conseguiram. Assumimos que nosso pipeline era rápido. Não era sob condições reais. Assumimos que melhorar era sempre válido. Era — mas só quando apontado para um alvo definido.

Essa é a disciplina operacional central da Avante: suposições são hipóteses, não fatos. Você as testa o mais rápido possível, com usuários reais, em trabalho real. É assim que o modelo de construção da Avante se traduz em prática — não apenas em posicionamento.

O AlphaJuri não é único em cometer esses erros. Toda empresa nativa de IA em legal tech está navegando pelo mesmo terreno. O que importa é a velocidade de detecção e correção. Um erro que leva uma semana para ser encontrado e corrigido é uma funcionalidade, não uma falha.

O que Isso Significa para Fundadores Construindo em Verticais Nativas de IA

Se você está construindo uma empresa nativa de IA em uma vertical de alto risco — jurídico, saúde, finanças, compliance — a taxonomia de erros acima não é específica do AlphaJuri. É próxima do universal.

O problema de alucinação é arquitetural. O problema de fit funcionalidade-mercado é um problema de escuta. O problema de onboarding é um problema de integração ao fluxo de trabalho. O problema de latência é um problema de priorização. O problema do 'pronto' é um problema de disciplina.

Nenhum deles é resolvido com prompts melhores. Todos são resolvidos com rigor operacional aplicado à IA como um sistema de engenharia de primeira classe.

O modelo de venture builder — onde operadores estão dentro da empresa, não observando de uma posição no cap table — é o que torna esse registro de erros possível. Os times da Avante trabalham dentro do AlphaJuri. Vemos os erros quando acontecem, não em um relatório trimestral para o board. Essa é a vantagem estrutural, e vale entender como ela difere das estruturas tradicionais de fundo.

Se você é um fundador que quer construir dessa forma — com suporte operacional real, aprendizado documentado e IA como fundação em vez de funcionalidade — a Avante está construindo essa infraestrutura agora.