RGPD e alojamento na UE: a que devem as equipas atender nas ferramentas de programação

Quando uma empresa quer introduzir uma nova ferramenta de análise, o processo já está rodado: o encarregado da proteção de dados pergunta pelo contrato de subcontratação, alguém verifica a localização do servidor, a política de privacidade é completada. Na caixa de ferramentas do departamento de desenvolvimento, muitas vezes é diferente: um membro da equipa encontra uma ferramenta útil, cria uma conta, e três meses depois ela é parte silenciosa do dia a dia de trabalho. Esta desigualdade de tratamento não tem fundamento objetivo — também as ferramentas de programação tratam dados, e algumas mais do que os seus utilizadores imaginam.

Os serviços de teste são para isso um bom objeto de observação. Um serviço de capturas de ecrã, por exemplo, fotografa páginas web — e uma fotografia de uma página web contém tudo o que essa página mostra. Numa página pública de marketing isso não é crítico. Interessante torna-se nas margens: ambientes de staging preenchidos com cópias de dados reais de produção. Páginas que mostram comentários de utilizadores, avaliações ou fotografias de perfil. Endereços em cujos parâmetros de URL estão marcas de sessão ou identificadores. Quem entrega páginas dessas a um serviço externo transmite eventualmente dados pessoais — mesmo que na cabeça só se passe «estamos a testar o layout».

O RGPD arruma uma constelação dessas com clareza: a empresa que utiliza o serviço continua a ser responsável pelo tratamento dos dados; o serviço atua, em regra, como subcontratante. Esta repartição de papéis não é uma formalidade, mas tem uma consequência prática: é preciso um contrato de subcontratação nos termos do artigo 28.º — habitualmente como documento-padrão do fornecedor — e a responsabilidade por o tratamento ser lícito no seu conjunto não migra com os dados para o prestador de serviços. Fica na empresa.

A segunda pergunta-padrão é sobre o local do tratamento. Dentro da UE, o RGPD aplica-se diretamente; com fornecedores que tratam dados em países terceiros começa, pelo contrário, um capítulo de verificação próprio: decisões de adequação, cláusulas contratuais-tipo, avaliações de impacto das transferências. Para as transferências para os EUA existe, é certo, uma decisão de adequação, mas as suas antecessoras já foram derrubadas duas vezes em tribunal, e também o quadro atual continua a ser juridicamente contestado. Nada disto torna os serviços norte-americanos inutilizáveis — mas cada uma destas construções é trabalho de verificação que, com uma localização na UE, simplesmente não existe. O alojamento na UE é, nesse sentido, menos um selo de qualidade do que um atalho: torna a avaliação mais curta, não dispensável.

O ScanU, um serviço de testes de regressão visual e de capturas de ecrã em navegadores, presta-se aqui como exemplo concreto, porque o fornecedor torna explícita a localização dos dados: segundo as indicações do fornecedor, os dados são alojados em Frankfurt, e o serviço posiciona-se expressamente com o olhar no RGPD — pode ler-se na página inicial em português do ScanU. Para uma empresa alemã isso significa: a questão do país terceiro não se coloca à partida para o serviço central, e a verificação pode concentrar-se nos pontos habituais — contrato, prazos de conservação, apagamento, subcontratantes ulteriores.

E é precisamente aqui que cabe uma frase honesta, válida para qualquer fornecedor, também para o aqui considerado: as afirmações num site de produto são o ponto de partida da verificação, não o seu resultado. «Alojado em Frankfurt» e «orientado para o RGPD» são autodeclarações do fornecedor — quem quer usar o serviço para fins profissionais lê o contrato de subcontratação, verifica a lista de subcontratantes ulteriores e esclarece o que acontece aos dados em caso de rescisão. Um fornecedor que entrega tais documentos de bom grado faz com isso mais pela confiança do que qualquer fórmula de marketing; um em que eles não se encontram já respondeu à pergunta mais importante.

Quem lê pela primeira vez um contrato de subcontratação pode orientar-se por quatro pontos. Primeiro, o objeto: o contrato descreve em concreto que dados são tratados e com que finalidade, ou mantém-se genericamente intermutável? Segundo, as medidas técnicas e organizativas, quase sempre em anexo: constam ali indicações compreensíveis sobre encriptação, controlo de acessos e localização — ou lugares-comuns? Terceiro, a regulação sobre subcontratantes ulteriores: o cliente é informado das mudanças e pode opor-se? Quarto, a devolução e o apagamento dos dados no fim do contrato. Nenhuma destas perguntas pressupõe um curso de Direito — são perguntas de compreensão, a que qualquer pessoa com competência técnica consegue responder. E onde o contrato se cala, a pergunta dirigida ao fornecedor é o teste mais honesto da sua disponibilidade para informar.

Um ponto de verificação muitas vezes esquecido são os prazos de conservação — e, no entanto, são em matéria de proteção de dados um tema central, sob a palavra-chave minimização dos dados: os dados não devem ser mantidos por mais tempo do que a finalidade exige. Nos serviços de capturas de ecrã, a conservação do histórico de verificação determina quanto tempo as imagens das páginas próprias ficam alojadas no fornecedor. O ScanU escalona esse histórico por nível de preço — de três dias no plano gratuito, passando por 15 e 30 dias, até 90 dias no nível maior, como indicam os níveis de preço do ScanU. Notável nisto: do ponto de vista da proteção de dados, o nível mais pequeno é o mais parcimonioso. Quem precisa de historiais longos, por exemplo para delimitar regressões ao longo de meses, escolhe conscientemente o prazo mais longo — mas deve ser uma escolha consciente, não uma predefinição sobre a qual nunca ninguém refletiu.

Pelo menos tão importante como a verificação do fornecedor é o comportamento de utilização próprio — porque a medida de proteção de dados mais eficaz é não entregar de todo dados sensíveis ao serviço. Para os serviços de teste, isso significa em concreto: preencher os ambientes de verificação com dados de exemplo sintéticos em vez de cópias da base de dados de produção. Testar páginas públicas e layouts em vez de vistas com sessão iniciada e dados reais de clientes. Prestar atenção a que nos URL testados não estejam tokens de sessão nem identificadores pessoais. Estas regras custam pouco, valem para qualquer ferramenta baseada em URL — e desarmam a questão da proteção de dados de forma mais eficaz do que qualquer cláusula contratual.

O aspeto que essas regras de utilização podem ter cabe em três frases para o wiki da equipa. Primeira: ao serviço vão apenas endereços de páginas públicas ou de ambientes de staging com dados sintéticos — nunca vistas que mostrem dados reais de clientes. Segunda: antes de criar um novo projeto de verificação, o URL é uma vez conscientemente examinado nos seus parâmetros; tokens de sessão e identificadores pessoais não têm ali nada que fazer. Terceira: os relatórios partilhados são tratados como documentos internos — divulgação apenas aos envolvidos, ligações fora dos canais públicos. Regras dessas formulam-se em dez minutos e transmitem-se depressa no acolhimento de novas colegas e novos colegas. O seu valor está menos na letra do que no facto de o tema ter sido uma vez posto em palavras: os incidentes de proteção de dados na utilização de ferramentas raramente nascem de intenção — quase sempre da rotina, em que nunca ninguém fez a pergunta.

Também os relatórios partilhados merecem um pensamento. Os relatórios de verificação partilháveis são extremamente práticos para a colaboração — precisamente por isso deveria estar esclarecido quem pode abrir um relatório partilhado e durante quanto tempo ele fica disponível. Isto não é uma particularidade dos serviços de teste: para os relatórios vale o mesmo que para os documentos partilhados em qualquer ferramenta na nuvem. Um relatório que contém capturas de ecrã de uma página de produto ainda não publicada é material confidencial e deve ser tratado como tal.

Até onde deve ir a verificação? O próprio RGPD dá a resposta: com base no risco. Um serviço de capturas de ecrã que fotografa páginas públicas de marketing é outro calibre do que um software de processamento de salários com dados de vencimentos. Seria desproporcionado cobrir ambos com o mesmo questionário — mas igualmente errado não olhar de todo para o caso menor. Um meio-termo pragmático para as ferramentas de programação: esclarecer o papel (subcontratante?), recolher o contrato, anotar a localização dos dados e os subcontratantes ulteriores, fixar os prazos de conservação e de apagamento, formular regras de utilização para a equipa. Isso despacha-se em tempo razoável e cobre os deveres essenciais.

Percorrido no exemplo de um serviço de capturas de ecrã, este catálogo fica assim. Papel: o serviço trata os conteúdos das páginas transmitidos por conta da empresa — subcontratante, portanto, logo recolher e arquivar o contrato nos termos do artigo 28.º. Localização dos dados: consultar junto do fornecedor e anotar; no ScanU está indicada Frankfurt, com o que a verificação de país terceiro para o serviço central não se aplica. Subcontratantes ulteriores: retirar a lista da documentação contratual ou solicitá-la — também um fornecedor da UE pode recorrer a subprestadores, e só essa lista completa a cadeia. Prazos de conservação: o nível de preço escolhido determina durante quanto tempo o histórico de verificação e, com ele, as capturas de ecrã são mantidos; confrontar o prazo com a necessidade real e fundamentar a decisão numa frase. Apagamento: esclarecer o que acontece aos relatórios e historiais em caso de rescisão. Quem documenta estes cinco pontos numa página fez, para uma ferramenta desta classe de risco, o essencial — e tem ao mesmo tempo um modelo reutilizável na ferramenta seguinte. As respostas às perguntas típicas sobre o próprio serviço reúne-as o fornecedor nas perguntas mais frequentes sobre o ScanU.

A isso pertence também uma entrada no registo das atividades de tratamento — aquela documentação obrigatória em que uma empresa fixa que serviços tratam que dados e com que finalidade. Soa mais burocrático do que é: para uma ferramenta de programação são poucas linhas. O valor verdadeiro está noutro lado: quem escreve a entrada tem de ter respondido às perguntas. A documentação obriga à verificação que, de outro modo, se perde no dia a dia.

Uma objeção vinda da prática merece nisto uma resposta honesta: se a verificação se tornar demasiado pesada, ela não passa a acontecer com mais rigor, mas deixa de acontecer. Se entre «ferramenta encontrada» e «ferramenta aprovada» estiverem seis semanas e três responsabilidades, as programadoras e os programadores acabam por criar a conta a título privado — e de um serviço verificável nasce shadow IT, de que ninguém mais sabe. A consequência disto não é prescindir da verificação, mas adaptá-la ao risco: uma verificação curta, rápida e documentada para as ferramentas com pouca ligação a dados, a verificação completa para tudo o que se aproxime de dados de produção ou de sistemas de clientes. Uma equipa que sabe que a verificação curta demora poucos dias e acaba quase sempre com um sim não tem motivo para a contornar. A organização de proteção de dados mais sólida é, no fim, aquela cujo caminho oficial é mais rápido do que o desvio.

Fica o enquadramento geral. A escolha de ferramentas parcimoniosas em dados e alojadas de forma transparente não é uma subtileza jurídica, mas parte do cuidado profissional que as equipas consideram há muito evidente noutros pontos — ninguém operaria uma base de dados sem plano de cópias de segurança. O alojamento na UE, prazos de conservação claros e um contrato de subcontratação em condições são, nisto, três bons critérios entre vários, não um substituto da verificação própria: também um serviço alojado em Frankfurt pode estar mal configurado, ser mal utilizado ou preenchido com os dados errados. A responsabilidade por isso não é do fornecedor, mas da empresa que o utiliza.

A boa notícia para terminar: o esforço é único e comportável. Uma hora de verificação estruturada por ferramenta, uma entrada curta na documentação, duas regras de utilização para a equipa — mais do que isso não é preciso para a maioria das ferramentas de programação. Comparado com o esforço de ter de explicar a posteriori uma transmissão de dados irrefletida, é uma troca muito boa.