Resolução das Atividades — Segurança da Informação em Saúde (Turma A)
Este arquivo destina-se exclusivamente ao uso do professor. Ele contém as resoluções comentadas das três atividades da Turma A, com gabaritos detalhados, orientações pedagógicas, indicação dos erros mais frequentes cometidos pelos estudantes e dicas sobre como conduzir a discussão em sala.
Resolução da Atividade 1 — A Tríade CIA diante de incidentes reais
Gabarito comentado
A atividade solicita que o estudante analise cada incidente em três dimensões: identificação dos pilares violados da Tríade CIA, consequências clínicas e medidas preventivas. A resposta de alto desempenho deve ir além da mera nomeação dos pilares e demonstrar compreensão do encadeamento causal entre a vulnerabilidade explorada, o pilar comprometido e o dano clínico resultante.
Incidente 1 — Funcionário administrativo com acesso indevido a prontuários:
O pilar primariamente violado é a confidencialidade. O caso descreve um acesso sistemático e não autorizado a informações de pacientes por um agente interno que possuía credenciais legítimas para outras finalidades. O ponto conceitual central aqui é que confidencialidade não é apenas sobre impedir acesso de forasteiros — é sobre garantir que somente as pessoas com necessidade legítima, delimitada pela função que exercem, acessem determinado dado. Credenciais legítimas que permitem acesso além do escopo da função não protegem a confidencialidade; elas a violam.
O incidente não afeta nem a integridade nem a disponibilidade: os dados não foram modificados e os sistemas não foram interrompidos. A análise não deve atribuir impacto secundário a esses pilares sem evidência no enunciado, o que seria um erro de leitura. O impacto é unidimensional: violação pura de confidencialidade por insider threat — ameaça interna.
As consequências clínicas são de natureza discriminatória e social, não de risco imediato à vida. O repasse de informações diagnósticas a uma seguradora concorrente cria condições para que o plano de saúde tome decisões sobre cobertura com base em dados obtidos ilicitamente. Pacientes com diagnósticos de doenças crônicas, condições psiquiátricas ou patologias de alto custo podem ter apólices negadas, canceladas ou com prêmios majorados com base em informações que a seguradora não deveria ter. O dano, embora não imediato, é real, potencialmente irreversível e viola simultaneamente a proteção de dados e o sigilo médico.
As medidas preventivas que uma resposta de alto desempenho deve mencionar envolvem três eixos. O primeiro é o controle de acesso baseado em papéis (role-based access control — RBAC), pelo qual cada função no sistema de saúde tem acesso apenas aos registros estritamente necessários para o exercício daquela função. Um funcionário administrativo da área de faturamento, por exemplo, não teria acesso ao histórico clínico completo, apenas às informações de autorização de procedimentos. O segundo eixo é o monitoramento e análise de logs de acesso: sistemas de prontuário eletrônico devem registrar todos os acessos, e sistemas de detecção de anomalias devem identificar padrões suspeitos — como um funcionário que acessa prontuários de pacientes de outras especialidades em volume muito superior ao esperado para sua função. O terceiro eixo é a revisão periódica de privilégios de acesso: a função de um colaborador evolui ao longo do tempo e os acessos devem ser revisados regularmente para garantir que permissões não se acumulam além do necessário.
Incidente 2 — Bug em atualização de software causando troca de laudos:
O pilar primariamente violado é a integridade. Integridade significa que os dados são precisos, completos e correspondem à realidade clínica do paciente ao qual estão associados. Quando laudos de exames de coagulação são enviados com os valores de outro paciente, a informação registrada no sistema — e comunicada ao médico e ao paciente — é factualmente incorreta: ela existe, está disponível, mas não descreve a realidade do paciente em questão. Isso é uma violação de integridade por corrupção de dados, ainda que o mecanismo não tenha sido um ataque malicioso, mas uma falha técnica.
Há uma consequência secundária de privacidade — dados de um paciente foram inadvertidamente enviados no laudo de outro, o que configura exposição de informações sem autorização — mas o impacto primário e o mais clinicamente relevante é a integridade comprometida.
As consequências clínicas são as mais diretamente perigosas à vida dos três incidentes. Dois pacientes receberam doses erradas de anticoagulante com base em resultados que não eram deles. Dependendo da direção do erro — paciente com coagulação aumentada recebendo laudo de outro com coagulação diminuída, ou vice-versa — as consequências vão de eventos tromboembólicos a hemorragias. Anticoagulantes têm janela terapêutica estreita e dosagem baseada em resultados laboratoriais precisos é condição para segurança do tratamento. O intervalo de três dias entre o erro e a descoberta agravou o risco: as doses erradas foram administradas durante todo esse período.
As medidas preventivas envolvem três dimensões. A primeira é o processo de validação e teste de software antes da implantação em ambiente de produção: atualizações de sistemas críticos — como gestão de laudos em laboratório — devem passar por ambiente de homologação isolado, com testes específicos de integridade de dados e rastreabilidade de associação entre resultados e pacientes. A segunda é a existência de mecanismos de dupla verificação para resultados críticos: em exames cujo resultado impacta diretamente condutas terapêuticas de alto risco — anticoagulação, quimioterapia, imunossupressão — protocolos de confirmação manual ou digital da identidade do paciente antes do envio do laudo adicionam uma camada de proteção contra falhas sistêmicas. A terceira é a assinatura digital de laudos, que cria um registro imutável de que aquele resultado foi gerado naquele momento para aquele paciente, permitindo detecção posterior de qualquer alteração ou inconsistência.
Incidente 3 — Ransomware paralisando sistema regional de saúde:
O pilar primariamente violado é a disponibilidade. Ransomware é um tipo de ataque que criptografa dados e sistemas, tornando-os inacessíveis para os usuários legítimos até que um resgate seja pago. O sistema não foi corrompido no sentido de ter seus dados alterados (a integridade dos dados em si pode estar preservada nos servidores criptografados), e não houve acesso não autorizado a informações por terceiros (a confidencialidade não foi primariamente comprometida, embora em muitos ataques de ransomware modelos haja exfiltração de dados antes da criptografia). O impacto dominante é a interrupção total do acesso por 11 dias.
A disponibilidade no contexto da saúde não é uma métrica abstrata de desempenho — é um requisito de segurança do paciente. Médicos que não conseguem acessar o histórico clínico do paciente, a lista de medicamentos em uso, as alergias documentadas ou os resultados de exames anteriores tomam decisões clínicas sem informação. Em 11 dias de operação a 30% de capacidade, com atendimento manual, o risco de erros por ausência de informação — prescrição de medicamento ao qual o paciente é alérgico, não identificação de interação medicamentosa, falta de dados para triagem de risco — é substancialmente elevado.
As medidas preventivas mais relevantes são três. A primeira é a existência de backups offline e imutáveis: cópias de segurança que não estejam conectadas à rede do hospital não podem ser criptografadas pelo ransomware. Backups em nuvem com versionsamento imutável (write-once, read-many) são uma solução contemporânea para isso. A segunda é a segmentação de rede: se os sistemas clínicos, administrativos e de suporte estiverem em segmentos de rede isolados, a propagação lateral do ransomware — que é o mecanismo pelo qual um único ponto de entrada contamina toda a infraestrutura — é contida. Um ataque que afeta o sistema de agendamento não deveria conseguir acessar os servidores de prontuário por segmentação adequada. A terceira é um plano formal de resposta a incidentes cibernéticos, testado periodicamente com simulações de restauração de backup, para que a equipe saiba exatamente o que fazer nas primeiras horas de um ataque e consiga reduzir o tempo de inatividade de dias para horas.
Dicas de resolução para o professor
O erro mais frequente nesta atividade é a classificação superficial dos pilares: estudantes reconhecem o incidente mais “óbvio” — o ransomware como problema de disponibilidade — mas hesitam em classificar o incidente do funcionário como violação de confidencialidade quando as credenciais eram legítimas. A confusão decorre de associar “acesso com credenciais válidas” a “acesso autorizado”. O professor deve retomar a distinção do material: a autorização não é dada pela posse de credenciais, mas pelo escopo da função. Credenciais legítimas usadas fora do escopo são tão problemáticas quanto credenciais obtidas ilegalmente em termos de impacto à confidencialidade.
O Incidente 2 frequentemente gera respostas que atribuem a violação à disponibilidade, porque o estudante associa o erro a um problema técnico de sistema. O professor deve redirecionar: o sistema funcionou, os laudos foram enviados, os médicos os receberam e os usaram — mas eram incorretos. O problema não é que o sistema parou; o problema é que o sistema produziu dados errados. Isso é integridade, não disponibilidade.
Um segundo erro frequente é propor medidas preventivas genéricas — “investir em tecnologia”, “treinar os funcionários”, “fazer backups” — sem especificidade técnica ou conceitual. O professor deve insistir que medidas preventivas precisam ser conectadas ao vetor de ataque específico do incidente. Para o Incidente 1, a medida relevante é RBAC, não criptografia. Para o Incidente 2, a medida relevante é validação de software e verificação de integridade de dados, não controle de acesso.
Como explicar a resolução aos estudantes
A estratégia mais eficaz é iniciar a discussão do Incidente 1 com uma pergunta-teste: “se o funcionário tivesse compartilhado apenas o nome e o diagnóstico de um único paciente, e sem usar nenhum sistema — apenas de memória — ainda seria uma violação de segurança da informação?” A resposta afirmativa orienta o estudante a compreender que a Tríade CIA não se aplica apenas a sistemas técnicos, mas a qualquer fluxo de informação.
Para o Incidente 2, um exercício útil é pedir ao estudante que descreva o que o médico via na tela ao abrir o laudo: nome do paciente X, data de nascimento do paciente X, número de prontuário do paciente X — e valores de coagulação do paciente Y. A imagem concreta da discrepância torna a violação de integridade imediatamente intuitiva.
Para o Incidente 3, o professor pode complementar com a seguinte reflexão: se o hospital tivesse backups íntegros e restauráveis em quatro horas, o incidente de ransomware ainda seria grave, mas o impacto à disponibilidade teria duração completamente diferente. Isso demonstra que a medida preventiva relevante não é “não ser atacado” — é “reduzir o tempo de indisponibilidade quando o ataque ocorrer inevitavelmente”.
Resolução da Atividade 2 — LGPD no cotidiano médico
Gabarito comentado
A atividade exige análise jurídica fundamentada de cinco situações cotidianas do ambiente médico. Uma resposta de alto desempenho não apenas classifica cada situação como conforme ou violação, mas demonstra o raciocínio jurídico que conecta a prática descrita ao artigo ou princípio da LGPD violado ou observado, e propõe conduta alternativa concreta quando necessário.
Situação 1 — Foto de exame pelo celular pessoal enviada por WhatsApp pessoal:
A prática configura violação da LGPD. A análise deve percorrer dois vetores independentes de violação, ambos presentes na situação.
O primeiro vetor é o uso de canais e dispositivos sem controles institucionais de segurança. O Art. 46 da LGPD estabelece que os agentes de tratamento devem adotar medidas técnicas e administrativas aptas a proteger os dados pessoais. Fotografar dados de saúde com celular pessoal — que não está sob gestão institucional, pode não ter criptografia de armazenamento, pode não ter bloqueio de tela adequado, e sincroniza automaticamente com serviços de nuvem pessoal fora do controle do hospital — é a negação precisa do que o Art. 46 exige. O WhatsApp pessoal, similarmente, não oferece as garantias de segurança que uma plataforma de comunicação institucional certificada para dados de saúde deve oferecer.
O segundo vetor é a natureza dos dados tratados. Os dados de saúde são classificados como dados sensíveis pelo Art. 5, XI da LGPD, e seu tratamento está sujeito às condições mais restritivas do Art. 11. O compartilhamento de imagem contendo nome, data de nascimento e número de prontuário — dados diretamente identificáveis — com terceiro, ainda que colega de profissão, exige base legal específica e meio seguro. Consulta informal para segunda opinião não está elencada entre as bases legais do Art. 11.
A conduta alternativa correta mantém o objetivo legítimo — obter segunda opinião de especialista — mas por meios adequados. O hospital deve dispor de sistema institucional de comunicação segura para consultas entre profissionais, ou de plataforma de teleconsulta aprovada. Se não existir, a alternativa é descrever o caso clinicamente sem dados identificadores do paciente — apresentando as características clínicas e o achado de imagem sem nome, data de nascimento ou número de prontuário, preservando integralmente o propósito da consulta sem expor dados sensíveis.
Situação 2 — Familiar solicita prontuário completo por e-mail não criptografado com autorização verbal:
A prática configura violação da LGPD em dois planos que o professor deve distinguir na correção.
O primeiro plano é o da base legal para o compartilhamento. Dados sensíveis de saúde — e o histórico psiquiátrico e os exames de HIV do Art. 11 são exemplos paradigmáticos — exigem consentimento específico e destacado do titular (Art. 8, §1; Art. 11, I) ou outra base legal expressamente prevista. Autorização verbal de paciente não satisfaz o requisito de consentimento específico e destacado da LGPD, que pressupõe manifestação livre, informada e inequívoca (Art. 5, XII). A solicitação por familiar, sem instrumento formal de representação, acrescenta ainda a ausência de prova de que o próprio paciente autorizou o ato.
O segundo plano é o do meio utilizado. O Art. 46 exige proteção técnica adequada. E-mail não criptografado é transmitido em texto simples pela infraestrutura da internet, podendo ser interceptado em qualquer ponto do trajeto. Isso viola o dever de segurança no tratamento de dados, independentemente de a base legal para o compartilhamento existir ou não.
A conduta correta exige dois passos: obter autorização escrita, datada e assinada pelo próprio paciente — ou por representante legal com documentação formal — especificando quais dados podem ser compartilhados e com qual finalidade; e utilizar canal de comunicação seguro, preferencialmente entregando a documentação em ambiente presencial ou por sistema com criptografia ponta a ponta sob gestão institucional. Se a finalidade alegada é uso em disputa judicial, o Art. 11, II, f da LGPD prevê essa base legal para dados sensíveis, mas exige que o procedimento seja conduzido por autoridade competente, não por solicitação informal de familiar.
Situação 3 — Clínica oncológica compila base de dados interna para pesquisa de protocolos:
Esta situação admite conformidade condicionada, e o professor deve enfatizar que “potencialmente compatível” não significa “automaticamente permitido”. A análise deve mapear os requisitos que precisam ser satisfeitos para que a prática seja legal.
A coleta de dados de pacientes para pesquisa interna sobre protocolos de tratamento pode ser amparada pela base legal de pesquisa (Art. 11, II, c — tratamento necessário para realização de estudos por órgão de pesquisa, garantida, sempre que possível, a anonimização dos dados) ou por legítimo interesse do controlador (Art. 10), se devidamente fundamentado. O fato de a pesquisa ser interna e não ser publicada não a exclui dessas bases; pode, inclusive, facilitar o enquadramento, pois o risco de exposição pública é menor.
Entretanto, o uso do CPF na base de dados é o ponto crítico que uma resposta de alto desempenho deve identificar. O princípio da minimização de dados (Art. 6, III) exige que somente os dados estritamente necessários para a finalidade sejam coletados e processados. Para pesquisa interna sobre protocolos de quimioterapia, o CPF é um identificador excessivo — ele vincula o dado ao cidadão no universo inteiro dos registros estatais, muito além do necessário para identificar o paciente dentro da própria base interna da clínica. Um identificador interno pseudonimizado — como um número de registro gerado pela própria clínica — atende ao propósito de identificação interna sem expor o paciente ao risco adicional associado ao CPF. A clínica deve substituir o CPF por um identificador pseudonimizado e conduzir um Relatório de Impacto à Proteção de Dados Pessoais (RIPD, Art. 38), dado o volume e a sensibilidade dos dados envolvidos.
Situação 4 — Startup de saúde mental com consentimento genérico e compartilhamento futuro com seguradora:
Esta situação envolve múltiplas camadas de análise e configura violação da LGPD em pelo menos três dimensões distintas, que uma resposta de alto desempenho deve articular de forma integrada.
A primeira camada é a invalidade do consentimento. O Art. 8 da LGPD exige que o consentimento seja livre, informado e inequívoco. O Art. 5, XII define que consentimento é “manifestação livre, informada e inequívoca pela qual o titular concorda com o tratamento de seus dados pessoais para uma finalidade determinada”. A expressão “os dados poderão ser usados para melhorar os serviços” é o oposto de uma finalidade determinada. Ela é vaga ao ponto de não informar ao usuário o que, concretamente, será feito com seus dados. Consentimento obtido com base nessa linguagem não satisfaz os requisitos do Art. 8, e a startup não tem base legal válida para o tratamento pretendido.
A segunda camada é a incompatibilidade de finalidade. Mesmo que o consentimento inicial fosse válido para o uso em detecção de risco de crise, o compartilhamento com seguradora para precificação de apólices é uma finalidade nova, distinta e incompatível com a finalidade original pela qual os dados foram coletados. O Art. 6, I (princípio da finalidade) proíbe o tratamento de dados “de forma incompatível com as finalidades informadas ao titular”. Dados coletados com a finalidade de monitoramento de saúde mental para suporte clínico não podem ser redirecionados para uso atuarial por uma seguradora sem novo consentimento específico para essa finalidade.
A terceira camada é a questão da anonimização genuína. O material do módulo distingue dados anonimizados — que não permitem identificação do titular por nenhum meio razoável — de dados pseudonimizados, que ainda permitem reidentificação mediante uso de informação adicional. Perfis psicométricos detalhados, diários de humor com granularidade temporal e registros de sono constituem um conjunto de dados de alta dimensionalidade. Pesquisas em reidentificação demonstram que conjuntos de dados de saúde considerados “anonimizados” podem permitir reidentificação de indivíduos quando cruzados com outras bases de dados disponíveis. A startup não pode afirmar que os dados são anonimizados sem realizar uma avaliação formal de risco de reidentificação. Para uma seguradora que dispõe de múltiplas bases de dados dos seus segurados, o risco de reidentificação é real e juridicamente relevante.
A conduta correta exige reformulação completa: obter consentimento específico, destacado e informado para o compartilhamento com a seguradora; avaliar formalmente se os dados são genuinamente anonimizáveis para esse uso específico; e considerar se o compartilhamento com seguradora para precificação é compatível com a finalidade de saúde pela qual os dados foram originalmente coletados — o que provavelmente não é, dado que o Art. 11 restringe o uso de dados sensíveis de saúde a finalidades de prestação de serviços de saúde, proteção da vida, pesquisa e obrigações legais.
Situação 5 — Hospital público compartilha dados de tuberculose com Ministério da Saúde para vigilância epidemiológica:
A prática é compatível com a LGPD e, mais do que compatível, representa o cumprimento de uma obrigação legal. Uma resposta de alto desempenho deve identificar a base legal correta e demonstrar por que essa situação não configura violação, mesmo envolvendo dados sensíveis.
A notificação compulsória de doenças de notificação obrigatória no Brasil é estabelecida pela Lei 6.259/1975 e regulamentada pela Portaria GM/MS 217/2023, que lista a tuberculose entre as doenças de notificação compulsória. O tratamento de dados para cumprimento de obrigação legal ou regulatória pelo controlador encontra respaldo no Art. 11, II, b da LGPD. Adicionalmente, o Art. 11, II, e autoriza o tratamento de dados sensíveis sem consentimento do titular para fins de pesquisa em saúde pública, desde que observada a anonimização sempre que possível — o que, em vigilância epidemiológica ativa de doença infectocontagiosa, inclui dados identificadores necessários para o seguimento de casos e controle de contatos.
O ponto que distingue respostas boas de respostas superficiais é a observação de que a compatibilidade não é incondicional. O hospital deve verificar que a solicitação é formal, proveniente de autoridade competente (o Ministério da Saúde, não um particular), via canal oficial, e que os dados solicitados são os estritamente necessários para a finalidade epidemiológica. O princípio da minimização de dados (Art. 6, III) aplica-se mesmo quando a base legal é obrigação legal: compartilham-se os dados necessários, não todos os dados disponíveis do paciente.
Dicas de resolução para o professor
O erro mais disseminado nesta atividade é a crença de que o consentimento do paciente resolve qualquer questão de LGPD. Estudantes com frequência propõem como “conduta correta” para as situações 1 e 2 simplesmente “obter o consentimento do paciente”. O professor deve retomar que consentimento é apenas uma das dez bases legais do Art. 7 e uma das condições do Art. 11, e que sua validade depende de requisitos formais rigorosos que não se satisfazem com um assentimento verbal. Para dados sensíveis de saúde, o consentimento precisa ser específico, destacado e para finalidade determinada — não um salvo-conduto genérico.
A Situação 4 é a mais complexa e exige tempo de discussão proporcional. O professor deve conduzir a análise em etapas sequenciais: primeiro a validade do consentimento inicial, depois a questão de finalidade, depois o problema da anonimização. Tentar abordar as três camadas simultaneamente tende a produzir respostas que misturam os argumentos sem clareza analítica.
Na Situação 3, um erro específico é a conclusão precipitada de que “pesquisa interna não precisa de base legal”. O professor deve esclarecer que toda atividade de tratamento de dados — interna ou externa, publicada ou não — exige base legal. O que varia é qual base legal se aplica e quais salvaguardas devem ser observadas.
Como explicar a resolução aos estudantes
A estratégia mais produtiva para esta atividade é comparar as cinco situações em termos de qual dimensão da LGPD cada uma viola, usando uma representação visual. O professor pode construir uma tabela com as situações nas linhas e as dimensões de análise nas colunas (base legal, segurança técnica, finalidade, minimização, consentimento) e preenchê-la coletivamente com a turma. Isso torna visível que algumas situações violam múltiplas dimensões ao mesmo tempo — como a Situação 4 — enquanto outras têm uma violação mais localizada.
Para a Situação 5, o professor pode explorar a pergunta: “o que aconteceria se o médico se recusasse a compartilhar os dados alegando privacidade do paciente?” A resposta — que configuraria descumprimento de obrigação legal e prejudicaria a vigilância epidemiológica de uma doença infectocontagiosa de interesse coletivo — demonstra que a LGPD não foi criada para impedir o funcionamento dos sistemas de saúde pública, mas para regulamentá-lo de forma responsável.
Resolução da Atividade 3 — Privacy-by-design aplicado ao projeto de startup
Considerações gerais sobre a atividade
Esta atividade não tem gabarito fixo, pois cada grupo analisa a startup que desenvolveu ao longo do semestre — e os projetos são distintos. O papel do professor é avaliar a qualidade do raciocínio aplicado à situação específica do grupo, não a conformidade com uma resposta esperada. As orientações a seguir fornecem os critérios que distinguem respostas de alto desempenho de respostas mediocres, os padrões de erro mais comuns e uma estrutura para que o professor conduza o feedback de forma consistente entre os grupos.
Framework de avaliação
O framework está organizado em três dimensões que correspondem às três partes da atividade. Para cada dimensão, o professor deve avaliar se a resposta do grupo alcança o padrão de excelência ou se incorre nos padrões de mediocridade ou nos erros frequentes descritos.
Dimensão 1 — Mapeamento de dados:
Uma resposta de excelência identifica ao menos três categorias de dados distintas que o produto da startup coletaria, processa ou armazenaria, classificando cada uma corretamente como dados sensíveis nos termos do Art. 5, XI da LGPD (dados de saúde, dados biométricos, dados de origem racial ou étnica, dados de orientação sexual etc.) ou como dados pessoais não sensíveis. Para cada categoria, a resposta de excelência: indica a base legal do Art. 11 que justificaria o tratamento com argumentação — não apenas nomeando o inciso, mas explicando por que aquela base se aplica àquele dado naquele contexto específico do produto; e avalia genuinamente se o dado é estritamente necessário ou se poderia ser substituído por dado menos sensível ou por dado agregado ou anonimizado que atendesse à mesma finalidade funcional.
Uma resposta medíocre classifica os dados corretamente em termos de sensibilidade — o que demonstra memorização da lei — mas cita as bases legais sem argumentação (“usaremos consentimento”), não analisa a necessidade do dado e não cogita alternativas de minimização. A resposta medíocre trata a pergunta sobre base legal como se ela tivesse uma resposta única e óbvia, sem perceber que diferentes dados do mesmo produto podem ter bases legais distintas.
Um grupo que identifica apenas uma categoria de dados para um produto que obviamente coletaria múltiplos tipos de dados demonstrou análise superficial e deve receber orientação para revisitar a arquitetura do produto.
Dimensão 2 — Aplicação dos princípios de privacy-by-design:
Uma resposta de excelência seleciona ao menos quatro dos sete princípios e, para cada um, articula uma decisão de design concreta e específica ao produto. O critério central aqui é a especificidade: uma decisão de design de excelência descreve uma escolha de produto — arquitetural, de interface, de fluxo de dados ou de política de acesso — que decorre do princípio e que seria diferente se o princípio não fosse observado. Por exemplo, o princípio da privacidade como padrão não é satisfeito pela declaração “adotaremos as melhores práticas de privacidade”; é satisfeito por uma afirmação como “o produto terá coleta de dados desativada por padrão, e o usuário precisará optar ativamente por compartilhar dados de localização para receber a funcionalidade de recomendação contextual — e poderá reverter essa escolha a qualquer momento sem perder as funcionalidades principais do produto”.
Uma resposta medíocre reconhece os sete princípios corretamente — demonstra que o grupo leu o material — mas aplica cada um ao produto com frases que poderiam ser ditas de qualquer produto de qualquer empresa: “implementaremos criptografia”, “respeiteremos a privacidade dos usuários”, “faremos backups”. Essas afirmações não demonstram que o grupo pensou sobre como o princípio se traduz nas decisões específicas do seu produto. O professor deve devolver esse tipo de resposta com a pergunta: “o que, concretamente, no design do produto mudaria se vocês ignorassem esse princípio?”
O professor deve verificar também se o grupo aplicou os princípios de forma integrada ou apenas justapostos. Respostas de excelência mostram como os princípios se relacionam entre si no contexto do produto — por exemplo, que a privacidade proativa (primeiro princípio) implica que a análise dos demais princípios deve acontecer antes do desenvolvimento, não como revisão posterior.
Dimensão 3 — Plano de conformidade com três requisitos prioritários:
Uma resposta de excelência identifica três requisitos que sejam realmente prioritários para aquele produto específico — não os três primeiros que vieram à mente, mas os três que, se não satisfeitos, criariam os maiores riscos para os usuários ou para a viabilidade legal da startup. Para cada requisito, a resposta de excelência: cita o artigo da LGPD ou o princípio de security-by-design que o fundamenta com precisão; descreve a consequência concreta da ausência do requisito — tanto para os usuários (que tipo de dano, com que probabilidade) quanto para a startup (sanção administrativa, responsabilização civil, perda de confiança dos usuários); e especifica o que seria necessário implementar tecnicamente, com nível de detalhe suficiente para que um desenvolvedor pudesse entender o requisito — não “usar criptografia”, mas “criptografar o armazenamento local no dispositivo do usuário com chave derivada da senha do usuário (não armazenada no servidor), de modo que perda do dispositivo não implique exposição dos dados”.
Uma resposta medíocre apresenta requisitos genéricos que se aplicam a qualquer produto digital (“ter política de privacidade”, “usar HTTPS”, “obter consentimento dos usuários”), sem análise das consequências específicas da ausência e sem especificidade técnica. O professor deve orientar o grupo a se perguntar: “se nossa startup fosse auditada pela ANPD (Autoridade Nacional de Proteção de Dados) no dia do lançamento, quais seriam as três exigências mais prováveis de serem levantadas, dada a natureza dos dados que coletamos?”
Erros frequentes
O erro mais disseminado nesta atividade — e que o professor deve antecipar e corrigir explicitamente durante a apresentação dos grupos — é tratar o consentimento do usuário como resposta universal para qualquer questão de LGPD. Grupos frequentemente concluem que, obtendo consentimento do usuário, qualquer tratamento de dados fica automaticamente legitimado. Essa interpretação é incorreta por razões que o material do módulo explica, mas que merecem reforço na correção.
O consentimento para dados sensíveis de saúde deve ser específico, informado e destacado — não um clique em “aceitar os termos de uso” em tela de login. Deve ser revogável a qualquer momento sem prejuízo ao serviço. E, mais importante, consentimento não é a única nem necessariamente a mais adequada base legal para dados de saúde: em muitos contextos clínicos, a base legal de tutela da saúde (Art. 11, II, f) ou de legítimo interesse (Art. 10) é mais robusta e menos dependente das vicissitudes do consentimento revogável. Um produto de saúde construído sobre consentimento como única base legal é vulnerável a qualquer revogação em massa pelos usuários.
O segundo erro frequente é a aplicação dos princípios de privacy-by-design como checklist de conformidade, não como filosofia de design. Grupos que percorrem os sete princípios em sequência e associam um item técnico a cada um — “criptografia para proatividade”, “autenticação de dois fatores para segurança embarcada” — demonstram que entenderam os rótulos dos princípios, não o seu sentido. O professor deve orientar que privacy-by-design não é uma lista de medidas técnicas; é uma forma de raciocinar sobre o produto antes de cada decisão de design: “essa decisão expõe mais dados do que o necessário? Existe uma alternativa que atinja o mesmo objetivo com menor impacto à privacidade?”
O terceiro erro frequente ocorre especificamente nos projetos cujo produto coleta dados biométricos ou dados comportamentais de alta granularidade — como aplicativos de monitoramento contínuo de saúde, wearables ou plataformas de saúde mental. Esses grupos tendem a subestimar o risco de reidentificação em dados aparentemente anonimizados. O professor deve estimular a reflexão: “se alguém tiver acesso à sua base de dados ‘anonimizada’, conseguiria saber que aquele perfil com padrão de sono específico, histórico de humor e pontuação psicométrica particular é de um usuário específico que conhece?” A resposta honesta para muitos perfis de alta granularidade é sim, e isso tem implicações diretas para a afirmação de que os dados são genuinamente anonimizados.
Como conduzir o feedback com os grupos
O formato mais produtivo para a discussão desta atividade em sala é a apresentação curta de cada grupo — cinco minutos — seguida de questionamento estruturado do professor. O professor deve fazer ao menos uma pergunta de especificidade para cada dimensão: na dimensão de mapeamento, “por que vocês escolheram essa base legal para esse dado específico, e não outra?”; na dimensão de privacy-by-design, “o que mudaria no design do produto se vocês removessem esse princípio?”; na dimensão de conformidade, “qual seria o primeiro sinal concreto de que esse requisito não está sendo satisfeito?”.
O professor também deve identificar grupos que, ao apresentarem a análise de privacy-by-design, descreveram decisões que já deveriam ter sido incorporadas ao produto no módulo anterior — o que indica que o grupo não pensou em privacidade durante o desenvolvimento do produto, mas retroativamente para satisfazer a atividade. Esse é exatamente o oposto do que privacy-by-design preconiza, e o professor pode usar esse momento como oportunidade pedagógica: “o que essa análise revela sobre o processo de design de vocês ao longo do semestre? O que precisaria ser modificado no produto para que essas decisões fossem genuinamente de design, não de remediação?”
Para grupos cujos produtos coletam dados de pacientes reais ou de usuários vulneráveis — como crianças, idosos ou pacientes psiquiátricos — o professor deve dedicar atenção especial à análise de consentimento e representação. A LGPD prevê regras específicas para dados de menores de 18 anos (Art. 14) e para situações em que o titular não tem capacidade plena de dar consentimento válido. Grupos que projetaram produtos para esses públicos devem ser estimulados a discutir como garantiriam a validade do consentimento nessas condições específicas.