Criptocontratação-Uma nova forma de contratação ......ledger technologies (como o blockchain e o...

Daniel Augusto de Senna Fernandes Batalha

Criptocontratação: uma nova forma de contratação automatizada?

•

Cryptocontracting: a new means of automatized contracting?

Dissertação apresentada à Faculdade de Direito da Universidade de Coimbra

no âmbito do 2.º Ciclo de Estudos em Direito (conducente ao grau de Mestre), na Área de Especialização em Ciências Jurídico-Forenses

Orientador: Doutor Alexandre Libório Dias Pereira

Coimbra, 2018

Ao Doutor Alexandre Libório Dias Pereira,

À Rás,

Aos meus amigos Andreia, Júlia, Sara, Susana, Nelson, Paulo e Zé Tó,

À minha família,

E, em especial, à minha Mãe e Irmã,

que sempre acreditaram em mim e sem as quais não seria o que sou hoje.

Resumo

Esta investigação almeja analisar as tecnologias que apoiam as distributed ledger technologies

(como o blockchain e o tangle), para que se possa determinar se a contratação automatizada com

recurso a agentes de software se trata de uma nova forma automatizada de contratar e se o actual

regime aplicável à contratação sem intervenção humana, previsto no art. 33.º da Lei do

Comércio Electrónico (Decreto-lei n.º 7/2004, de 7 de Janeiro, mais recentemente alterada pela

Lei n.º 46/2012, de 9 de Agosto) é suficiente para resolver os problemas que possam surgir em

caso de conflito.

Palavras-chave: agentes electrónicos; agentes de software; blockchain; contratação

automatizada; contratação electrónica; contratação sem intervenção humana; decreto-lei n.º

46/2012, de 7 de Janeiro; distributed ledger technology; smart contracts

Abstract

This research aims at analyzing distributed ledger technologies (such as blockchain and tangle),

in order to determine whether the use of software agents in automated contracting is in fact a

new means of automated contracting, and if the current regulation is sufficient to solve problems

that may arise in case of conflict.

Keywords: electronic agents; software agents; blockchain; automatized contracting; electronic

contracting; contracting without human intervention; decree-law 46/2012 of January 7;

distributed ledger technology; smart contracts.

«For time flows on, and if it did not,

it would be a bad prospect for those who do not sit at golden tables.

Methods become exhausted; stimuli no longer work.

New problems appear and demand new methods.

Reality changes; in order to represent it, modes of representation must also change.

Nothing comes from nothing; the new comes from the old,

but that is why it is new»

– Bertolt Brecht

Índice Introdução ..........................................................................................................................9

1. A criptografia e as distributed ledger technologies ........................................................... 11

1.1 Noção de criptografia .............................................................................................. 11

1.2 Noção de distributed ledger technology .................................................................... 12

2. A assinatura electrónica ................................................................................................. 15

2.1. A assinatura tradicional e a assinatura electrónica ...................................................... 15

2.2. Modalidades de assinatura electrónica e seus efeitos jurídicos .................................... 16

2.3. O papel da criptografia e do time stamping na assinatura electrónica .......................... 18

3. Smart contracts e agentes de software ............................................................................... 20

3.1 Origem e noção de smart contracts ............................................................................ 20

3.2. Noção e tipos de agentes de software ........................................................................ 21

4. Contratração electrónica ................................................................................................ 28

4.1. Abordagem ao tema e modalidades de contratação electrónica .................................. 28

4.2 Caracterização dos agentes de software........................................................................ 32

4.3 Qualificação jurídica dos agentes de software ............................................................. 34

4.4 O (eventual) regime jurídico dos agentes de software ................................................. 41

4.4.1 A ‘procuração’ do agente de software ................................................................. 42

4.4.2 A forma e o momento de celebração do contrato ................................................ 43

4.4.3 O ‘erro’ do agente de software ............................................................................ 45

5. Algumas notas sobre a Resolução do Parlamento Europeu ............................................... 51

Conclusão ........................................................................................................................ 55

Bibliografia ....................................................................................................................... 57

Índice de figuras Figura 1 – Compra e venda numa plataforma blockchain ............................................................... 23 Figura 2 – Inscrição de uma aposta em blockchain ......................................................................... 24 Figura 3 – Representação do ‘blockchain AirBnb’ .......................................................................... 25

Siglas e abreviaturas mais usadas Ac./Acs. Acórdão, Acórdãos Al./Als. Alínea, alíneas

Art./Arts. Artigo, artigos atEDI Recomendação da Comissão 94/820/CE, de 19 de Outubro, relativa aos

aspectos jurídicos da transferência electrónica de dados Cf. Conferir, confrontar

DAG Directed Acyclic Graph, Gráfico Dirigido Acíclico DCD Directiva 2011/83/EU, de 25 de Outubro, Directiva relativa aos direitos dos

consumidores DCE Directiva 2000/31/CE, de 8 de Junho, Directiva sobre o Comércio Electrónico DL Decreto-lei

DLT Distributed Ledger Technology / Distributed ledger technologies EDI/TED Electronic Data Interchange, Intercâmbio Electrónico de Dados, Transferência

Electrónica de Dados eIDAS Regulamento (UE) 910/2014, que revogou a Directiva 1999/93/CE

Et al. Et alia LCE Lei do Comércio Electrónico, Decreto-lei n.º 7/2004, de 7 de Janeiro, mais

recentemente alterada pela Lei n.º 46/2012, de 29 de Agosto MAC Message authentication code

N.º/n.ºs Número, números P2P/p2p Peer-to-peer

PoC Proof-of-Capacity, Proof-of-Space PoS Proof-of-Stake PoW Proof-of-work

RJDEAD Regime Jurídico do Documento Electrónico e da Assinatura Digital Decreto-lei n.º 290-D/99, de 2 de Agosto, mais recentemente alterado pelo Decreto-Lei n.º 88/2009, de 9 de Abril

RUE Regulamento (UE) SHA Secure Hash Algorithm, Algorítmo de Hash Seguro SSL Secure Sockets Layer STA Supremo Tribunal Administrativo TCA Tribunal Central Administrativo TSL Transport Layer Security V. Vide, Veja-se

V.g. Verbi gratia VPN Virtual Private Network

Criptocontratação: uma nova forma de contratação automatizada? Daniel Augusto de Senna Fernandes Batalha

9 | 69

Introdução Nunca o desenvolvimento tecnológico nas áreas da robótica e da inteligência artificial

sentiu um progresso tão acentuado quanto aquele que é sentido hodiernamente. Perante a rápida

(rapidíssima) evolução destas áreas, é apenas natural que se formem sentimentos de curiosidade,

incerteza, desconfiança e até medo do desconhecido na sociedade.

Por ocasião da 9ª edição da Conferência Web Summit (uma conferência centrada na

tecnologia da internet, que decorreu entre os dias 6 e 9 de Novembro de 2017), que contou com

a apresentação do robô Sophia, de um serviço de deslocações partilhadas pelo ar e ainda com a

apresentação e discussão de diversas criptomoedas, como a bitcoin e a ethereum, e das chamadas

Distributed Ledger Technologies (e suas respectivas aplicações), divulgaram-se nos meios de

comunicação social duas notícias com manchetes patentemente contraditórias, espaçadas por

pouquíssimos dias: lia-se no dia 7 de Novembro de 2017, na manchete de uma notícia do CNBC

«Bitcoin has no future because of its anonymity, SocGen CEO says»1 (A bitcoin não tem futuro

devido ao seu intrínseco anonimato, diz presidente executivo da SocGen, numa tradução livre);

poucos dias depois, a 11 de Novembro de 2017, surge outra manchete novamente sobre a bitcoin,

mas desta vez do RT, onde se podia ler «Bitcoin is ‘the greatest technology since the internet’ –

cryptocurrenty investor Tim Draper» 2 (A bitcoin é a ‘melhor tecnologia desde a internet’ –

investidor em criptomoeda, Tim Draper, numa tradução livre).

Retratando duas opiniões incontestavelmente díspares (uma pessimista e outra

optimista), pode-se afirmar que se trata, no fundo de um reflexo daqueles sentimentos de

curiosidade, incerteza, desconfiança e medo do desconhecido. É precisamente a partir desta

incerteza e curiosidade que ‘nasce’ o trabalho a que nos propomos desenvolver; um trabalho que,

por força da sua novidade, carece de apoio jurisprudencial, mas nem por isso desmerece a nossa

atenção e dedicação.

Pelo exposto, esta investigação almeja analisar as tecnologias que apoiam as distributed

ledger technologies (como o blockchain e o tangle), para que se possa determinar se a contratação

automatizada com recurso a agentes de software se trata de uma nova forma automatizada de

contratar e se o actual regime aplicável à contratação sem intervenção humana, previsto no art.

1 Cf. BROWNE (2017). 2 Cf. RT (2017.


10 | 69

33.º da Lei do Comércio Electrónico (Decreto-lei n.º 7/2004, de 7 de Janeiro, mais

recentemente alterada pela Lei n.º 46/2012, de 9 de Agosto) é suficiente para resolver os

problemas que possam surgir em caso de conflito. Revela-se uma questão pertinente pois, não

sendo, significaria que se reclama um novo regime jurídico, adequado às características desta

forma de contratar ou, no limite, uma reforma no actual regime, de maneira a adaptá-lo à

realidade que se convoca.

Assim, após apresentação das distributed ledger technologies e da criptografia, estudaremos

as modalidades da assinatura electrónica, o seu regime e os seus efeitos jurídicos. Findo este

percurso, debruçar-nos-emos sobre a origem e o conceito de smart contracts e ainda da noção e

tipologias de agentes de software, que constituem, a bem dizer, o cerne deste trabalho.

Lançadas as bases, estaremos em condições para correctamente compreendermos a

tecnologia em apreço. Assim, será objecto do Capítulo 4 o tema da contratação electrónica.

Neste Capítulo teremos oportunidade de, não apenas apresentar a contratação automatizada

com recurso à EDI, mas também demonstrar que os agentes de software poderão constituir a

nova forma de contratar ‘automatizadamente’. Por outras palavras, iremos apresentar uma forma

de contratar que convocará a participação de agentes de software e ao recurso à criptografia para

concluir negócios jurídicos sem intervenção humana, a que alguns denominam de

criptocontratação (do inglês cryptocontract)3.

Após um estudo mais aprofundado das características dos agentes de software (que, como

veremos se trata de um programa de computador destinado a actuar autonomamente ‘em nome’

do seu sujeito utilizador, podendo este ser dotado de capacidades de observação de padrões de

comportamento e de auto-aprendizagem), focar-nos-emos na tentativa da qualificação jurídica

e da apresentação de um eventual regime jurídico aplicável a estes. Em síntese, se o agente se

trata de um mero instrumento do seu sujeito utilizador, se o agente se trata antes de um núncio,

ou, ainda, se o agente de software poderá ser enquadrado no regime da representação.

Antecipando, iremos corroborar com a posição adoptada por Francisco Pereira COELHO4, que

demonstra como possível e justificado o enquadramento do agente de software enquanto

representante.

3 Cf. ROUSE (2016). 4 Cf. COELHO (2017).


11 | 69

1. A criptografia e as distributed ledger technologies

1.1 Noção de criptografia

Criptografia tem oridem do grego kryptos, que significa escondido, oculto, envolto,

seguro; e graphos, que significa grafar, escrever. Ou seja, etimologicamente podemos definir

‘criptografia’ como escrita secreta, ou escrita oculta.

Outrora, os termos criptografia e encriptação (a conversão de informação legível para

algo aparentemente ilegível) eram usados sinonimicamente, sendo que o criador da mensagem

encriptada partilhava o método de desencriptação apenas com o(s) destinatário(s) pretendido(s),

prevenindo assim que terceiros tivessem acesso à mesma. Contudo, o desenvolvimento de

máquinas criptográficas, como a Lorenz SZ 40/42 durante a Primeira Grande Guerra, e dos

computadores, na Segunda Grande Guerra, fomentou a evolução da criptografia. Porém,

actualmente já não nos limitamos à mera encriptação/decriptação de mensagens; antes

deparamo-nos com uma criptografia aliada à teoria matemática e à ciência computacional,

recorrendo a algoritmos, conferindo uma garantia de segurança (quase) absoluta.

Da chamada criptografia moderna, destacamos dois modelos de sistemas criptográficos:

(i) a criptografia simétrica com chave única e (ii) a criptografia assimétrica de chave pública5.

Ambos os modelos recorrem a uma função hash criptográfica (do inglês cryptographic hash

function) para proteger uma determinada mensagem a ser enviada do remetente para o

destinatário; este processo traduz-se na tradução daquela mensagem, através de uma função hash

para um message digest (que se expressa numa determinada sequência binária ou de bits)6. Porém,

distinguem-se no modo como protegem este message digest:

§ Na criptografia simétrica de chave única o remetente encripta a message digest com o

auxílio da chave secreta partilhada com o destinatário, sendo esta desencriptada pelo

destinatário com o auxílio da mesma chave secreta. Trata-se do mesmo sistema que

permite a encriptação das caixas ATM (vulgo Multibanco), a privacidade do correio

electrónico7 e a segurança do acesso remoto;

§ Já na criptografia assimétrica de chave pública tanto o remetente como o destinatário

possuem um par chaves matematicamente conexas, distintas e indissociáveis: uma

5 Cf. CORREIA (2009), p. 162; PEREIRA (1999), pp. 21-25. 6 Cf. SCHNEIER (2004) e ROCHA (2002), p. 2, PEREIRA (1999), p. 20. 7 Cf. WONG (2005).


12 | 69

pública e uma privada. Assim, para cifrar a mensagem, o remetente encripta a sua

mensagem com o auxílio da chave pública do destinatário, sendo esta posteriormente

decifrada pelo destinatário com o auxílio da sua chave privada.

É precisamente a criptografia assimétrica de chave pública que permite a existência de

esquemas de segurança em rede (v.g. SSL/TLS, diversos VPNs, etc.8), bem como retirar as

presunções de autoria, apropriação do conteúdo da declaração, completude do texto e da

inalterabilidade do DEc quando é aposto a este uma assinatura electrónica qualificada (cf. art.

2.º, al. g), e art. 7º, n.º 1, ambos do RJDEAD). A este respeito, CORREIA afirma que, apor este

tipo de assinatura, traduz-se na criação de uma «espécie de ‘selo electrónico’ que é acrescentado»

àquele9. Entre nós, as definições de chave pública e chave privada encontram-se plasmadas nas

als. e) e f) do art.º 2.º do RJDEAD, sendo estas definições cruciais para que se compreendam as

noções de assinatura digital e assinatura electrónica qualificada (respectivamente definidas nas

als. d) e g) da mesma norma), noções sobre as quais nos debruçaremos mais adiante.

1.2 Noção de distributed ledger technology

A distributed ledger technology, ou DLT, é uma tecnologia que recorre ao uso extensivo

de criptografia para guardar, proteger e validar transacções electrónicas10, registando-as numa

base de dados electrónica cuja manutenção cabe a uma rede distribuída (ou partilhada) de

participantes (chamados nodos11), e não a mais por uma entidade centralizada, dispensando a

necessidade de um sistema central de validação. Apresenta-se, destarte, como um “sistema de

livro-razão” descentralizado, aberto e público, assemelhando-se a uma base de dados, sendo a

sua validação feita pelos seus utilizadores de forma local, segundo um determinado protocolo de

consenso (v.g. PoW, PoS, PoC e DAG 12 ). É precisamente devido a esta característica

8 Cf. SCHNEIER (1996). 9 Cf. CORREIA (2009), pp. 162-163. 10 Cf. ESMA (2016). 11 Um nodo (do Latim “nodus”) é um ponto de conexão ou redistribuição ou terminal de comunicação. Neste contexto, referimo-nos a “nodo” de refere física, ou seja, um dispositivo electrónico activo ligado a uma rede e capaz de enviar, receber ou transmitir informações através de um canal de comunicação. Cf. <http://www.webcitation.org/5kx5kPIKV> (Obtido em 10 de Novembro de 2017). 12 Sobre o conceito de PoW, cf., nomeadamente, DWORK et al. (1993); sobre o PoW, cf. BACK (2002); sobre o PoS, cf., designadamente, VASIN (2014), KING et al. (2012), BUTERIN (2013); para uma comparação entre PoW e PoS, cf., por exemplo, BitFury Group (2015); sobre o PoC, cf., entre outros, GALESI et al. (2014), DZIEMBOWSKI et al. (2013); sobre o DAG, cf. BTCmanager.com (2017), THULASIRAMAN et al. (2011), BANG-JENSEN et al. (2009), entre outros.


13 | 69

descentralização e capacidade de guardar e confirmar a validade da informação em tempo real a

um custo muito reduzido, que se tem tido em conta o potencial revolucionário no modo de

funcionamento da indústria de serviços financeiros com recurso à DLT. De facto, no entender

de Don e Alex Tapscott, estamos a aproximarmo-nos de uma mudança de paradigma: de uma

Internet of Information para uma Internet of Value13.

Podemos identificar o Tangle e o Blockchain como dois exemplos de DLT, que se

distinguem, essencialmente, no sistema de consenso adoptado: no Tangle recorre-se a DAG para

criar uma espécie de “trança” de registos, no Blockchain recorre-se a PoW, PoS ou PoC para criar

uma ‘corrente’ de registos. Porém, dada a novidade do Tangle14, concentrar-nos-emos somente

no Blockchain, que foi apresentado como a trave-mestra da criptomoeda bitcoin15.

O Blockchain pode ser definido como uma rede peer to peer (p2p) que recorre a um

esquema de consenso baseado em PoW, PoS ou PoC para registar e validar transacções

(esquemas que se contrapõem ao esquema de funcionamento baseado na confiança, utilizado,

v.g. por bancos, que recorrem a terceiros de confiança que asseguram a validade da transacção)16.

Ou seja: a rede, aplica um selo temporal a todas as transacções (que foram assinadas

electronicamente) e insere-as numa “corrente”, por via de funções hash17, criando assim um

registo que não pode ser alterado sem que se refaça toda a “cadeia”. Destarte, quanto mais longa

for a ‘corrente’, mais evidente será a demonstração/prova da sequência de transacções feitas entre

os nodos naquele blockchain. É justamente este protocolo de consenso de Nakamoto – a

aceitação por parte de todos os nodos do blockchain dos factos inseridos na ‘cadeia’ – que garante

a validade destas transacções18.

Compreende-se da exposição feita que é possível atender às (naturais) preocupações no

que à privacidade dos particulares e das suas transações diz respeito perante a reconhecida

13 Cf. TAPSCOTT et al. (2016), p. 6. 14 Cf. BTCmanager.com (2017), LIMO (2017), BUNTINX (2016), VIZARD (2017). 15 V. infra. 16 Cf. NAKAMOTO (2008), p. 3; BACK (2002); JAKOBSSON (1999). 17 Na verdade, o bitcoin recorre ao uso do SHA-256 (ou SHA-2). SHA trata-se de uma hash function criptográfica que permite a encriptação de determinada mensagem, transformando-a num message digest de 32 bytes (equivalente a 256 bits). Sendo um sucessor do SHA-1, é uma das funções hash disponíveis mais seguras. Sobre SHA, cf., por exemplo, FIPS PUB 180-4 (2015). 18 Cf. NAKAMOTO (2008), pp. 1, 6 e 8.


14 | 69

descentralização e transparência do blockchain. Todavia, tratando-se de código, é possível optar

por um sistema de acesso-restrito (ou acesso-limitado)19.

Por fim, deve-se fazer especial referência à mais recente Lei-Modelo da Comissão das

Nações Unidas para o Direito Comercial Internacional (UNCITRAL), no âmbito da

contratação electrónica: a Lei-modelo sobre registos electrónicos transmissíveis, numa tradução

livre (doravante somente Lei-Modelo)20, aplicável às DLT. A UNCITRAL trata-se de um órgão

subsidiário da Assembleia Geral das Nações Unidas que promove o desenvolvimento do

enquadramento jurídico do comércio internacional, através da elaboração de instrumentos

legislativos tendo em vista a modernização do direito comercial internacional, para uso dos

Estados e através da preparação de textos não legislativos relativos a transacções comerciais, a ser

usados pelas partes. Neste sentido, é propósito daquela Lei-Modelo viabilizar o uso legal de

registos electrónicos transmissíveis, no mercado interno e transfronteiriço.

Das notas explicativas da Lei-Modelo, revelam-se os benefícios e utilidades desta

tecnologia e da importância da criação de um regime jurídico próprio que regule o comércio

electrónico fundado neste tipo de tecnologias, dando particular relevo ao princípio da não

discriminação do recurso aos meios de contratação electrónica e à sua equivalência funcional,

fundando-se num texto tecnologicamente neutro.

19 Neste sentido, BOUCHER (2017, p. 19) refere-se a «private encrypted blockchain systems». Sobre o tema, cf., entre outros, ANTHONYLEWIS2015(2016); BUTERIN (2015b). 20 Disponível online em: <http://www.uncitral.org/uncitral/en/uncitral_texts/electronic_commerce/2017model.html> (Obtido em 10 de Novembro de 2017).


15 | 69

2. A assinatura electrónica

2.1. A assinatura tradicional e a assinatura electrónica

Antes de nos dedicarmos ao tema da assinatura electrónica, importa procurar

compreender o que se entende por assinatura, pois, apesar da preeminência dada a esta figura (já

que apenas o documento assinado poderá revestir força probatória plena), não existe na

experiência legislativa uma definição única uniformizadora por serem diversos os tipos de sinais

e procedimentos técnicos que utilizam esta mesma expressão21. Com efeito, podemos dizer que

uma assinatura é uma «subscrição de um documento pelo nome do seu autor»22, podendo esta

ser de chancela, a rogo ou digital; ou que se trata do «nome civil ou comercial da pessoa, por ela

lançado abaixo dum acto escrito, para lhe dar autenticidade», podendo esta ser de próprio punho,

quando esta «é feita pela mão do subscritor e não por meio de carimbo, sinete ou chancela»,

abreviada ou rubrica, completa ou por extenso, público, a rogo ou em branco23; ou, de forma

semelhante, que é «a subscrição do documento com o nome do seu autor (signatário)» ou que

«consiste na aposição do nome da pessoa feita pelo seu titular»24 ou «a person’s name or mark

written by that person or at the person’s direction»25, podendo ser uma digital, facsimile, private ou

unauthorized; ou ainda «a sign or mark impressed upon anything; a stamp, a mark; the name of a

person written by himself either in full or by initials only»26. São, portanto, inúmeras as (tentativas

de) definição desta figura. Não obstante, e sufragando a posição de CORREIA27, consideramos

que a assinatura se trata de um sinal ou processo usado por determinada pessoa com

exclusividade, colocado em dado documento por forma a que o autor deste (i) revele a sua

identidade pessoal de forma evidente e inequívoca, (ii) manifeste as suas declarações de vontade

lá presentes e (iii) preserve a integridade do documento, na medida do possível.

Em Portugal, foi o DL n.º 290-D/99, de 2 de Agosto, que veio regular as relações

jurídicas por meios electrónicos, tendo sido posteriormente alterado pelo DL n.º 62/2003, de 3

21 Em 1930, a Comissão de Redacção das Leis Uniformes sobre as Letras e Livranças e sobre os Cheques veio esclarecer o sentido em que a palavra ‘assinatura’ era empregue naquele diploma, dada a importância de um conceito globalmente válido. 22 Cf. CARMO (2013), p. 24. 23 Cf. NUNES (1999), p. 120. 24 Cf. FRANCO et al. (1993), p. 102. 25 Cf. GARNER (1999), p. 1387. 26 Cf. JOWITT (1959), p. 1641. 27 Cf. CORREIA (2009), p. 160.


16 | 69

de Abril, em resultado da transposição da Directiva 1993/93/CE28, e, mais recentemente, pelo

DL n.º 88/2009, de 9 de Abril. Ora, atendendo à noção supracitada de assinatura, parece que

nos aproximamos do conceito de assinatura electrónica, previsto no art.º 2.º, al. b), do RJDEAD:

«o resultado de um processamento electrónico de dados susceptível de constituir objecto de

direito individual e exclusivo e de ser utilizado para dar a conhecer a autoria de um documento

electrónico». O legislador português, ao adoptar esta definição, distanciou-se do disposto pelo

legislador comunitário 29 , afastando-a de todos os meios de autenticação que não se

considerassem pessoais e exclusivos30.

Considerando que nos encontramos no domínio digital, no que respeita às funções

essenciais da assinatura, compreende-se que o conceito de assinatura electrónica (AE) assuma

um significado funcional, sendo igualmente natural que se entenda que a um documento

electrónico deva ser aposto uma assinatura electrónica31, por se tratar do sinal tecnologicamente

mais próximo. É justamente neste contexto que urge distinguir as ‘peças’ que integram a

assinatura electrónica: (i) a assinatura, que consiste no símbolo ou marca aposto no ou ao

documento electrónico pelo subscritor, (ii) o acto de assinar, que se traduz no recurso a software

para o processamento de dados do qual resulta uma assinatura electrónica, (iii) os dados de

criação de assinatura32 e (iv) o documento electrónico33, que estabelece o nexo de ligação entre

os dados de criação de assinatura e o subscritor, possibilitando ao destinatário a faculdade de

verificar a autoria do documento.

2.2. Modalidades de assinatura electrónica e seus efeitos jurídicos

O RJDEAD identifica três tipos de assinaturas electrónicas: a assinatura electrónica

avançada, a assinatura digital e a assinatura electrónica qualificada34. Neste seguimento, SOUSA,

L. F. P .35 vai mais longe ao reconhecer a assinatura electrónicaprevista na al. b) do art.º 2.º do

28 A Directiva 1999/93/CE, que procurou desenvolver a prestação transfronteiras de serviços de certificação e trocas comerciais no âmbito do espaço económico europeu (cf. CAMMARATA et al. (2001)), foi revogada pelo RUE 910/2014. 29 Cf. art.º 2.º, n.º 1, da Directiva 1999/93/CE e art.º 3.º, n.º 10, do eIDAS. 30 Neste sentido, cf. PATRÃO (2012), p. 51. 31 Neste sentido, cf. CORREIRA (2009), p. 161. 32 Cf. Art. 2.º, al. h), RJDEAD. 33 Cf. Art.º 2.º, al. a), do RJDEAD. 34 Cf. Als. c), d) e g) do art.º 2.º do RJDEAD, respectivamente. 35 Cf. SOUSA, L. F. P. (2016), p. 82-83.


17 | 69

RJDEAD como assinatura electrónica simples, distinguindo-a dos demais tipos de assinatura

previstos no RJDEAD36.

Atendendo às definições plasmadas nas als. c), d) e g) do art.º 2.º do RJDEAD, podemos

concluir que a assinatura electrónica qualificada é a assinatura mais segura, por se tratar de uma

assinatura digital – que é uma modalidade de assinatura electrónica avançada37 –, baseada num

sistema criptográfico assimétrico de chave pública38 e num certificado qualificado e concebido

por via de um dispositivo seguro de criação de assinatura.

Por conseguinte, esta ‘graduação’ de segurança de assinaturas electrónicas resulta em

diferentes efeitos jurídicos: quando o conteúdo de determinado documento electrónico for

susceptível de ser representado como declaração escrita, este satisfará o requisito legal de forma

escrita 39 e a força probatória do documento electrónico será distinta conforme seja aposta (i)

uma assinatura electrónica simples ou avançada ou (ii) uma assinatura electrónica qualificada ou

assinatura digital: (i) nos primeiros, os documentos electrónicos serão apreciados nos termos

gerais do direito40, (ii) nos últimos, passam a funcionar as presunções de autoria, vontade e

inalterabilidade previstas nas als. a) a c) do n.º 1 do art.º 7.º do RJDEAD. Diversos autores41 e

alguma jurisprudência 42 identificam estas presunções como funções caracterizadoras desta

modalidade de assinaturas electrónicas, especificamente: (a) função identificadora, (b) função de

completude (ou finalizadora) e (c) função de garantia de inalterabilidade. Em termos concisos,

diremos que a função identificadora estabelece a autoria do documento electrónico, que a função

de completude (ou finalizadora) manifesta a conclusão do documento electrónico bem como o

36 De acordo com SOUSA, L. F. P. (2016), considerar-se-iam assinatura electrónicas simples a (a) digitalização de uma subscrição autógrafa, (b) a autenticação por palavra-passe ou PIN, (c) a autenticação por dados biométricos, (d) a simples digitação do nome do autor no final do documento ou ainda (e) um autenticador de mensagem (do inglês, MAC), baseado na criptografia simétrica de chave única. Contudo, consideradas as exigências legais do carácter pessoal e sigiloso do processo de assinatura do documento, na definição supramencionada apenas se subsume o MAC, pois veja-se que a assinatura electrónica simples está apta a identificar o subscritor, mas não permite assegurar, de forma absoluta, que somente o subscritor tem acesso aos dados de criação da assinatura electrónica. 37 A assinatura electrónica avançada deve ser apta para identificar univocamente o titular como autor do documento, dependendo a sua aposição da vontade do titular (sendo criada por meios que este pode manter sob seu controlo) e, a partir da sua conexão com o documento, ser capaz de garantir a inalterabilidade do conteúdo do documento. 38 Cf. Art. 2.º, al. d), do RJDEAD. 39 Cf. Art. 3.º, n.º 1, do RJDEAD. 40 Cf. Art.º 3.º, n.º 5, do RJDEAD. 41 Neste sentido cf., entre outros, CORREIA (2009), pp. 164-165 e 170-171; SOUSA, L. F. P. (2016), pp. 70-71; SOUSA, M. T. (2008), pp. 29-33; ROCHA et al. (2000), pp. 72-74; PEREIRA (2004), p. 203. 42 Cf., designadamente, Ac. STA de 12-03-2015, Ac. STA de 20-06-2012, Ac. TCA Sul de 15-01-2015 (Processo 11671/14), Ac. TCA Sul de 19-05-2016 (Processo 13093/16), todos disponíveis em <www.dgsi.pt>.


18 | 69

assentimento e/ou conhecimento do subscritor quanto às declarações e conteúdo daquele,

assumindo-as como suas e que a função de garantia de inalterabilidade comprova que o

documento electrónico não foi alterado desde a aposição da AE até à sua recepção pelo

destinatário.

Posto isto, retira-se do disposto no art.º 376.º, n.º 1, do CC (aplicável ex vi art.º 3.º, n.º

2, do RJDEAD), que o DEc poderá gozar de força probatória plena, desde que seja aposto a este

uma AE qualificada, exarada ao abrigo de um certificado emitido por uma entidade certificadora

que se ache credenciada; de modo inverso, o documento electrónico que não cumpra estes

requisitos será apreciado segundo o livre critério do julgador.

2.3. O papel da criptografia e do time stamping na assinatura electrónica

Pelo exposto, rapidamente se chega à conclusão que a assinatura electrónica qualificada

recorre, não apenas à criptografia assimétrica de chave pública para que se cumpram as suas

aludidas funções 43 , mas também a certificados qualificados emitidos por uma entidade

certificadora44. É precisamente este certificado, que contém os dados do detentor do par de

chaves e a sua chave pública, que irá permitir verificar a autenticidade da assinatura electrónica.

Como tal, é possível equiparar o certificado a uma espécie de documento identificativo do titular

de um dispositivo de criação de assinatura electrónica, pois, se tradicionalmente se verificava a

autenticidade de uma assinatura autógrafa comparando-a a um documento de identificação do

subscritor, neste contexto é a assinatura electrónica verificada (pelo destinatário ou por um

terceiro que pretenda fiscalizar a autoria da assinatura) pelo referido certificado45.

Verificada a autenticidade da assinatura, dá-se por lançada a primeira pedra para o

desenvolvimento da contratação electrónica: na verdade, o art.º 6º-1, do RJDEAD refere-se à

transmissão de documentos electrónicos por um meio de telecomunicações para determinado

endereço electrónico que deverá ser convencionado, expressa ou tacitamente. Assim, poderá ser

expressamente convencionado o endereço electrónico das partes, v.g. num acordo de

transferência electrónica de dados46.

43 Cf. CORREIA (2009), p. 162. 44 Cf. Art.º 2.º, als. g), o), p) e q), art.ºs 24.º e 29.º, todos do RJDEAD. 45 Cf. CORREIA (2009), p. 175 e ROCHA (2002), p. 2. 46 Cf. art.º 1.1 da atEDI.


19 | 69

Além disso, no que respeita à transferência electrónica de documentos electrónicos, o

legislador pátrio definiu, na al. u) do art.º 2.º do RJDEAD, a validação cronológica como «a

declaração [...] que atesta a data e hora da criação, expedição ou recepção de um documento

electrónico», sendo estes dados oponíveis entre as partes e a terceiros quando esta validação seja

emitida por entidade certificadora. Se o documento electrónico contiver uma assinatura

electrónica qualificada, a sua expedição poderá ser equiparada à carta registada, quando seja feita

por via de telecomunicação que assegure a sua efectiva recepção. Por outro lado, se a à recepção

corresponder o envio de uma mensagem de confirmação subscrita com assinatura electrónica

qualificada e dirigida ao remetente, equivalerá à carta registada com aviso de recepção 47 .

Referindo-se a este mesmo conceito, o legislador comunitário optou por denominar este

conceito de «selo temporal» ou «time stamping» – denominação que preferimos –, estando esta

figura definida e regulada nos arts. 3.º, n.ºs 33 e 34, e 41.º e seguintes, do eIDAS.

47 Cf. Art.º 6.º, n.ºs 2 e 3, do RJDEAD.


20 | 69

3. Smart contracts e agentes de software

3.1 Origem e noção de smart contracts

A bitcoin trata-se de uma criptomoeda criada por Satoshi Nakamoto48 que assenta num

sistema p2p, cujas transacções são verificadas por nodos e registadas numa base de dados

distribuída, sem recurso a um repositório central (ou administrador único)49. É precisamente no

artigo técnico50 em que é divulgada esta criptomoeda que encontramos o aludido blockchain,

que inspirou outros programadores no desenvolvimento de novas aplicações desta tecnologia.

Há autores que consideram o bitcoin de per si menos relevante, por se tratar “apenas” de

‘dinheiro’; são antes as inúmeras aplicações da tecnologia blockchain que merecem a sua (e a

nossa) total atenção 51 . É neste contexto que se manifesta a chamada Crypto 2.0 52 (ou

Criptografia 2.0), que se traduz, como já se adivinha, na implementação do blockchain (ou outro

DLT) em ambientes diversos, para além de um sistema de pagamentos digital.

É justamente a limitação da bitcoin, enquanto plataforma digital de pagamentos, que

inspira a criação de novas plataformas, como o Ethereum 53 e o NXT 54 : tratando-se de

plataformas descentralizadas, baseadas no blockchain de NAKAMOTO, estão aptas para, não

apenas permitir aos seus utilizadores a realização de pagamentos sem recurso a terceiros, mas

também executar smart contracts mais complexos. Por outras palavras, o acervo digital do

blockchain daquelas plataformas poderia passar a representar, além de moeda, instrumentos

financeiros ou câmbios personalizados (tradução livre de colored coins)55 , a propriedade de

determinado bem físico (a chamada smart property)56, ou até mesmo votos num sistema de

votação electrónica57, sendo todas as transacções feitas registadas no blockchain da plataforma.

Os supramencionados smart contracts (ou contratos inteligentes, numa tradução livre),

compreendem uma denominação que poderá induzir a erro: na verdade, SZABO58 frisa que a

48 Cf. DAVIS (2011). 49 Sobre as principais características da bitcoin, cf., entre outros, SAVELYEV (2017). 50 Cf. NAKAMOTO (2008). 51 Cf. ALTER (2017) e TAPSCOTT et al. (2016), pp. 7 e 152 e seguintes. 52 Cf. BROKAW (2014). 53 Cf. BUTERIN (2015a). 54 Cf. Nxt Community (2014). 55 Sobre o termo colored coins, cf. ASSIA et al. (2012). 56 Sobre o conceito de smart property, cf., designadamente, SZABO (1997), BitcoinWiki: Smart Property (2016). 57 Sobre o sistema de votação electrónica baseado na tecnologia blockchain, cf., ente outros, KUBJAS (2017), BARNES et al. (2016), CAIAZZO (2016). 58 Cf. SZABO (1996).


21 | 69

adopção do termo ‘smart’ (ou inteligente na nossa tradução), não implica necessariamente o

recurso à inteligência artificial, mas antes pretende indicar que aquele contrato é dotado de

determinadas funções/capacidades que, devido à sua natureza intrínseca, os contratos

tradicionais não possuem. Assim, SZABO define um contrato inteligente como um conjunto de

promessas expressas em formato digital, onde se incluem as condições/cláusulas que devem ser

respeitadas para que o compromisse se realize.

Embora aparentemente irrisório, é possível dizer que uma máquina automática de

vendas realiza smart contracts primitivos, na medida em que a máquina está programada para

dispensar determinado bem, após verificar que a totalidade do preço foi inserida pelo utilizador59.

Como bem se sabe, esta modalidade de venda encontra-se prevista nos arts. 22.º e seguintes do

DL n.º 24/2014, de 14 de Fevereiro. Contudo, será correcto afirmar que aos smart contracts se

aplicaria por analogia o disposto neste diploma? Não nos parece. Como nota SZABO60, «[s]mart

contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that

is valuable and controlled by digital means». No mesmo sentido, SAVELYEV61 refere que as

máquinas de venda automática apenas substituem a ‘acção humana’ de uma das partes, exigindo-

se alguma intervenção da outra parte (v.g. inserção de moedas, ou uso de algum meio de

pagamento). Por sua vez, smart contracts idealizam uma total autonomização da acção humana,

manifestando-se uma nova característica daquele contrato. Desta forma, não nos parece razoável

subsumir este na definição disposta no diploma anterior.

3.2. Noção e tipos de agentes de software

Antes de propormos uma noção de agente de software, importa desde logo referir que

também aqui se verifica uma denominação indutora de erro, ainda que, desta vez, o lapso seja

por conta da tradução e não da escolha de termos: enquanto que o termo smart contracts foi

escolhido por autores que optaram pelo uso indiscriminado de termos jurídicos62, a expressão

‘agente de software’ trata-se de uma tradução literal do inglês ‘software agents’, sendo que o termo

‘agent’ no direito anglo-saxónico se aproxima mais da nossa figura de ‘representante’ ou

59 Sobre a equiparação das máquinas automáticas a ‘smart contracts primitivos’, cf., entre outros, BAILIS et al. (2017), p. 50; SZABO (1996) e SZABO (1997). 60 Cf. SZABO (1997). 61 Cf. SAVELYEV (2017). 62 Neste sentido, cf. MIK (2017), pp. 272-274.


22 | 69

‘procurador’ do que do nosso ‘agente’, pelo que não podemos compreender estes agentes no

sentido técnico que é dado entre nós.

Assim, e embora não exista consenso quanto à definição de agentes de software63 ,

podemos adiantar que se tratam de programas de computador que assistem um sujeito utilizador

de modo contínuo e autónomo, realizando certa(s) tarefa(s) ou procurando atingir

determinado(s) objectivo(s) definidos pelo mesmo. Esta autonomia e continuidade de

funcionamento destes agentes permite distingu-los dos comuns programas de computador que

tão bem conhecemos.

Sendo possível distinguir diversos tipos de agentes de software, interessam-nos

especialmente os agentes autónomos e os oráculos: enquanto que os agentes autónomos (ou

agentes de software stricto sensu) dizem respeito a agentes de software que residem no blockchain

e são responsáveis pela execução do seu código (rectius a vontade do sujeito utilizador), os

oráculos são agentes de software instalados em servidores externos que, de modo contínuo e

autónomo, verificam e registam determinado tipo de dados no blockchain 64 , funcionando,

portanto, como ‘pontes’ entre o blockchain e o mundo externo. Os oráculos podem ainda ser de

software (quando lidam com dados disponíveis no ciberespaço externo/para além daquela

plataforma) ou hardware (quando lidam com dados disponíveis no mundo externo físico) e

inbound (quando carregam informação do mundo externo para a plataforma) ou outbound

(quando enviam um comando/instrução da plataforma para o mundo externo, como resultado

da operação output65).

Partindo da definição anterior, facilmente se compreende a razão de BUTERIN66 ter

optado pela designação ‘agentes autónomos’ ao invés de ‘contratos (inteligentes)’, uma vez que,

neste contexto, o contrato vai-se cumprindo à medida que o código do agente autónomo é

executado – código este que representa a ‘vontade’ do sujeito utilizador e que, por sua vez,

compreende as condições/cláusulas que devem ser respeitadas pelo agente na execução das suas

63 Sobre a definição de agentes de software, cf. BURGIN et al. (2009); FRANKLIN et al. (1996); JANSEN (1997); NWANA et al. (2012), p. 31; JANCA et al. (2012), p. 75; ALLEN & WIDDISON (1996), p. 27; MAES et al. (1999), p. 1; LEROUGE (2000), p. 405; KERR (2001), pp. 183-184; MOUKAS et al. (2000), pp. 1-2; HABIBZADEH (2016), p. 153; entre outros. 64 Cf. BITFURY GROUP (2015), CHAINFROG OY (2017), WEUSE.CASH (2017), BlockchainHub (n.d.) e LARCHEVÊQUE (2016). 65 V. infra Figura 3 – O conceito de blockchain AirBnB, onde a operação output está representada na operação [5], sendo o oráculo neste exemplo a porta inteligente. 66 Cf. BUTERIN (2015a)


23 | 69

tarefas 67 . Por fim, acrescente-se que estes contratos são identificados por um endereço

(representados por um identificador de 160 bits), sendo a sua correcta execução garantida por

via de um protocolo de consenso, e que, uma vez cumprido o seu propósito, o agente de software

– rectius, o contrato inteligente – caduca e desaparece.

Sendo assim, é concebível que um agente de software seja codificado para realizar uma

compra e venda, verificando a legitimidade do pretenso vendedor (impedindo a venda de coisa

alheia) e a disponibilidade económica do pretenso comprador, garantindo a efectiva entrega do

bem caso as condições se verifiquem. O exemplo descrito na Figura 1, representa uma situação

que conta com a intervenção de apenas um tipo de agente de software.

Na Figura 1, André [A], que pretende vender um e-book por 15 € e que se identifica

com o endereço blockchain 614494 (chave pública), cria o smart contract “SC231” com os

67 Relativamente à ‘vontade’ do agente de software e do seu sujeito utilizador, v. infra §4.3 Qualificação jurídica dos agentes de software.

Figura 1 – Compra e venda numa plataforma blockchain


24 | 69

termos e condições da venda (assinando-o digitalmente com a sua chave privada e registando-o

no blockchain, ficando visível a todos os sujeitos utilizadores da plataforma) [1] e carrega o e-

book na plataforma, que passa a deter o endereço blockchain 3800K1, onde fica armazenado

[1.1]; Bruno [B], que pretende comprar o e-book 3800K1, subscreve o smart contract “SC231”

com a sua chave privada, transferindo 15 € do seu endereço blockchain (chave pública) 778956

para o endereço blockchain de André 614494 [2], ficando esta transferência registada no

blockchain [2.1] (operação input); posteriormente o agente verifica se André tem legitimidade

para vender o e-book e se Bruno detém crédito suficiente para efectuar a compra e se o

pagamento foi efectuado [3]. Sendo todas as condições favoráveis, [4], inicia-se a operação de

output, concedendo a Bruno um ponto de descarga do e-book 3800K1 e disponibilizando-se o

valor de 15 € na conta de André, transferidos da conta de Bruno [5]68.

Na Figura 2 é representado um exemplo de uma aposta inscrita num blockchain cujo

resultado depende de dados externos, sendo necessário recorrer a dados obtidos por um oráculo.

68 Cf. LUU et al. (2016), pp. 254-256.

Figura 2 – Inscrição de uma aposta em blockchain


25 | 69

Na Figura 2, Antero [A] e Bento [B] criam uma aposta sobre o estado meteorológico de

Coimbra no dia 1 de Abril de 2018: para A choveria nesse dia [1], para B estaria um dia radiante

de sol [2]. Esta aposta é inscrita num smart contract que é registado na plataforma blockchain [3].

A execução do código deste contrato consiste na monitorização, por parte do agente autónomo,

dos dados meteorológicos submetidos pelo oráculo de hardware inbound do Instituto Português

do Mar e da Atmosfera, que são contínua e autonomamente registados no blockchain [4].

Verificada a data e as condições meteorológicas no dia 1 de Abril de 2018 [5], o agente

autónomo atribui o prémio a A [5a] ou a B [5b], emitindo um documento electrónico com essa

informação.

Por fim, na Figura 3 é exibido um exemplo de uma plataforma de pesquisa e reserva de

alojamentos locais particulares, semelhante ao AirBnB69, operado com recurso a blockchain

69 Sobre o AirBnB, cf. AirBnB URL: <http://www.airbnb.pt>;

Figura 3 – Representação do ‘blockchain AirBnb’


26 | 69

(‘bAirBnB’)70, uma plataforma destinada ao apresentar uma listagem de imóveis disponíveis para

arrendamento a curto prazo. Neste exemplo, o oráculo corresponde a uma porta inteligente que

permite o acesso ao imóvel/divisão do imóvel quando se verifique que estão reunidas as

condições acordadas entre as partes.

Na Figura 3, Artur [A] e Benjamim [B] já se encontram inscritos na plataforma

‘bAirBnB’. A, interessado em ficar alojado no imóvel disponibilizado por B, procede ao

pagamento do depósito exigido, apresentando o documento comprovativo [1]. Perante a

proposta de A e pretendendo aceitá-la, B valida e autoriza a reserva do imóvel [2]. Estes actos

são todos inscritos num smart contract que por sua vez é registado no blockchain [3]. Verificando-

se todas as condições do contrato, a chave do imóvel é entregue a A, no formato de um código

QR [4a], sendo disponibilizado o valor pecuniário a B [4b]. Assim, quando A pretender entrar

no imóvel, deverá apresentar a ‘chave QR’ do imóvel no leitor óptico na fechadura da porta

inteligente para abri-la. Assim, se a porta inteligente (rectius o oráculo) verificar que ainda estão

reunidos os pressupostos que legitimam a entrada no imóvel, o trinco da porta é desbloqueado.

Sendo cogitável que as partes pudessem ter interesse em que os seus contratos

persistissem mesmo após a sua execução e, desejando inclusivamente que o agente de software

do contrato interagisse com outros agentes de software e/ou oráculos, pensou-se numa figura

associada aos contratos inteligentes: a ‘organização autónoma descentralizada’ (do inglês

decentralized autonomous organization). HEARN 71 idealizou um futuro onde veículos sem

condutor transportariam passageiros que pagariam a viagem electronicamente e, depois de deixar

o passageiro no seu destino, dirigir-se-iam a uma bomba de abastecimento para reabastecer,

utilizando o valor pecuniário guardado na sua carteira electrónica. Além disso, o veículo poderia,

por sua iniciativa, contratar um terceiro para efectuar algum tipo de reparação/manutenção,

pagando igualmente por via electrónica. No entender do autor, neste cenário, o veículo é dono

de si próprio, rectius, é efectivamente uma organização autónoma descentralizada. Deste cenário,

é inegável que, sendo realidade, aproximar-nos-íamos de organizações mais eficientes,

económicas e competitivas, quando comparadas às tradicionais empresas no mercado real.

70 Cf. TAPSCOTT ET AL. (2016), pp. 115-117. 71 Cf. HEARN (2013)


27 | 69

Contudo, ressalte-se que o cenário que se apresenta remete para o campo da inteligência artificial

e da condução autónoma que, não obstante uma realidade notavelmente actual e intensamente

debatida72, para o trabalho que desenvolvemos, não tem interesse.

72 Sobre os veículos autónomos, v., por exemplo nos meios de comunicação social, ANTÓNIO (2017), STRAIGHT (2018), HAWKINS (2017), KHARPAL (2017). Sobre o desenvolvimento da inteligência artificial, cf. AlphaGo URL, disponível em <https://deepmind.com/research/alphago/> (Obtido em 28 de Janeiro de 2018), e nos meios de comunicação social, designadamente, ALBERTSON (2018), SCMP (2018), HARWELL (2018), WEHNER (2017), BHATIA (2018).


28 | 69

4. Contratração electrónica

4.1. Abordagem ao tema e modalidades de contratação electrónica

Situando-nos presentemente na Era da Informação, assiste-se a uma crescente mitigação

de distâncias entre pessoas através da tecnologia; trata-se, pois, de um resultado dos avanços

tecnológicos provenientes da Terceira Revolução Industrial, mais concretamente da evolução e

expansão da Internet. A renomada network of networks, trazendo consigo uma nova forma de

comunicação mais eficiente, cómoda e económica, não passou despercebida aos prestadores de

bens e serviços e a potenciais consumidores, que rapidamente a adoptaram para fins comerciais73.

Foi precisamente a facilidade e rapidez de processamento e transmissão electrónicos de dados,

que permitiu a negociação executada por meios electrónicos e do aparecimento do comércio

electrónico74.

Diversas realidades foram antecipadas no Livro Verde para a Sociedade da Informação,

nomeadamente a realidade do comércio electrónico, prevendo o ponto §5.7 que «[a]

globalização dos mercados obriga as empresas a repensar e modificar os seus processos

empresariais por forma a adaptá-los à nova realidade envolvente. Neste contexto, o comércio

electrónico surge como uma ferramenta estratégica para esta redefinição dos processos de

negócio, muitas vezes catalisando essa globalização. As empresas que aderem a este conceito

pretendem tornar mais flexíveis e eficientes as suas actividades associadas à comercialização,

alargar a sua base de clientes, e melhorar a resposta às expectativas dos seus parceiros

comerciais»75. Estas afirmações não poderiam ser mais actuais, reportando para uma realidade

indubitavelmente palpável.

Entre nós, a contratação electrónica encontra-se regulada no DL n.º 7/2004, de 7 de

Janeiro (com as alterações dadas pelo DL n.º 62/2009, de 10 de Março, e pela Lei n.º 46/2012,

de 28 de Agosto), que procedeu à transposição da Directiva n.º 2000/31/CE, de 8 de Junho. O

preceituado deste Diploma pretende abranger «todo o tipo de contratos, sejam ou não

qualificáveis como comerciais», como se lê no Preâmbulo do mesmo, sendo subsidiariamente

73 Cf. SILVA (1999), p. 216, ASCENSÃO, in ANACOM (2004), p. 157. 74 O comércio electrónico pode ser definido como o conjunto de operações materiais e actos jurídicos concluídos ou praticados por via do processamento e transmissão electrónicos de dados. Sobre o conceito de contratação electrónica, cf., entre outros, VICENTE (2003), p. 241; PEREIRA (1999a), p. 14; TELLES (2002), pp. 151-153.; SILVA (2003), p. 290. 75 Livro Verde para a Sociedade da Informação em Portugal (1997), p. 47.


29 | 69

aplicável, nomeadamente, o disposto no DL n.º 24/2014, de 14 de Fevereiro, com as alterações

da Lei n.º 47/2014, de 28 de Julho76_77. É também aplicável o Regulamento (UE) n.º 910/2014,

de 23 de Julho, relativo à identificação electrónica e aos serviços de confiança para as transacções

electrónicas no mercado interno, que veio revogar a Directiva 1999/93/CE, e que tem em vista

o reforço da confiança nas transacções electrónicas, bem como a Recomendação da Comissão

94/820/CE, de 19 de Outubro, relativa aos aspectos jurídicos da transferência electrónica de

dados.

Como nota ASCENSÃO78, é na tendencial equiparação plena da contratação electrónica

(e contratação informática) à contratação comum que encontramos a nossa base jurídica

elementar. E dizemos tendencial devido à exclusão de determinados domínios, como se retira

do prescrito no art. 9.º, n.º 2, da DCE, no art. 3.º, n.º 3, da DCD, no art.º 2.º do DL n.º

7/2004, de 7 de Janeiro (com as alterações introduzidas pelo DL n.º 62/2009, de 10 de Março,

e pela Lei n.º 46/2012, de 28 de Agosto). O autor adianta ainda que o contrato electrónico se

trata de um contrato celebrado à distância por meios electrónicos, podendo este entendimento

ser retirado da nota (20) do preâmbulo da DCD. Assim, justifica-se a aplicação dos princípios

relativos à contratação à distância aos contratos electrónicos (e informáticos), salvo disposição

legal em contrário, implicando igualmente a vigência dos deveres de informação inerentes

àqueles na contratação electrónica (e informática).

Apresentado o tema da contratação informática, mas antes de passar ao cerne da nossa

investigação, cumpre-nos identificar as modalidades da contratação electrónica: dado que

estaremos perante a forma electrónica de contratação quando as declarações de vontade das

partes sejam transmitidas por meios electrónicos, é possível afirmar que o conceito de

contratação electrónica será mais amplo ou mais restrito conforme os meios tecnológicos

empregues durante os actos de processamento e transmissão daquelas79. Assim, por um lado,

quando para a conclusão do negócio jurídico seja exigível intervenção humana no momento da

76 Note-se que a Directiva sobre contratos à distância (Directiva 97/7/CE, do Parlamento Europeu e do Conselho, de 20 de Maio) foi transposta para a ordem jurídica interna através do DL n.º 143/2001, de 26 de Abril. Contudo, tendo aquela sido revogada pela Directiva relativa aos direitos dos consumidores (Directiva 2011/83/UE, do Parlamento Europeu e do Conselho, de 25 de Outubro), foi o nosso DL n.º 143, 2001, de 26 de Abril, revogado pelo DL n.º 24/2014, de 14 de Fevereiro, que transpõe a aludida Directiva relativa aos direitos dos consumidores. 77 Cf. Lei do Comércio Electrónico Anotada (2005), p. 94. 78 Cf. ASCENSÃO in ANACOM (2004), p. 104. 79 Cf. FESTAS (2006), nota (3), p. 412.


30 | 69

celebração do negócio jurídico, diremos que estamos perante contratação electrónica stricto

sensu: nesta modalidade os aparelhos electrónicos são utilizados única e exclusivamente como

meios de comunicação (v.g. contratação efetuada por correio electrónico); por outro, quando

aquela intervenção seja inexigível, visto que os contratos são celebrados e formados (unilateral

ou bilateralmente) por computador(es), já se denominará como contratação electrónica

automatizada80, ou somente contratação automatizada.

Como facilmente se depreende, cabe na contratação electrónica automatizada a

contratação com recurso à transferência electrónica de dados (TED, na sigla portuguesa, ou

electronic data interchange, EDI, na sigla inglesa), que já foi definida de diversas maneiras81. Das

diferentes definições, é possível destacar três elementos comuns que caracterizam a EDI: (i) o

formato electrónico estruturado e estandardizado, (ii) a capacidade de partilhar dados, de modo

legível, entre (pelo menos dois) computadores situados em locais diversos e (iii) a inexigibilidade

de intervenção humana para receber (e interpretar) e (inserir e) enviar os dados.

Apesar da conveniência, rapidamente se identificaram alguns contratempos na

contratação com recurso à EDI (que, por sua vez, dificultavam a sua adesão): além de um

avultado investimento na aquisição da tecnologia, associada à contratação automatizada com

recurso à EDI esteve sempre a exigência de celebração de complexos acordos prévios (onde são

estabelecidos diversos aspectos da contratação por forma a garantir o «ambiente operacional para

pôr em funcionamento o EDI»82). Perante isto, o desenvolvimento desta conheceu diversas

recomendações (nacionais, internacionais e institucionais) cujo seu desiderato era a simplificação

e estandardização das normas utilizadas nos sobreditos acordos-prévios, proporcionando uma

redução ou eliminação de obstáculos jurídicos e da ambiguidade no comércio electrónico, que

se traduziram em modelos de acordos de intercâmbio (do inglês interchange agreements)83 e que

80 No mesmo sentido, cf. FESTAS (2006) pp. 412-417; (2003), p. 290. Em sentido diverso, cf., nomeadamente, ASENSIO (2002, p. 332, apud FESTAS, 2006, nota (3), p. 413), que distingue a contratação automatizada (contratação electrónica em sentido estrito) da contratação por meios electrónicos. 81 O art. 2.2 da atEDI define a EDI como «[t]ransferência eletrónica, de computador para computador, de dados comerciais e administrativos utilizando uma norma acordada para estruturar uma mensagem EDI». Para mais interpretações, cf., entre outros, HILL et al. (1989), p. 6; O’CALLAGHAN et al. (1992), p. 46; UPTON et al. (1996), p. 125; WALTON et al. (1997), p. 31; FISCHER (1997), pp. 547-550; FINNEGAN et al. (1998), p. 28; ANDERSON et al. (2002), p. 704; FESTAS (2006), nota (9), p. 414; ASHER (2007), p. 375. 82 Cf. art. 9.1 da atEDI. 83 Relativamente aos modelos de acordo de intercâmbio, destacamos o Modelo Europeu de Acordo de EDI (atEDI), as Uniform Rules of Conduct for Interchange Trade of Data by Teletransmission (UNCID) da Câmara de Comércio Internacional, o Model Trading Partner Agreement da American Bar Association, o EDI-Modellvertrag (que resultou do projecto de investigação ELTRADO – Elektronische Transaktion von Dokumenten zwischen Organisationen) e a


31 | 69

deveriam ser adoptados pelas partes. Como nota FESTAS 84 , a adopção da contratação

automatizada com recurso à EDI foi especialmente relevante em determinadas indústrias,

nomeadamente na indústria automóvel, na actividade bancária e seguradora, na negociação em

bolsa85 e no sector da distribuição.

Todavia, a evolução da contratação electrónica automatizada conta hoje, não apenas com

com a contratação com recurso à EDI, mas também com a contratação com recurso a agentes

electrónicos. Com efeito, em 2005, na Convenção das Nações Unidas sobre o Uso de

Comunicações Electrónicas em Contratos Internacionais86_87, consagrou-se a possibilidade de

contratar com recurso a sistemas automatizados de mensagens (do inglês automated message

systems), também conhecidos como «agentes electrónicos»88. Ou seja, através de um programa

de computador (ou outro meio automatizado electrónico) utilizado para iniciar uma acção ou

responder a operações ou mensagens de dados, e que dispensa, total ou parcialmente, a

intervenção de uma pessoa humana de cada vez que se inicia uma acção e/ou quando seja gerada

uma resposta pelo sistema, como é definido na Convenção89. Na verdade, e como denota

FESTAS90, os agentes electrónicos, dotados de uma versatilidade que lhes permite executar

diversas funções, tratam-se de um instrumento relevantíssimo para o comércio, podendo adoptar

diferentes nomenclaturas conforme a sua função. Dito de outra forma, serão agentes electrónicos

os search agentes, os filtering agentes, os shopping agentes e os broker agentes, já que a sua função é

pesquisar, filtrar, adquirir e negociar, respectivamente, sendo possível identificar muitos outros

Lei-Modelo da Comissão das Nações Unidas para o Direito da Comércio Internacional sobre o Comércio Electrónico, de 1996. 84 Cf. FESTAS (2006), nota (9), p. 415. 85 Cf. WONG, D. D., (1999), p. 90. 86 A Convenção das Nações Unidas sobre o Uso de Comunicações Electrónicas em Contratos Internacionais, adoptada pela Assembleia Geral das Nações Unidas em Nova Iorque a 23 de Novembro de 2005 através da Resolução 60/21, teve em vista, sem se imiscuir na legislação de cada Estado relativo ao regime substantivo dos contratos (cf. arts. 7.º e 13.º da Convenção), a fixação de um regime legal aplicável à contratação internacional efectuada por meios electrónicos. Nos termos do art.º 4 daquela, diz-se comunicação electrónica aquela que se processa por meio de transmissão de mensagens de dados por meios electrónicos, ópticos, magnéticos, ou equivalente, incluindo-se aqui também a correspondência electrónica de dados, o correio electrónico, o telegrama, o telex ou a telecópia. Entre nós, encontramos na Lei n.º 5/2004, de 10 de Fevereiro, recentemente alterada pelo DL n.º 92/2017, de 31 de Julho, a definição de “rede de comunicações electrónicas” no art. 3º, al. dd). 87 A seguir designado somente “Convenção” 88 Cf. Notas explicativas da Convenção das Nações Unidas sobre o Uso de Comunicações Electrónicas em Contratos Internacionais, p. 69, §208. 89 Cf. art. 4.º, al. g), da Convenção. 90 Cf. FESTAS (2006), nota (9), p. 415.


32 | 69

agentes com funções distintas. Por conseguinte, cremos que a definição de agentes electrónicos

adiantada pela Convenção se identifica com a supracitada noção de agentes de software91.

4.2 Caracterização dos agentes de software

Tendo-se verificado que o agente de software é, a bem dizer, um agente electrónico, é

necessário esclarecer que a actividade dos agentes de que temos falado se traduz na celebração de

contratos (tipicamente ‘em nome’ de uma pessoa singular ou colectiva) de modo autónomo e

sem intervenção humana, mas agora recorrendo ao uso extensivo de operações criptográficas92

para conferir maior segurança e confiança, deixando de operar em rede aberta (rectius na World

Wide Web), como se verificava no caso de agentes como o Kasbah93, o Tête-à-Tête (T@T)94, ou

o AuctionBot95.

Não obstante, uns e outros partilham determinadas características que os distinguem dos

comuns programas de computador que tão bem conhecemos96 , e das quais destacamos as

capacidades (i) de actuação autónoma e de autonomia decisória (autonomy)97, (ii) comunicativa

(social ability), (iii) de reacção a estímulos (reactivity)98, (iv) de proactividade (pro-activeness) e (v)

de execução continuada. Note-se que JANCA & GILBERT 99 enunciam um conjunto de

características que são, à primeira vista, distintas daquelas que acabámos de apresentar; no

entanto, entende-se que estas se subsumem naquelas, já que o agente de software, munido

daquelas cinco capacidades, é capaz de encontrar a solução mais adequada para cumprir o fim

91 V. supra §3.2 – Noção e tipos de agentes de software. 92 V. supra §1. – A criptografia e as distributed ledger Technologies e §2. – A assinatura electrónica. 93 Sobre o agente Kasbah, cf., designadamente, Kasbah URL: <https://kasbah.media.mit.edu>; MAES et al. (1999), p. 1 e 8-10; KERR (2001), p. 185; MOUKAS et al. (2000), p. 3; GUTTMAN et al. (1998), pp. 149-151. 94 Sobre o agente Tête-à-Tête (T@T), cf., entre outros, T@T URL: <http://ecommerce.media.mit.edu/tete-a-tete/>; MAES et al. (1999), pp. 1 e 10; KERR (2001), pp. 185-186; GUTTMAN et al. (1998), pp. 151. 95 Sobre o agente AuctionBot, cf., nomeadamente, AuctionBot URL: <http://auction.eecs.umich.edu/>; MAES et al. (1999), pp. 1 e 8; GUTTMAN et al. (1998), pp. 150, WURMAN et al. (1998), pp. 301-308. 96 Sobre as características dos agentes electrónicos/agentes de software, cf., entre outros, FESTAS (2006), nota (9), p. 415; JANCA et al. (2012), p. 75; Nwana (1996), pp. 211-212; BELLIA JR. (2001), nota (19), p. 1051; FRANKLIN et al. (1996), pp. 21-27; WOOLDRIGE et al. (1995), pp. 116-117; ETZIONI et al. (1994), p. 10; FISCHER (1997), p. 558; KERR (1999), §I. The technological promise of autonomous electronic devices; COELHO (2017). 97 A autonomia do softbot pode ser definida como «capacidade de tomar decisões e de as aplicar no mundo exterior, independentemente do controlo ou da influência externa» (cf. Resolução do Parlamento Europeu de 16 de Fevereiro de 2017, §AA), podendo o grau desta capacidade depender do «nível de sofisticação da interação de um robô com o seu ambiente» (cf. Resolução do Parlamento Europeu de 16 de Fevereiro de 2017, §AA). 98 Por capacidade de reacção a estímulos quer-se dizer a habilidade de recolher e interpretar diversas informações quer do mundo físico (v.g. via oráculos), quer do mundo digital, por forma a adequar/modificar, se necessário, a ‘sua’ decisão. 99 Cf. JANCA et al. (2012), p. 75.


33 | 69

para o qual foi programado, em nome do seu sujeito utilizador, da forma mais eficiente possível.

Com efeito, além de não nos podermos esquecer que o nosso agente é um programa de

computador dotado de características específicas, é fundamental compreender que a sua

interacção é personalizável. Por outras palavras: sabendo que o agente de software é um programa

de computador destinado a actuar ‘em nome’ do seu sujeito utilizador autonomamente, o

utilizador pode decidir o seu grau de autonomia e se será ou não, por exemplo, dotado de

capacidades de observação de padrões de comportamento e de auto-aprendizagem (e, se for o

caso, em que medida) para melhor se adaptar a situações futuras iguais ou semelhantes e, dessa

maneira, optar, por uma decisão melhor (ou mais adequada).

É indiscutível que o código do agente de software é concebido por engenheiros humanos

e instalado em determinado sistema por um programador humano; porém a autonomia

característica destes programas de computador verifica-se na medida em que a sua actividade

não resulta de uma instrução precisa e inequívoca humana (v.g. comprar a caneta ∂, ao vendedor

W que custa €3, na Plataforma AlphaBuy); aliás, resulta antes de uma instrução incompleta, mas

adequada, dada por um humano para ser completada pelo agente100 (v.g. comprar a caneta ∂, ao

melhor preço101). Perante uma instrução deste tipo, caberá ao agente preparar, negociar e celebrar

o contrato autonomamente, a partir da sua capacidade de análise de dados e autonomia decisória.

Não espanta por isto que se equipare estes agentes a robôs de software (ou, na expressão abreviada

anglo-saxónica, softbots). Posto isto, diremos que os interlocutores neste modo de contratação

são, precisamente, os aludidos softbots.

Pelo exposto depreende-se que, das características que já avançamos dos softbots, devemos

dar especial ênfase à sua capacidade de autonomia decisória, na medida em que é esta habilidade

que confere ao softbot a faculdade de tomar decisões, segundo as instruções do seu sujeito

utilizador, em função das informações que vai captando do mundo físico e/ou digital e em nome

do seu sujeito utilizador, podendo esta sua autonomia decisória ser personalizada. Desta maneira,

no entender de COELHO102, aos agentes de software não compete somente a mera emissão de

declarações contratuais; estes serão também portadores de uma « ‘vontade’ negocial», ainda que

100 Cf. WELLMAN et al. (2007), p. 3; FESTAS (2006), pp. 422-425. 101 O ‘melhor preço’, como se compreende, será um conceito indeterminado que o agente de software deverá interpretar, atendendo à instrução que lhe é dada e às informações (do mundo físico e/ou do mundo digital) de que dispõe. 102 Cf. COELHO (2017).


34 | 69

em formato electrónico103. De facto, o agente de software prepara, negoceia e celebra contratos,

mas executa estas funções ‘em nome’ (lato sensu) do seu sujeito utilizador (que será sempre uma

pessoa singular ou colectiva titular de uma esfera jurídica, de direitos e obrigações, e de um

património responsável).

4.3 Qualificação jurídica dos agentes de software

Já se avançou que a EDI permite que programas de computador desencadeiem ordens

de encomenda para outros computadores, que por sua vez dão instruções para a execução

correspondente, emitindo avisos de recepção no processo, de modo automático e sem

intervenção humana104. Sendo assim, e considerando que a contratação com recurso a softbots é

uma forma de contratação electrónica automatizada, seria a atEDI igualmente aplicável? Cremos

ser razoável responder pela negativa, devido às diferenças entre a contratação com recurso à EDI

e a contratação com recurso a softbots. Uma das principais características da EDI europeia é o da

estandardização da estrutura de comunicação a ser mantida entre as partes, permitindo um

ambiente operacional estável e sem ambiguidades por via de um acordo prévio entre as partes,

reduzido a escrito (cf. arts. 1.º, 2.º e 9.º atEDI). Do sobredito, evidenciam-se desde logo três

diferenças:

(i) Enquanto que na contratação com recurso à EDI as partes conhecem-se antes de

iniciarem trocas comerciais, na contratação com recurso a softbots, as partes não têm

necessariamente de se conhecer previamente;

(ii) Na contratação com recurso à EDI as partes estabelecem entre si um acordo-tipo que

definirá o modo como deverão comunicar e contratar, convenção esta que inexiste na

contratação com recurso a softbots;

(iii) Por fim, tipicamente são grandes empresas que dão uso à contratação com recurso à

EDI para comprar ou vender bens ao(s) mesmo(s) sujeito(s); na contratação com

recurso a softbots os sujeitos intervenientes poderão ser ambos consumidores105.

Não obstante, ainda que o tipo de contratação electrónica automatizada de que tratamos

(rectius criptocontratação) convoque a participação de softbots e o recurso à criptografia para

103 Neste sentido, cf., entre outros, FESTAS (2006), p. 418; MONTEIRO (1999), pp. 232-233; SILVA (2003). 104 Cf. ASCENSÃO (2003a), pp. 63-65, PEREIRA (1999a), pp. 30-32, PEREIRA (1999b), pp. 970-973. 105 Neste sentido, cf., entre outros, KIS (2004), pp. 15-16; FESTAS (2006), nota (9), p. 416.


35 | 69

concluir negócios jurídicos sem intervenção (directa) humana 106 , não pode um contrato

celebrado por esta via, no nosso ponto de vista, ver os seus efeitos legais negados pelo recurso a

este meio. Efectivamente, prescreve o art.º 24.º da LCE que as disposições do capítulo relativo

à contratação electrónica se aplicam «a todo o tipo de contratos celebrados por via electrónica

ou informática». Contudo, o legislador impôs uma condição subjectiva para os arts. 27.º a 29.º

e 34.º, na medida em que se pressupõe que uma das partes seja um prestador de serviços da

sociedade da informação107. Ao que tudo indica, prima facie, os restantes preceitos legais serão

aplicáveis a esta forma de contratação.

A análise dos arts. 8.º, 9.º e 12.º da Convenção, bem como dos seus Considerandos,

permite-nos depreender que se consagram dois princípios: o princípio da igualdade jurídica dos

meios de comunicação e da proibição de discriminação das comunicações por meios electrónicos

e o princípio da liberdade de forma.108. Atendendo o disposto no art. 25.º, n.º 1, da LCE e no

art.º 9, n.º 1, da DCE (ambos relativos à contratação electrónica) e nos arts. 25.º, n.º 1, 35.º,

n.º 1, 41.º, n.º 1, 43.º, n.º 1, e 46.º, todos do Regulamento UE 910/2014, de 23 de Julho

(referentes às assinaturas electrónicas, aos selos electrónicos, aos selos temporais electrónicos, ao

serviço de envio registado electrónico e aos documentos electrónicos, respectivamente), diremos

que também no ordenamento jurídico português se faz alusão a uma proibição de discriminação

das comunicações por meios electrónicos, em prol de uma igualdade jurídica dos meios de

comunicação e liberdade de forma. Nesta senda, figura-se a consagração do princípio da

liberdade de celebração de contratos por via electrónica no art. 25.º, n.º 1, da LCE e no art. 9.º,

n.º 1, da DCE109. CORREIA110 vai mais longe ao entender estar consagrado um princípio mais

amplo: o chamado «princípio da admissibilidade e equiparação dos contratos electrónicos aos

contratos não electrónicos». Este mobiliza, por sua vez, a aplicação do princípio da liberdade

contratual e do princípio da liberdade de forma, previstos nos arts. 405.º e 219.º do Código

Civil, respectivamente, posição que será por nós adoptada.

106 V. supra § 1. A criptografia e as distributed ledger technologies e §2. A assinatura electrónica. 107 Cf. Lei do Comércio Electrónico Anotada (2005), pp. 94-95. 108 Neste sentido, PEREIRA, D. A. (2013), pp. 8-9. 109 Sobre o princípio da admissibilidade, cf., designadamente, ASCENSÃO (2003a), p. 241; Lei do Comércio Electrónico Anotada (2005), p. 96-98. 110 Cf. CORREIA (2013), p. 4.


36 | 69

Pelo exposto, é natural que se conclua pela tendencial 111 validade destes contratos,

atendendo, não apenas ao prescrito no art. 12.º da Convenção (que trata sobre os contratos

unilateral ou bilateralmente celebrados por meios automatizados), mas também pela remissão

explícita para o “regime comum” prevista no art. 33.º, n.º 1, da LCE, sendo por essa razão

aplicável à contratação sem intervenção humana as normas do Código Civil previstas nos arts.

217.º e seguintes e outras normas que regulem a contratação através de meios electrónicos112.

Antes de prosseguirmos, servem algumas notas sobre o aludido art. 33º da LCE: tendo

a LCE sido destinada fundamentalmente a realizar a transposição da DCE, a norma em apreço

constitui uma inovação do legislador português em relação àquela, ao regular a contratação sem

intervenção humana, problemática não regulada pela Directiva113. Porém, considerando que

interpretar a lei constitui uma tarefa que tem como fim a descoberta do seu preciso e concreto

sentido, e que se inicia a partir do seu elemento literal para se avaliar a mens legislatoris, devendo

ser presumido que o «legislador consagrou as soluções mais acertadas e soube exprimir o seu

pensamento em termos adequados»114, cremos que o legislador foi infeliz ao incluir na redacção

a parte final desta norma («salvo quando este pressupuser uma actuação»). Na verdade, o

legislador quis dizer que à contratação celebrada exclusivamente por meios de computadores,

sem intervenção humana, será aplicável o regime geral composto pelas normas do Código Civil

(arts. 217.º e seguintes) e por outras normas relativas à contratação através de meios electrónicos,

e, nos casos em que para a conclusão de determinado contrato electrónico seja exigível

intervenção humana, aplicar-se-á regime diverso115, sem indicar, todavia, qual o regime então

aplicável. Ora, não parece congruente que não seja aplicável o regime geral à contratação

111 Cumpre-nos esclarecer que nem todos os contratos gozam desta protecção, ao terem sido expressamente excluídos pelo legislador (i) os negócios jurídicos familiares e sucessórios, (ii) os negócios jurídicos que exijam por lei a intervenção de tribunais, entidades públicas ou profissões que exercem poderes públicos, (iii) os negócios jurídicos de caução e garantias prestadas por pessoas agindo para fins exteriores à sua actividade comercial, empresarial ou profissional e (iv) os negócios jurídicos que criem ou transfiram direitos sobre bens imóveis, com excepção de de direitos de arrendamento (cf. art. 25.º, n.º 2, da LCE, e art. 9.º, n.º 2, da DCE), sendo certo que estão fora do âmbito de aplicação da LCE (e da DCE) a matéria fiscal, a disciplina da concorrência, o regime do tratamento de dados pessoais e da protecção da privacidade, o patrocínio judiciário, os jogos de fortuna e azar em que é feita aposta em dinheiro, a actividade notarial ou equiparadas, nos termos do art. 2.º da LCE (e no art. 1.º, n.º 5, da DCE). 112 Cf. Lei do Comércio Electrónico Anotada (2005), pp. 130-131. 113 Cf. PEREIRA (2004), §3.6 e ASCENSÃO (2003a), pp. 246-247. 114 Cf. Artigo 9.º, n.º 3, do Código Civil Português. 115 Cf. Lei do Comércio Electrónico Anotada (2005), pp. 130-131.


37 | 69

electrónica com intervenção humana, por força do princípio da especialidade, previsto no art.º

7.º, n.º 3, do Código Civil. Aliás, por maioria de razão, apenas fará sentido que o regime geral

seja aplicável a toda a contratação electrónica, salvo quando exista lei especial que derrogue a lei

geral.

Pelo exposto, tendo sido vontade do legislador apenas estender a aplicação do regime

geral à contratação electrónica sem intervenção humana116, a última parte da norma podia ser

dispensada sem se perder o seu sentido117. Recorrendo às palavras de PINTO MONTEIRO, «deve

o intérprete presumir que o legislador foi um ás, ainda que, porventura, na realidade, pudesse

ter sido um asno!»118.

Retomando o nosso percurso e julgando pela validade dos supramencionados contratos,

estamos em condições de avançar para uma tentativa de enquadramento jurídico dos agentes de

software. Anuindo com COELHO 119 e FESTAS 120 , identificamos três enquadramentos

potencialmente viáveis: (1) o softbot enquanto simples instrumento de transmissão da declaração,

(2) o softbot enquanto núncio e (3) o softbot enquanto representante. Vejamos:

(1) O softbot enquanto simples instrumento de transmissão de declaração121

Considerando o que já foi explicitado sobre o funcionamento dos softbots, torna-se

evidente a inaplicabilidade deste enquadramento, atenta capacidade de autonomia decisória

do softbot. É claro que o agente executa a sua programação de maneira a atingir o fim a que

foi destinado; porém, todo o processo de contratar (preparar, negociar e contratar) cabe

exclusivamente àquele. Assim, de uma instrução incompleta, mas adequada, nasce um

contrato que talvez não tivesse sido sequer cogitado pelo sujeito utilizador. É esta distância

que se verifica entre as instruções do sujeito utilizador e do contrato-resultado que nos

permite dizer que o softbot não é um simples instrumento.

116 Cf. ASCENSÃO, in ANACOM (2004), pp. 113-114; COELHO (2017). 117 No mesmo sentido, cf. MARTINS et al. (2012), p. 193. 118 Cf. MONTEIRO (2017), p. 9. 119 Cf. COELHO (2017). 120 Cf. FESTAS (2006), pp. 419-425. 121 Cf. COELHO (2017).


38 | 69

(2) O softbot enquanto núncio122

Como é do conhecimento geral, o núncio figura somente como um longamanus,

limitando-se a transmitir apenas a declaração de outrem123 ; como se acabou de ver, a

instrução incompleta, mas adequada, do sujeito utilizador, não se identifica com o contrato

celebrado pelo softbot, pelo que também este enquadramento não nos parece configurável.

(3) O softbot enquanto enquanto representante124

Prevista no art. 258.º do Código Civil, a representação consiste na prática de certo acto

jurídico em nome de outrem, tendo em vista a produção dos respectivos efeitos jurídicos na

esfera dessa outra pessoa125. Este acto é eficaz, mesmo que não seja concluído no interesse do

representado, mas desde que o representante não exceda os «limites dos poderes que lhe

competem» (art. 258.º do Código Civil). Ora, na contratação electrónica com recurso a

softbots, como já se disse, o sujeito utilizador dirige ao softbot uma instrução incompleta, mas

adequada, sendo função do softbot interpretar a ‘vontade’ daquele, para melhor cumprir

autonomamente a sua finalidade, adaptando e modificando a sua actuação em conformidade

com as eventuais informações que for recebendo/captando do mundo físico e/ou digital.

Como se demonstrou, o agente não se limita a transmistir a declaração negocial do seu

sujeito utilizador; efectivamnete, o agente é portador de uma espécie de ‘vontade’ que é, de

algum modo, sua, possibilitando-lhe a faculdade de produzir e emitir uma declaração

negocial. Desta forma, torna-se possível um contrato: de um lado temos o softbot responsável

pela compra da caneta ∂, ao melhor preço126 e, do outro, teremos um segundo softbot, este

responsável pela venda de canetas ∂, da melhor qualidade, ao preço mais baixo, na

plataforma TauBuy. Em suma, parece-nos que a representação configura o melhor

enquadramento para as competências do agente de software127.

122 Cf. COELHO (2017). 123 Cf. PINTO (2005), pp. 543-544. 124 Cf. COELHO (2017). 125 Cf. PINTO (2005), pp. 539-547. 126 Recorde-se o exemplo apresentado supra §4.2 Caracterização dos agentes de software. 127 No mesmo sentido, cf. FESTAS (2006), pp. 419-425; COELHO (2017).


39 | 69

Ainda que se aceite este terceiro enquadramento como possível e justificável, duas

questões ficam ainda por resolver128:

(1) Visto que o agente de software não tem, à partida, personalidade jurídica, será aquele

enquadramento compatível?

(2) Considerando que o agente não se figuraria nem como o nosso típico representante nem

seria emissor de declarações negociais iguais às emitidas por um humano, em que medida

seriam os respectivos regimes aplicáveis?

Debruçando-nos sobre a primeira questão colocada, prima facie, parece que o

enquadramento que fizemos seria incompatível, já que o agente de software seria um

representante sem personalidade jurídica. Porém, entendemos não ser completamente

inconcebível129, por estar previsto no art. 263.º do Código Civil que «[o] procurador não

necessita de ter mais do que a capacidade de entender e querer», e já demonstrámos que o nosso

agente de software detém esta competência.

Adicionalmente, ainda que o legislador não tenha expressamente exigido que o representante

fosse uma entidade portadora de personalidade jurídica (rectius um humano), no limite parece

pressupor tal exigência, em virtude do facto do ser humano ser (ter sido) o único dotado daquelas

capacidades – que por sua vez lhe permitiriam agir em nome de outrem. Mas também já vimos

que o agente de software é dotado de capacidades de cognição e volição, pelo que nada parece

obstar a uma interpretação actualista desta exigência aparentemente implícita. Diremos que não

parecer obstar, pois o nosso ordenamento jurídico já atribui personalidade jurídica às pessoas

colectivas (que se trata de «um processo técnico de organização das relações jurídicas

conexionadas com um dado empreendimento colectivo»130), que podem ser constituídas por um

conjunto de pessoas ou por uma massa de bens, não existindo necessariamente uma

personalidade humana e não lhes sendo negado o direito de representar outrem131.

Além disso, ainda que não seja admissível tal interpretação à luz do direito constituído, uma

alteração legislativa poderia facilmente resolver a incompatibilidade, passando a reconhecer uma

capacidade de agir limitada às capacidades de actuação do software, que não assentasse numa

128 As mesmas questões são colocadas por COELHO (2017). 129 No mesmo sentido, cf. COELHO (2017). 130 Cf. PINTO (2005), pp. 193-94 e 269. 131 Neste sentido, cf., nomeadamente, CUNHA (1985), pp. 5-11; SANTOS (2014), pp. 78-80.


40 | 69

personalidade jurídica. Esta opção não seria novidade no direito comparado132, atenta a proposta

de revisão do Uniform Commercial Code da National Conference of Commissioners on Uniform

State Laws e da American Law Institute em 1996133.

Sendo assim, respondendo à primeira questão que colocámos, entendemos ser tal

enquadramento compatível, ainda que ao agente de software não seja atribuída personalidade

jurídica, posto que é o próprio legislador que é omisso quanto à (in)exibilidade desta, sendo

bastante as capacidades de compreender, querer e agir.

Relativamente à segunda questão colocada, importa desde já clarificar que, sendo o

recurso ao regime da representação justificado e possível, este será, em princípio, também

necessário134, na medida em que o agente de software não é apenas um instrumento do seu sujeito

utilizador, mesmo que não dotado de personalidade jurídica. Desta maneira, a representação

parece ser o instituto ideal para acautelar os interesses das partes: por um lado, a possibilidade

do sujeito utilizador se poder escudar das decisões que sejam contrárias às instruções originais

assumidas pelo seu agente de software; e, por outro, da contraparte, que confiou no contrato que

celebrou com o softbot.

Assim, para que se possa acautelar os interesses da contraparte, os contratos celebrados

pelo agente de software terão de ser, em regra, válidos. Ora, porque nem sempre é possível prever

as decisões que o agente de software tomará para completar a instrução incompleta, mas

adequada, que lhe é dada, não poderia ser exigido do sujeito utilizador a manifestação antecipada

da sua efectiva vontade de celebrar determinado negócio jurídico futuro cujo conteúdo ainda é

desconhecido, sob pena de se constituir um vício de falta de consciência da declaração135_136.

132 Cf. DODD et al. (1998), p. 4; FISCHER (1997), pp. 556-564. 133 Esta proposta de revisão procurava modernizar o Artigo 2.º, relativo à venda de bens, introduzindo o conceito de electronic agency. Porém, dada a falta de adopção pelos diversos Estados, aquelas instituições abandonaram a proposta, não tendo sido aprovada a revisão. Sobre esta revisão, cf. Uniform Commercial Code Article 2B: Licences (DRAFT), de 25 de Julho - 1 de Agosto de 1997 <http://www.uniformlaws.org/shared/docs/computer_information_transactions/2b/ucc2bam97.pdf> (Obtido em: 27 de Janeiro de 2018); BLUM et al. (2017), §3. Revisions of the UCC; FISCHER (1997), pp. 556-564. 134 Cf. COELHO (2017). 135 Cf. Art. 246.º do Código Civil. 136 Aliás, ainda que se exigisse a referida manifestação antecipada, entendemos que seria fundamental que o sujeito utilizador confirmasse o negócio jurídico celebrado pelo seu agente de software, sanando o aludido vício (v. art. 288.º do Código Civil), para que se pudessem produzir os respectivos efeitos jurídicos na sua esfera jurídica; porém, concordando com COELHO (2017), também não nos parece que seja esta opção eficiente, ao contrariar o sentido da contratação automatizada.


41 | 69

Como tal, é o instituto da representação que permite a produção dos efeitos negócio jurídico

celebrado pelo representante (o agente de software) em nome do representado (o sujeito

utilizador)137 na esfera jurídica deste, porquanto a actuação representativa, além de significar que

o representante actua juridicamente em nome do representado e que não é autor do acto,

também significa que aquele não pretende que os efeitos do referido negócio se façam sentir na

sua esfera jurídica138.

Ademais, é também o regime da representação que permite ao representado desvincular-

se de determinado negócio que tenha sido celebrado pelo representante quando este viole as

instruções que lhe foram inicialmente dadas, agindo como um «representante sem poderes ou

‘falsus procurator’» 139 . Faculdade esta que não seria tão fácil de aceder se aceitássemos os

enquadramentos do agente de software enquanto instrumento ou do agente de software como

núncio, ao exigir-se a verificação do erro na transmissão da declaração do representado ou da

relevância do seu erro mecânico140.

Concordámos com COELHO141 quando indicámos que o enquadramento do agente de

software enquanto representante seria possível, justificado e, em princípio, necessário. Todavia,

algumas notas devem ser tidas em conta antes de considerarmos que o enquadramento é

efectivamente necessário, sob pena de irreflectidamente pressupormos que todo o regime

jurídico (ou grande parte deste) seria analogicamente aplicável aos agentes de software. Questão

que iremos ver já de seguida.

4.4 O (eventual) regime jurídico dos agentes de software

Se, por um lado, encontramos a posição de COELHO142, que defende que a caracterização

dos agentes de software poderia ser compatibilizada (mediante certas adaptações) com o instituto

da representação, por outro encontramos a Resolução do Parlamento Europeu de 16 de

137 Dispõe o art. 258.º do Código Civil que «[o] negócio jurídico realizado pelo representante em nome do representado, nos limites dos poderes que lhe competem, produz os seus efeitos na esfera jurídica deste último». 138 Cf. PRATA (2017), pp. 311-312 (v. §7). 139 Cf. PINTO (2005), p. 549. 140 Cf. COELHO (2017). 141 Cf. COELHO (2017). 142 Cf. COELHO (2017).


42 | 69

Fevereiro de 2017143 (que contém recomendações à Comissão sobre disposições de Direito Civil

sobre Robótica), em que se invoca a necessidade da criação de um regime próprio para estes144_145.

De facto, a adopção de um regime próprio seria deveras vantajosa, ao permitir, em

princípio, a previsão de diversas soluções que, com grande certeza, não iremos encontrar se nos

limitarmos a uma aplicação analógica do aludido regime comum. Porém, também não nos

parece irrazoável optar por uma alteração legislativa, de maneira a contemplar determinadas

soluções que as normas tradicionais não prevêem.

De uma maneira ou de outra, a verdade é que o nosso legislador já em 2004 previu, na

LCE, a contratação sem intervenção humana146, à qual remete a aplicação do regime geral147.

Tendo em conta tudo o que foi aqui mencionado anteriormente, não choca que concordemos

novamente com COELHO148, ao afirmarmos que, caso se legisle ex novo, esse regime muito

provavelmente se aproximará do regime geral da representação e da declaração negocial. Por

conseguinte, importa desde logo tratar de três questões: a ‘procuração’ do agente de software, a

forma e o momento da celebração do contrato e o ‘erro’ do agente de software. Vejamos:

4.4.1 A ‘procuração’ do agente de software

A procuração, que se trata do acto (unilateral ou bilateral) pelo qual certa pessoa atribui

poderes representativos a outrem (cf. art. 262.º do Código Civil)149. No caso do agente de

software, verifica-se de imediato a desnecessidade de consentimento da sua parte, pelo que tratar-

se-ia de um acto unilateral; no entanto, este acto teria de ser traduzido nalgum comportamento

que compreendesse a concessão voluntária de poderes representativos, mesmo que este fosse

apenas tacitamente compreendido como tal (v.g. o acto de programar o agente de software).

143 Doravante somente Resolução. Disponível em <http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+TA+P8-TA-2017-0051+0+DOC+PDF+V0//PT> (obtido em 28 de Janeiro de 2018). 144 Lê-se naquele Considerando que «as máquinas concebidas para escolher as suas contrapartes, para negociar as condições contratuais, para celebrar contratos e para decidir se e como os aplicam, invalidam a aplicação das normas tradicionais; considerando que isto sublinha a necessidade de novas normas, eficientes e mais atualizadas». 145 Acrescente-se que, além do Parlamento Europeu, também outras entidades adoptaram esta opinião – v., por exemplo, o discurso de THOMAS (2017, §39), juiz Britâncio e ex-Lord Chief Justice of England and Wales, que frisa a importância de uma actualização legislativa – ou, tendo ido mais longe, propondo uma alteração, como é o caso do Estado de Florida dos EUA, com a sua House Bill 1357, nas suas linhas 48 a 54, proposta a 26 de Janeiro de 2018, estando disponível online em: <https://legiscan.com/FL/text/H1357/id/1676376/Florida-2018-H1357-Introduced.pdf> (Obtido em 28 de Janeiro de 2017). 146 Cf. art. 33.º da LCE. 147 V. supra §4.3 A qualificação jurídica dos agentes de software. 148 Cf. COELHO (2017). 149 Cf., entre outros, PINTO (2005), pp. 541-542; FERNANDES (2001), p. 208; PRATA (2017), pp. 318 e seguintes.


43 | 69

4.4.2 A forma e o momento de celebração do contrato

Como se sabe, vigora no ordenamento jurídico português o princípio da autonomia

privada, que consiste no reconhecimento do poder de autorregulamento dos interesses dos

particulares e de autogoverno da sua esfera jurídica (cf. art. 405.º do Código Civil), sendo a

liberdade contratual e a liberdade de forma, (cf. art. 219.º do Código Civil) as suas mais notórias

manifestações.

Remetendo para o que já foi referido quanto ao princípio da admissibilidade e

equiparação dos contratos electrónicos aos contratos não electrónicos150, importa recordar que a

contratação electrónica pode ser equiparada à contratação ‘tradicional’ na medida em que recorre

ao uso de software/hardware para produzir a declaração negocial, a meios de transporte de dados

para transmitir a referida declaração e à assinatura electrónica qualificada ou digital para que

passem a funcionar as presunções de autoria, vontade e inalterabilidade, previstas nas als. a) a c)

do n.º 1 do art. 7.º do RJDEAD151.

No entender de COSTA152, encontramos dois casos de sobreposição de normas: no

primeiro caso, encontramos as normas do RJDEAD (cf. arts. 1º, n.º 1, e 3.º, n.º 1) que vêm

dizer que aquele diploma regula a validade, eficácia e valor probatório dos documentos

electrónicos e que os documentos electrónicos satisfazem o requisito legal de forma escrita,

quando o seu conteúdo seja susceptível de representação como declaração escrita, que contrasta

com o disposto na LCE (art. 25.º, n.º 1), onde é consagrado o aludido princípio da

admissibilidade e equiparação dos contratos electrónicos aos contratos não electrónicos. No

segundo, deparamo-nos com o texto do art. 3.º, n.º 1, do RJDEAD (que prevê a satisfação do

requisito legal de forma escrita dos documentos electrónicos quando o seu conteúdo seja

susceptível de representação como declaração escrita, como se acabou de ver), que parece

confrontar o prescrito no art. 26.º, n.º 1, da LCE (que estatui que as declarações emitidas por

via electrónica satisfazem o requisito legal de forma escrita quando contidas em suporte que

ofereça as mesmas garantias de fidedignidade, inteligibilidade e conservação).

150 V. supra §4.3 Qualificação jurídica dos agentes de software. 151 V. supra §2.3 O papel da criptografia e do time stamping na assinatura electrónica. 152 Cf. COSTA (2005), in Lei do Comércio Electrónico Anotada, pp. 183-185.


44 | 69

É evidente que, em ambos os casos, a LCE vai mais longe, evidenciando-se a equiparação

dos contratos electrónicos aos contratos não electrónicos, mas não entendemos que estas

sobreposições invalidem o relevo do disposto no art. 3.º, n.º 1, do RJDEAD, na medida que é

a partir desta norma que se viabiliza a aplicação das regras relativas à prova documental.

Considerando que o agente de software possui capacidades cognitivas e volitivas, que o

sujeito utilizador, por acto unilateral, confere ao softbot poderes representativos e que, por via

das suas capacidades, o agente é capaz de agir ‘em nome’ do sujeito utilizador, diremos que a

forma electrónica da ‘vontade’ do softbot e da emissão e recepção da declaração dessa ‘vontade’

não chocará com as disposições que acabámos de referir, uma vez que todos os intervenientes

(i.e. os sujeitos utilizadores e os softbots que intervenham no negócio jurídico) possuem a sua

própria assinatura electrónica, o que irá permitir a identificação de todos os actos electrónicos

praticados pelos intervenientes (visto que todos os actos são inscritos na plataforma e, por isso,

assinados electronicamente 153 ). Além disso, ainda que os softbots, na interacção que

(eventualmente) façam com outros agentes de software, o façam numa linguagem ‘própria’, pode

(e deve) esta linguagem ser traduzida – ou traduzível – para uma linguagem humana, passando

a ser susceptível de representação escrita, viabilizando, como se disse, a aplicação das regras

relativas à prova documental.

Por fim, relativamente ao momento da celebração do contrato, algumas notas. Na

formação do contrato identificam-se (pelo menos) duas declarações negociais: a proposta e a

aceitação, que se devem conciliar num consenso. Aqui chegados, coloca-se o problema em saber

qual o momento da sua perfeição. Sendo várias as doutrinas que tentam apresentar uma solução

para este problema, foi adoptado pelo legislador de 1966 (e também pelo legislador alemão e

pela Convenção de Viena sobre compra e venda internacional de mercadorias), no art. 224.º do

Código Civil, a doutrina da recepção, que defende que «o contrato está perfeito quando a

resposta contendo a aceitação chega[r] à esfera de acção do proponente»154.

Assim, no contexto da forma de contratação electrónica automatizada que temos

analisado, visto que todos os actos electrónicos levados a cabo pelos intervenientes, humanos ou

não (v.g. inscrição do smart contract/agente de software na plataforma e das instruções inicias,

análise (por parte do agente) dos dados disponíveis relevantes para a tomada de decisão,

153 Cf. Figuras 1, 2 e 3. 154 Cf. PINTO (2005), pp. 648-650.


45 | 69

negociação do conteúdo do contrato, emissão da declaração negocial, etc.), são inscritos e

assinados electronicamente na plataforma, dir-se-á que o momento da perfeição negocial será

atingido quando se verifique a validade e legitimidade para negociar e seja atingido um consenso

entre as duas declarações negociais, que por sua vez resultará numa operação output. Como tal,

poderão a data e hora da criação, expedição ou recepção dos actos electrónicos ser identificados

pela análise da informação contida no acto assinatura electrónica155.

4.4.3 O ‘erro’ do agente de software

Já vimos que o agente de software é uma entidade dotada de autonomia e de (limitada)

inteligência, no entanto, não deixa de ser um produto da criatividade e dos avanços tecnológicos

humanos, pelo que seria inconcebível afirmar que estes estariam imunes ao erro (ainda que estes

estivessem munidos de uma excepcional capacidade de auto-aprendizagem e/ou de adaptação).

O funcionamento do agente de software consiste, essencialmente, na execução do seu código

fonte e das instruções iniciais programadas pelo seu sujeito utilizador, sendo possível que o seu

código fonte e/ou a programação inicial do sujeito utilizador sofrer de alguma falha ou vício.

Dito por outras palavras: é possível acontecer que algum erro na execução do código fonte do

agente de software ocorra independentemente do facto de as instruções inicias terem sido

correctamente inseridas e compreendas pelo agente.

Avançámos supra a possibilidade de o agente agir sem poderes ou em abuso de

representação156; se uma situação destas ocorresse num contexto de contratação ‘tradicional’, os

interesses do representado estariam salvaguardados na medida em que o negócio celebrado nessas

condições seria ineficaz em relação a ele, nos termos do art. 268.º, n.º 1, do Código Civil. Porém

o nosso agente não é uma entidade dotada de personalidade jurídica e também não dispõe de

um património responsável para poder responder por eventuais danos que cause à contraparte,

o que parece levantar um problema.

COELHO157 resolve esta questão ao convocar a aplicação (com as devidas adaptações) do

regime da representação aparente do contrato de agência, previsto no art. 23.º do DL n.º 178/86,

155 V. supra §2.3 O papel da criptografia e do time stamping na assinatura electrónica. 156 Cf. PINTO (2005), p. 549. 157 Cf. COELHO (2017).


46 | 69

de 3 de Julho, alterado pelo DL n.º 118/93, de 13 de Abril158_159, justificando que também esta

relação existente entre o sujeito utilizador e o seu agente de software constituirá uma espécie de

relação de cooperação, admitindo-se assim a extensão daquela norma a este regime.

Porém, esta solução não resolve o problema do erro humano na programação do agente,

nem do funcionamento deficiente do software. É verdade que o nosso legislador apresentou uma

solução para estes problemas nas alíneas a) a c) do n.º 2 do art. 33.º da LCE160, mas entendemos

que a simples aplicação analógica daquele regime poderá resultar em soluções menos acertadas.

Vejamos as três categorias de erro, considerando, a título de exemplo, as seguintes situações:

§ O erro de programação

Hipótese 1:

António, após recorrentes insistências do seu amigo Bernardo, entusiasta de filmes de

ficção científica, ordena o seu softbot a adquirir o primeiro filme da saga da ‘Guerra das

Estrelas’ para que pudesse assistir, como um verdadeiro fã. Momentos mais tarde, após

indicação do cumprimento da instrução dada, António e Bernardo são surpreendidos

ao verificar que, ao invés de ter sido adquirido o ‘Episódio IV – Uma Nova Esperança’,

de 1977, como era expectável, foi adquirido o ‘Episódio I – A Ameaça Fantasma’, de

1999. Muita embora tivesse sido adquirido o primeiro filme de acordo com o enredo,

Bernardo insistia que António deveria começar pelo primeiro filme em ordem de

lançamento. Quid iuris?

Hipótese 2:

Camila, leitora ávida e amante de ficção científica, em conversa com a sua amiga Dulce,

teve conhecimento sobre o lançamento de uma edição exclusiva do seu livro preferido

de Douglas Adams – o ‘The Hitchhiker's Guide to the Galaxy’ – assinada pelo autor.

Interessada em adquirir uma cópia, mas não sabendo onde comprar, ordena o seu softbot

a procurar e comprar uma cópia. Por engano, Camila, no momento em que introduzia

158 Dispõe o art. 23.º, n.º 1, do Diploma: «O negócio celebrado por um agente sem poderes de representação é eficaz perante o principal se tiverem existido razões ponderosas, objectivamente apreciadas, [...]». 159 Cf. MONTEIRO (2017), pp. 58 e 78-80. 160 Assim, havendo erro na programação, aplicar-se-ia o regime do erro da formação da vontade (al. a)), havendo funcionamento defeituoso, aplicar-se-ia o regime do erro na declaração (al. b)) e havendo defeito na mensagem aquando da sua recepção pelo destinatário, aplicar-se-ia o regime do erro na transmissão (al. c)).


47 | 69

o valor da quantidade de exemplares a adquirir, acrescenta um zero a mais, resultando

numa instrução de aquisição de dez exemplares do livro em vez de apenas um. Quid iuris?

Na primeira hipótese representa-se uma situação em que o sujeito utilizador programa

correctamente o seu agente de software e este segue rigorosamente as instruções. Todavia, a

vontade que esteve na base da programação está viciada por erro-vício, enquanto falsa

representação das circunstâncias em que se fundou a decisão de contratar.

Já na segunda figura-se uma situação em que não existe um erro-vício, como se passava

na primeira hipótese, mas também não existe um erro-obstáculo, visto que, se o processo de

programação se assemelha a um «processo volitivo interno»161 e se a emissão da declaração

automatizada só irá ser formulada posteriormente pelo softbot, inexiste uma divergência entre a

vontade expressa por Camila e a declaração negocial, já que esta ainda não foi emitida pelo

agente de software.

Em ambas as hipóteses, deparamo-nos com erros de programação, que, por remissão do

disposto na alínea a) do n.º 2 do art. 33º da LCE, nos levaria à aplicação das regras previstas nos

arts. 251.º (erro-vício sobre o objeto do negócio ou sobre a pessoa do declaratário), 252º, n.º 1

(erro-vício sobre os motivos) e 252.º, n.º 2 (erro-vício sobre a base do negócio), todos do Código

Civil. Assim, para a primeira hipótese, convocar-se-ia a aplicação do disposto no art. 247.º ex vi

o art. 251.º, por se tratar de uma situação que se aproxima de um erro-vício sobre o objecto.

Atento o que fora dito sobre o tipo de erro presente na segunda hipótese, que regime seria,

então, aplicável? Por falta de compatibilidade, entendemos que nenhuma das regras poderia ser

convocada, embora concordemos com a solução apresentada por FESTAS, que propõe a aplicação

do art. 247.º do Código Civil, «não apenas pela analogia existente com as situações tradicionais

de erro na declaração, como também pelo facto de [...] todo o processo de preparação e

programação [...] dever ser equiparado ao processo volitivo interno de formação da vontade que

se verifica na contratação comum»162. Mesmo assim, o recurso a este regime conduzir-nos-á a

outra dificuldade: a de inserir no código fonte do agente de software a capacidade de conhecer,

ou não poder ignorar, a essencialidade do elemento sobre que incidiu o erro, pelo que, não sendo

161 Cf. FESTAS (2006), p. 440. 162 Cf. FESTAS (2006), nota (82), pp. 445-446.


48 | 69

isso possível e adoptando a posição de diversos autores163, teríamos de aplicar os requisitos

constantes no art. 247.º do Código Civil aos sujeitos utilizadores164, porquanto são estes os

sujeitos que verdadeiramente celebram o contrato, ainda que por intermédio do(s) seu(s)

softbot(s).

§ O funcionamento defeituoso do agente de software

Hipótese 3:

Evaristo, guia turístico por profissão, tendo tido conhecimento que iria ser realizada uma

exposição interactiva em Londres para celebrar os 55 anos da sua série televisiva britância de

ficção científica preferida, ‘Doctor Who’, ordena o seu softbot a negociar e adquirir um

pacote de viagem que contemple a passagem de avião e a estadia num hotel próximo da

exposição. Mas, em virtude de um defeito no seu funcionamento, o softbot, no lugar de

adquirir um pacote de viagem para uma pessoa, adquire um pacote para um grupo de 10

pessoas. Quid iuris?

Nesta situação, o vício não advém de uma actuação humana e tem como resultado uma

divergência não intencional entre a programação (e a vontade aí expressa) e a declaração emitida

pelo softbot. Assim, considerando o disposto no art. 33º, n.º 2, al. b), e no art. 33.º, n.º 3, ambos

da LCE, deveria ser aplicada a regra do art. 247.º do Código Civil, devendo, por essa ordem de

razão, provar-se a essencialidade do elemento sobre que incidiu o erro. Porém, nem por isso seria

esta solução ajustada. O facto de se ter verificado uma divergência entre a vontade que o sujeito

utilizador pretendia que fosse exteriorizada e a vontade que foi exteriorizada pelo softbot, ao invés

de uma divergência entre a vontade que o sujeito utilizador queria exprimir e que efectivamente

exprimiu na programação (como vimos anteriormente), não afasta o problema que encontrámos

na tentativa de solução da segunda hipótese.

163 Neste sentido, cf. FESTAS (2006), pp. 444-446; ROSA, in Lei do Comércio Electrónica Anotada (2005), p. 205; ASCENSÃO (2003b), p. 67. 164 Invocando, por exemplo e como propõe ASCENSÃO (2003b, p. 67), «a culpa in contrahendo», «o risco» ou «a teoria da aparência».


49 | 69

§ O erro na transmissão da mensagem aquando da sua recepção pelo destinatário

Hipótese 4:

Fátima, pretendendo conhecer mais sobre as tecnologias blockchain, ordena o seu softbot

a procurar e comprar um exemplar do livro ‘Blockchain Revolution’ de Tapsctott e

Tapscott. Porém, no decurso da transmissão da mensagem (rectius da execução da

instrução), a declaração deforma-se e surge como uma encomenda de 100 exemplares da

obra. Quid iuris?

Situação mais difícil de conceber, dado o modo de funcionamento das DLT, é da

identificação de uma deformação na mensagem durante a sua transmissão sem se confundir com

um funcionamento defeituoso do agente de software. FESTAS, na tentativa de apresentar uma

solução para uma hipótese semelhante à nossa, refere ser imprescindível identificar se a

transmissão da mensagem é feita por via de um servidor do declarante ou por via de um servidor

intermediário, pois concorrem fundamentos diferentes para a mesma solução: a vinculação do

declarante165. Ora, na nossa situação, é preciso recordar que uma plataforma fundada em DLT

será necessariamente descentralizada, sendo todos os actos verificados e registados por todos os

nodos da rede, sendo desde logo muito difícil cogitar uma tal situação de erro de transmissão166.

Por essa razão, das duas, uma: ou estaremos perante um erro de funcionamento de (pelo menos)

um agente de software dos vários nodos da rede, responsáveis pela verificação e inscrição e dos

actos no livro-razão dos nodos, ou houve conluio na rede no sentido de se modificar os registos

de (no mínimo) mais de metade dos livros-razão dos nodos da plataforma para permitir a

inscrição e execução de um acto electrónico que era anteriormente impossível167.

165 Sumariamente, o autor entende que haverá sempre vinculação do declarante mas por fundamentos diversos: no caso de se tratar de um servidor do declarante, haverá vinculação do declarante, na medida em que o servidor equiparar-se-á a um núncio, por força de uma relação contratual entre o declarante e o servidor; no caso de se tratar de um servidor intermediário, haverá vinculação pelo facto de ter sido o declarante que escolheu aquele meio de transmissão, devendo por isso suportar o risco, aplicando-se a aplicação analógica do art. 250.º do Código Civil – v. FESTAS (2006, pp. 456-460). 166 Aliás, se assim fosse, que segurança traria esta tecnologia que se gaba pela renúncia de terceiros intermediários? Veja-se que no blockchain da bitcoin, é exatamente no processo de verificação que se impede que seja transferida uma quantia superior à soma disponível na carteira electrónica; se é assim, no nosso exemplo, o pedido corresponderia à ‘soma disponível’ do exemplo antetior da bitcoin e a declaração a ser emitida pelo softbot a ‘quantia a transferir’. Em suma, esta tecnologia gaba-se pela impossibilidade de double spending. 167 A este conluio designa-se fork, que consiste na modificação simultânea e concertada das informações constantes nos livros-razão de mais de metade da capacidade computacional da rede, para que, por exemplo, se ‘autorize’ a transferência de 10 bitcoins da conta A para a conta B quando na conta A existiam somente 5 bitcoins.


50 | 69

De uma maneira ou de outra, tendo em vista todas as hipóteses que apresentámos e sem

desconsiderar o iter percorrido por FESTAS168 quanto ao regime aplicável ao erro de programação,

ao erro na declaração e ao erro na transmissão na contratação electrónica automatizada,

entendemos que o actual «regime comum» aplicável a estas situações carece de uma reforma,

visto que, quando na altura da sua concepção, não se havia cogitado uma realidade como a nossa:

um agente não humano, com capacidades cognitivas e volitivas, capaz de agir ‘em nome’ de

outrem, mas que carece de personalidade jurídica. Citando o autor: «[h]á uma dificuldade

evidente na aplicação destes requisitos à contratação automatizada porque não existe aqui uma

vontade contemporânea da celebração do negócio jurídico»169.

A Resolução, ciente dos problemas levantados pela impossibilidade de responsabilização

dos robôs pelas suas acções ou omissões quando não seja possível atribuir a causa a um

interveniente humano, prescreve que não deverão, de modo algum, «limitar[-se] o tipo ou a

extensão dos danos a indemnizar nem as formas de compensação que podem ser disponibilizados

à parte lesada, pelo simples facto de os danos terem sido provocados por um agente não humano»,

evidenciando-se, também aqui, um corolário de não discriminação em razão do sujeito170.

168 Cf. FESTAS (2006), pp. 433-460. 169 Cf. FESTAS (2006), p. 444. 170 Cf. Considerando (52) da Resolução.


51 | 69

5. Algumas notas sobre a Resolução do Parlamento Europeu As patentes dificuldades que acabámos de ver no capítulo anterior, na tentativa de

enquadrar um regime jurídico aplicável aos agentes de software são, de certo modo, espelhadas

na Resolução do Parlamento Europeu, de 16 de Fevereiro de 2017, que teve como desiderato

apresentar à Comissão e ao Conselho algumas recomendações quanto às disposições de Direito

Civil sobre Robótica171.

Eis que, à semelhança da dificuldade em codificar a capacidade de conhecer, ou não

poder ignorar, a essencialidade do elemento sobre que incidiu o erro que vimos supra172, vem a

Resolução afirmar que as Leis de Asimov173 devem ser encaradas como dirigidas «aos criadores,

aos produtores e aos operadores de robôs, incluindo robôs com autonomia integrada e

autoaprendizagem», apoiando-se precisamente na dificuldade em traduzir e incorporar estas

regras no código fonte do software174.

Pretendendo uma maior transparência e confiança nestas novas tecnologias, considera-

se (e bem) que deve ser introduzido um sistema de registo de robôs avançados no mercado

interno da União, podendo este abranger todas (ou apenas determinadas) categorias de robôs175,

permitindo-se assim que qualquer sujeito que venha a interagir com um robô registado conheça

da sua «natureza do fundo, dos limites da respectiva responsabilidade em caso de danos

patrimoniais [...] e de todas as outras informações relevantes»176. Além disso, prevê igualmente a

criação de um sistema de licenciamento de robôs inteligentes, que viria abranger tanto os seus

criadores como os seus utilizadores177.

De facto, uma implementação de um sistema de registo e um sistema de licenciamento

de softbots poderia indubitavelmente permitir uma maior transparência e confiança na

171 Versando sobre, nomeadamente, os princípios gerais, a responsabilidade, os princípios gerais relativos ao desenvolvimento da robótica e da inteligência artificial para utilização civil, os princípios éticos, a normalização, segurança e protecção e as licenças para os criadores e utilizadores de robôs. 172 V. supra §4.4.3 O erro do agente de software. 173 ASIMOV (1943, pp. 27 e seguintes) definiu as Três Leis da Robótica como: (1) Um robô não pode magoar um ser humano ou, por inação, permitir que tal aconteça; (2) Um robô tem de obedecer às ordens dos seres humanos, excepto se essas ordens entrarem em conflito com a primeira lei; (3) Um robô tem de proteger a sua própria existência desde que essa proteção não entre em conflito com a primeira ou com a segunda lei; e, mais tarde, (0) Um robô não pode magoar a humanidade ou, por inação, permitir que a humanidade se magoe. 174 Cf. Considerando (T) da Resolução. 175 Cf. Considerando (2) da Resolução e §Registo de «robôs inteligentes» do Anexo da Resolução. 176 Cf. Considerando (59), al. e), da Resolução. 177 Cf. Considerandos (W), (9) e (23) da Resolução e §Licença para os Criadores e §Licença para os Utilizadores do Anexo da Resolução.


52 | 69

contratação, na medida em que a implementação de critérios estandardizados de teste de robôs

em cenários da vida real poderia resultar numa melhor avaliação dos riscos implicados na sua

utilização e, eventualmente, de um sistema de inspecção regular do software (e do hardware) dos

mesmos, almejando assegurar o seu correcto funcionamento.

Ademais, é sugerida a hipótese de se averiguar a necessidade de uma revisão do

Regulamento Geral sobre a Protecção de Dados (RGPD)178, na medida em que alguns aspectos

ligados ao acesso a dados e à proteção de dados pessoais e da privacidade podem ainda estar por

resolver e/ou persistirem preocupações quanto à garantia de privacidade no método de

comunicação sem intervenção humana entre dispositivos e aplicações e/ou com bases de dados179.

A este respeito, revelou o legislador comunitário nos Considerandos da RGPD certa

preocupação com o processamento de dados por meios automatizados, estatuindo que a

proteção dos dados pessoais das pessoas singulares deve ser tecnologicamente neutra e

independente das técnicas utilizadas (sob pena de se correr um risco sério desta proteção ser

contornada), prevendo-se o direito do titular dos dados exigir a recepção dos dados que lhe

digam respeito que tenham sido processados por meios automatizados para transmití-los a outro

responsável (salvo quando o tratamento de dados for «necessário para o cumprimento de uma

obrigação jurídica à qual o responsável esteja sujeito, para o exercício de atribuições de interesse

público ou para o exercício da autoridade pública de que esteja investido o responsável pelo

tratamento»180). Sendo posteriormente contemplado, no corpo do RGPD, o tratamento de

dados por meios automatizados, passando a protecção de dados a funcionar independentemente

da forma utilizada para o seu tratamento181.

Salienta-se a necessidade de um conjunto de disposições legais que rejam, em particular,

a responsabilidade, a transparência e a prestação de contas, tendo em vista que a nossa actual

realidade já conta com grandes avanços tecnológicos, que viabilizaram a atribuição de certas

capacidades aos robôs que, até então, eram exclusivas ao Homem, devendo esta questão ser

igualmente resolvida ao nível da União, «a fim de garantir o mesmo nível de eficácia, de

178 Cf. Regulamento (UE) 2016/679, de 27 de Abril, do Parlamento Europeu e do Conselho, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Directiva 95/46/CE. 179 Cf. Considerandos (N), (10), (13), (14) e (18) e seguintes da Resolução. 180 Cf. Considerando (68) do RGPD. 181 Cf. Art. 2.º, n.º 1, art. 4.º, nºs. 1 e 4, art. 13.º, n.º 2, al. f), art. 14.º, n.º 3, al. g), art. 15.º, n.º 1, al. h), art. 20.º, n.º 1, al. b), arts. 21.º e 22.º, art. 35.º, n.º 3, al. a), e art. 47.º, n.º 2, al. e), todos do RGPD.


53 | 69

transparência e de coerência na execução da segurança jurídica em toda a União para benefício

dos cidadãos, dos consumidores e das empresas»182.

Em virtude quer do facto de que será tanto mais difícil a equiparação do robô a um mero

instrumento do seu utilizador quanto maior for a sua autonomia, quer do facto de lhes poder

ser atribuída a capacidades de auto-aprendizagem e adaptabilidade, questiona-se se o actual

regime ordinário em matéria de responsabilidade é suficiente para resolver os eventuais

problemas, ou se será necessário um novo complexo de normas e princípios que venha clarificar

a responsabilidade jurídica dos vários intervenientes quanto à responsabilidade por actos ou

omissões dos robôs «quando a causa não puder ser atribuída a um interveniente humano

específico e os actos ou as omissões dos robôs que causaram os danos pudessem ter sido

evitados»183.

Mais ainda, sublinha-se que as normas tradicionais não estão preparadas para resolver os

problemas da responsabilidade jurídica pelos danos causados por um robô, por não ser possível

identificar a parte responsável para prestar a indemnização e para lhe exigir que reparasse os

danos causados. Evidenciando-se também a intrínseca complexidade dos problemas de

responsabilidade objectiva suscitados por danos causados robôs capazes de auto-aprendizagem e

de adaptação, na medida em que se acentua o grau de imprevisibilidade da actuação do robô.

Perante isto, é sugerido que os robôs deveriam ser dotados de uma «caixa negra», onde seriam

registadas todas as operações realizadas, desde a sua concepção até à sua efectiva realização184.

Dada a falta de soluções legais adequadas para os problemas referidos na Resolução, é

recomendada a adopção de um regime de seguros obrigatórios como uma potencial solução para

acautelar os interesses daqueles que sofreram danos causados por robôs e de um fundo de

garantia de reparação de danos não abrangidos pelo seguro, devendo o regime do seguro ter em

consideração todos os elementos potenciais da cadeia de responsabilidade (sendo por isso mais

abrangentes que um regime de automóveis)185.

Por fim, uma última nota relativamente à Resolução: não fossem já todas as sugestões

apresentadas pelo Parlamento de se louvar, vai este Instituto mais longe ao sugerir, nos seus

Considerandos (AC) e (59), al. f), que, em última instância, poderia ser ponderada a hipótese

182 Cf. Considerando (49) da Resolução. 183 Cf. Considerando (AB) da Resolução. 184 Cf. Considerandos (Q), (U), (Y), (Z), (AB), (AD) a (AI), (12) e (53) a (55) da Resolução. 185 Cf. Considerandos (57) a (59), als. a), b) e c) da Resolução.


54 | 69

de se criar uma nova categoria jurídica, «com características e implicações próprias»: a

‘personalidade electrónica’.

Não existem dúvidas que todas as recomendações que salientámos são indubitavelmente

inovadoras e ajustadas à realidade que vivemos, mas nem por isso nos parece que, em sede do

tema que temos desenvolvido, se possa ir tão longe quanto à criação de uma ‘personalidade

electrónica’. Entedemos, pelo contrário, que até melhor compreensão das capacidades/limitações

da inteligência artificial, será bastante a criação de uma nova categoria jurídica que atribua, como

já se sugeriu186, uma capacidade de agir limitada às capacidades de actuação do software que não

assente na personalidade jurídica.

186 V. supra §4.3 A qualificação jurídica dos agentes de software.


55 | 69

Conclusão Aqui chegados, torna-se difícil negar que nos aproximamos de uma realidade tecnológica

e, possivelmente, juridicamente novas. Pelo contrário, evidencia-se uma crescente preocupação

com a previsão de soluções novas para um futuro que se avizinha mais rápido do que se pensa.

É verdade que no desenvolvimento deste trabalho ocupámo-nos grandemente sobre o

funcionamento da tecnologia e dos problemas que o recurso a esta convocaria no âmbito da

contratação electrónica. Não obstante, cumpre-nos reiterar que as DLTs não se limitam (nem

têm que se limitar) apenas a sistemas de pagamento descentralizados e à contratação;

diferentemente, estão em curso projectos-pilotos de diversas áreas que recorrem ao uso desta

tecnologia, nomeadamente em sistemas de gestão e distribuição de energias renováveis187, na

indústria hospitalar e farmacêutica188, no âmbito do registo predial189, em sistemas de votação

online190, entre muitos outros. Perante a versatilidade desta tecnologia, fez-se referência à mais

recente Lei-Modelo da Comissão das Nações Unidas para o Direito Comercial Internacional

(UNCITRAL), no âmbito da contratação electrónica, a Lei-modelo sobre documentos

transmissíveis electrónicos.

Neste contexto, concluímos que o recurso a esta tecnologia no âmbito da contratação

electrónica constitui, de facto, uma nova forma de contratar, podendo ser adoptado a

denominação ‘criptocontratação’, uma vez que, por um lado, não se identifica com a contratação

automatizada com recurso à EDI (desde logo pela inexistência de um acordo-tipo prévio entre

as partes contratantes), e, por outro, se trata de uma forma de contratação electrónica

automatizada que convoca a participação de agentes de software e ao recurso à criptografia para

concluir negócios jurídicos sem intervenção humana. No entanto, depreende-se que, caso seja

adoptado uma denominação própria para esta forma de contratar, dever-se-á optar por uma

denominação tecnologicamente neutra.

Ademais, ainda que seja possível e justificável um enquadramento jurídico em que se

contemple o agente de software enquanto representante do seu sujeito utilizador, entendemos

que deve ser criado um regime próprio para regular a criptocontratação, visto que a actuação do

187 Cf. NASDAQ (2018). 188 Cf. United News of India (2018). 189 Cf. YOUNG (2017), WONG, J. I. (2017). 190 Cf. HIGGINS (2017.


56 | 69

agente de software levanta diversas dúvidas quanto à natureza jurídica da sua ‘vontade’, que por

sua vez irá conduzir a problemas na aplicação do regime do erro-vício e do erro-obstáculo,

alegadamente aplicável por força do disposto no art. 33.º, n.ºs 2 e 3, da LCE.

É que, no fundo, a grande diferença entre a contratação ‘tradicional’ e a

criptocontratação reside no facto de na primeira se estipularem cláusulas contratuais para auxiliar

a resolução ex post de eventuais conflitos que possam advir daquele negócio; já na última,

codificam-se ‘cláusulas contratuais’ para que ex ante se previnam (tentativamente) todos os

possíveis conflitos, sendo isso impossível como se sabe, já que «a lei é insuficiente: não pode[ndo]

prever todas as situações com que a vida nos surpreende de quando em vez»191.

Além disso, pelas dificuldades que acabámos de referir, igualmente difícil se revela a

tentativa de identificação da parte responsável para prestar a indemnização e para lhe exigir a

reparação dos danos causados por um robô e da aplicação do regime da responsabilidade

objectiva quando os danos sejam causados por robôs capazes de auto-aprendizagem e de

adaptação. Aliás, neste sentido recomenda-se na Resolução que as Leis de Asimov192 devam ser

encaradas como dirigidas aos humanos, apoiando-se precisamente na dificuldade em traduzir e

incorporar estes ‘princípios’ no código fonte do software.

Mais ainda, atenta a regra de não discriminação em razão do sujeito (que dispõe que não

se poderá «limitar o tipo ou a extensão dos danos a indemnizar nem as formas de compensação

[...] pelo simples facto de terem sido provocados por um agente não humano»193), entendemos

ser justa e adequada considerar a implementação de sistemas de registo, classificação,

licenciamento e revisão periódica dos agentes de software e da adopção de um regime de seguros

obrigatórios (como potencial solução para acautelar os interesses daqueles que sofreram danos

causados por robôs) e de um fundo de garantia de reparação de danos não abrangidos pelo seguro,

devendo o regime do seguro ter em consideração todos os elementos potenciais da cadeia de

responsabilidade.

Por fim, entendemos ser razoável a criação de uma nova categoria jurídica, ajustada aos

agentes de software e que lhe atribua uma capacidade de agir limitada às suas capacidades de

actuação, diferente de uma ‘personalidade electrónica’.

191 Cf. JUSTO (2003), pp. 122-123. 192 Cf. ASIMOV (1943), pp. 27 e seguintes. 193 Cf. Considerando (52) da Resolução.


57 | 69

Bibliografia Albertson, Mark. 2018. Artificial intelligence gets smarter at predicting what’s coming next. Janeiro

27. Accessed Janeiro 28, 2018. https://siliconangle.com/blog/2018/01/27/artificial-

intelligence-gets-smarter-predicting-whats-coming-next/.

Allen, Tom, and Robin Widdison. 1996. "Can computers make contracts?" Harvard Journal of

Law & Technology 9 (1): 26-52.

Alter, Lloyd. 2017. Forget Bitcoin; it's the blockchain that might change everything. Novembro 27.

Accessed Dezembro 15, 2017. https://www.treehugger.com/economics/forget-bitcoin-

its-blockchain-might-change-everything.html.

ANACOM. 2004. “O Comércio Electrónico em Portugal: O quadro legal e o negócio.”

ANACOM. 30 de Março. Acedido em 19 de Dezembro de 2017.

https://www.anacom.pt/streaming/manual_comercio_elec.pdf?contentId=178219&fie

ld=ATTACHED_FILE.

Anderson, Shannon W., and William N. Lanen. 2002. "Using Electronic Data Interchange

(EDI) to Improve the Efficiency of Accounting Transactions." The Accounting Review

77 (4): 703-729.

antonylewis2015. 2016. So you want to use a blockchain for that? Julho 16. Accessed Janeiro 1,

2018. https://bitsonblocks.net/2016/07/19/so-you-want-to-use-a-blockchain-for-that/.

António, Francisco. 2017. Táxi autónomo. Continental aponta à Uber e Google. 26 de Julho.

Acedido em 28 de Janeiro de 2018. http://observador.pt/2017/07/26/taxi-autonomo-

continental-aponta-a-uber-e-google/.

Ascensão, José de Oliveira. 2003a. “Bases para uma transposição da directriz n.º 00/31, de 8 de

Junho (Comércio electrónico).” Separata da Revista da Faculdade de Direito da

Universidade de Lisboa (Coimbra Editora) XLIV (1 e 2): 215-252.

Ascensão, José de Oliveira. 2003b. Contratação electrónica. Vol. IV, em Direito da Sociedade da

Informação, de APDI, 43-68. Coimbra Editora.

Asher, Abraham. 2007. "Developing a B2B E-Commerce Implementation Framework: A Study

of EDI Implementation for Procurement." Information Systems Management 24 (4):

373-390.

Asimov, Isaac. 1943. "Runaround." I, Robot. Accessed Janeiro 30, 2018.

http://kaitnieks.com/files/asimov_isaac__i_robot.pdf.


58 | 69

Assia, Yoni, Vitalik Buterin, Meni Rosenfeld, and Rotem Lev. 2012. "Colored Coins

Whitepaper." Agosto 20. Accessed Dezembro 15, 2017.

https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrT

LuoWu2z1BE/edit#heading=h.wxrvzqj8997r.

Back, Adam. 2002. "Hashcash." Hashcash - A Denial of Service Counter-Measure. Agosto 1.

Accessed Novembro 10, 2017. http://www.hashcash.org/papers/hashcash.pdf.

Bailis, Peter, and Han Song. 2017. "Research for Practice: Cryptocurrencies, Blockchains, and

Smart Contracts; Hardware for Deep Learning." Communications of the ACM (Color

Photograph) 60 (5).

Bang-Jensen, Jørgen, and Gregory Z Gutin. 2009. "2.1 Acyclic Digraphs." In Digraphs: Theory,

Algorithms and Applications, 32-34. Springer.

Barnes, Andrew, Christopher Brake, and Thomas Perry. 2016. "Digital Voting with the use of

Blockchain Technology." Plymouth University. Accessed Dezembro 15, 2017.

https://www.economist.com/sites/default/files/plymouth.pdf.

Bellia Jr., Anthony J. 2001. "Contracting with Electronic Agents." Emory Law Journal 50: 1047-

1092.

Bhatia, Shekhar. 2018. Teaching Artificial Intelligence to teach itself. Janeiro 23. Accessed Janeiro

28, 2018. http://www.livemint.com/Leisure/vtiKX8KtqZ97zjbB3M2q3N/Teaching-

Artificial-Intelligence-to-teach-itself.html.

BitcoinWiki. 2016. Smart Property. Maio 16. Accessed Dezembro 15, 2017.

https://en.bitcoin.it/wiki/Smart_Property.

BitFury Group. 2015. Smart Contracts on Bitcoin Blockchain. Setembro 4. Accessed Dezembro

14, 2017. http://bitfury.com/content/5-white-papers-research/contracts-1.1.1.pdf.

—. 2015. Proof of Stake versus Proof of Work. 15 de Setembro. Acedido em 27 de Dezembro de

2017. http://bitfury.com/content/5-white-papers-research/pos-vs-pow-1.0.2.pdf.

BlockchainHub. n.d. Blockchain Oracles. Accessed Dezembro 14, 2017.

https://blockchainhub.net/blockchain-oracles/.

Blum, Brian A., and Amy C. Bushaw. 2017. Contracts: Cases, Discussion and Problems. Wolters

Kluwer Law & Business.

Boucher, Philip. 2017. "European Parliament." How blockchain technology could change our lives:

In-depth Analysis. EPRS (European Parliamentary Research Service). Fevereiro. Accessed


59 | 69

Maio 11, 2017.

http://www.europarl.europa.eu/RegData/etudes/IDAN/2017/581948/EPRS_IDA(20

17)581948_EN.pdf.

Brocaw, Alex. 2014. Coindesk. 08 14. Accessed 11 03, 2017. https://www.coindesk.com/crypto-

2-0-roundup-bitcoins-revolution-moves-beyond-currency/.

Browne, Ryan. 2017. "Bitcoin is 'definitely not a fraud,' CEO of mobile-only bank Revolut

says." CNBC (Disponível online em: <https://www.cnbc.com/2017/11/24/revolut-

signs-up-1-million-users-ahead-bitcoin-cryptocurrency-launch.html>. (Obtido em 30

de Janeiro de 2018)).

BTCManager.com. 2017. Dezembro 19. Accessed Dezembro 27, 2017.

https://btcmanager.com/dag-vs-blockchain/.

Buntinx, JP. 2016. Março 6. Accessed Dezembro 27, 2017. http://bitcoinist.com/iota-internet-

things-without-blockchain/.

Burgin, Mark, and Gordana Dodig-Crnkovic. 2009. "A Systematic Approach to Artificial

Agents." Fevereiro. Accessed Dezembro 15, 2017. https://arxiv.org/pdf/0902.3513.pdf.

Buterin, Vitalik. 2013. Bicoin Magazine. Agosto 26. Accessed Dezembro 27, 2017.

https://bitcoinmagazine.com/articles/what-proof-of-stake-is-and-why-it-matters-

1377531463/.

—. 2015a. Ethereum Github. Julho 30. Accessed Novembro 3, 2017.

https://github.com/ethereum/wiki/wiki/White-Paper.

—. 2015b. On Public and Private Blockchains. Agosto 7. Accessed Janeiro 1, 2018.

https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/.

Caiazzo, Francesca. 2016. "A Block-Chain Implemented Voting System." Dezembro 14.

Accessed Dezembro 15, 2017.

http://www.cs.tufts.edu/comp/116/archive/fall2016/fcaiazzo.pdf.

Cammarata, Manlio, and Enrico Maccarone. 2001. Interlex: Diritto Tecnologia Informazione. 09

21. Accessed 11 07, 2017. http://www.interlex.it/docdigit/recep1.htm.

Carmo, F. Cunha Leal. 2013. Dicionário Jurídico – Contratos e Obrigações. Vol. I. Escolar

Editora.

Chainfrog Oy. 2017. "What are Smart Contracts." Accessed Dezembro 14, 2017.

http://www.chainfrog.com/wp-content/uploads/2017/08/smart-contracts.pdf.


60 | 69

Coelho, Francisco Pereira. 2017. "Contratacão automatizada e execucão contratual

automatizada: dos “software agents” aos “smarts contracts”." Congresso de Direito e

Robótica. Coimbra: Em vias de publicação.

Correia, Miguel Pupo. 2009. Assinatura electrónica e certificação digital – Novas tendências. Vol.

VIII, in Direito da Sociedade da Informação, 155-187. Coimbra: Coimbra Editora, APDI.

—. 2013. "Formação dos Contratos." AICEP. AICEP. Outrubro. Accessed Janeiro 19, 2018.

http://www.aicep.pt/framework/download.php?id=98.

Cunha, Paulo de Pitta e. 1985. “As pessoas colectivas como administradores de sociedades.”

Revista da Ordem dos Advogados I (45): 5-11.

Davis, Joshua. 2011. "The New Yorker." The Crypto-Currency: Bitcoin and its mysterious inventor.

10 10. Accessed 03 10, 2017. https://www.newyorker.com/magazine/2011/10/10/the-

crypto-currency.

Dodd, Jeff C., e James A. Hernandez. 1998. “Contracting In Cyberspace.” Computer Law

Review and Technology Journal (Summer): 1-38.

Dwork, Cynthia, and Moni Naor. 1993. Pricing via Pro cessing or Combatting Junk Mail.


http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp.ps.

Dziembowski, Stefan, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. 2013.

Proofs of Space. Novembro 28. Accessed Dezembro 27, 2017.

https://eprint.iacr.org/2013/796.pdf.

ESMA. 2016. "European Securities and Markets Authority." Discussion paper: Distributed

Ledger Technology applied to securities markets. 06 02. Accessed 03 19, 2017.

https://www.esma.europa.eu/sites/default/files/library/2016-773_dp_dlt.pdf.

Etzioni, Oren, Neal Lesh, and Richard Segal. 1994. "Building Softbots for UNIX (Preliminary

Report)." AAAI Technical Report SS-94-04: 9-16.

Federal Information Processing Standards Publication. 2015. "National Institute of Standards

and Technology." Secure Hash Standard (SHS) . Information Technology Laboratory.

Agosto 4. Accessed Novembro 10, 2017.

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf.

Fernandes, Luís A. Carvalho. 2001. Teoria Geral do Direito Civil. 3ª edição revista e actualizada.

Vol. II. II vols. Universidade Católica Editora.


61 | 69

Festas, David de Oliveira. 2006. A contratação electrónica automatizada. Vol. VI, in Direito da

Sociedade da Informação, by APDI, 411-461. Coimbra Editora.

Finnegan, Pat, William Golden, and Denis Murphy. 1998. "Implementing Electronic Data

Interchange: A Nontechnological Perspective." International Journal of Electronic

Commerce 2 (4): 27-41.

Fishcher, John P. 1997. "Computers as Agents: A Proposed Approach to Revised U.C.C. Article

2." Indiana Law Journal 72 (2): 545-570.

Franco, João Melo, and António Herlander Antunes Martins. 1993. Dicionário de Conceitos e

Princípios Jurídicos. 3ª Edição. Coimbra: Livraria Almedina.

Franklin, Stan, and Art Graesser. 1996. "Is it an Agent, or just a Program?: A Taxonomy for

Autonomous Agents." University of Memphis. Agosto. Accessed Dezembro 15, 2017.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.589.5192&rep=rep1&type

=pdf.

—. 1996. "Is It an agent, or just a program?: A taxonomy for autonomous agents." Workshop

on Intelligent Agents III, Agent Theories, Architectures, and Languages (ECAI '96).

Springer-Verlag London. 21-35.

2017. Futuriom: the future of tech. Novembro 17. Accessed Dezembro 27, 2017.

http://www.futuriom.com/articles/news/augmate-announces-blockchain-for-

iot/2017/11.

Galesi, Nicola, Giuseppe Ateniese, Antonio Faonio, and Ilario Bonacina. 2014. "Proofs of Space:

When Space Is of the Essence." Edited by Michel Abdalla and Roberto De Prisco.

Security and Cryptography for Networks. Amalfi: Springer, Cham. 538-557.

https://sapienza.pure.elsevier.com/en/publications/proofs-of-space-when-space-is-of-

the-essence-7.

Garner, Bryan A. 1999. Black's Law Dictionary. 7th Edition. West Group.

Guttman, Robert H., Alexandros G. Moukas, and Pattie Maes. 1998. "Agent-mediated

Electronic Commerce: A Survey." The Knowledge Engineering Review (Cambridge

University Press) 13 (2): 147-159.

Habibzadeh, Taher. 2016. "Analysing Legal Status of Electronic Agents Is Contracting through

Interactive Websites: Comparative Study of American, English and EU Laws

Developing Iranian Legal System." Information & Communications Technology Law 25


62 | 69

(2): 150-172. http://www.ulcc.ca/en/annual-meetings/359-1999-winnipeg-mb/civil-

section-documents/362-providing-for-autonomous-electronic-devices-in-the-

electronic-commerce-act-1999?showall=1&limitstart=.

Harwell, Drew. 2018. Shake-up at Facebook highlights tension in race for AI. Janeiro 24. Accessed

Janeiro 28, 2018. https://www.washingtonpost.com/business/economy/shake-up-at-

facebook-highlights-tension-in-race-for-ai/2018/01/24/5d21239a-0138-11e8-9d31-

d72cf78dbeee_story.html?utm_term=.ba531f130398.

Hawkins, Andrew J. 2017. Uber is getting serious about building real, honest-to-god flying taxis.

25 de Abril. Acedido em 28 de Janeiro de 2018.

https://www.cnbc.com/2017/04/25/uber-reveals-plans-for-flying-taxis-at-elevate-

event.html.

Hearn, Mike. 2013. Autonomous agents, self driving cars and Bitcoin. 09 29. Accessed 11 04,

2017. https://www.youtube.com/watch?v=MVyv4t0OKe4.

—. 2013. Future of money. 09 29. Accessed 11 04, 2017.

https://www.slideshare.net/mikehearn/future-of-money-26663148.

Higgins, Stan. 2017. Moscow Government Open-Sources Blockchain Voting Tool. Dezembro 4.

Accessed Janeiro 30, 2018. https://www.coindesk.com/blockchain-voting-code-made-

open-source-moscows-government/.

Hill, Ned C., and Daniel M. Ferguson. 1989. "Electronic Data Interchange: A Definition and

Perspective." The Journal of Electronic Commerce 1 (1): 5-12.

Instituto Jurídico. 2017. Painel III Congresso Direito e Robótica. Instituto Jurídico da Faculdade

de Direito da Universidade de Coimbra. Novembro 16.

https://www.facebook.com/ij.fduc/videos/1931385373792186/.

Jakobsson, Markus. 1999. "Hashcash." Proofs of Work and Bread Pudding Protocols (extended

abstract). Setembro 20-21. Accessed Novembro 11, 2017.

http://www.hashcash.org/papers/bread-pudding.pdf.

Janca, P. C., and D. Gilbert. 2012. "Practical Design of Intelligent Agent Systems ." In Agent

Technology: Foundations, Applications, and Markets, by Nicholas R. Jennings and

Michael J. Wooldridge, 73-90. Springer Science & Business Media.


63 | 69

Jansen, James. 1997. Using Intelligent Agents to Enhance Search Engine Performance. Março.


http://firstmonday.org/ojs/index.php/fm/article/view/517/438.

Jowitt, Earl. 1959. The Dictionary of English Law. Vol. 2. Londres: Sweet & Maxwell Limited.

Justo, António Santos. 2003. Introdução ao Estudo do Direito. Coimbra: Coimbra Editora.

Kerr, Ian R. 2001. "Ensuring the Success of Contract Formation in Agent-Mediated Electronic

Commerce." Electronic Commerce Research (Springer) 1 (1): 183-202.

—. 1999. Providing for Autonomous Electronic Devices in the Electronic Commerce Act 1999.

Accessed Janeiro 26, 2018. http://www.ulcc.ca/en/1999-winnipeg-mb/359-civil-

section-documents/362-providing-for-autonomous-electronic-devices-in-the-

electronic-commerce-act-1999.

Kharpal, Arjun. 2017. NASA is working with Uber on its flying taxi project. Novembro 8.

Accessed Janeiro 28, 2018. https://www.cnbc.com/2017/11/08/uber-nasa-work-on-

flying-taxis.html.

King, Sunny, and Scott Nadal. 2012. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake.

Agosto 19. Accessed Dezembro 27, 2017. https://peercoin.net/assets/paper/peercoin-

paper.pdf.

Kis, Sabrina. 2004. "Contracts and Electronic Agents." University of Georgia School of Law.

Janeiro 8. Accessed Dezembro 18, 2017.

http://digitalcommons.law.uga.edu/cgi/viewcontent.cgi?article=1025&context=stu_ll

m.

Kubjas, Ivo. 2017. "Using blockchain for enabling internet voting." Janeiro 6. Accessed

Dezembro 15, 2017.

https://courses.cs.ut.ee/MTAT.03.323/2016_fall/uploads/Main/004.pdf.

Larchevêque, Eric. 2016. Hardware Pythias: bridging the Real World to the Blockchain. Ledger.

Agosto 31. Accessed Dezembro 14, 2017. https://www.ledger.fr/2016/08/31/hardware-

pythias-bridging-the-real-world-to-the-blockchain/#.2zeggzh6f.

Lerouge, Jean-François. 1999. "The Use of Electronic Agents Questioned under Contractual

Law: Suggested Solutions on a European and American level." John Marshall Journal of

Information Technology & Privacy Law 18 (2): 404-434.


64 | 69

Limo. 2017. The Tangler. Janeiro 25. Accessed Dezembro 27, 2017.

https://www.tangleblog.com/2017/01/25/the-tech-behind-iota-explained/#comment-

4719.

Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Hobor Aquinas. 2016. "Making

Smart Contracts Smarter." CCS '16 Proceedings of the 2016 ACM SIGSAC Conference

on Computer and Communications Security. Vienna: ACM New Yorn, NY, USA. 254-

269.

Maes, Pattie, Robert H. Guttman, and Alexandros G. Moukas. 1999. "Agents that Buy and Sell:

Transforming Commerce as we Know It." Communications of the ACM 42 (3): 81-91.

Martins, António Lourenço, José Garcia Marques, and Pedro Simões Dias. 2012. Cyber Law in

Portugal. Kluwer Law International.

Mik, Eliza. 2017. “Smart contracts: terminology, technical limitations and real world

complexity.” Law, Innovation and Technology (Disponível online:

<https://doi.org/10.1080/17579961.2017.1378468> (Obtido em: 30 de Janeiro 2018))

9 (2): 269-300.

Ministério da Ciência e da Tecnologia. 1997. Livro Verde para a Sociedade da Informação em

Portugal. Missão para a Sociedade da Informação.

Ministério da Justiça: Gabinete de Política Legislativa e Planeamento. 2005. Lei do Comércio

Electrónico Anotada. Coimbra Editora.

Monteiro, António Pinto de. 2017. “A cláusula penal perante as alterações de 1980 e de 1983

ao Código Civil.” Revista de Legislação e de Jurisprudência (GESTLEGAL) 4006.

Monteiro, António Pinto de. 1999. A responsabilidade civil na negociação informática. Vol. I, em

Direito da Sociedade da Informação, de APDI, 229-239.

—. 2017. "Revisitando a Lei da Agência 30 anos depois." Distribuição comercial nos 30 anos da

Lei do Contrato de Agência. Coimbra: Instituto Jurídico. 53-83.

Moukas, Alexandros, Robert Guttman, and Pattie Maes. 2000. "Agent-mediated Electronic

Commerce: An MIT Media Laboratory Perspective." Accessed Janeiro 18, 2018.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.335.8810&rep=rep1&type

=pdf.

Nakamoto, Satoshi. 2008. 11 08. Accessed 11 03, 2017. http://bitcoin.org/bitcoin.pdf.


65 | 69

Nasdaq. 2018. Estonia Launches Green Energy Blockchain Project. Janeiro 11. Accessed Janeiro

30, 2018. http://www.nasdaq.com/article/estonia-launched-green-energy-blockchain-

project-cm904091.

Nunes, Pedro. 1999. Dicionário de Tecnologia Jurídica. 13ª Edição. Rio de Janeiro: Renovar.

Nwana, and Hyacinth S. 1996. "Software Agents: An Overview." Knowledge Engineering Review

(Cambridge University Press) 11 (3): 205-244.

Nwana, Hyacinth S., and D. T. Ndumu. 2012. "A Brief Introduction to Software Agent

Technology." In Agent Technology: Foundations, Applications, and Markets, by Nicholas

R. Jennings and Michael J. Wooldridge, 30-48. Springer Science & Business Media.

Nxt Community. 2014. "Nxt Whitepaper." Vers. 1.2.2. Julho 12. Accessed Janeiro 22, 2018.

https://www.dropbox.com/s/cbuwrorf672c0yy/NxtWhitepaper_v122_rev4.pdf.

O'Callaghan, Ramón, Patrick J. Kaufmann, and Benn R. Konsynki. 1992. "Adoption correlates

and share effects of Electronic Data Interchange systems in marketing channels." Journal

of Marketing 56 (2): 45-56.

Patrão, Afonso. 2012. "Assinaturas Electrónicas e Garantias Reais — Da viabilidade de

constituição de garantias imobiliárias por meios electrónicos à luz da lei portuguesa."

Revista do CEDOUA 29 (1.12): 47-83.

Pereira, Alexandre Libório Dias. 1999a. Comércio Electrónico na Sociedade da Informação: Da

segurança técnica à confiança jurídica. Coimbra: Livraria Almedina.

Pereira, Alexandre Libório Dias. 2004. "Princípios do Comércio Electrónico." Miscelâneas –

IDET (Coimbra Editora) 3: 75-112.

Pereira, Alexandre Libório Dias. 1999b. “Programas de Computador, Sistemas informáticos e

Comunicações electrónicas: alguns aspectos jurídico-contratuais.” Revista da Ordem dos

Advogados Ano 59 (III): 915-1000.

Pereira, Duarte Amorim. 2013. "Princípios gerais da contratação pública electrónica." Revista

Electrónica de Direito. Centro de Investigação Jurídico-Económica. Outubro. Accessed

Janeiro 14, 2018. https://www.cije.up.pt/content/princ%C3%ADpios-gerais-da-

contratação-pública-electrónica.

Pereira, Joel Timóteo Ramos. 2004. Compêndio Jurídico da Sociedade da Informação. Lisboa:

Quid Iuris.

Pinto, Carlos Alberto Mota. 2005. Teoria Geral do Direito Civil. 4ª edição. Coimbra Editora.


66 | 69

Prata, Ana. 2017. Código Civil Anotado. Vol. I. Almedina.

Rocha, Manuel Lopes. 2002. "ASF: Autoridade de Supervisão de Seguros e Fundos de Pensões."

A assinatura electrónica: Uma Via Portuguesa "Original"? 01. Accessed 11 08, 2017.

http://www.asf.com.pt/winlib/cgi/winlibimg.exe?key=&doc=10038&img=961.

Rocha, Manuel Lopes, Miguel Pupo Correia, Marta Felino Rodrigues, Miguel Almeida Andrade,

and Henrique José Carreiro. 2000. As Leis do Comércio Electrónico. Centro Atlântico.

Rouse, Margaret. 2016. Definition: Smart Contract. Maio. Accessed Janeiro 30, 2018.

http://searchcompliance.techtarget.com/definition/smart-contract.

RT. 2017. "Bitcoin is ‘the greatest technology since the internet’ – cryptocurrency investor Tim

Draper." RT (Disponível online em: <https://on.rt.com/8s01>. (Obtido em: 30 de

Janeiro de 2018)).

Santos, Tiago José Prelhaz. 2014. A Designacão de Pessoas Colectivas para o Órgão de

Administrac ão de Sociedades Comerciais. Coimbra: Dissertacão apresentada à Faculdade

de Direito da Universidade de Coimbra no ambito do 2.o Ciclo de Estudos em Direito

(conducente ao grau de Mestre), na Área de Especializacão em Ciencias Jurídico-

Empresariais/Mencão em Direito Empresarial.

Savelyev, Alexander. 2017. "Contract law 2.0: ‘Smart’ contracts as the beginning of the end of

classic contract law." Journal Information & Communications Technology Law 26 (2):

116-134. http://dx.doi.org/10.1080/13600834.2017.1301036.

Schneier, Bruce. 1996. Applied Cryptography, Second Edition: Protocols, Algorthms, and Source

Code in C (cloth). 01 01. Accessed 11 03, 2017.

https://mrajacse.files.wordpress.com/2012/01/applied-cryptography-2nd-ed-b-

schneier.pdf.

—. 2004. Schneier on Security. Counterpane Internet Security Inc. 08 19. Accessed 11 08, 2017.

https://www.schneier.com/essays/archives/2004/08/cryptanalysis_of_md5.html.

SCMP. 2018. Facebook competes with Google and Microsoft, hiring AI experts and reshuffling its

managemen. Janeiro 27. Accessed Janeiro 28, 2018.

http://www.scmp.com/lifestyle/article/2130673/facebook-competes-google-and-

microsoft-hiring-ai-experts-and-reshuffling.

Silva, Paula Costa e. 2003. A contratação automatizada. Vol. IV, em Direito da Sociedade da

Informação, de APDI, 289-306. Coimbra Editora.


67 | 69

—. 1999. “Transferencia electrónica de dados: a formacão dos contratos.” Direito da Sociedade

da Informac ão, 181 e ss.

Sousa, Luís Filipe Pires de. 2016. O Valor Probatório do Documento Eletrónico no Processo Civil.

Almedina.

Sousa, Miguel Teixeira de. 2008. "APTS: Alves Pereira & Teixeira de Sousa, RL." A transmissão

de actos escritos das partes por meios electrónicos em processo civil. Accessed 11 08, 2017.

http://www.alvespereira.com/wp-content/uploads/a-transmissao-de-actos-escritos-das-

partes-por-meios-electronicos-em-processo-civil.pdf.

Straight, Brian. 2018. Toyota introduces autonomous freight concept vehicle. Janeiro 10. Accessed

Janeiro 28, 2018. https://www.freightwaves.com/news/toyota-shows-autonomous-

freight-vehicle.

Szabo, Nick. 1996. Smart Contracts: Building Blocks for Digital Markets. Accessed Dezembro 14,

2017.

http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/L

OTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html.

—. 1997. The Idea of Smart Contracts. Accessed 11 03, 2017.

http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/L

OTwinterschool2006/szabo.best.vwh.net/idea.html.

Tapscott, Don, and Alex Tapscott. 2016. Blockchain Revolution. Nova Iorque: Penguin Random

House LLC.

Teles, Inocêncio Galvão. 2002. Manual dos contratos em geral : refundido e actualizado. 4ª Edição.

Coimbra: Coimbra Editora.

Thomas, Roger John Laugharne. 2017. "'Law Reform Now' in 21st Century Britain: Brexit and

Beyond." 6th Scarman Lecture. Gray's Inn: Disponível online em <https://s3-eu-west-

2.amazonaws.com/lawcom-prod-storage-11jsxou24uy7q/uploads/2017/06/lcj-speech-

scarman-lecture-20170626.pdf> (Obtido em: 28 de Janeiro de 2018).

Thulasiraman, K., and M. N. S. Swamy. 2011. "5.7 Acyclic Directed Graphs." In Graphs:

Theory and Algorithms, edited by David Wood, 118-119. John Wiley & Sons.

UNCITRAL. 2005. "Convenção das Nações Unidas sobre o Uso de Comunicações Electrónicas

em Contratos Internacionais." Novembro 23. Accessed Janeiro 15, 2017.

http://www.uncitral.org/pdf/english/texts/electcom/06-57452_Ebook.pdf.


68 | 69

United News of India. 2018. Blockchain-based healthcare setup 'Healthureum' launched. Janeiro

29. Accessed Janeiro 30, 2018. http://www.uniindia.com/blockchain-based-healthcare-

setup-healthureum-launched/india/news/1120879.html.

Upton, David M., and Andrew McAfee. 1996. "The Real Virtual Factory." Harvard Business

Review (July-August): 123-133.

Vasin, Pavel. 2014. BlackCoin’s Proof-of-Stake Protocol v2. Julho. Accessed Dezembro 27, 2017.

http://blackcoin.co/blackcoin-pos-protocol-v2-whitepaper.pdf.

Vicente, Dário Moura. 2003. Comércio electrónico e resposabilidade empresarial. Vol. IV, em

Direito da Sociedade da Informação, de APDI, 241-288. Coimbra Editora.

Walton, Steve V., and Ann S. Marucheck. 1997. "The Relationship Between EDI and Supplier

Reliability." International Journal of Purchasing and Materials Management Summer (33):

30-35.

Wehner, Mike. 2017. Facebook engineers panic, pull plug on AI after bots develop their own

language. Julho 31. Accessed Janeiro 28, 2018. http://bgr.com/2017/07/31/facebook-

ai-shutdown-language/.

Wellman, Michael P., Amy Greenwald, and Peter Stone. 2007. Autonomous Bidding Agents.

WeUse.Cash. 2017. Dumb Contracts and Smart Scripts. Agosto 15. Accessed Dezembro 14,

2017. http://weuse.cash/2017/08/15/dumb-contracts-and-smart-scripts/.

Wong, David D. 1999. "The Emerging Law of Electronic Agents: E-Commerce and Beyond..."

Suffolk University Law Review XXXIII: 83-106.

Wong, Joon Ian. 2017. Sweden’s blockchain-powered land registry is inching towards reality. Abril

3. Accessed Janeiro 30, 2018. https://qz.com/947064/sweden-is-turning-a-blockchain-

powered-land-registry-into-a-reality/.

Wong, Shun. 2005. The Encryption Technology of Automatic Teller Machine Networks. 04 02.

Accessed 11 03, 2017.

http://www4.ncsu.edu/~kksivara/sfwr4c03/projects/4c03projects/SFWong-Project.pdf.

Wooldridge, Michael, and Nicholas R. Jennings. 1995. "Intelligent agents: theory and practice."

The Knowledge Engineering Review 10 (2): 115-152.

Wurman, Peter R., Michael P. Wellman, and William E. Walsh. 1998. "The Michigan Internet

AuctionBot: A Con gurable Auction Server for Human and Software Agents." Second

International Conference on Autonomous Agents (Agents-98). Minneapolis. 301-308.


69 | 69

Young, Joseph. 2017. Julho 6. Accessed Janeiro 30, 2018.

https://cointelegraph.com/news/sweden-officially-started-using-blockchain-to-register-

land-and-properties.

Criptocontratação-Uma nova forma de contratação ......ledger technologies (como o blockchain e o...

Documents

Transcript of Criptocontratação-Uma nova forma de contratação ......ledger technologies (como o blockchain e o...