Assistente de Petição — da reinvenção da roda à biblioteca centralizada
"A ferramenta superou minhas expectativas e será um grande marco para a instituição."
— Flávia Rodrigues, Procuradora do Estado
Procuradores de estado passam uma parte considerável do dia fazendo algo que não deveria ocupar tanto tempo: escrevendo, do zero, documentos que já escreveram antes.
Petições têm estrutura. Têm trechos que se repetem. Têm argumentos que mudam de processo para processo, mas que partem sempre de uma base parecida. E ainda assim, cada nova peça era tratada como se fosse a primeira.
Abria-se um editor de texto, buscava-se uma versão antiga no computador, copiavam-se parágrafos, ajustavam-se detalhes, rezava-se para não esquecer nada.
Era um fluxo manual, lento e cheio de pontos onde algo podia dar errado. E o problema não era falta de competência — os procuradores sabem escrever. O problema era que o processo os obrigava a reinventar a roda toda vez.
"A definição inicial era clara: criar uma forma de montar documentos com mais agilidade. Mas 'mais agilidade' pode significar muita coisa — e eu não queria construir a solução errada de forma eficiente."
O que eu encontrei foi um conjunto de problemas que se reforçavam mutuamente:
Cada procurador tinha sua própria forma de estruturar uma petição. Isso é natural — mas quando um documento precisava passar por várias mãos, ou quando um novo membro da equipe precisava dar continuidade a um caso, a falta de um padrão comum criava retrabalho desnecessário.
Demandas em massa — casos com a mesma natureza jurídica, os mesmos argumentos, as mesmas teses — eram tratadas como se fossem únicas. Cada peça partia do zero mesmo quando 80% do conteúdo seria idêntico à anterior.
Um documento jurídico não tem margem para inconsistência. Então, mesmo que o conteúdo fosse parecido com algo que já existia, o procurador precisava revisar tudo antes de assinar — consumindo energia que poderia estar sendo usada no que realmente exigia raciocínio estratégico.
O resultado: profissionais qualificados gastando horas em tarefas mecânicas.
Mapeei quatro caminhos antes de definir o que construir. A decisão foi sobre onde atacar a dor real com a menor fricção de implementação:
Uma biblioteca de trechos pré-definidos que os usuários selecionam e combinam para montar um documento completo. Flexível, escalável, e diretamente ligado à dor principal: eliminar a reescrita de conteúdo que já existe.
Atacava o problema central. Implementável como MVP. Deixava espaço para evoluir.
Com base no contexto do documento em elaboração, o sistema sugeriria automaticamente blocos relevantes. A ideia era boa, mas a complexidade de implementação era alta.
Para um MVP, o esforço não se justificava ainda. Boa camada para o futuro.
Uma coleção de templates prontos para personalização. O problema estrutural: a quantidade de variações nos trechos de cada modelo tornava essa abordagem difícil de manter e escalar.
Serviria para casos simples, mas quebraria nos complexos.
Permitir que procuradores e gestores revisassem e aprovassem documentos em conjunto. Útil, mas não resolvia a dor principal.
A dificuldade estava em criar o documento, não em aprová-lo.
Conversei com procuradores do estado para entender como o trabalho funcionava na prática.
Não o trabalho idealizado — o trabalho real, com as gambiarras, os atalhos e os momentos de
frustração.
Algumas coisas ficaram evidentes rapidamente. Os profissionais de demandas
repetitivas sentiam a dor de forma mais aguda — faziam a mesma coisa dezenas de vezes por semana
e sabiam exatamente onde o processo era ineficiente. Os que atuavam em casos
complexos tinham uma dor diferente: precisavam organizar e acessar argumentos de forma rápida,
sem nenhuma ferramenta que ajudasse nisso.
Isso informou diretamente o design. A solução precisava servir aos dois perfis.
Com o entendimento do problema consolidado, mapeei os fluxos de uso para dois tipos de
usuário: o administrador, responsável por criar e gerenciar os blocos
de texto e modelos; e o usuário final, que monta os documentos a
partir do que está disponível na biblioteca.
Esse mapeamento foi o que revelou decisões importantes de arquitetura — como a necessidade de um sistema de
classificação dos blocos para que a biblioteca não virasse um depósito desorganizado com o tempo.
O protótipo passou por rodadas de teste com usuários reais — procuradores que usariam o
sistema no dia a dia. A intenção não era validar se a ideia era boa, mas identificar onde a execução criava
atrito desnecessário.
Alguns ajustes vieram daí: nomenclaturas que faziam sentido para o time de produto mas não para os juristas,
hierarquias de ação que precisaram ser reorganizadas, e fluxos que assumiam conhecimento técnico que os
usuários não tinham.
O Assistente de Petição foi construído em torno de uma ideia simples: separar o conteúdo jurídico da tarefa de montagem do documento.
Em vez de criar cada peça do zero, os procuradores passaram a ter acesso a uma biblioteca de blocos de texto — trechos validados, classificados por tipo e área, que podem ser combinados para formar documentos completos. Quando uma tese jurídica muda, ela muda em um lugar só — e essa mudança reflete em todos os documentos futuros que usarem aquele bloco.
"A classificação dos blocos levou mais iteração do que o esperado — categorias muito amplas tornavam a busca difícil, categorias muito granulares criavam duplicatas. O equilíbrio só apareceu depois de testar com usuários reais."
Às vezes, os melhores dados de validação chegam em forma de texto.
A ferramenta superou minhas expectativas e será um grande marco para a instituição — a primeira vez que inteligência artificial seria efetivamente incorporada ao trabalho da PGE.
O valor da ferramenta não está só nas demandas repetitivas — nos casos complexos, organizar e acessar teses e argumentos com agilidade faz diferença real.
A possibilidade de atualizar os modelos a qualquer momento era exatamente o que faltava para padronizar as peças de cada setor sem perder flexibilidade.
Esses três feedbacks juntos dizem algo importante: o produto resolveu a dor que foi identificada na pesquisa, mas também abriu possibilidades que os próprios usuários não haviam imaginado antes de usar. Isso é o sinal mais claro de que o processo de pesquisa e design foi no caminho certo.