PIA e DPIA — fáceis de confundir

Quase nenhum projeto dispensa dados pessoais: um formulário de candidatura, a migração de um CRM, uma câmara no portão, um modelo treinado com pedidos de apoio ao cliente. Se isso prejudica alguém, raramente se vê de dentro do projeto — e as pessoas que sairiam prejudicadas não estão na sala. Uma avaliação de impacto põe a pergunta em cima da mesa antes de o tratamento começar, enquanto mudar o desenho ainda custa pouco.

Circulam dois nomes para esta avaliação, PIA e DPIA (esta última é, em português, a avaliação de impacto sobre a proteção de dados, ou AIPD), e muitas vezes são tomados por um só. Sobrepõem-se, mas não são a mesma coisa: uma é um método, a outra uma obrigação legal.

O que é uma PIA?

Uma avaliação de impacto sobre a privacidade (em inglês, privacy impact assessment, PIA) é um processo sistemático para identificar e avaliar os riscos que um projeto, um programa ou um sistema representa para a privacidade. Analisa a forma como a informação pessoal é recolhida, utilizada, divulgada, conservada e apagada, o que isso pode significar para as pessoas em causa e que medidas reduzem o risco a um nível defensável.

É o termo mais antigo e o mais amplo. Nos Estados Unidos, o E-Government Act de 2002 obriga as agências federais a realizar PIA; na maior parte dos outros países, uma PIA é uma boa prática, descrita na norma ISO/IEC 29134 e nas orientações de muitas autoridades de controlo. A forma, escolhe-a a organização.

O que é uma DPIA?

Uma avaliação de impacto sobre a proteção de dados (AIPD; em inglês, data protection impact assessment, DPIA) é a avaliação que o artigo 35.º do RGPD impõe sempre que um certo tipo de tratamento for «suscetível de implicar um elevado risco para os direitos e liberdades das pessoas singulares». O regulamento estabelece quando tem de ser realizada, o que tem de conter, pelo menos, e quem tem de ser consultado.

Em poucas palavras: uma AIPD é uma PIA com base jurídica — mais restrita no objeto, mais rigorosa na forma.

PIA vs DPIA: as diferenças num relance

No dia a dia, a fronteira é menos nítida do que no quadro. Muitas organizações dizem PIA e referem-se à avaliação do art. 35.º, e o mesmo fazem muitas ferramentas e modelos de relatório — a autoridade de controlo francesa, a CNIL, chama simplesmente «PIA» ao seu software para a AIPD. O que conta não é o nome na capa, mas se o conteúdo cumpre o que a lei exige.

A Complaica é um software DPMS com um Data Protection Kit pronto a usar: uma estrutura organizacional predefinida, a lista de atividades de tratamento para cumprir o art. 30.º, catálogos de ameaças e controlos e relatórios já preparados para o registo das atividades de tratamento e para a avaliação de impacto.

O que a PIA e a DPIA têm em comum

O método. Ambas percorrem as mesmas quatro fases, e ambas são um ciclo, não um documento que se escreve uma vez:

1. Contexto. Descrever o tratamento: que dados, de quem, para que finalidade, por que meios.
2. Controlos. Definir as medidas que asseguram o respeito pelos princípios fundamentais — necessidade, proporcionalidade, os direitos das pessoas em causa.
3. Riscos. Avaliar o que pode acontecer a essas pessoas, com que probabilidade e com que gravidade.
4. Validação. Decidir se o nível de proteção alcançado é aceitável e registar quem decidiu.

Em cada fase, há quatro coisas a esclarecer:

• as partes: responsável pelo tratamento, subcontratantes e titulares dos dados;
• a natureza e o âmbito dos dados;
• as finalidades do tratamento;
• os requisitos aplicáveis — do RGPD, de outra legislação ou de ambos.

Quando é que o RGPD exige uma DPIA?

Sempre que um certo tipo de tratamento, em particular que utilize novas tecnologias, for suscetível de implicar um elevado risco — é o que diz o art. 35.º, n.º 1. O art. 35.º, n.º 3, indica três casos em que é sempre assim:

• a avaliação sistemática e completa dos aspetos pessoais, baseada no tratamento automatizado, incluindo a definição de perfis, sendo com base nela adotadas decisões que produzem efeitos jurídicos ou que afetam a pessoa significativamente de forma similar;
• o tratamento em grande escala de categorias especiais de dados, ou de dados pessoais relacionados com condenações penais e infrações;
• o controlo sistemático de zonas acessíveis ao público em grande escala.

Para tudo o resto, existem as orientações do Grupo de Trabalho do Artigo 29.º (WP 248), que o Comité Europeu para a Proteção de Dados aprovou. Indicam nove critérios e, como regra prática, uma operação de tratamento que preencha dois deles exige uma AIPD:

• Avaliação ou classificação, incluindo a definição de perfis e a previsão — do desempenho profissional, da situação económica, da saúde, das preferências, do comportamento ou da localização.
• Decisões automatizadas com efeitos jurídicos ou que afetem significativamente de modo similar, e que podem levar à exclusão ou à discriminação.
• Controlo sistemático de pessoas, incluindo em zonas acessíveis ao público.
• Dados sensíveis: categorias especiais, como dados de saúde ou opiniões políticas, condenações penais e dados de natureza altamente pessoal.
• Tratamento em grande escala — medido pelo número de pessoas, pelo volume de dados, pela duração e pela dimensão geográfica.
• Estabelecer correspondências ou combinar conjuntos de dados provenientes de operações de tratamento diferentes.
• Titulares de dados vulneráveis: crianças, trabalhadores, doentes, idosos, requerentes de asilo.
• Utilização inovadora de tecnologia, como a combinação da impressão digital com o reconhecimento facial para o controlo de acessos.
• Tratamento que impede as pessoas de exercer um direito ou de utilizar um serviço ou um contrato.

A isto somam-se as listas nacionais. Nos termos do art. 35.º, n.º 4, cada autoridade de controlo torna pública a lista dos tipos de operações de tratamento para os quais a AIPD é obrigatória no seu país; nos termos do art. 35.º, n.º 5, pode também tornar pública a dos tipos para os quais não o é. As listas diferem, pelo que uma organização que opere em vários países tem de verificar cada uma delas. Os nossos especialistas em proteção de dados ajudam a apurar quais se aplicam.

O que uma AIPD tem de incluir, pelo menos, está fixado no art. 35.º, n.º 7:

• uma descrição sistemática das operações de tratamento previstas e da finalidade do tratamento, incluindo, se for caso disso, os interesses legítimos do responsável pelo tratamento;
• uma avaliação da necessidade e proporcionalidade das operações de tratamento em relação aos objetivos;
• uma avaliação dos riscos para os direitos e liberdades dos titulares dos dados;
• as medidas previstas para fazer face aos riscos — garantias, medidas de segurança e procedimentos destinados a assegurar a proteção dos dados pessoais e a demonstrar a conformidade com o regulamento.

Se a avaliação indicar que, apesar dessas medidas, subsistiria um elevado risco, o responsável pelo tratamento tem de consultar a autoridade de controlo antes de proceder ao tratamento (art. 36.º).

Quando se justifica uma PIA?

O lugar de uma PIA é no início do projeto, e ela acompanha-o ao longo de todo o ciclo de vida. As orientações do Office of Management and Budget dos EUA relativas ao E-Government Act (M-03-22) enumeram as ocasiões típicas para as agências federais, e estas valem para qualquer organização:

• registos em papel são convertidos em sistemas eletrónicos;
• informação anónima passa a poder ser atribuída a pessoas;
• um sistema informático existente passa a ser gerido de forma significativamente nova, por exemplo com novas tecnologias;
• bases de dados com informação pessoal são fundidas, centralizadas ou cruzadas;
• uma tecnologia de autenticação — palavras-passe, certificados digitais, biometria — é aplicada pela primeira vez a um sistema a que o público tem acesso;
• informação de fontes comerciais ou públicas é integrada em sistemas existentes;
• os dados são utilizados ou trocados de uma forma nova entre organizações;
• a alteração de um processo de negócio conduz a novas utilizações ou divulgações de informação;
• a uma recolha são acrescentados novos elementos de informação pessoal que aumentam o risco — dados de saúde ou financeiros, por exemplo.

Uma PIA ou DPIA em dez passos

Seja qual for a que está em causa, o trabalho segue a mesma sequência:

1. Reunir a informação. Recolher o que se sabe sobre o tratamento: descrição do projeto, fluxos de dados, sistemas, contratos.
2. Envolver quem sabe. Falar com os responsáveis das áreas de negócio, com a informática e a segurança, com o departamento jurídico e com o encarregado da proteção de dados.
3. Apurar os requisitos legais. Que leis, regulamentos e contratos se aplicam a este tratamento?
4. Avaliar a licitude e a necessidade. O tratamento é lícito, transparente, necessário e proporcionado à sua finalidade?
5. Identificar e hierarquizar os riscos. Onde estão as lacunas e o que significariam para as pessoas em causa?
6. Procurar aconselhamento externo, se necessário. Junto de especialistas externos — e da autoridade de controlo, quando a lei o exige.
7. Definir as medidas. Alterações técnicas, organizativas ou contratuais que reduzem o risco.
8. Fazer aprovar o resultado. As conclusões e o plano são aprovados por quem responde por eles.
9. Executar o plano. Com responsáveis e datas — uma medida que não tem dono não é executada.
10. Rever e atualizar. A intervalos fixos e sempre que mudar a forma como os dados são utilizados.

A sequência é um guia, não um formulário. Os projetos pequenos percorrem vários passos numa só reunião; os grandes repetem alguns mais do que uma vez.

Como preparar uma PIA

Preparar é reunir informação precisa sobre o tratamento. As agências federais dos EUA, por exemplo, registam em cada PIA realizada ao abrigo do E-Government Act:

• que informação é recolhida;
• porque é recolhida e para que vai ser utilizada;
• com quem é partilhada, dentro e fora da organização;
• como são informadas as pessoas e como é obtido o seu consentimento;
• como é protegida a informação.

Ninguém sabe tudo isto sozinho. A quem perguntar depende do objeto: se a avaliação incide sobre uma plataforma de marketing, a direção de marketing pode dizer que objetivos de negócio a plataforma serve — e a informática, que dados ela realmente movimenta.

Como preparar uma DPIA

Uma AIPD precisa dos mesmos factos e, além deles, do que o art. 35.º exige em particular. Ajuda ter o seguinte em cima da mesa antes de a avaliação começar:

• A proposta ou a descrição do projeto — dá o contexto de negócio.
• As pessoas em causa — clientes, trabalhadores, candidatos, doentes.
• As categorias de dados pessoais — dos dados de contacto ao comportamento em linha.
• Dados sensíveis — categorias especiais, ou dados como a localização exata.
• As fontes dos dados — criação de conta, cookies de rastreio, terceiros.
• O âmbito do tratamento — local ou internacional, com ou sem transferências para países terceiros.
• Os terceiros envolvidos — fornecedores, parceiros de negócio, outras áreas da empresa.
• Os avisos e as políticas de privacidade aplicáveis à atividade.
• As obrigações contratuais — o que os contratos da organização dizem sobre este tratamento.
• As medidas já existentes — as medidas técnicas e organizativas em que o tratamento se pode apoiar.

Muito disto já está escrito onde o registo das atividades de tratamento previsto no art. 30.º é mantido atualizado. Um registo bem cuidado é o melhor ponto de partida que uma AIPD pode ter.

PIA e DPIA com a Complaica

Uma avaliação guardada num documento de texto responde à pergunta uma vez. O tratamento muda e o documento não — e, na auditoria seguinte, ninguém sabe dizer que risco foi aceite, por quem e quando. É por isso que a avaliação deve ficar onde se gere o resto da proteção de dados.

A Complaica reúne DPMS e ISMS numa única ferramenta:

• Data Protection Kit. Uma estrutura organizacional típica predefinida, a lista de atividades de tratamento para cumprir o art. 30.º e catálogos de ameaças e controlos relevantes para a proteção de dados — adapta-os, em vez de começar com um sistema vazio.
• Relatórios para a auditoria. Relatórios já preparados para o registo das atividades de tratamento (art. 30.º) e para a avaliação de impacto (art. 35.º).
• Uma única gestão de risco. As medidas técnicas e organizativas do ISMS são reutilizadas na proteção de dados, e as ameaças idênticas gerem-se uma só vez.
• Assistente de IA. A Complaica suporta MCP e liga-se ao ChatGPT, ao Claude ou a um serviço de IA alojado localmente — para documentar estruturas em linguagem natural ou perguntar o que um requisito exige.
• Integrações. i-doit, GSTool, Jira, SAP, Office 365 e outros, ou os seus próprios sistemas através da REST API.
• Encarregado de proteção de dados externo. Como serviço, pelos nossos especialistas.

Conheça o software DPMS Complaica

Consultoria em proteção de dados

Quando falta o tempo ou a experiência para uma avaliação, entram os nossos especialistas em proteção de dados:

• DPMS como serviço. Ajudamos a identificar riscos, a desenvolver políticas e procedimentos e a melhorar continuamente o estado de segurança.
• Análise de proteção de dados. Analisamos os seus tratamentos de dados e identificamos os riscos potenciais.
• Implementação da proteção de dados. Desenvolvemos políticas e procedimentos adequados à sua empresa, implementamo-los e apoiamos a formação dos seus colaboradores.
• Monitorização da proteção de dados. Revisões regulares mantêm sempre atual o seu conceito de proteção de dados.
• Encarregado de proteção de dados externo. Os nossos especialistas acompanham a legislação em vigor, para que se mantenha em conformidade.
• Linha de apoio. Das 9h às 18h, para questões sobre segurança da informação e proteção de dados.