Porque é que a informação aos titulares deve corresponder ao esquema da base de dados

Este artigo começa com um texto jurídico, mas a origem do problema está no software. O sítio que mostra com mais rigor que dados uma organização recolhe é o esquema da base de dados da aplicação que usa. Se a informação aos titulares não corresponde a esse esquema, a correção deve muitas vezes começar pelo sistema e não pelo texto.

Quando reviso o aviso de proteção de dados de uma organização, a primeira coisa que faço não é lê-lo. É pegar nas categorias de dados que o aviso enumera e compará-las com o esquema da base de dados.

Essa comparação dá quase sempre o mesmo resultado: há campos que o aviso não menciona. Por vezes acontece o contrário, categorias que o aviso enumera mas que o sistema nunca chega a recolher. Ambos os casos apontam para o mesmo problema de fundo. O aviso foi elaborado a partir de um modelo, não de uma verificação real dos factos.

O dever não é elaborar um documento

O artigo 10.º da Lei 6698 exige que o responsável pelo tratamento, ao recolher dados pessoais, comunique determinados elementos: a sua identidade, a finalidade do tratamento, os destinatários a quem os dados serão transferidos e porquê, o método de recolha e a base jurídica, além dos direitos previstos no artigo 11.º.

O verbo-chave aqui é comunicar. O documento é um veículo; o dever consiste em dar informação exata. Um aviso que dá informação inexata é pior do que não ter aviso nenhum, porque a organização já fez uma declaração que não corresponde à realidade.

Por isso, redigir o aviso tem de vir depois do inventário, não antes. Uma organização com inventário escreve o aviso num dia. Uma sem inventário escreve-o sem saber realmente sobre o que está a escrever.

Os cinco erros que mais vejo

Há anos que vejo os mesmos erros, e nenhum deles resulta de falta de conhecimento jurídico.

Fundir o aviso e o consentimento expresso numa única caixa de verificação. O utilizador marca "li e aceito" e é considerado simultaneamente informado e a prestar consentimento. O aviso é uma comunicação, não algo que se aceita. Esta fusão enfraquece o carácter do consentimento como declaração de vontade autónoma.

Mostrar o aviso depois de a operação já estar concluída. O formulário é enviado e só depois surge um link para o aviso numa página de agradecimento. Nessa altura os dados já foram recolhidos.

Forçar um único aviso a cobrir todos os processos. Recrutamento, contacto com clientes, relação com fornecedores e visitas ao site são todos reunidos num só documento. O resultado é um aviso geral que não descreve com rigor nenhum deles.

Não indicar a base jurídica, ou enumerá-las todas de uma vez. Uma frase como "nos termos das condições previstas nos artigos 5.º e 6.º" não indica base jurídica nenhuma. Deve escrever-se aquela de que depende realmente cada tratamento concreto.

Não indicar o prazo de conservação. O Comunicado espera que isto conste da informação dada ao titular dos dados, e sem essa indicação o titular não tem forma de saber durante quanto tempo os seus dados serão conservados.

Como o aviso deve ser estruturado

Um bom aviso é redigido processo a processo. Não começa com "a nossa empresa trata os seus dados pessoais", começa com "quando preenche o formulário de contacto, são tratados os seguintes dados".

Elaborar uma tabela de quatro colunas para cada processo facilita muito acertar: categoria de dados, finalidade do tratamento, base jurídica, prazo de conservação. Com essa tabela pronta, o aviso praticamente se escreve sozinho, e quem o lê consegue encontrar o que procura.

A linguagem também importa. O Comunicado exige que a informação seja transmitida de forma clara, compreensível e simples. Na prática, vemos o contrário. Os avisos alongam-se, as frases tornam-se pesadas e o resultado deixa de se ler. Um aviso que ninguém lê não cumpre a sua função de comunicação. Simplificá-lo não é aqui uma questão de estilo, é o que o dever exige.

Manter o aviso atualizado

Um aviso de proteção de dados não é um documento que se escreve uma vez e se esquece. Quando se adiciona um novo campo, se começa a trabalhar com um novo fornecedor ou se introduz uma nova transferência, o aviso também precisa de ser atualizado.

A única forma sustentável de o conseguir é ligar a atualização ao próprio processo de desenvolvimento. Uma alteração que acrescenta um novo campo de dados pessoais ao modelo de dados deve desencadear também a atualização do inventário e do aviso. Sem essa ligação, o aviso afasta-se da realidade já no primeiro ano, sem que ninguém dê por isso.

Foi assim que construímos essa ligação no nosso próprio site. Quando adicionámos a funcionalidade de análise assistida por inteligência artificial, entrou ao mesmo tempo no aviso uma secção própria a explicar a transferência internacional. A funcionalidade não foi publicada sem ela. Deve ser essa a ordem.