Uma unidade partilhada com a senha certa dá-lhe acesso ao ficheiro. Não lhe dá prova de quem tinha realmente direito a esse ficheiro. Essa lacuna permanece silenciosa em segundo plano em cada contrato, cada sociedade, cada tabela de participações, até que alguém se vá embora, uma relação se deteriore, ou uma senha seja a única coisa que separa uma equipa de um registo de que precisa com urgência. Nessa altura, já é tarde para mudar a forma como o ficheiro foi guardado. Nunca foi mais do que custódia por conveniência, e conveniência não é prova.
O que é realmente a custódia por conveniência
O armazenamento na nuvem concede acesso a quem tiver as credenciais. Dropbox, Google Drive, uma pasta partilhada da empresa: nenhum deles pergunta se a pessoa que abre um ficheiro é realmente quem tem direito a ele. Perguntam apenas se a senha está correta. Na maior parte das vezes isso não é problema, porque na maior parte das vezes ninguém contesta nada. O problema surge exatamente nos momentos que uma equipa financeira ou jurídica não consegue planear: um sócio fundador sai a meio de um litígio e mantém as credenciais. A conta de um prestador de serviços continua ativa muito depois de o contrato terminar. Um contrato dissolvido deixa uma unidade partilhada sem proprietário claro, e dois antigos sócios acreditam, cada um, que lhes pertence. Um gestor de senhas falha, um colaborador sai sem entregar as credenciais, ou uma conta é simplesmente bloqueada após demasiadas tentativas falhadas, e de repente um escritório deixa de conseguir aceder a ficheiros que guarda há anos.
Nada disto é uma falha técnica. É exatamente para isso que o armazenamento na nuvem foi construído: conceder acesso com base na posse de uma credencial. Nunca foi construído para responder à pergunta "quem tem direito a isto", e tratá-lo como se respondesse é precisamente a lacuna que surge assim que um litígio torna essa pergunta importante.
O que muda quando a recuperação está ligada a uma identidade, não a uma sessão iniciada
O escrow no registo da Swiss Trust Layer funciona de forma diferente, porque parte de uma pergunta diferente. Antes de uma pessoa sequer conseguir aceder ao armazenamento em escrow ou subscrevê-lo, tem de concluir uma verificação de identidade completa, verificada por passaporte, a mesma verificação usada noutras partes do registo. A recuperação fica então ligada a essa pessoa verificada, não ao dispositivo ou ao navegador que estiver sessão iniciada nesse momento. Se as credenciais desaparecerem, a identidade não desaparece. Essa é a verdadeira mudança: de "quem tem a senha" para "quem o registo consegue verificar como sendo a pessoa certa", e é isso que torna o escrow um tipo de custódia diferente do que uma unidade partilhada alguma vez foi concebida para oferecer.
O próprio ficheiro é guardado na Suíça, independentemente de qualquer fornecedor de nuvem. Junta-se a tudo o que o registo já faz: um ficheiro selado com uma marca temporal qualificada, uma identidade verificada por trás, um código ISCC que identifica a obra sem a expor, e etiquetas de conteúdo onde se aplicam. Descrevemos o registo completo num artigo anterior, registe-se uma vez, leve a prova para todo o lado, e o escrow é a parte construída especificamente para o que acontece depois de um ficheiro ser selado: quem ainda consegue aceder-lhe, e em que condições, anos depois de a pessoa que o selou ter iniciado sessão pela primeira vez.
O que isto não promete
Vale a pena ser preciso sobre o que o escrow verificado por identidade cobre hoje. Quanto custa, e que plano se aplica a que conta, é uma conversa à parte, que este artigo não vai ter em seu lugar. O que podemos afirmar com clareza é a própria promessa de recuperação: a identidade pode ser reverificada, online ou pessoalmente através de um agente KYC, e o acesso a registos e a ficheiros colocados em escrow pode ser restaurado. É isso que o escrow faz, formulado com a precisão que conseguimos sustentar, sem acrescentar nada e sem prometer nada para além disso.
Onde isto realmente importa para o trabalho financeiro e jurídico
Pense nos ficheiros que uma equipa financeira ou jurídica acumula sem que ninguém planeie contestá-los, até que alguém o faça. Os registos de um contrato com um cliente que termina mal. Os documentos de apoio a uma linha da tabela de participações, redigidos por alguém que saiu do escritório dois anos antes de surgir um litígio. As provas de cessão de propriedade intelectual de um trabalho construído em conjunto, depois contestado quando a joint venture se dissolve. Os documentos fundadores de uma sociedade, guardados numa unidade que ambos os antigos sócios ainda conseguem tecnicamente abrir, sem que nenhum confie que o outro não alterou nada. Em cada um destes casos, a pergunta que acaba por ser feita não é "este ficheiro estava guardado algures em segurança". É: "consegue provar quem tinha direito a aceder-lhe, independentemente de quem tem hoje as credenciais." Uma unidade partilhada não consegue responder a essa pergunta. Um registo em escrow ligado a uma identidade verificada foi construído exatamente para isso. Para trabalho desta natureza, a nossa página dedicada a equipas jurídicas e de PI descreve como a selagem e o escrow se encaixam na prática probatória já existente de um escritório, sem a substituir.
Higiene de custódia, não uma solução pontual
Nada disto substitui os acordos subjacentes que determinam, em primeiro lugar, a quem pertence um ficheiro: cartas de contrato, cláusulas de cessão de propriedade intelectual, contratos de sociedade continuam a desempenhar esse papel. O que o escrow verificado por identidade acrescenta é uma forma de continuar a aceder ao próprio ficheiro depois de as pessoas, as senhas e a confiança mútua que antes mantinham unida uma unidade partilhada terem todas mudado. Não é uma decisão tomada uma única vez. É um hábito que vale a pena incorporar na forma como um escritório guarda os registos que um dia terá de defender, antes de o litígio ser a razão pela qual os procura.
