O diálogo entre direito e computação tem se intensificado recentemente, com várias vertentes bastante interessantes, que podem render boas pesquisas: a ascensão (e queda?) dos criptoativos, algoritmos e manipulação de mercado, algoritmos e direito concorrencial, decisões judiciais e inteligência artificial, fakenews e democracia, proteção de dados pessoais, cyberbullying, big data, entre inúmeros temas que começam a disputar espaço com assuntos mais tradicionais em textos e eventos jurídicos.
Ao tratarmos de direito e computação, não raro surge a discussão acerca da possibilidade de as “máquinas” substituírem o juiz e as decisões serem tomadas sem interferência humana. O direito como “arte do bom e do justo” se tornaria relíquia do passado (como se já não tivesse se tornado, dadas as petições e sentenças “pré-fabricadas” que os estagiários bem conhecem, mas não queremos polemizar aqui).
A discussão aqui proposta sequer se aproxima da automação do processo decisório, embora seja necessário registrar que existem esforços nesse sentido pelo menos para auxiliar o juiz na elaboração de votos, especialmente em casos repetitivos, envolvendo técnicas de processamento de linguagem natural e aprendizado de máquina.
Nosso foco envolve tarefas bem mais simples: a customização de contratos relativamente padronizados ou peças processuais de contencioso de massa, por exemplo.
A automação inteligente de documentos compreende o objeto de ferramentas como a Looplex e de outras Legaltechs congêneres. Entre os dias 16 e 27 de julho, ocorrerá um “Bootcamp” na FGV Direito SP, iniciativa em parceira com a Looplex Academy, no qualestudantes de graduação em direito poderão aprender outro tipo de código: programas de computador que podem ser uma nova forma de aprender sobre o mundo jurídico e, de quebra, uma nova habilidade necessária para o “advogado do futuro”.
A construção de um software se assemelha ao processo de criação de normas. A polissemia do termo código é oportuna, pois o processo que cria (e também o que aplica) um conjunto de normas destinadas a sujeitos de direito guarda algumas semelhanças com o processo de criação e aplicação de um conjunto de instruções destinadas a máquinas.
O respeito do advogado e do jurista às categorias desenvolvidas pela dogmática se assemelha à diligência de um programador (e, de modo mais geral, do arquiteto de soluções) no sentido de buscar, dentre os componentes já existentes, quais são aqueles que já foram testados e se aplicam ao problema que se deseja resolver sem que “a roda seja reinventada”. Com isso, é possível facilitar a comunicação entre os envolvidos – com base em um vocabulário e uma gramática já consolidados – e atingir alguma previsibilidade com relação aos resultados que serão alcançados.
Com base nesta premissa – o direito e os códigos (jurídicos e também os programas de computador) evoluem por camadas, gradualmente, num processo de “sedimentação” – podemos dizer que o ciclo de desenvolvimento, aplicação e transformação das normas e dos programas de computador se desdobra em movimentos indutivos e dedutivos. Vejamos o que isso significa.
Sem detalhar todos os papéis dos membros de uma equipe de desenvolvimento de software, haverá aqueles que terão que se comunicar com o cliente final para colher os requisitos, normalmente fornecidos em uma linguagem ainda insuscetível de ser codificada. Será necessário compreender o domínio do problema, os conceitos, as variáveis e condições de contorno, as expectativas dos usuários. Será necessário abstrair alguns padrões e categorias, como, por exemplo, em uma loja de e-commerce, Cliente, Produto e Marca. São criados “tipos” a partir da realidade.
Na automação da criação de um documento jurídico, um analista de requisitos irá identificar, por exemplo, quais são as cláusulas recorrentes de certo tipo de contrato e quais as variações na sua redação, de modo a criar templates flexíveis, adaptáveis a diferentes possibilidades,com lacunas a serem preenchidas pelo usuário quando da criação do documento final. E este documento poderá se inserir em um fluxo mais complexo, conforme as necessidades de negócio especificadas para a fábrica de software.
Quando chega a hora de desenvolver, normalmente há um arquiteto, que tem mais experiência e conhece os componentes que já existem – seria o equivalente a um “jurista de escol” – e que faz o projeto em linhas gerais.
Outros programadores se juntam ao time e efetivamente constroem o software, as interfaces gráficas de usuário, eventuais rotinas específicas para o cliente. É neste momento que a mágica acontece. Classes, funções, tipos abstratos de dados (listas, árvores, grafos) se conjugam para dar vida a sistemas que transformam nosso cotidiano, assim como leis, artigos, incisos, alíneas, tribunais e advogados dão vida ao direito. Gosto de pensar que computadores e ordenamentos jurídicos são, cada um a seu modo, caixinhas de música.
Após a construção do software, são realizadas diversas etapas de testes e homologação pela equipe e, posteriormente, pelo cliente, até que seja feita a entrega do produto final. Ao longo de todo o processo, são gerados documentos que permitem a comunicação entre os membros da equipe de desenvolvimento e entre a fábrica de software e o cliente final, especialmente os manuais e documentos de apoio para quando a solução já tiver sido implantada.
No ciclo de vida do software, novas necessidades de negócio geram novos requisitos, demandando adaptações, correções ou mesmo novos esforços de desenvolvimento a partir do zero.
Durante o desenvolvimento, há preponderância de um método indutivo, com a criação de um software a partir da realidade do cliente, quando são gerados componentes que usam uma ou mais tecnologias de desenvolvimento de software (linguagens de programação e processos de desenvolvimento e garantia de qualidade de software). Posteriormente, quando do funcionamento da aplicação desenvolvida, as situações reais vão sendo confrontadas com o modelo desenvolvido, segundo um método dedutivo, um silogismo de premissa maior (pré-existente) e premissa menor (a situação concreta submetida ao software), com as consequências resultantes.
Em uma escala “um pouco mais lenta” (talvez em um tempo geológico), algo semelhante ocorre no direito.
Paula A. Forgioni acentua o método indutivo utilizado na criação de categorias do direito comercial a partir da realidade negocial. Diante de uma inovação – e o sistema econômico, em face das novas tecnologias, é o lugar perfeito para as novidades que desafiam o direito – é preciso obter uma resposta: a nova prática deve ser regulada, deve ser proibida ou é juridicamente irrelevante? Este problema já foi enunciado pelo jurista italiano Emílio Betti para quem o direito tem uma “função dinâmica de tornar possível a perene renovação, de facilitar a circulação de bens e serviços e a recíproca utilização dos serviços, em conformidade com as necessidades que vão surgindo sucessivamente”
O discurso jurídico se constrói a partir deste movimento indutivo que permite a criação de categorias com base na realidade. Estas categorias se consolidam, muitas vezes se cristalizam em Códigos, e, posteriormente, são aplicadas pelos “operadores do direito” em situações concretas, agora em movimentos dedutivos. Nestes casos, nos colocamos diante dos problemas de encontrar a “natureza jurídica” de certo fenômeno, para definir o regime jurídico aplicável.
Em síntese, sem as categorias abstratas previamente construídas, não seria possível aplicar o direito. Sem os tipos de dados, as estruturas de dados, as funções, as classes, os métodos, não seria possível executar os programas.
O esforço intelectual de criação de modelos a partir da realidade é um pressuposto para que os sistemas jurídicos e os sistemas de informação cumpram a sua função. Trata-se de um exercício intelectual extremamente prazeroso sujar as mãos lendo e escrevendo estes dois tipos de códigos. Fica aqui o convite para os mais empolgados como você, que chegou até o fim deste texto.
Fonte: JOTA