Capturas de ecrã e dados pessoais em bases de conhecimento
As bases de conhecimento internas — Confluence, Notion, SharePoint, GitBook — acumulam um tipo específico de problema com dados pessoais que as ferramentas de conformidade padrão não detetam: dados pessoais de clientes incorporados em capturas de ecrã usadas para documentar processos.
O padrão repete-se em milhares de equipas de suporte e operações.
Um agente de suporte encontra uma configuração de conta incomum. Tira uma captura de ecrã da página da conta do cliente para documentar o problema. A captura mostra o nome do cliente no cabeçalho da interface, o seu e-mail nas definições de conta e os detalhes do plano.
O artigo é publicado na base de conhecimento interna. Cento e cinquenta agentes de suporte podem agora consultá-lo. Doze prestadores de serviços do helpdesk externo também. O artigo é útil. Mostra como tratar esse caso especial. Qualquer agente que encontre essa configuração no futuro irá lê-lo.
Três anos depois, a base de conhecimento tem 847 artigos deste tipo. Cada um contém capturas de ecrã de contas de clientes. Os clientes mostrados não deram consentimento para esta utilização secundária dos seus dados. A maioria não sabe que os seus dados estão armazenados ali.
Não é um problema menor. Cresce com cada novo artigo.
Riscos do RGPD: porque é importante
A análise do RGPD para capturas de ecrã em bases de conhecimento é direta.
Minimização de dados (Artigo 5.º(1)(c)): Os dados pessoais devem ser «adequados, pertinentes e limitados ao que é necessário». Um artigo sobre configuração de conta não precisa do nome real nem do e-mail do cliente. Uma captura com dados ocultados serve o propósito igualmente bem. Incluir dados reais do cliente não é necessário.
Limitação das finalidades (Artigo 5.º(1)(b)): Os dados recolhidos para uma finalidade — serviço ao cliente — não podem ser reutilizados para outra — documentação interna de processos — sem base jurídica. Os dados de conta foram recolhidos para prestação de serviço, não para artigos internos. São duas finalidades distintas. Usar os mesmos dados para ambas requer uma base legal que a maioria das equipas não estabeleceu.
Controlo de acessos (Artigo 5.º(1)(f) e Artigo 32.º): Medidas técnicas adequadas devem proteger os dados pessoais. Capturas de contas de clientes numa ferramenta acessível a 150 agentes e prestadores — incluindo os sem acesso ao sistema de contas — representam um acesso demasiado amplo.
Direito ao apagamento (Artigo 17.º): Um titular de dados que solicite o apagamento tem o direito de ver os seus dados removidos «sem demora injustificada». Se os seus dados aparecem em 23 artigos como capturas incorporadas, o pedido exige encontrar e atualizar os 23 artigos. Isso é difícil sem um sistema. O nosso guia sobre o direito ao apagamento do RGPD detalha os passos.
Não são interpretações de casos-limite. São aplicações diretas do texto regulatório a uma prática comum.
O contorno dos controlos de acesso
O problema de conformidade mais grave com capturas de ecrã no Confluence é o contorno dos controlos de acesso que criam.
As equipas de suporte usam controlo de acesso baseado em funções (RBAC) para limitar quem pode ver os sistemas de contas de clientes. Os agentes de nível 1 veem dados básicos. Os de nível 2 veem dados de faturação e técnicos. Os gestores veem o perfil completo.
Quando um agente de nível 2 cria um artigo com uma captura da conta completa do cliente, essa captura fica visível para todos os utilizadores da ferramenta. Os agentes de nível 1 que não deveriam ver dados de faturação podem agora vê-los. Os prestadores sem acesso ao sistema também. Os novos colaboradores em integração também.
A captura contorna os controlos RBAC do sistema de contas. Os dados pessoais que o RBAC devia proteger estão agora acessíveis a todos.
Não é um risco teórico. É o resultado normal do fluxo de trabalho de documentação. A captura fica ali sem data de expiração, sem registo de acesso e sem trilha de auditoria.
Passos práticos de remediação
Para equipas que descobrem este problema durante uma auditoria ao RGPD:
Remediação retroativa:
- Identificar todas as páginas da base de conhecimento com anexos de imagens
- Executar deteção de dados pessoais em cada anexo
- Rever as imagens sinalizadas: as deteções de alta confiança vão para a fila de revisão
- Para cada imagem sinalizada: substituir por uma versão limpa ou restringir o acesso à página
- Registar as ações para os registos do RGPD
A escala do trabalho retroativo depende do tamanho da base. Para uma base de três anos numa equipa de suporte de 50 pessoas, o número de imagens pode chegar a milhares. O processamento em lote torna isso viável. A revisão humana das imagens sinalizadas é o principal estrangulamento.
Controlos prospetivos:
- Formar todos os membros da equipa de suporte para limpar capturas antes de publicar
- Fornecer ferramentas: ferramentas de anotação de capturas que ocultam nomes de clientes antes de colar
- Adicionar um passo de revisão: um revisor designado verifica os artigos antes de publicar, procurando especificamente dados pessoais de clientes nas imagens
- Executar uma verificação trimestral de todos os anexos do Confluence
Controlo mínimo viável: Uma lista de verificação de publicação: «Remover ou ocultar todos os nomes, e-mails e IDs de conta nas capturas antes de publicar». Simples, não automatizado, mas cria um controlo documentado. Para equipas pequenas, este é o ponto de partida.
Consulte a nossa visão geral de conformidade com o RGPD para o enquadramento jurídico mais amplo, e por que a política sem controlos técnicos falha para perceber por que as abordagens apenas com listas de verificação falham em escala.
Por que o problema cresce com o tempo
Sem controlos sistemáticos, a exposição de dados pessoais na base de conhecimento acumula-se.
Volume: Cada novo artigo com uma captura de cliente aumenta a exposição total. À medida que a equipa de suporte cresce e a base de conhecimento se expande, os dados pessoais acumulados também crescem. As propriedades que tornam estas ferramentas úteis — facilidade de publicação, permanência, acesso amplo — são o que agrava o problema.
Artigos esquecidos: Os artigos sobre casos antigos que já não ocorrem permanecem acessíveis. Contêm dados de clientes que entretanto submeteram pedidos de apagamento. Ninguém verifica um artigo atualizado pela última vez em 2022.
Difusão entre equipas: As bases de conhecimento tornam-se frequentemente transversais. Um artigo de suporte com capturas de clientes pode ser partilhado com a equipa de produto, de engenharia ou prestadores externos como contexto de um pedido de funcionalidade ou relatório de erro. Cada partilha alarga a audiência dos dados pessoais.
Acumulação de pedidos de apagamento: Quanto mais dados de clientes se acumulam na base, mais complexo se torna responder aos pedidos de apagamento. Sem um sistema, não há forma fiável de confirmar que todas as instâncias dos dados de um titular foram encontradas e removidas.
Os dados pessoais em bases de conhecimento são mais fáceis de prevenir do que de remediar. Os controlos implementados agora evitam o problema de remediação que se agrava. Cada artigo publicado sem uma captura limpa é uma tarefa de remediação adiada para o futuro.