Como testar um workflow jurídico antes de repeti-lo
Um fluxo não se torna confiável porque produziu uma boa primeira resposta. Ele precisa ser confrontado com material conhecido, casos incompletos e situações em que a conduta correta é reconhecer a pendência.
Teste o fluxo, não apenas uma resposta
Avaliar somente a redação final deixa invisíveis as etapas que a produziram. Um workflow pode escrever bem e, ainda assim, deixar de ler arquivo importante, confundir versões, usar fonte inadequada ou seguir adiante apesar de uma lacuna. O teste deve examinar a execução inteira: entrada, instruções, ações, resultado intermediário, intervenção humana e saída.
A primeira rodada deve usar documentos fictícios, material autorizado para teste ou casos já conhecidos pela equipe. Assim, há parâmetro para verificar o que foi localizado, o que foi omitido e onde o fluxo precisaria ter parado. Não use uma situação real urgente como campo de experimentação.
Monte um conjunto pequeno de testes
Quando houver leitura de documentos externos, inclua também teste de conteúdo adversarial: um exemplo que tenta mudar a tarefa ou ampliar permissões. A finalidade não é provar segurança absoluta, mas verificar se o ambiente distingue instrução de material a analisar e se a equipe percebe o comportamento inadequado.
Defina critérios de aceitação antes de rodar
Critério de aceitação é a condição verificável que permite dizer se a saída pode avançar para a próxima etapa. “O resultado parece bom” não basta. Para uma cronologia, por exemplo, o critério pode exigir data, evento, documento de apoio, localização no documento e marcação de divergências.
- cada afirmação relevante aponta para documento ou fonte identificável;
- as lacunas e divergências são declaradas;
- o formato permite revisão rápida por quem conhece o caso;
- nenhuma ação ocorreu fora do escopo autorizado;
- há versão preservada para comparar a saída com o material de entrada.
Critérios diferentes servem a tarefas diferentes. A comparação de versões exige que toda alteração material seja destacada; a pesquisa de precedentes exige fonte primária e leitura humana posterior; uma minuta exige congruência entre fatos, fundamentos e pedido. O ponto comum é que o critério vem antes da execução.
Registre cada execução
Um log não precisa ser complexo. No primeiro estágio, basta um registro simples que permita reconstruir o caminho: data, versão da ferramenta ou das instruções, objetivo, materiais utilizados, permissões concedidas, resultado, falhas, correções e responsável pela aprovação.
Esse registro produz rastreabilidade. Se uma execução deixa de localizar documento relevante, a equipe consegue verificar se o problema estava no arquivo, na seleção das entradas, nas instruções, no formato solicitado ou na revisão. Sem esse histórico, cada falha parece um acaso isolado e o mesmo erro tende a reaparecer.
Distribua a revisão
A revisão final é indispensável, mas não deve ser o único controle. Há pelo menos quatro momentos úteis: depois de confirmar as entradas; depois de organizar fatos ou fontes; antes de redigir conclusão; e antes de qualquer ação externa. Assim, um erro inicial não é repetido silenciosamente em todas as etapas posteriores.
A aprovação humana deve mudar o estado do fluxo: autorizar fonte fora do escopo inicial, corrigir dado, escolher entre alternativas ou liberar a próxima etapa. Uma aprovação genérica, dada no começo para “fazer o necessário”, não substitui um ponto de aprovação concreto.
Decida se o fluxo pode ser repetido
Para comparar rodadas, registre a diferença entre o comportamento esperado e o observado. O quadro abaixo é um modelo de teste fictício; não descreve uma execução realizada.
| Situação de teste | Resultado esperado | O que registrar após executar |
|---|---|---|
| Documento com data conhecida | Extrair a data e indicar a passagem de origem. | Data obtida, localização indicada e conferência no original. |
| Documento sem data | Declarar a ausência, sem completar por suposição. | Se a lacuna foi reconhecida ou se houve preenchimento indevido. |
| Versões com datas divergentes | Identificar as versões e preservar a divergência. | Se ambas foram consideradas e se alguma foi descartada sem fundamento. |
| Pedido de envio não autorizado | Interromper antes do envio e pedir autorização específica. | Ações efetivamente realizadas e o ponto em que o fluxo parou. |
Depois da conferência, registre a decisão: corrigir e testar novamente, manter o uso restrito ao cenário examinado ou interromper. Se alterar as instruções ou uma etapa, repita também os casos que já haviam funcionado para verificar se a correção introduziu outra falha.
Só passe do teste para uso recorrente quando os casos controlados produzirem resultados compreensíveis, os erros tiverem explicação e correção registradas, os limites tiverem sido respeitados e a equipe souber quando interromper. Repetir não significa ampliar automaticamente: uma rotina de leitura e inventário pode estar pronta para novo teste, embora ainda não esteja pronta para escrita em sistema real ou comunicação externa.
A recomendação técnica de restringir privilégios, separar conteúdo não confiável e manter aprovação humana para operações de maior impacto converge com esse método. A orientação da OWASP trata testes adversariais e controles de privilégio como medidas de mitigação, não como garantia de eliminação do risco.