Software de tecnologia jurídica precisa de mais do que gerar documentos

As tecnologias jurídicas são uma das cinco áreas em que desenvolvemos software. O equívoco mais frequente nesta área é procurar o valor do produto no documento que gera. O valor real está em a regra funcionar sempre da mesma forma dentro do sistema.

Ao olhar para a apresentação de um produto de tecnologia jurídica, é muito provável que veja o seguinte. Gera minutas de contratos, propõe cláusulas, formata o documento. São tarefas úteis. O problema é que a verdadeira questão da área não é essa, e o problema que julgamos que estas ferramentas resolvem é, na realidade, a parte mais fácil do problema.

A verdadeira questão está aqui. Uma organização está sujeita a uma obrigação jurídica. Faz-se uma interpretação sobre o que significa essa obrigação. A interpretação é escrita num documento. Depois esse documento é arquivado, e o funcionamento diário da organização continua sem conhecimento desse documento. Esta desconexão entre o documento e o sistema é o erro mais dispendioso que vejo na prática, e nenhuma ferramenta de modelos de contratos o resolve.

Interpretar é tarefa da pessoa, aplicar é tarefa do sistema

Transformar uma regra em software não é escrever a regra em código. Entre as duas coisas existe um passo que não pode ser automatizado.

O artigo 7.º da Lei 6698 estabelece que, quando desaparecerem as razões que exigiam o seu tratamento, o dado pessoal será apagado, destruído ou anonimizado. Esta disposição é clara. Mas o que significa exatamente "o desaparecimento da razão" quanto aos dados de faturação de uma organização? O fim da relação com o cliente, o termo do prazo de conservação previsto na legislação fiscal, ou o que ocorrer mais tarde entre os dois? A esta pergunta responde um jurista. A resposta dada é uma interpretação, e enquanto essa interpretação não ficar registada, dentro de seis meses ninguém se lembrará de por que razão se escolheu aquele prazo.

É aqui que começa o trabalho do software. Depois de dada a interpretação, garantir que ela é aplicada sempre da mesma forma e que essa aplicação pode ser demonstrada. Se dispõe de um sistema que faz isto, está a usar tecnologia jurídica. Se apenas gera modelos, está a usar um processador de texto.

O que acontece quando o documento e o sistema se separam

Vejamos um exemplo concreto. Na política de conservação de uma organização consta que os registos de comunicação com clientes serão conservados durante dois anos. Quando chega uma auditoria, essa política é apresentada.

O auditor faz uma única pergunta. Que componente aplica este prazo?

A resposta, na maior parte das vezes, não existe. Na base de dados há um campo created_at, mas não há expires_at. Não existe nenhum processo que apague o registo quando o prazo termina. Mesmo que a eliminação ocorra, não produz qualquer registo do que foi feito. No final, a organização não consegue demonstrar que faz o que a sua política diz. A própria política não é prova, é quando muito uma declaração de intenções.

A forma de corrigir este quadro não é escrever um melhor texto de política. É acrescentar ao modelo de dados um campo que transporte o prazo de conservação, escrever um componente que aplique esse prazo, e garantir que esse componente produz um registo quando é executado. Quando as três coisas existem em conjunto, o texto da política deixa de ser uma afirmação e passa a ser a descrição daquilo que o sistema efetivamente faz.

Os cinco elos da cadeia

A transformação de um texto jurídico num controlo que funciona no sistema ocorre em cinco passos. A ordem destes passos é importante, e a omissão de qualquer um deles torna o resultado pouco fiável.

Primeiro identifica-se a norma. Determina-se a regra aplicável e, se existir, a sua exceção. Depois faz-se a interpretação, ou seja, decide-se o que a regra significa no processo de negócio concreto. Este passo é da responsabilidade da pessoa e deve ficar registado. No terceiro passo, a interpretação é ligada à arquitetura, determinando-se que campo transportará que regra. No quarto passo escreve-se o componente que aplica a regra no momento da operação. No quinto passo regista-se a execução desse componente.

Um controlo escrito sem a interpretação prévia aplica a regra errada. Um controlo que não produz prova não serve numa auditoria. O erro que encontro com frequência é saltar o terceiro e o quarto passo e avançar diretamente para o quinto. A organização mantém um registo, anota ali algo, mas não é claro que regra esse registo demonstra ter sido aplicada.

A questão do monopólio da advocacia

Existe um limite que qualquer pessoa que desenvolva produtos nesta área deve conhecer. O artigo 35.º da Lei da Advocacia n.º 1136 reserva aos advogados o acompanhamento de assuntos jurídicos e a emissão de pareceres jurídicos.

Na prática, isto determina o que o seu produto pode e não pode dizer. Dizer "falta esta cláusula no seu contrato" é informar. Dizer "não assine este contrato, terá consequências contra si" é emitir um parecer. A linha entre as duas coisas é fina e deve ser conscientemente preservada na conceção do produto. O método mais sólido para preservar essa linha é o sistema não tomar a decisão por si próprio e manter visível, atrás de cada resultado, uma decisão humana.

Este limite parece um obstáculo, mas é na realidade uma boa restrição de conceção. Um sistema que não assume a decisão também não assume a responsabilidade quando comete um erro, e isso impede que o utilizador confie cegamente no sistema.

O que a inteligência artificial mudou e o que não mudou

O processamento de linguagem natural traz um ganho real de eficiência na análise de documentos. Encontrar um determinado tipo de cláusula entre centenas de contratos era antes um trabalho de semanas. Agora demora horas.

O que não muda é a responsabilidade. Se não for possível rastrear de que documento e de que parágrafo provém o resultado produzido pelo modelo, esse resultado não é uma constatação, é uma suposição. Do mesmo modo, se o sistema não mostrar de forma distinguível um resultado de que não está seguro face a um de que está, o utilizador confia igualmente em todos eles, e o erro passa despercebido.

Quando estas duas condições não são cumpridas, o ganho de eficiência obtido é depois compensado pelo risco que surge. E o pior é que não se sabe quando esse risco se concretizará.

Por onde começar

Ao iniciar um projeto corporativo de tecnologia jurídica, recomendo escolher uma única obrigação. Abordá-las todas de uma vez soa bem, mas na prática nenhuma delas chega a concluir-se.

Para a obrigação escolhida constroem-se os cinco elos na íntegra. Redige-se a norma, a interpretação fica registada, liga-se ao modelo de dados, o controlo funciona, produz-se a prova. Este trabalho conclui-se em seis semanas, e no final não terá um relatório, mas um controlo a funcionar e um registo que pode ser mostrado numa auditoria.

A segunda obrigação avança muito mais depressa. Porque a parte difícil não é a regra, é construir a cadeia pela primeira vez.