Ir para o conteúdo
Legiscope
Menu
Proteção de dados

Exatidão dos dados: verificações e atualização preventiva

Controlos preventivos por campo, fonte e efeito no titular. Método de aplicação, exemplos preenchidos e critérios de verificação.

Também disponível em:Italiano·Svenska·Dansk·Suomi·Norsk

O princípio da exatidão exige que os dados pessoais sejam corretos e, quando necessário, atualizados em função das finalidades do tratamento. Para a organização, isso implica controlar a qualidade da informação antes de a utilizar e reagir quando descobre um erro. Não é suficiente disponibilizar um endereço para pedidos de retificação se os sistemas continuam a importar informação desatualizada todos os dias.

Este guia organiza controlos preventivos e de manutenção: origem, validação, atualização, propagação e análise de consequências. O resultado é uma ficha de controlo por conjunto de dados, com critérios de verificação e responsáveis. O procedimento para responder a um pedido individual é tratado separadamente no guia do direito de retificação do artigo 16.º.

Avaliar a exatidão em função da finalidade

O artigo 5.º, n.º 1, alínea d), do RGPD exige medidas adequadas para que dados inexatos, tendo em conta as finalidades, sejam apagados ou retificados sem demora. A expressão «quando necessário» torna importante distinguir um dado atual de um registo histórico.

Uma morada de entrega precisa de estar atualizada para uma encomenda futura. A morada que constava de um documento emitido há três anos pode precisar de ser preservada como facto histórico, com o seu contexto. Substituir indiscriminadamente todos os valores antigos pela morada atual pode tornar inexato o próprio histórico.

Por isso, defina campos e utilizações. «Morada atual», «morada de entrega desta encomenda» e «morada constante do documento original» não devem ser confundidos. A limitação das finalidades ajuda a perceber que informação se pretende representar e por que motivo uma atualização é necessária num sistema, mas não noutro.

Conhecer a origem e a autoridade de cada campo

Registe de onde vem a informação: pessoa titular, serviço interno, fornecedor, fonte pública ou inferência produzida pelo sistema. Inclua a data da recolha ou da última confirmação quando for relevante. Um valor sem origem pode parecer fiável apenas porque foi copiado repetidamente.

Uma empresa fictícia recebe contactos de clientes a partir do seu portal, de formulários em papel e de um ficheiro enviado por um parceiro. A integração dá prioridade ao ficheiro do parceiro, mesmo quando o próprio cliente já corrigiu o telefone no portal. O problema não é resolvido com nova limpeza manual: a regra de precedência volta a repor o número antigo.

A empresa decide que uma atualização confirmada pelo cliente no percurso autorizado prevalece para o contacto corrente. Mantém a origem do valor e impede que uma importação anterior o substitua sem revisão. Para os dados de faturação, define regras específicas de validação e de preservação dos documentos já emitidos. A decisão depende da função do campo, não de uma fonte universalmente considerada superior.

Distinguir formato válido de informação verdadeira

Um endereço eletrónico com formato correto pode pertencer a outra pessoa. Uma data dentro do intervalo permitido pode ter sido introduzida no campo errado. A validação técnica reduz erros de formato, mas não prova a identidade ou a atualidade do conteúdo.

Defina controlos proporcionados à consequência do erro. Confirmar um endereço para enviar uma comunicação corrente não precisa necessariamente do mesmo nível de prova que alterar um contacto utilizado para recuperar uma conta. Exigir documentos extensos para corrigir um lapso simples pode criar recolha excessiva e dificultar o exercício de direitos.

A minimização de dados deve acompanhar os controlos. Peça apenas a informação necessária para a verificação. Quando bastar confirmar um dado já conhecido por um percurso seguro, não acrescente por rotina uma cópia integral de um documento de identificação.

Nas interfaces, explique o que se pede, permita caracteres e formatos adequados e evite regras que obriguem a pessoa a inventar um valor para avançar. Um campo obrigatório sem opção apropriada pode produzir uma base aparentemente completa, mas materialmente incorreta.

Definir momentos de atualização

Escolha acontecimentos que justifiquem confirmar dados: nova encomenda, renovação de um serviço, alteração comunicada, devolução de correspondência ou utilização numa decisão importante. Não existe uma periodicidade única que torne todos os dados exatos.

No exemplo, a empresa confirma a morada antes de uma nova entrega e investiga mensagens devolvidas antes de voltar a usar o contacto para informação importante. Para dados provenientes do parceiro, regista a data da atualização e limita a reutilização de ficheiros antigos. Um contacto que nunca recebeu uma confirmação recente permanece com esse estado visível.

Distingua «não verificado» de «incorreto». O primeiro estado indica uma lacuna de evidência; o segundo corresponde a um erro identificado. Esta distinção evita apagar informação válida sem necessidade e impede que a falta de verificação seja apresentada como confirmação positiva.

Examinar opiniões, avaliações e inferências

Uma opinião registada sobre alguém pode ser um dado pessoal. O registo deve permitir compreender quem a formulou, quando, com que contexto e quais os factos utilizados. A discordância da pessoa não significa automaticamente que a opinião histórica deva ser substituída pela opinião contrária; também não permite tratar qualquer avaliação como imune à correção.

Separe o facto do juízo. Num exemplo fictício, uma avaliação refere «entregou três relatórios fora do prazo» e conclui «precisa de apoio na organização». Se um dos atrasos foi atribuído à pessoa errada, existe um elemento factual a verificar. Corrigir esse elemento pode exigir reconsiderar a avaliação e os usos posteriores. Uma simples nota de discordância pode não ser suficiente para resolver um erro factual demonstrado.

Se a divergência incide no juízo profissional, analise a finalidade, o contexto e a possibilidade de completar o registo com a posição da pessoa. A CNPD explica o direito a retificar dados inexatos e completar dados incompletos. Não existe uma resposta única de «manter sempre» ou «apagar sempre» para todas as avaliações contestadas.

A mesma cautela vale para inferências automáticas. Uma probabilidade não deve ser apresentada como facto certo. Se o sistema estima uma preferência, o campo e a explicação devem refletir que se trata de uma estimativa, com as limitações relevantes para a utilização pretendida.

Exemplo preenchido: correção que não deve desaparecer na importação

O cliente comunica no portal que o contacto telefónico mudou. O serviço valida a alteração pelo percurso previsto e atualiza a ficha principal. Na noite seguinte, uma importação do parceiro repõe o número anterior. Uma mensagem de entrega é então enviada a esse número.

A investigação identifica três falhas: a importação ignora a data de confirmação, o sistema não conserva a origem do campo e a plataforma de mensagens mantém uma cópia independente. A equipa decide corrigir o percurso completo, em vez de fechar o incidente após voltar a editar a ficha principal.

Componente Correção decidida Verificação preenchida
Ficha principal Valor confirmado no portal com data e origem Novo contacto aparece como atual
Importação Impedir substituição por fonte mais antiga sem revisão Reimportação controlada não repõe o valor anterior
Plataforma de mensagens Sincronizar atualização e remover contacto obsoleto do envio corrente Próxima mensagem usa o destinatário correto
Histórico Preservar evento de alteração com acesso limitado É possível explicar o que ocorreu sem expor todo o perfil
Equipa de suporte Instrução para analisar sistemas derivados Pedido não encerra enquanto houver propagação pendente

A empresa verifica também se a mensagem enviada ao número anterior continha dados pessoais e se é necessário avaliar uma violação. Um erro de exatidão pode gerar uma divulgação indevida, mas essa conclusão depende do conteúdo e dos factos. O procedimento de notificação de violações permite documentar essa análise separadamente.

Propagar correções sem criar nova exposição

Identifique destinatários, sistemas derivados e exportações relevantes. O artigo 19.º prevê comunicação de retificação, apagamento ou limitação a destinatários, salvo impossibilidade ou esforço desproporcionado, e informação sobre esses destinatários ao titular se o solicitar. A aplicação deve respeitar as condições do artigo, em vez de prometer que qualquer cópia externa será automaticamente modificada.

Quando o destinatário atua como subcontratante, as instruções e mecanismos de atualização devem ser coerentes com o contrato de subcontratação. Uma notificação genérica ao endereço comercial do fornecedor pode não chegar à equipa que mantém os dados. Defina o canal operacional e a confirmação esperada.

Não envie mais informação do que a necessária para localizar e corrigir o registo. Uma mensagem de retificação com uma folha completa de clientes pode criar uma exposição adicional. Use identificadores adequados, delimite o campo e proteja o percurso de comunicação.

Controlar bases antigas e duplicados

Dados antigos exigem triagem. Verifique se continuam necessários, se a finalidade atual corresponde à recolha e se existe informação suficiente para confiar nos campos utilizados. A política de conservação pode levar a eliminar dados que já não devem ser mantidos, evitando gastar recursos a atualizar informação sem finalidade atual.

Na deduplicação, não una perfis apenas porque partilham nome ou endereço. Pessoas diferentes podem ter características semelhantes; uma fusão incorreta pode associar dívidas, compras ou avaliações à pessoa errada. Defina critérios e encaminhe casos ambíguos para revisão adequada, preservando a possibilidade de desfazer uma associação incorreta.

Uma operação de limpeza deve ter âmbito, cópia de segurança quando adequada e verificação das consequências. Use uma amostra controlada para confirmar que a regra produz o efeito pretendido. Não confunda melhoria estatística da base com correção factual de cada pessoa abrangida.

Medir o processo e os efeitos dos erros

Escolha indicadores relacionados com o tratamento: atualizações que falham na sincronização, contactos devolvidos, erros repetidos da mesma fonte e tempo até corrigir sistemas derivados. Um indicador de «campos preenchidos» pode aumentar enquanto a informação se torna menos fiável, se os utilizadores forem obrigados a fornecer valores artificiais.

Quando os dados alimentam decisões automatizadas, identifique decisões potencialmente afetadas e o processo de reavaliação. Corrigir a fonte sem analisar um resultado já comunicado pode deixar a consequência do erro por resolver. Registe a versão dos dados e a regra utilizada de forma proporcional, para conseguir reconstruir a avaliação quando necessário.

O dossiê de responsabilidade pelo cumprimento deve reunir critérios, responsáveis e evidências suficientes para explicar os controlos. Não precisa de duplicar integralmente todas as bases pessoais. A informação útil é saber onde nasce o dado, quando foi confirmado, como se corrige e como a organização impede que o mesmo erro volte a circular.

Fontes verificadas em 8 de setembro de 2026.

L
Escrito por
Legiscope
Legiscope

Passe esta orientação à prática

Veja como o Legiscope liga registos de privacidade, fontes e trabalho sujeito a revisão.

Marcar uma demonstração personalizada
Continuar a ler

Artigos relacionados

01Proteção de dados

Anonimização de dados: técnicas e teste de reidentificação

Anonimizar dados exige demonstrar que o resultado já não permite identificar pessoas pelos meios razoavelmente suscetíveis de serem utilizados. Apagar nomes e números de identificação é apenas uma…

8 de setembro de 2026
02Proteção de dados

Artigo 12.º: comunicar com clareza e gerir pedidos de direitos

Uma pessoa deve conseguir perceber o que a organização faz com os seus dados e exercer os seus direitos sem atravessar um circuito desnecessariamente difícil. O artigo 12.º liga a clareza da…

8 de setembro de 2026
03Proteção de dados

BCR, cláusulas-tipo e DPF: comparar o âmbito das garantias

A escolha entre regras vinculativas aplicáveis às empresas, cláusulas contratuais-tipo e Data Privacy Framework depende do destinatário e do fluxo de dados. Estes mecanismos não têm o mesmo âmbito…

8 de setembro de 2026
04Proteção de dados

Biometria para assiduidade e acessos: avaliação em Portugal

Um leitor biométrico não deve ser escolhido apenas porque evita cartões esquecidos. A organização precisa de demonstrar por que o tratamento é necessário, quais os dados realmente utilizados e como…

8 de setembro de 2026
05Proteção de dados

Cartografia dos sistemas de informação: mapa de dados e dependências

A cartografia dos sistemas de informação mostra como a atividade depende de aplicações, dados, pessoas, equipamentos e prestadores. Um inventário de software é um ponto de partida, mas não explica…

8 de setembro de 2026
06Proteção de dados

Certificação para EPD: comparar formação jurídica e operacional

Uma certificação de EPD pode ajudar a demonstrar conhecimentos, mas a escolha deve começar pelas funções que a pessoa vai desempenhar e pelas competências que lhe faltam. Comprar a formação com o…

8 de setembro de 2026
07Proteção de dados

Cifragem de dados pessoais: escolher medidas e gerir chaves

A cifragem protege a confidencialidade de dados quando o mecanismo e as chaves são adequados ao risco. Para escolher uma medida, é preciso identificar quem poderá aceder ao conteúdo, em que momento e…

8 de setembro de 2026
08Proteção de dados

Cláusulas contratuais-tipo: escolher módulos e preencher anexos

As cláusulas contratuais-tipo para transferências internacionais só são úteis quando o contrato identifica o fluxo real: quem disponibiliza os dados, quem os recebe, em que qualidade, para que…

8 de setembro de 2026