Resposta curta: uma avaliação de impacto sobre a proteção de dados (AIPD) é o documento em que descreve uma operação de tratamento, demonstra que é necessária e proporcional, avalia os riscos para as pessoas cujos dados utiliza e regista as medidas que reduzem esses riscos. O Artigo 35.º do RGPD torna-a obrigatória onde o tratamento seja suscetível de resultar num risco elevado, e menciona o tratamento em larga escala de categorias especiais, que inclui dados de saúde, como um caso. Na prática, todas as aplicações de saúde com mais do que um punhado de utilizadores e todas as plataformas de dados de saúde precisam de uma, antes de o tratamento começar, revista quando o tratamento muda. O modelo abaixo segue o Artigo 35.º(7) e as diretrizes europeias; descarregue-o no final.
Quando é exigida
A Avaliação de Impacto sobre a Proteção de Dados (AIPD) é exigida ao abrigo do Artigo 35.º do RGPD sempre que o tratamento for suscetível de resultar num elevado risco, sendo o tratamento em larga escala de categorias especiais, como dados de saúde, mencionado como um gatilho automático. De acordo com os critérios do Comité Europeu para a Proteção de Dados (CEPD), uma aplicação de saúde cumpre geralmente vários requisitos (dados sensíveis, larga escala, pessoas vulneráveis), pelo que quase todas as aplicações de saúde necessitam de uma antes de o tratamento começar.
O Artigo 35.º(3) lista três gatilhos automáticos: elaboração de perfis sistemática e extensiva com efeitos significativos; tratamento em larga escala de categorias especiais (Artigo 9.º) ou de dados de natureza criminal; monitorização sistemática em larga escala de áreas acessíveis ao público. Os critérios do Comité Europeu para a Proteção de Dados (do anterior Grupo de Trabalho do Artigo 29.º) adicionam mais seis; se dois ou mais se aplicarem, faça uma AIPD: avaliação ou pontuação; decisões automatizadas com efeitos jurídicos ou efeitos semelhantes significativos; monitorização sistemática; dados sensíveis; larga escala; correspondência ou combinação de conjuntos de dados; dados sobre pessoas vulneráveis (pacientes contam); utilização inovadora da tecnologia; impedir as pessoas de exercerem um direito ou de utilizarem um serviço. Uma aplicação de saúde atinge tipicamente dados sensíveis, larga escala, pessoas vulneráveis e, muitas vezes, tecnologia inovadora. As autoridades nacionais também publicam listas de tratamentos que exigem sempre uma AIPD (Artigo 35.º(4)); a maioria inclui aplicações de saúde e dispositivos conectados.
A lista de verificação
Uma lista de verificação para a AIPD de uma aplicação de saúde segue os quatro elementos do Artigo 35.º(7) do RGPD: uma descrição do tratamento (finalidades, dados, intervenientes, tecnologia), uma avaliação da necessidade e proporcionalidade (base jurídica, minimização, direitos, subcontratantes, conservação), uma avaliação dos riscos para as pessoas cujos dados são utilizados e as medidas que abordam esses riscos, seguida de consulta, aprovação e revisão periódica.
1. Descrever o tratamento (Art. 35.º(7)(a))
- Finalidades, uma a uma: armazenamento dos registos da pessoa; partilha com uma clínica; lembretes; estatísticas anonimizadas; funcionalidades de IA.
- Categorias de dados por finalidade, com os dados de saúde marcados; fontes (a pessoa, clínicas, wearables, documentos); destinatários; conservação por categoria; transferências para fora da UE e o seu mecanismo.
- Atores: responsável(is) pelo tratamento, subcontratantes (hospedagem, análise, ferramentas de suporte, fornecedores de IA) com os seus contratos; o Encarregado da Proteção de Dados (EPD).
- Tecnologia: arquitetura, onde os dados residem, encriptação, identidade, registos. Um diagrama de fluxo de dados é a forma mais rápida de encontrar o que se esqueceu.
2. Necessidade e proporcionalidade (Art. 35.º(7)(b))
- Base jurídica ao abrigo do Artigo 6.º e da exceção do Artigo 9.º(2), por finalidade (Artigo 9.º do RGPD explicado).
- Minimização de dados: para cada elemento de dados, por que é necessário; o que decidiu não recolher.
- Informação às pessoas (Artigos 13.º-14.º) e como os direitos (acesso, retificação, apagamento, portabilidade, oposição, retirada do consentimento) são exercidos no produto, não por e-mail para o suporte.
- Subcontratantes: contratos ao abrigo do Artigo 28.º em vigor; subcontratantes listados; direitos de auditoria.
- Conservação e eliminação: períodos concretos e o mecanismo que os impõe.
3. Riscos para as pessoas (Art. 35.º(7)(c)) Avaliar a probabilidade e a gravidade para cada um dos três eventos clássicos, para cada finalidade:
- Acesso ilegítimo (violação, acesso interno, partilha excessiva, uma clínica a ver mais do que o aprovado);
- Modificação indesejada (dados incorretos num registo em que um médico confia, erros de sincronização, uma funcionalidade de IA a escrever no registo);
- Desaparecimento (perda de um registo de que a pessoa depende; roubo de conta; um fornecedor a encerrar atividades). Depois os específicos da saúde: reidentificação de estatísticas "anónimas"; inferência de condições a partir do comportamento; discriminação se os dados chegarem a seguradoras ou empregadores; danos com dados de crianças; dados de localização em torno de clínicas; SDKs de terceiros na aplicação a enviar dados para redes de publicidade (a constatação mais comum em auditorias regulamentares de aplicações de saúde).
4. Medidas (Art. 35.º(7)(d)) Para cada risco, o controlo e o risco residual: encriptação em repouso e em trânsito; autenticação forte; acesso limitado por consentimento e tempo, com registos que a pessoa pode ler; pseudonimização em análises e em registos; sem SDKs de publicidade ou rastreamento de terceiros; ambientes separados e dados sintéticos para desenvolvimento; cópias de segurança com restauração testada; revisão de fornecedores; resposta a incidentes com o prazo de 72 horas; práticas de desenvolvimento seguras; formação e confidencialidade do pessoal; exportação e eliminação de dados no produto; um "kill-switch" para integrações.
5. Consulta
- O parecer do EPD é registado (Art. 35.º(2)); as opiniões das pessoas ou dos seus representantes são solicitadas quando apropriado (Art. 35.º(9)), por exemplo, através de um painel de utilizadores ou de uma associação de pacientes.
- Se permanecer um risco residual elevado, consulte a autoridade de controlo antes do tratamento (Art. 36.º). A maioria das aplicações de saúde bem controladas não chega a este ponto; as plataformas que tratam dados para muitas clínicas, por vezes, sim.
6. Aprovação e revisão
- Aprovado pela gestão do responsável pelo tratamento; datado; versionado.
- Revisto quando as finalidades, os dados, a tecnologia ou os destinatários mudam, e pelo menos a cada um ou dois anos (Art. 35.º(11)).
Constatações típicas em AIPDs de aplicações de saúde
As constatações mais comuns nas AIPDs de aplicações de saúde incluem SDKs de análise e de reporte de falhas que recebem identificadores juntamente com o contexto de saúde, notificações push que revelam condições no ecrã de bloqueio, pessoal de apoio com acesso irrestrito à base de dados, cópias de segurança fora da UE, dados mantidos após o encerramento de uma conta, ecrãs de consentimento que agrupam finalidades e conjuntos de dados "anonimizados" que ainda identificam pessoas.
Cada uma destas constatações tem uma correção concreta, e a AIPD é o local onde essa correção é registada.
O modelo
O modelo de AIPD nesta página é um documento em Markdown preenchível para uma aplicação de saúde, estruturado em seis secções (descrição do tratamento, necessidade e proporcionalidade, riscos para as pessoas, medidas, consulta, aprovação e revisão) com uma tabela de riscos e uma tabela de medidas. Segue o Artigo 35.º(7) do RGPD e os critérios do CEPD, sendo uma estrutura inicial, não um aconselhamento jurídico.
Descarregue o modelo de AIPD. Pode ser importado para qualquer ferramenta de documentos; o seu Encarregado de Proteção de Dados (EPD) adapta-o.
Na Anpheros
A Anpheros mantém uma AIPD para Anpheros Daily e outra para Anpheros Platform como subcontratante, com a estrutura acima, e as escolhas que levaram a elas são visíveis no produto: consentimento por finalidade, acesso limitado e registado, sem SDKs de publicidade, hospedagem na UE, exportação e eliminação na aplicação. Ver Transparência de saúde.
Esta página explica a regulamentação para equipas de produto e engenharia. Não constitui aconselhamento jurídico; os textos ligados em Fontes são a autoridade, e o seu encarregado da proteção de dados, organismo notificado ou consultor decide para o seu caso. Última revisão: Outubro de 2026.
Páginas relacionadas
- Artigo 9.º do RGPD para dados de saúde
- Desidentificação de dados de saúde
- Quem viu o meu registo médico?
- Uma aplicação de saúde é um dispositivo médico?
- ISO 27001 vs ISO 27799
- Mapa da regulamentação de dados de saúde
Fontes
- Artigos 35.º e 36.º do RGPD, EUR-Lex
- Grupo de Trabalho do Artigo 29.º / CEPD: Diretrizes sobre AIPD (WP248 rev.01)
- CNIL: Metodologia e software de PIA
- ICO: Avaliações de impacto sobre a proteção de dados
- CEPD: diretrizes, recomendações e boas práticas
Perguntas frequentes
Preciso de uma AIPD para uma pequena aplicação com poucos utilizadores?
Se tratar dados de saúde, quase sempre sim: dados sensíveis mais pessoas vulneráveis já cumprem o teste de dois critérios, e várias listas nacionais mencionam explicitamente aplicações de saúde. A AIPD de uma pequena aplicação é simplesmente mais curta.
Quem escreve a AIPD?
O responsável pelo tratamento é responsável; na prática, o gestor de produto e o líder de engenharia escrevem-na com o conselho do EPD, porque conhecem os fluxos de dados. Terceirizar completamente a sua produção resulta num documento que ninguém consegue manter atualizado.
A AIPD tem de ser publicada?
Não. É um documento de responsabilização interno mostrado à autoridade de controlo a pedido. Muitas organizações publicam um resumo; o EHDS e algumas regras nacionais exigem transparência sobre determinados tratamentos.
Como é que uma AIPD difere de uma avaliação de risco ao abrigo da ISO 27001?
A avaliação ISO analisa os riscos para a organização; a AIPD analisa os riscos para as pessoas cujos dados são tratados. Partilham controlos e evidências, e um bom programa de segurança alimenta a secção de medidas da AIPD.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →