Documentos estruturados, contratos ricardianos e smart contracts

Documentos jurídicos podem ser produzidos por automação, associados a dados estruturados e utilizados em fluxos que executam tarefas. Para projetar essas soluções, é útil separar três aspectos: o conteúdo expresso, sua representação computacional e as operações realizadas a partir dele.

Esses aspectos podem coexistir em uma aplicação. Um contrato pode ter uma versão legível pelas partes, dados sobre suas obrigações e um fluxo que acompanha vencimentos. Cada componente tem um papel e precisa manter uma relação identificável com os demais.

Texto, dados e execução

Aspecto	Função	Exemplo
Texto e apresentação	Comunicar o conteúdo às pessoas.	A cláusula que descreve uma obrigação de pagamento.
Dados estruturados	Representar elementos em um formato utilizável por sistemas.	Credor, devedor, valor, moeda e vencimento.
Regras e execução	Avaliar condições e realizar operações.	Calcular um valor ou encaminhar uma obrigação para conferência.

Um arquivo legível por computador pode conter apenas texto. A estruturação semântica acrescenta a identificação dos conceitos e das relações necessárias à aplicação. Já a execução depende de regras, serviços ou programas que utilizem essas informações.

A representação deve preservar a origem e o estado da informação. Um valor extraído de uma minuta, uma proposta aceita e uma obrigação registrada após assinatura não são intercambiáveis.

Documentos automatizados e documentos estruturados

Um documento automatizado é produzido, total ou parcialmente, por um processo de geração. O processo pode preencher campos, selecionar cláusulas, aplicar regras ou utilizar IA na elaboração de conteúdo.

Um documento estruturado, no sentido utilizado neste guia, mantém conteúdo ou elementos associados organizados segundo um esquema. Essa estrutura pode estar no próprio arquivo ou em registros relacionados. O Modelo de Dados Jurídicos Comum oferece uma referência para representar conceitos compartilhados entre aplicações.

A geração automatizada e a estruturação são propriedades diferentes. Um documento recebido de terceiros pode ser estruturado por extração e conferência. Um documento gerado automaticamente pode ser entregue como arquivo sem expor ao destinatário os dados utilizados em sua montagem.

A expressão documento inteligente pode descrever a combinação de conteúdo, dados e automações. Ao utilizá-la em uma especificação, convém indicar quais capacidades estão efetivamente presentes e onde são executadas.

O conceito de contrato ricardiano

Na formulação de Ian Grigg, o contrato ricardiano relaciona uma descrição contratual legível por pessoas e programas à identificação de um instrumento e de suas transações. O modelo inclui assinatura digital, informações de chaves e servidor e um identificador seguro associado ao documento.¹

Essa proposta ajuda a compreender a ligação entre conteúdo, identidade documental e registros computacionais. A leitura por programas não implica que o documento execute, por si só, todas as obrigações descritas.

Uma aplicação que associa texto e dados pode aproveitar essa ideia sem implementar integralmente o modelo ricardiano original. Nesse caso, a documentação deve explicitar a adaptação. O simples uso de um template, de JSON ou de assinatura eletrônica não basta para afirmar equivalência com o modelo.

Smart contracts e execução computacional

No contexto do Ethereum, um smart contract é um programa composto por código e estado, implantado na rede e executado conforme as chamadas e regras do ambiente.²

Esse programa pode participar da execução de uma relação contratual, mas sua função computacional precisa ser distinguida do conteúdo do acordo e de seus efeitos jurídicos. Informações externas, permissões, erros e condições não representadas no código também precisam ser considerados no projeto.

O termo Turing-complete descreve capacidade computacional: a possibilidade de expressar computações gerais, considerados os pressupostos teóricos de recursos. Ele não significa que um programa represente todas as obrigações de um negócio ou dispense decisões humanas. Ambientes reais impõem limites de execução; no Ethereum, o consumo de recursos é controlado por gas.³

Validade jurídica e automação

A validade de um negócio jurídico não decorre do rótulo tecnológico adotado. No Brasil, a análise deve observar, entre outros requisitos aplicáveis, capacidade, objeto e forma, conforme o art. 104 do Código Civil; o art. 107 trata da liberdade de forma quando a lei não exige forma especial.⁴

A execução de código tampouco resolve, por si, questões de interpretação, consentimento, cumprimento ou responsabilidade. Ao projetar uma solução, é necessário definir a relação entre o texto aprovado, os dados registrados e as operações autorizadas.

Aplicação à arquitetura da Looplex

Na Looplex, essa distinção ajuda a compreender como diferentes recursos participam de um trabalho:

• O Analyzer identifica documentos e estrutura informações dos materiais recebidos.
• O Builder gera documentos com modelos, dados e regras.
• O Content organiza os arquivos, suas versões e seu acesso.
• O Cases relaciona documentos, informações, atividades e histórico.
• O Assistente, os fluxos e as integrações podem utilizar esses elementos em trabalhos configurados.

Por exemplo, um contrato recebido pode ter suas informações extraídas e conferidas, ser relacionado ao caso e originar atividades de acompanhamento. A operação ocorre nos serviços e fluxos habilitados, com as permissões e aprovações previstas. A conexão entre arquivo, dados e atividades pode existir sem execução em blockchain.

Esses recursos não tornam automaticamente todo documento produzido pela plataforma um contrato ricardiano. Uma integração com um ambiente de smart contracts exigiria especificação própria de dados, código, identidade, autorizações e condições de execução.

Definições necessárias em um projeto

Para tornar a relação entre conteúdo e execução verificável, a especificação deve identificar:

1. Qual documento e versão expressam o conteúdo aprovado.
2. Quais dados foram extraídos, informados ou calculados, com suas origens.
3. Quais regras e serviços utilizam esses dados.
4. Quais operações exigem revisão ou aprovação.
5. Como alterações, divergências e falhas serão tratadas.
6. Como serão registrados os resultados e a vinculação com o caso.

O guia Automação jurídica: modelos, regras e inteligência artificial aprofunda a combinação desses mecanismos.

Footnotes

1. Ian Grigg, The Ricardian Contract, 2004. A descrição é uma referência conceitual; escolhas criptográficas de implementações atuais exigem avaliação própria. ↩

2. Ethereum, Introduction to smart contracts. ↩

3. Ethereum, Whitepaper — Turing-Completeness. Referência ao conceito computacional e à limitação de execução por gas. ↩

4. Brasil, Código Civil, arts. 104 e 107. ↩