RGPD para software feito à medida em Portugal

O erro mais caro em proteção de dados num projeto de software é tratá-la como uma camada final, algo a "acrescentar" antes de entrar em produção. Não é. Metade dos requisitos do RGPD afeta o modelo de dados e a arquitetura, e alterar o modelo de dados depois de o sistema estar em uso implica migração, reteste e indisponibilidade.

Este texto lista o que deve entrar no âmbito desde o desenho, num software feito à medida em Portugal. É uma lista técnica, escrita para quem contrata e para quem constrói, e não substitui aconselhamento jurídico, que é indispensável antes de fechar decisões sobre categorias especiais de dados.

Os requisitos que viram código

Minimização. Recolher apenas o necessário para a finalidade declarada. Na prática, isto é uma revisão campo a campo do formulário: cada dado pedido ao utilizador tem de ter uma razão. Recolher "por precaução" é exatamente o que o princípio proíbe.

Base legal por finalidade. Consentimento, execução de contrato, obrigação legal, interesse legítimo, definidos por finalidade, não em bloco para o sistema inteiro. Quando a base é o consentimento, o sistema tem de registar quando foi dado, para quê, e permitir retirá-lo com a mesma facilidade.

Registo de acessos e alterações. Quem viu, quem alterou, quando e a que registo. Isto é uma tabela de auditoria e um conjunto de intercetores no código, trabalho real que tem de estar orçamentado.

Prazos de conservação. Cada categoria de dado precisa de um prazo e de um mecanismo automático de eliminação ou anonimização quando esse prazo expira. Guardar tudo indefinidamente não é uma posição neutra.

Direitos dos titulares como funcionalidade. Exportar todos os dados de uma pessoa num formato legível e eliminá-los têm de ser funções do sistema. Se a resposta a um pedido de titular for "alguém vai ao banco de dados fazer consultas manuais", o processo não é sustentável nem auditável.

Cifragem, acessos e ambientes. HTTPS obrigatório, base de dados e cópias de segurança cifradas, segredos fora do código-fonte. Cada pessoa com conta própria e perfil mínimo necessário, sem contas partilhadas. E dados reais de produção fora dos ambientes de desenvolvimento e teste, se forem precisos dados realistas, que sejam anonimizados.

Checklist para pôr na proposta

Uma proposta de software que trata dados pessoais e não menciona nenhum destes pontos ainda não olhou para o problema. Isso não a torna necessariamente má, torna-a incompleta, e o custo em falta vai aparecer depois.

O contrato de subcontratante

Na relação típica, a sua empresa é o responsável pelo tratamento e o fornecedor de software é subcontratante. O contrato entre ambos tem de definir, no mínimo:

• Objeto, duração, natureza e finalidade do tratamento.
• Categorias de dados e de titulares abrangidas.
• Obrigação de tratar dados apenas segundo instruções documentadas.
• Confidencialidade das pessoas envolvidas.
• Medidas técnicas e organizativas de segurança.
• Regras para subcontratação ulterior, alojamento, serviços terceiros, ferramentas.
• Apoio no cumprimento de pedidos de titulares e na notificação de violações.
• Devolução ou eliminação dos dados no fim do contrato.
• Disponibilidade de informação para auditoria.

Se o fornecedor estiver fora do Espaço Económico Europeu, acresce a necessidade de um mecanismo válido de transferência internacional, tipicamente cláusulas contratuais-tipo, acompanhadas de uma avaliação da transferência. Manter os dados alojados em infraestrutura na UE simplifica bastante este ponto, mesmo com a equipa de desenvolvimento fora.

Erros que aparecem com frequência

Consentimento usado como base legal para tudo. É a base mais frágil, porque pode ser retirada a qualquer momento. Para o núcleo de um sistema de gestão, a execução de contrato costuma ser a base adequada, mas a escolha é jurídica.

Registo de acessos que ninguém lê. Auditoria só serve se houver quem a consulte. Defina quem revê e com que frequência.

Cópias de segurança esquecidas. Se um titular pede eliminação e os dados continuam nas cópias por dois anos, o processo está incompleto.

Exportações informais. Uma folha de cálculo com dados pessoais enviada por email cria uma cópia fora de todo o controlo. O sistema deve oferecer o relatório de que a pessoa precisa, para que a extração informal deixe de ser necessária.

Tratar RGPD como documento. Uma política de privacidade no site não é conformidade. Conformidade é o que o sistema faz.

Onde parar e chamar um jurista

Este artigo cobre requisitos técnicos correntes. Há decisões que não devem ser tomadas a partir de um texto como este:

• Escolha da base legal para cada finalidade.
• Necessidade de encarregado de proteção de dados.
• Necessidade de avaliação de impacto sobre a proteção de dados.
• Tratamento de categorias especiais, saúde, biometria, dados de menores.
• Definição de prazos de conservação quando existem obrigações legais setoriais.
• Enquadramento de transferências internacionais.

Estas são decisões jurídicas com consequências reais. O papel de quem desenvolve é implementar corretamente o que foi decidido e alertar quando o pedido técnico não bate certo com o que foi declarado, não substituir a análise jurídica.

A Retti Tech tem sede no Brasil e trabalha com clientes em Portugal remotamente, construindo sistemas com estes requisitos no âmbito desde o desenho. Quando o projeto envolve dados pessoais de residentes na UE, a nossa posição é sempre a mesma: a arquitetura é da nossa responsabilidade, o enquadramento jurídico é validado por quem tem competência para o fazer.