Como projetar sistemas de negócio que atendam aos requisitos de proteção de dados

A Lei de Proteção de Dados Pessoais B.E. 2562 (2019) se aplica a organizações que coletam, usam ou divulgam dados pessoais de pessoas na Tailândia. Ela distingue o controlador, que decide por que e como os dados são tratados, do operador, que realiza o tratamento em nome do controlador, e é supervisionada pelo Personal Data Protection Committee (PDPC). A lei estabelece as bases legais para o tratamento, os direitos dos titulares dos dados, as obrigações de segurança, os deveres de manutenção de registros e a exigência de notificação de violações.

Este guia é informativo e não constitui aconselhamento jurídico. A lei, seus regulamentos e as orientações do PDPC mudam com o tempo; o encarregado de proteção de dados ou a assessoria jurídica da sua organização deve confirmar como eles se aplicam a ela. O que segue é a visão de engenharia: quando a lei exige que a organização seja capaz de fazer algo, este guia descreve o que o sistema precisa ter para fazê-lo.

Quando o consentimento é a base, o sistema precisa ser capaz de mostrar que uma pessoa específica concordou com um uso específico, com uma redação específica, em um momento específico, e de que forma. Armazene um registro de consentimento com o identificador do titular dos dados, a finalidade, a versão do aviso ou do texto de consentimento que ele viu, a data e hora, o canal (formulário web, aplicativo, papel digitalizado, ligação) e qualquer evidência, como o ID do formulário. Guarde cada versão do texto de consentimento; um registro que aponta para um texto já reescrito não comprova nada.

A revogação deve ser tão fácil quanto dar o consentimento e deve ter efeito em todos os sistemas que agiram com base nele. Projete o consentimento como um estado central que os sistemas subsequentes (uma plataforma de marketing, um sistema de envio de newsletter, um pipeline de analytics) consultam no momento do uso, e não como um indicador copiado uma vez e esquecido. A newsletter do nosso próprio site é um pequeno exemplo desse padrão: double opt-in por e-mail, um link de descadastro em todas as mensagens e uma lista de supressão aplicada antes do envio.

O consentimento não é a base adequada para tudo. O tratamento dos dados de um funcionário para a folha de pagamento ou dos dados de um cliente para entregar uma compra se baseia em contrato ou obrigação legal; pedir consentimento nesses casos cria um direito de revogação que a organização não pode honrar. Quando a base é escolhida com precisão, os registros de consentimento se tornam menos numerosos e mais significativos.

A lei exige medidas de segurança adequadas. Em termos de sistema, isso começa pelo menor privilégio: acesso baseado em funções, em que cada função vê os campos de que seu trabalho precisa e nada além. Um modelo Proprietário/Administrador/Membro/Leitor é uma boa base para um workspace; as aplicações de negócio geralmente precisam de funções mais granulares, para que um operador de armazém veja os endereços de entrega, mas não os números de documento de identidade, e um atendente de suporte veja os quatro últimos dígitos de um cartão, mas nunca o número completo. O mascaramento em nível de campo, aplicado na camada da API para que nenhum cliente possa contorná-lo, vale o esforço para campos pessoais e sensíveis.

A minimização se aplica na coleta e em cada cópia. Colete apenas os campos de que uma finalidade precisa; não copie dados pessoais de produção para ambientes de teste e desenvolvimento, e gere ou anonimize dados de teste no lugar deles; restrinja exportações e downloads em massa às funções que precisam deles e registre cada um. Uma autenticação forte protege tudo isso: login único (SSO) com o provedor de identidade da organização, autenticação de dois fatores, chaves de acesso (passkeys) onde houver suporte e tempos limite de sessão proporcionais à sensibilidade dos dados.

Os operadores de que a organização depende (hospedagem, e-mail, analytics, serviços de IA) precisam de contratos que os vinculem aos mesmos padrões, e a arquitetura deve deixar claro quais dados pessoais fluem para cada um deles.

Os dados pessoais só podem ser mantidos pelo tempo que a finalidade exigir ou que uma lei determinar. Transforme isso em uma tabela de retenção por categoria de dados, com um prazo e uma justificativa legal ou de negócio: registros contábeis pelo período exigido pela legislação tributária, dados de candidatos a vagas por um tempo definido após a decisão, contas de clientes inativas após um período definido de inatividade, transcrições de chats de suporte após um prazo definido. Em seguida, automatize a tabela. Uma política de retenção que depende de alguém executar um script uma vez por ano não é um controle.

Defina como a exclusão funciona tecnicamente. A exclusão lógica (soft delete) torna os dados invisíveis, mas eles continuam lá; ela só é aceitável como um curto período de carência antes da exclusão definitiva ou da anonimização. A anonimização, que remove ou transforma de forma irreversível os identificadores preservando as estatísticas, permite que a organização mantenha o histórico do negócio sem manter as pessoas. Os backups precisam do mesmo tratamento: defina por quanto tempo eles são mantidos, confirme que estão criptografados e garanta que os dados restaurados passem pelas exclusões feitas depois que o backup foi gerado.

Os titulares dos dados podem perguntar quais dados a organização tem sobre eles, solicitar cópias e correções, pedir a exclusão, se opor ao tratamento ou restringi-lo e revogar o consentimento, e o controlador precisa agir dentro do prazo estabelecido pela lei e pelos regulamentos. O requisito para o sistema é permitir que um funcionário treinado atenda a essas solicitações sem ajuda da engenharia: localizar todos os registros de uma pessoa em todos os módulos, gerar uma exportação legível dos seus dados pessoais, corrigir um campo com um registro de auditoria e executar a exclusão ou a anonimização respeitando as regras de retenção que precisam ser cumpridas (uma fatura não pode ser excluída porque o cliente pediu a exclusão; ela pode ser mantida com uma base legal registrada).

Mantenha um registro das solicitações: quem pediu, quando, como a identidade foi verificada, o que foi feito e quando foi concluído. Esse registro demonstra a conformidade e mostra onde os processos estão lentos.

Um log de auditoria registra quem fez o quê, com quais dados e quando: logins, alterações de permissões, visualizações e exportações de dados pessoais, edições e exclusões, alterações de configuração. Ele deve ser gravado pela aplicação no momento da ação, armazenado separadamente dos dados de negócio, com acesso de gravação restrito, e mantido por um prazo definido de forma deliberada. Logs que ficam no mesmo banco de dados, com os mesmos administradores, não oferecem proteção contra uma ameaça interna.

Os logs precisam ser úteis, e não apenas existir: pesquisáveis por pessoa e por registro, revisados periodicamente e com alertas para padrões incomuns, como exportações em massa ou acessos fora do horário de trabalho. Os próprios logs de auditoria contêm dados pessoais e devem constar na tabela de retenção.

A lei exige que os controladores notifiquem o PDPC sobre uma violação de dados pessoais sem demora injustificada e, sempre que possível, em até 72 horas após tomarem conhecimento dela, a menos que seja improvável que a violação represente risco aos direitos e liberdades; quando o risco é alto, os titulares afetados também devem ser informados. Setenta e duas horas passam rápido. Do lado do sistema, estar preparado significa detectar, ou seja, ter registros e monitoramento capazes de revelar um acesso não autorizado, além da capacidade de determinar rapidamente quais dados foram afetados, de quem e em que período.

Do lado da organização, é preciso um processo de incidentes por escrito: quem é avisado primeiro, quem avalia o risco, quem redige a notificação, quem fala com os clientes, além de modelos preparados com antecedência em cada idioma em que a organização trabalha. Faça anualmente um exercício de simulação (tabletop) com um cenário realista, para que o runbook não seja usado pela primeira vez durante uma violação.