Semelhanças entre a Verificação de Contratos e a Depuração explicadas por um Advogado Ex-Engenheiro de IT

O cerne do trabalho do chamado “advogado consultor da empresa” é verificar e corrigir os contratos que a empresa celebra diariamente com clientes e parceiros de negócios. E esta verificação e correção só pode ser adequadamente realizada por alguém que é “conhecedor da lei e do respectivo campo de negócios”. Explicarei porquê.

No entanto, a explicação a seguir pode ser difícil de entender para aqueles que não são engenheiros ou têm experiência em programação. O escritório de advocacia Monolith é um escritório de advocacia liderado por um advogado que é um ex-engenheiro de TI com experiência em gestão de empresas. Portanto, é posicionado como um “artigo que explica a verificação e correção de contratos, direcionado a gestores com experiência em engenharia e programação, de um escritório de advocacia liderado por um ex-engenheiro de TI e gestor de empresas”.

E com base neste posicionamento, a verificação e correção de contratos é um trabalho semelhante ao chamado “debugging”.

1. O que é um “bug” em primeiro lugar
2. Que tipo de trabalho é o “debugging”
3. Como é que um contrato estabelece um algoritmo
4. Que tipo de trabalho é a correção de um contrato

Embora comece com uma discussão que é “óbvia” para os engenheiros, vou explicar a seguir.

O que são “Bug” e “Debug”

Um “Bug” não é uma “falha no PC”

Quando se fala em “bug”, algumas pessoas podem imaginar uma situação em que, enquanto trabalham num PC, fumaça começa a sair da máquina e o ecrã apresenta uma exibição estranha. No entanto, um PC, basicamente, só executa “como instruído”. Isto é verdade mesmo quando ocorre um bug. Portanto, um “bug” é:

• O PC está a funcionar conforme instruído, mas
• Para o utilizador, essa ação é um “comportamento inesperado”

Este é o fenómeno.

Por que ocorre um “comportamento inesperado”?

Por exemplo, vamos pensar sobre o bug de “atravessar paredes” num jogo de ação do tipo Mario.

O salto do Mario é uma função quadrática. Aceleração, velocidade, coordenadas. No entanto, numa função quadrática típica, por exemplo, “Qual é o valor de Y quando X=1.76582?”, pode-se dividir X em partes infinitamente pequenas, mas num videojogo, não se pode dividir o tempo em partes infinitamente pequenas. Isto porque o ecrã só muda (por exemplo) 30 vezes por segundo. Portanto, de certa forma, o Mario está a “teletransportar-se” 30 vezes por segundo.

Neste contexto, por exemplo, quando “Mario salta e bate numa parede no ar e é repelido”, o que acontece é:

1. No momento anterior, Mario estava no ar, mas
2. No próximo momento, as coordenadas de Mario estão dentro da parede

Este é o caso.

Nestes casos, pode-se determinar que “Mario bateu numa parede no ar enquanto saltava”. Portanto, em linguagem natural,

Se as coordenadas de Mario estiverem dentro da parede, execute o processo de repulsão (※1)

Se escrever um programa como este, pode-se realizar o processo de “Mario salta, bate numa parede no ar e é repelido”.

※1 parece correto, desde que seja escrito desta forma. E, de facto, sob “certas condições”, este processo é correto.

Contudo, se pensar bem, também pode haver situações como a seguinte (※2).

Neste caso, não existe um momento em que “as coordenadas de Mario estão dentro da parede”, portanto, o processo de repulsão não ocorre, e Mario acaba por atravessar a parede.

Este é um exemplo de “bug”. Mesmo que ocorra um “bug de atravessar paredes” por estas razões, não significa que o PC está avariado. O PC está apenas a funcionar conforme instruído, e é o ser humano que avalia esse comportamento como “inesperado” ou “um bug”. E esse “bug” ocorre porque o algoritmo não é adequado.

Considerando se “comportamentos inesperados ocorrerão”

No entanto, na realidade, não se sabe apenas pensando abstratamente se o “atravessar paredes” ocorrerá durante o jogo. Se o “atravessar paredes” pode ocorrer depende de:

• Quão forte é o salto de Mario (velocidade inicial), existem itens como power-ups de salto?
• Quão espessa é a parede no seu ponto mais fino?

Depende destas condições. Depende se o caso ※2 é possível. Se o caso ※2 não for possível, então não há problema com o programa ※1.

O que é o trabalho de “Debug”

Portanto, para realizar o “debug”, ou seja, encontrar e corrigir bugs, é necessário:

1. Decifrar que tipo de algoritmo é o programa (※1 está em linguagem natural, mas na realidade, o programa é escrito numa linguagem própria, por isso a decifração em si é difícil)
2. Considerar sob que condições esse programa opera (investigar a força do salto e a espessura da parede)
3. Considerar se algum comportamento inesperado ocorrerá durante isso

Este é o processo necessário.

O que envolve a verificação de um contrato?

A verificação de um contrato é semelhante a este processo. Em primeiro lugar, um contrato é um instrumento que estabelece regras para as partes envolvidas, considerando eventos futuros possíveis, e define quais direitos e obrigações surgirão para as partes nesses casos, e como elas deverão agir. Nesse sentido, pode-se dizer que é um “programa que regula o mundo real”. Por exemplo,

No caso de ocorrer a situação ●●, a parte A deverá indemnizar a parte B em 1 milhão de euros.

Um contrato que estabelece regras como esta define as condições e os efeitos para eventos futuros possíveis.

E o trabalho de verificar se há algum problema com esse “programa que regula o mundo real” e corrigi-lo se houver, é semelhante à “depuração”.

O contrato não descreve a totalidade do algoritmo

Contudo, existe um ponto extremamente importante, mas difícil de entender para aqueles que não são especialistas em direito, em relação aos contratos. O contrato é um documento que estabelece apenas uma “parte” do algoritmo que regula as relações entre as partes envolvidas. Em outras palavras, ao ler apenas o contrato, não é possível compreender a totalidade do algoritmo que regula a relação entre si e a outra parte.

Por exemplo, quando se compra um CD usado numa loja, o cliente e a loja não celebram um “contrato de compra e venda”, mas se o CD comprado tiver um arranhão que o torne inutilizável no leitor, o cliente vai querer reclamar na loja, e espera que a loja responda adequadamente. Isto não é apenas uma questão de “é um serviço”, mas teoricamente:

1. Mesmo sem um contrato escrito, um contrato de compra e venda é estabelecido
2. O Código Civil Japonês (Código Civil) estipula que o vendedor tem uma responsabilidade de garantia por defeitos em contratos de venda de bens específicos, como CDs usados
3. Portanto, o algoritmo definido pelo Código Civil Japonês está em vigor entre a loja e o cliente, e a loja tem uma responsabilidade de garantia por defeitos

Este é o raciocínio. E um “contrato” é algo que sobrescreve o algoritmo definido por leis como o Código Civil Japonês. Por exemplo, se houver um contrato entre a loja e o cliente que diz “não aceitamos reclamações posteriores sobre quaisquer defeitos nos CDs”, então:

1. Um contrato de compra e venda foi estabelecido
2. O Código Civil Japonês estipula que o vendedor tem uma responsabilidade de garantia por defeitos para o contrato em questão
3. Contudo, de acordo com as disposições do contrato, o princípio 2 é sobrescrito, e a loja não tem uma responsabilidade de garantia por defeitos

É assim que funciona.

O contrato é algo que “sobrescreve” os princípios do Código Civil Japonês

Isto é verdade também para contratos celebrados entre empresas, como no caso do desenvolvimento de sistemas. Por exemplo, se um contrato de desenvolvimento de sistema sob contrato for celebrado entre as partes A e B,

1. O contrato de empreitada é claramente estabelecido pela celebração do contrato
2. No caso de um contrato de empreitada, a responsabilidade pela garantia de defeitos surge para o contratado de acordo com as disposições do Código Civil Japonês
3. Se houver uma disposição sobre a responsabilidade pela garantia de defeitos no contrato, essa disposição sobrescreverá o princípio 2 do Código Civil Japonês. Por exemplo, se uma cláusula de garantia de defeitos for estabelecida por um período mais longo do que o princípio do Código Civil Japonês, a disposição desse período será válida

Esta é a estrutura. Em outras palavras, mesmo que não haja disposição especial sobre a responsabilidade pela garantia de defeitos no contrato, a responsabilidade pela garantia de defeitos ocorrerá.

Isto não se limita a contratos de empreitada ou desenvolvimento de sistemas, mas é uma teoria geral sobre todos os contratos que uma empresa faz, como transferência de ações, captação de fundos por dívida (empréstimo de consumo de dinheiro), emprego, emissão de ações, etc.

Portanto, apenas lendo o contrato, não é possível entender a totalidade do “algoritmo” que regula a relação entre a outra parte e a sua empresa. Para entender a totalidade, é necessário entender o “algoritmo padrão” estabelecido por leis como o Código Civil Japonês. O contrato é apenas algo que sobrescreve esse “algoritmo padrão”.

Não é possível “depurar” sem prever eventos futuros possíveis

Além disso, apenas entender um algoritmo não permite verificar se “não ocorrerão comportamentos inesperados com esse algoritmo”. Tal como acontece com os “bugs” num jogo, um algoritmo é, no final das contas, algo abstrato e, a menos que se preveja que tipo de evento pode ocorrer no futuro, não é possível verificar se “não se tornará um comportamento inesperado quando tal evento ocorrer”.

Isso é particularmente problemático quando se trata de novos produtos como aplicações ou serviços, ou novos esquemas de negócios. Que tipo de coisas podem acontecer no futuro quando se expande um negócio com esses produtos ou esquemas? Isso é difícil de prever sem conhecimento na área relevante. Além disso, especialmente no caso de contratos entre empresas, ambas as empresas agem sob uma certa racionalidade económica, portanto, para prever eventos futuros e as ações do outro partido que os causarão, é necessário um pensamento baseado na teoria dos jogos da gestão empresarial.

Se algo é “inesperado” depende também do julgamento da gestão

Além disso, assim como é o ser humano e não o PC que determina se um evento é um “bug”, se uma consequência resultante de um contrato é “inesperada” ou não, não é apenas uma questão de direito puro, mas também uma questão de julgamento de gestão.

Por exemplo, pode haver casos em que o algoritmo “de acordo com os princípios do Código Civil Japonês” é inaceitável para um determinado negócio de uma determinada empresa. Embora isto seja uma mudança do exemplo anterior, o Código Civil Japonês, por exemplo, estabelece um algoritmo padrão que diz que “a subcontratação pelo contratado é uma violação do contrato”. No entanto, pode haver casos em que “para uma determinada empresa, é natural que um determinado negócio use subcontratados”. Em tais casos, um contrato que torna impossível a subcontratação, ou seja,

• Nada é especificado sobre a possibilidade de subcontratação (neste caso, como mencionado acima, os princípios do Código Civil Japonês são aplicados)
• Está claramente indicado que a subcontratação é impossível

deve ser inaceitável, mesmo que seja “de acordo com os princípios do Código Civil Japonês”.

Além disso, na gestão, há sempre o risco de “ser responsabilizado se certas circunstâncias ocorrerem”. Não existe basicamente um contrato que “não tem risco” para a própria empresa. Se aceitar ou não esse risco é, em última análise, uma decisão de gestão. A decisão de gestão é tomada pelo gestor, não por um consultor como um advogado consultor, mas o consultor deve fornecer informações suficientes para o gestor tomar uma decisão de gestão, tais como:

• Riscos que não precisam ser apontados a cada vez
• Riscos que, se aceitos, se tornam uma decisão importante para a empresa e podem exigir reuniões, dependendo do caso

devem ser apontados com diferentes graus de importância. Para definir esses “níveis de importância”, assim como em outras áreas de consultoria, os advogados que verificam os contratos também precisam ter um certo senso de “gestão”.

Resumo

Assim, podemos dizer que a verificação e correção de contratos envolve, em grande parte, as seguintes tarefas:

1. Compreender como os princípios do Código Civil Japonês, entre outros, são substituídos pelo contrato e, como resultado, que tipo de algoritmo é formado
2. Considerar que tipo de eventos podem ocorrer no futuro sob esse algoritmo
3. Verificar se não ocorrerão comportamentos inesperados

E cada uma dessas tarefas é:

1. Difícil para quem não entende a lei
2. Difícil para quem não entende o conteúdo do negócio que o contrato regula, como um aplicativo ou serviço web, esquemas de negócios, etc.
3. Difícil para quem não tem um certo nível de compreensão do conteúdo da empresa ou do negócio, ou do senso de gestão

É por isso.

A verificação e correção de contratos são, por estas razões, muito “especializadas”.

Informações sobre a criação e revisão de contratos pela nossa firma

Na Monolis Law Firm, como uma firma de advocacia especializada em IT, Internet e negócios, oferecemos serviços como a criação e revisão de vários contratos para as nossas empresas clientes e consultoras.

Se estiver interessado, por favor veja os detalhes abaixo.

https://monolith.law/contractcreation[ja]