Documentos Inteligentes

Introdução

Contratos inteligentes prometem transformar radicalmente a forma, velocidade e custos das transações, não apenas no mercado financeiro, mas em toda a economia.

Essas tecnologias estão no estágio relativamente inicial de desenvolvimento. Por conta disso, ainda há uma falta de acordo sobre o que é um contrato inteligente, que papel ele pode desempenhar e como ele pode interagir com os padrões e documentação legais existentes.

Poderia um contrato inteligente substituir um contrato legal existente em sua totalidade, ou seria ele apenas uma forma de automação de algumas ou todas as ações das partes especificadas no contrato?

E, quase tão importante quanto essa primeira pergunta, como seriam construídos esses contratos, quais seriam o ferramental e infraestrutura tecnológicos necessários para materializar esse novo mundo?

Para responder isso, veremos quais são os tipos de contratos inteligentes (smart contracts, documentos automatizados e ricardian contracts) e depois veremos os diferentes sistemas de automação, com ênfase no framework de arquitetura da Looplex.

O que são contratos inteligentes

Entre as várias definições concorrentes do que é um contrato inteligente, há duas linhas centrais de pensamento: a visão dos cientistas da computação e a visão dos advogados.

Nenhum dos dois tem a resposta completa; em verdade, eles se complementam. Assim, precisamos conhecer o que cada um fala para então definirmos o que é “contrato inteligente”.

A própria terminologia “smart contract” e “intelligent contract” também é objeto de discussões filosóficas. Usaremos aqui contrato inteligente como um termo geral que engloba smart contracts, contratos de construção automatizada e ricardian contracts.

E, mais amplamente, usaremos o termo documento inteligente para definir qualquer conteúdo (inclusive contratos) que contém os mesmos atributos computacionais de um ricardian contract.

Advogados e programadores batendo cabeça

A comunidade de ciência da computação costuma usar o termo contrato inteligente ou smart contract de uma maneira muito diferente dos advogados.

Para advogados, o termo “contrato” conota uma relação jurídica de obrigações e direitos (conteúdo), enquanto os cientistas da computação tendem a pensar em contrato inteligente em termos do código que processa uma transação (execução).

Para quem vê o código como elemento mais importante, um smart contract é um software projetado para executar determinadas tarefas se condições pré-definidas forem atendidas.¹

Do outro lado, para quem vem do mercado jurídico e lida com a atual infraestrutura (analógica) do Direito, o termo é usado para se referir mais ao conteúdo do que sua execução; é um documento – como o papel era no paradigma tecnológico anterior – que expressa todos os elementos de um contrato legalmente válido e vinculante, porém em uma mídia digital e representado em código.

Mas para ser um verdadeiro contrato inteligente ambas as coisas são necessárias: representação digital do conteúdo e execução das ações nele descritas.

Em outras palavras, ele precisa (a) estar sob o guarda-chuva de um relacionamento global que cria direitos e obrigações legalmente vinculantes; e (b) incorporar código feito para executar tarefas quando certas condições pré-definidas forem atendidas.

O que é o “contrato” de um contrato inteligente

Para que um contrato seja existente, válido e eficaz, nosso sistema jurídico impõe certos requisitos. Em uma compra e venda, por exemplo, três elementos de conteúdo devem ser satisfeitos: (a) declaração inequívoca da coisa (existente ou futura) que está sendo vendida; (b) preço definido ou definível, com termos e condições para o seu pagamento; (c) manifestação de vontade explícita do vendedor e do comprador em fazer aquele negócio. Como diziam os romanos, res, precium, consensus.

Mas isso não é tudo. Há dois elementos adicionais necessários para expressar o contrato no mundo real: sua forma e registro. A compra e venda de um imóvel, por exemplo, deve ser feita por escritura. E, para alguns contratos, seus efeitos (eficácia) só ocorrerão se a transação for registrada em algum local definido em lei; cartório de imóveis, DETRAN, CETIP, livro de registro de transferência de ações de uma S.A., etc.

Para um smart contract ser um verdadeiro contrato, ele deveria satisfazer todos esses requisitos legais, com algum elemento de sua execução sendo automatizado: se o código existisse sozinho e não fizesse nada, teríamos apenas uma diferente forma de representação do conteúdo, mas poderia não haver contrato legalmente eficaz².

“Inteligência” vs. “esperteza” de um smart contract

O uso do termo smart em contratos inteligentes refere-se ao fato de que algum elemento do contrato é automático e auto-executável de acordo com condições pré-definidas. O próprio contrato pode examinar se determinados estados ocorreram e, em caso positivo, pode desencadear uma ação predeterminada.

Demis Hassabis, o co-fundador da empresa de inteligência artificial Deep Mind, diz: “Em sua essência, a inteligência pode ser vista como um processo que converte informações não estruturadas em conhecimento útil e acionável.”

Mas um smart contract que é expresso apenas em código não possui esse tipo de inteligência. Tudo o que faz é executar etapas pré-programadas. É um contrato algorítmico puro.

Portanto, para ir além da simples “esperteza” do smart e tornar-se verdadeiramente inteligente, um contrato inteligente precisa de um empurrãozinho de cognição humana, que participa de sua construção contextual e escreve ali a sua vontade de fazer o negócio ali representado.

No mínimo, humanos indicam sua expressão de vontade, direta ou indiretamente (pois pode ser um contrato que desencadeia outro); e, no máximo, humanos dão todos os ingredientes semanticamente relevantes para a sua construção e execução. Há vários sabores no meio do caminho.

Desta forma, contratos inteligentes são mais do que smart contracts no seu sentido estreitamente definido pela turma de ciência de computação:

• eles são algoritmos em código que instanciam uma execução por meio de agentes de software

• eles encapsulam a conversão de informações não estruturadas em conhecimento útil e acionável (dados estruturados)

• eles representam um contrato legalmente válido e eficaz, reconhecido pelo sistema jurídico estatal atual.

Ou seja, para um contrato inteligente ser completo do ponto de vista jurídico e de ciência computação, ele precisa ter agência (código em tempo de execução fazendo coisas, não necessariamente tudo), dados estruturados (o output é machine readable) e validade legal (pode ser levado a um tribunal para ser cumprido em caso de inadimplemento humano ou máquina).

Tipos de contratos inteligentes

Cientistas da computação e advogados vêm tentando fazer a conversão de contratos analógicos e contratos inteligentes de diferentes maneiras.

O problema é que o “cobertor” lógico é curto; cada uma das abordagens cobre uma parte do desafio descobrindo a outra parte.

Visão dos cientistas da computação

A maioria dos aplicativos que os cientistas da computação chamam de “smart contract” e rodam em redes distribuídas tais como o Ethereum não são propriamente contratos inteligentes, pois não dispõem do terceiro elemento de validade legal (enforceability). Em vez disso, eles se fiam na característica de serem “turing complete”³ ou, mais restritivamente, de serem totalmente autoexecutáveis sem intervenção humana.

Porque eles se auto executam sem intervenção humana, discussões sobre a sua validade jurídica e possibilidade de interface com o Judiciário tornar-se-iam irrelevantes. O aplicativo roda e não importa o que as partes achem ou deixem de achar depois que ele começa, não há inadimplemento e não há debates sobre a interpretação ou alcance de alguma cláusula ou obrigação.

Mágico, né? O problema disso é que a implementação na prática de um smart contract esbarra na complexidade e opacidade do sistema jurídico. Como nada pode ser subentendido ou referenciado por contexto, o agente de software precisa conter dentro do seu código um microcosmos com todos os elementos necessários para sua execução.⁴

Smart contracts são programados usando lógica proposicional.⁵ Para manter sua autossuficiência executiva, o uso de uma lógica predicada acaba sendo proibitivamente caro de se computar, pois implicaria na necessidade de se ter um completo modelo semântico de referência do Direito embarcado no aplicativo, o que simplesmente não é possível.⁶

Como consequência disso, esses aplicativos somente são capazes de executar operações muito simples, como uma compra e venda discreta de objetos inequívocos, como um valor mobiliário simples e sem obrigações acessórias, declarações e garantias etc. Isso limita em muito o alcance e utilidade de smart contracts.

Visão dos advogados

Uma maneira de contornar as limitações de reprodução de toda a complexidade jurídica da maioria dos contratos seria simplesmente não enfrentar o problema!

Advogados e outros profissionais do Direito podem converter seu conteúdo jurídico para uma série de instruções de geração automatizada em sistemas de montagem de documentos (document assembly). O nome desse processo é legal coding⁷.

Chamamos esse tipo de contrato ou documento de documento automatizado. Diferentemente dos smart contracts dos cientistas da computação, documentos automatizados são plenamente válidos do ponto de vista legal e são parcialmente capazes de gerar dados estruturados para reutilização e BI, mas não possuem qualquer agência.

Seu output é estático, um conjunto de textos, gráficos e tabelas que precisam de humanos para serem interpretados e executados. E, embora o conteúdo pode ser abstraído, reduzindo dramaticamente a dificuldade de formalização do conhecimento, essa solução não tem qualquer compreensão do conteúdo dos documentos.

É basicamente um preenchedor de formulários (única capacidade do sistema anterior de field merge) com lógica condicional, formatadores de texto e filtros (data extraction de sistema ERP,m CRM e outros).

Abordagem híbrida: Contratos Ricardianos

A ideia de um ricardian contract foi introduzido pela primeira vez em 1995 por um conhecido programador, Ian Grigg, mas o conceito agora faz parte do mundo dos contratos inteligentes, seja ele executado em blockchain ou não. Aqui está a definição básica:

Um contrato ricardiano é uma forma de documento digital que funciona como um acordo entre duas partes sobre os termos e condições para uma interação entre elas, cujo output é um documento legalmente válido, que pode ser lido e executado ao mesmo tempo tanto por programas de computador quanto por humanos.

A principal diferença de um smart contract é sua validade legal perante a infraestrutura do sistema jurídico legado ou tradicional atualmente existente, uma vez que ele tem uma camada semântica em linguagem natural de expressão do que as partes ajustaram no negócio jurídico.

E, também diferentemente de documentos automatizados, ele tem a característica de captura de dados de maneira estruturada para análise (como os smart contracts), capacidade de interação com outros sistemas e business intelligence, e ainda permite a execução de métodos e funções associados à sua construção e ao implemento de suas obrigações.

Simplificando, ele serve a dois propósitos. Em primeiro lugar, é um contrato legalmente válido fácil de ler entre duas ou mais partes. Um advogado pode facilmente entendê-lo, e até as partes signatárias podem lê-lo e entender os seus termos centrais.

Em segundo lugar, ele é um contrato legível e executável por máquinas também, capaz de se tornar um smart contract.

Mas, como ele não precisa da propriedade de auto execução sem intervenção humana (se “der ruim” você pode levá-lo ao Judiciário), o processo de transformação digital pode ser gradual, com contratos ricardianos se comportando como meros documentos automatizados em um extremo ou como um smart contract turing complete no outro.

Por fim, essa flexibilidade também permite extensão dessa solução para outros tipos de documento. Tal como nos documentos automatizados, não apenas contratos, mas também petições, decisões, memorandos e outros conteúdos podem se tornar documentos ricardianos.

Sistemas de automação

Outra questão diz respeito às diferentes capacidades dos sistemas de software que criam, armazenam e executam documentos inteligentes.

Dividiremos aqui em quatro diferentes tipos, em ordem crescente de sofisticação e funcionalidades: field merge, document assembly, expert systems e digital experience platforms (DXP).

Field Merge

Field merge (fusão ou preenchimento de campos) é a mais antiga tecnologia nessa área. Foi introduzido pela Microsoft no início dos anos 2000 com a função Mail Merge usada para gerar letras, rótulos de envelopes e outros documentos básicos, mesclando dados em um documento do Excel com um modelo do Word.

Uma vez que a fusão de campo só pode substituir uma variável em um documento com o valor inserido, ela só é adequada para documentos muito básicos que não possuem variações dependendo dos valores inseridos. Um bom exemplo de um uso adequado da fusão de campo são os campos de endereço para papel timbrado, documentos de mala direta, ou rótulos onde os padrões de idioma, sintaxe ou formatação não precisam ser ajustados com base nos valores de dados inseridos.

Document Assembly

Sistemas de document assembly (automação documental) são uma evolução do field merge. Eles permitem programar lógicas no processo de montagem de seus documentos com instruções lógicas condicionais, formatação e filtros.

Por isso, eles incluem templates marcados com campos de variáveis e operações lógicas básicas (árvores de decisão), que usam segmentos de texto e/ou dados pré-existentes para montar um novo documento a partir de uma entrevista com o usuário.

Expert System

No campo da inteligência artificial, um sistema especialista (expert system) é um sistema de computador que emula a capacidade de tomada de decisão de um especialista humano.

Expert Systems são projetados para resolver problemas complexos através do raciocínio através de corpos de conhecimento, representados principalmente como regras IF-THEN em uma camada separada em vez de código procedural comum.

Um expert system é dividido em subsistemas ou camadas: ele desacopla o motor de inferência (rules engine) da base de conhecimento (knowledge base). A base de conhecimento representa fatos e regras e o motor de inferência aplica as regras aos fatos conhecidos para deduzir novos fatos. Os motores de inferência também podem incluir habilidades de explicação e depuração.

Esse desacoplamento de motor e base de conhecimento em diferentes camadas permite a especialização de trabalhos, com advogados programadores (engenheiros jurídicos) focando na conversão de conteúdo, enquanto cientistas da computação e engenheiros de software dedicam-se a otimizar a infraestrutura de execução da plataforma.

Além disso, em expert systems é possível organizar a base de conhecimento para usar lógica predicada, indicando significado semântico complexo aos termos em linguagem natural utilizados, e permitindo assim a reutilização de entidades de lógica jurídica que foram previamente normalizadas de acordo com um Modelo Semântico de Referência.

Digital Experience Platform

Uma plataforma de experiência digital (DXP) é feita para gerenciar, entregar e otimizar experiências digitais de forma consistente em todas as fases do ciclo de vida do cliente.

Em outras palavras, uma DXP é uma coleção de produtos e serviços integrados que ajudam as organizações a oferecer uma experiência digital consistente aos seus clientes. Alguns desses produtos e serviços controlam o que o usuário vê, e outros funcionam nos bastidores para coletar e analisar dados, ou para integrar sistemas em conjunto.⁸

Alguns dos principais elementos de uma DXP são:

• Um sistema de gerenciamento de conteúdo (CMS)

• Software de gerenciamento de projetos e/ou de relacionamentos (CRM/ERP)

• Plataformas de análise e BI embarcada

• Sistemas integrados de automação de processos de negócio (BPA)

• Aplicativo de comércio eletrônico ou marketplace⁹

A Looplex é um DXP de serviços jurídicos, sendo que o elemento de Content Management System (CMS) é na verdade um completo Expert System¹⁰, capaz de construir tanto conteúdo jurídico não normalizado na sua base de conhecimento (ou seja, usando lógica proposicional semelhante ao que é feito em um sistema de document assembly), quanto conteúdo semanticamente referenciado em um modelo ontológico de representação do Direito.

Além de bancos de dados fragmentados por serviços e contextos específicos, todo conteúdo da base de conhecimento referenciado no nosso Modelo Semântico é acessado por agentes de automação de processos de negócios (BPA do Looplex Flow), pipeline de ETL para Legal Analytics e BI, além de um sistema de gestão de projetos (case management system), que é o Looplex Cases.

A Looplex é capaz de gerar documentos ricardianos (não apenas contratos) e, como consequência, cobre com isso quaisquer demandas por documentos automatizados e mesmo pela geração de smart contracts.¹¹

Além disso, podem ser gerados outros objetos de lógica jurídica, desacoplados, mas totalmente integráveis entre si, compondo uma verdadeira rede de aplicativos de mini smart contracts ou deamons capazes de executar diferentes aspectos de uma experiência de serviços jurídicos digitais. Chamamos eles de Legal Applications.

“Headless” CMS (expert system)

Em um CMS tradicional, o mesmo sistema de software controla o gerenciamento e processamento de conteúdo no backend e a apresentação da interface no frontend.

Mas os CMS modernos são “sem cabeça” (headless, dissociados). É oferecida uma solução frontend integrada de todos os serviços, mas o cliente pode usar todos os serviços diretamente via API ou usando web components para criar sua própria experiência ou integrar um ou mais aspectos da plataforma em seus próprios sistemas e serviços.

Na nossa DXP isso é chamado de Looplex Inside e o seu acesso é feito pelo Looplex Graph, nosso gateway de integração.

Conclusão

Colocando as ideias centrais desse artigo em uma tabela consolidada:

Footnotes

1. Tais tarefas são frequentemente incorporadas e executadas em um ledger distribuído. Por exemplo, implementações bem conhecidas de smart contracts descrevem agentes de software que criam utility tokens e criptomoeda (DApp para ICO), fornecem um mecanismo de votação eletrônica (DAO) e oferecem um mecanismo eletrônico de leilão cego, entre outros. ↩

2. Tomemos o exemplo de um agente de software que é formulado para que uma quantia predefinida de um ativo seja movida de uma conta de uma pessoa (A) para outra (B) se uma condição pré-determinada for atendida. Este agente de software não cria obrigações legais entre A e B. Ele não impõe uma obrigação legal em A de transferir o ativo; esse agente simplesmente prevê que uma transferência ocorrerá se a condição relevante for satisfeita. Se o agente de software for projetado para atender a uma obrigação legal preexistente, isso pareceria uma instância em que o código materializa um smart contract, conforme descrito anteriormente. Porém, isso levanta a questão de porque A iniciaria tal agente se isso não satisfizesse uma obrigação legal de B e o que aconteceria se A simplesmente decidisse não executar o agente de software. ↩

3. Na área de smart contract design, também não é pacífico o uso dessa terminologia. Adotamos aqui a linha de que turing completeness refere-se à capacidade de um smart contract executar todas as operações jurídicas nele contidas e assim finalizar todos os atos ligados a um negócio jurídico sem necessidade de qualquer interpretação e/ou ação humana subsequente. Uma explicação super simplificada do problema pode ser lida aqui: https://academy.binance.com/en/glossary/turing-complete ↩

4. Mesmo quando auxiliado por Oracles para verificação de condições e eventos, ou para definição de variáveis, ainda assim todas as operações precisam ser definidas (declaradas) e precisam ter seus parâmetros de execução pré-determinados ou determináveis sem precisar recorrer a seres humanos, pois isso removeria sua auto exequibilidade; no instante em que você reintroduz a necessidade de ação humana em qualquer momento após a assinatura ou surgimento do contrato, seu implemento passa a sofrer o risco de ser ilegitimamente bloqueado. ↩

5. Programadores declaram os objetos e estabelecem proposições elementares, mas seus significados não analisados para determinar se tais proposições são verdadeiras ou falsas. Você armazena as disposições de um contrato na forma de regras explícitas. Mesmo quando adicionado operadores deônticos (permissões e obrigações), smart contracts construídos dessa forma não possuem qualquer “conhecimento” do Direito ou “compreensão” do significado das palavras usadas no documento. Para entender o problema filosófico envolvido, veja o paper clássico de 1991 Semantics in Legal Expert Systems de Ronald K. Stamper: https://ris.utwente.nl/ws/files/6690611/Stamper91role.pdf. ↩

6. Além da complexidade do próprio código, que teria de ser 100 ou até 1.000 vezes maior do que o código de um smart contract baseado em funções simples e lógica proposicional, o custo computacional é elevado e a performance é reduzida pela necessidade do agente de software levar consigo todos os inputs (objetos de dados instanciados), executar todas as funções e operações lógicas no mesmo ambiente de runtime. ↩

7. Legal coding é o processo de tomar uma minuta padrão e adicionar sintaxe a ela para que possa ser devidamente automatizada sistemas de document assembly, Uma vez que um documento é “codificado” o modelo (ou template) pode ser usado em sistemas de document assembly para consultar informações de um banco de dados e completar a tarefa de montagem de documentos em lote com as informações adequadas e relevantes. ↩

8. Veja por exemplo https://www.smoothfusion.com/blog/what-is-a-digital-experience-platform-dxp ↩

9. Esse módulo ainda não está disponível na plataforma Looplex. ↩

10. Com dois motores de inferência distintos (Looplex Assembler, Looplex Render), dois motores de visual analytics (PowerBI e Looplex Plot) e várias outras opções dependendo do desafio de automação desejado pelo usuário. ↩

11. Se o usuário precisa efetivamente de um smart contract turing complete, executável em um ledger distribuído (DLT), como o blockchain do Ethereum, é possível gerar uma dupla camada de output: texto e código de execução do conteúdo, sem prejuízo dos fluxos automatizados de execução que podem rodar dentro da plataforma. ↩