Clínica pode usar legítimo interesse para dados de saúde no formulário de agendamento?

cmsapointoo on August 16, 2026

Não. Uma clínica não deve usar o legítimo interesse do artigo 7º, IX da LGPD como base para tratar dados pessoais sensíveis de saúde num formulário de agendamento. Dados de saúde pertencem à categoria sensível definida pela lei, e seu tratamento precisa caber numa das hipóteses do artigo 11. Isso não significa que consentimento seja sempre obrigatório. O artigo 11 também prevê tratamentos sem consentimento quando as condições da hipótese escolhida forem atendidas.

A análise ocorre por campo e finalidade. Identificação, contato, horário, informação clínica e marketing não formam uma finalidade única por aparecerem na mesma tela. A clínica deve justificar cada tratamento, coletar somente o necessário e bloquear a reutilização automática em publicidade.

A resposta jurídica começa nos artigos 7º e 11

Lei: o artigo 7º reúne hipóteses para o tratamento de dados pessoais em geral e inclui, no inciso IX, o legítimo interesse do controlador ou de terceiro. O artigo 11 disciplina especificamente dados pessoais sensíveis. Quando o dado é de saúde, a pergunta não é se o legítimo interesse parece razoável. A pergunta é qual hipótese do artigo 11 cobre aquela finalidade e se suas condições estão presentes.

Orientação da ANPD: o Guia orientativo sobre legítimo interesse afirma expressamente que essa hipótese não se aplica a dados pessoais sensíveis. O guia também usa uma situação envolvendo clínica e informações de saúde para mostrar que a organização deve procurar uma hipótese do artigo 11, em vez de estender o artigo 7º, IX.

Uma avaliação de legítimo interesse não corrige a escolha errada de artigo. Ela pode ser pertinente a um tratamento separado de dado não sensível, mas não fundamenta o uso de sintomas, condições ou outra informação de saúde. A análise sobre base legal e Customer Match em saúde aplica a mesma separação.

Quando um campo do agendamento revela dado de saúde?

Lei: o artigo 5º, II inclui dado referente à saúde na definição de dado pessoal sensível quando ligado a uma pessoa natural. Um campo não precisa ter o rótulo “diagnóstico” para entrar nessa categoria. A combinação entre resposta, contexto e titular pode revelar que alguém procura determinada especialidade, exame, procedimento ou cuidado.

Nome, telefone e email são dados pessoais, mas isoladamente não são necessariamente dados de saúde. Motivo da consulta, condição, procedimento ou texto sobre sintomas pode revelar saúde diretamente. Uma escolha administrativa também pode fazê-lo quando identifica o serviço procurado.

Recomendação editorial: classifique o campo pelo que ele revela no fluxo real, não apenas por seu tipo técnico. Documente se o valor é necessário para localizar a pessoa, reservar um recurso, orientar atendimento ou fazer outra operação. Se uma categoria ampla atende à agenda, adie detalhes clínicos para um canal assistencial com acesso apropriado. O artigo sobre agendamento pediátrico e LGPD mostra a mesma disciplina de separar pessoa, campo e contexto.

Consentimento não é automaticamente obrigatório

Lei: o artigo 11, I permite o tratamento de dado sensível com consentimento específico e destacado para finalidades específicas. O inciso II também prevê hipóteses sem consentimento, desde que o tratamento seja indispensável e satisfaça a condição aplicável. Entre elas estão cumprimento de obrigação legal ou regulatória, proteção da vida, exercício regular de direitos e tutela da saúde nas condições descritas pela lei.

Essas hipóteses impedem duas respostas automáticas: exigir consentimento antes de qualquer pedido ou dizer que a atividade de saúde o dispensa em toda finalidade. O artigo 11 exige enquadramento concreto, com atores e limites próprios.

Orientação da ANPD: o guia não escolhe uma base universal para clínicas. Ele explica que legítimo interesse não pode ser usado para dado sensível e indica que o controlador deve avaliar consentimento ou outra hipótese do artigo 11 que corresponda ao caso. A decisão final precisa considerar o serviço, o papel da organização e a finalidade descrita.

Separe campo, finalidade e etapa do fluxo

Recomendação editorial: monte uma linha por tratamento, não por página. Um formulário pode localizar a pessoa, oferecer horários, recolher dado para triagem e pedir adesão a mensagens promocionais. Registre campos, finalidade, destinatários, retenção e hipótese analisada para cada operação.

Parte do fluxo Pergunta de finalidade Fronteira recomendada
Identificação e contato O que é necessário para responder e administrar o pedido? Limitar aos dados operacionais aprovados
Escolha de horário Qual informação permite reservar unidade, profissional ou recurso? Evitar detalhe clínico quando uma categoria ampla basta
Triagem Existe necessidade assistencial antes da confirmação? Usar etapa, equipe e acesso próprios
Marketing A clínica quer promover outro serviço? Não herdar dados ou base do agendamento

A separação entre origem do agendamento e origem de marketing ajuda a manter essa fronteira no modelo de dados. Ela evita que a aplicação trate uma origem operacional como autorização para novo uso.

Agendamento, triagem e marketing pedem decisões diferentes

Lei: os princípios do artigo 6º exigem finalidade, adequação e necessidade, entre outros. Uma justificativa ligada à prestação ou organização do atendimento não se estende sozinha a campanhas, criação de audiência ou análise promocional. A clínica deve descrever a finalidade de modo específico o suficiente para comparar o uso real com o uso informado.

Agendamento administra disponibilidade e contato. Triagem pode recolher informação necessária antes do atendimento, conforme o serviço. Marketing procura promover uma nova interação. Mesmo que a mesma pessoa participe das três etapas, mudar a finalidade muda a análise. O dado não perde seu caráter sensível quando é copiado para outra tabela, exportado ou resumido num rótulo.

Recomendação editorial: mantenha listas de campos e destinos independentes. Marketing recebe somente o aprovado para sua finalidade, sem texto clínico ou conteúdo livre. Para mensuração, uma taxonomia de resultados de agendamento representa estados operacionais sem reproduzir conteúdo clínico.

Qual é o papel do controlador e do operador?

Lei: a LGPD define controlador como quem toma decisões referentes ao tratamento e operador como quem trata dados em nome do controlador. O rótulo comercial do fornecedor não substitui essa análise. Uma clínica pode decidir por que e quais dados recolher, enquanto uma plataforma executa instruções técnicas. Outras atividades do mesmo fornecedor podem exigir avaliação própria.

A escolha da hipótese do artigo 11 pertence à governança do tratamento. O fornecedor documenta campos, armazenamento, acessos e eliminações, mas uma configuração padrão não produz conclusão jurídica universal. Um contrato também não resolve finalidade, necessidade ou reutilização.

Recomendação editorial: associe a matriz de finalidade ao contrato e ao sistema. Registre quem aprova novos campos, quem pode consultar respostas, quais subprocessadores recebem dados e o que acontece quando o pedido não vira consulta. A análise sobre BAA, DPA e contrato de operador aprofunda a diferença entre papel real e nome do documento.

Como transformar a análise em controles de produto

Recomendação editorial: depois da decisão jurídica, implemente controles que tornem a conclusão verificável. Uma política sem correspondência no formulário, nas permissões e nas integrações não descreve o fluxo real.

  1. Liste campos, valores ocultos, parâmetros de URL e texto livre.
  2. Defina uma finalidade concreta e um proprietário para cada grupo de dados.
  3. Marque quais valores revelam ou podem revelar saúde no contexto da pessoa.
  4. Registre a hipótese do artigo 11 para cada finalidade sensível.
  5. Mostre aviso contextual perto da coleta, com linguagem compatível com a etapa.
  6. Restrinja acesso conforme a necessidade aprovada de cada equipe.
  7. Use allowlists por destino para impedir que o objeto completo do agendamento seja exportado.
  8. Defina retenção para cada estado do pedido.
  9. Reabra a análise quando um campo, finalidade, destinatário ou integração mudar.

O teste deve usar dados sintéticos. Confirme que campos clínicos não aparecem em analytics, logs amplos, notificações expostas ou destinos promocionais. Preserve o resultado do teste e a versão do formulário analisado.

Que evidência sustenta uma conclusão responsável?

Orientação da ANPD: o guia propõe uma avaliação documentada do legítimo interesse para os tratamentos aos quais essa hipótese pode se aplicar. Para dados sensíveis, seu valor está em deixar claro o limite: não use o teste como substituto do artigo 11.

Recomendação editorial: guarde uma matriz com campo, finalidade, categoria, hipótese, necessidade, acesso, retenção, destinatários e aprovadores. Anexe a configuração sem dados reais. A evidência mostra o produto, sem acumular respostas de pacientes.

Limite a conclusão ao comprovado: determinada finalidade foi avaliada sob uma hipótese específica e os controles testados bloquearam destinos não aprovados. Evite dizer que “o formulário é compatível com a LGPD” em abstrato. Uma mudança pode alterar a conclusão.

Perguntas frequentes

Posso usar legítimo interesse apenas para nome e telefone?

Talvez, mas somente após análise separada desse tratamento não sensível. O legítimo interesse exige finalidade legítima, necessidade, equilíbrio e salvaguardas conforme a orientação da ANPD. Ele não se estende aos campos de saúde nem transforma todo o formulário numa única operação.

Toda clínica precisa pedir consentimento para agendar?

Não como regra universal. O artigo 11 prevê consentimento específico e destacado, além de hipóteses sem consentimento sob condições próprias. A clínica precisa identificar qual hipótese cobre cada finalidade e confirmar que seus requisitos estão presentes.

Uma caixa de consentimento permite usar o motivo da consulta em marketing?

Não automaticamente. Consentimento para uma finalidade não deve ser tratado como autorização genérica. Marketing exige avaliação própria de finalidade, necessidade, informação, escolha e demais regras aplicáveis. Dados clínicos não devem ser herdados do agendamento por padrão.

Excluir o campo aberto elimina todo dado de saúde?

Não necessariamente. Especialidade, procedimento, unidade ou combinação de respostas ainda pode revelar informação de saúde. Classifique o que o conjunto comunica sobre a pessoa e reduza os campos ao necessário para aquela etapa.

Referências

Agendamento pediátrico online: como separar LGPD art. 14 e ECA Digital

cmsapointoo on August 16, 2026

Um formulário de agendamento pediátrico não deve partir da regra simplificada de que qualquer tratamento exige consentimento parental. O Enunciado CD/ANPD nº 1/2023 afirma que o tratamento de dados de crianças e adolescentes pode se apoiar nas hipóteses legais dos artigos 7º ou 11 da LGPD, desde que o melhor interesse seja observado e prevaleça na avaliação do caso concreto. Consentimento continua relevante em situações previstas pela lei, mas não é uma resposta universal.

O ECA Digital exige análise separada. A Lei nº 15.211/2025 alcança produtos ou serviços de tecnologia da informação direcionados a crianças e adolescentes ou de acesso provável por eles. Um formulário operado pelo responsável não fica automaticamente dentro ou fora desse escopo. Avalie público, linguagem, divulgação, desenho e uso esperado.

Comece pelo fluxo real de agendamento

Mapeie quem usa o formulário e o que acontece depois do envio. Em uma consulta pediátrica, o responsável pode pesquisar, preencher, receber mensagens e comparecer com a criança. Em outros serviços, o adolescente pode procurar atendimento, usar o próprio telefone ou conversar diretamente com a clínica. A interface precisa refletir o fluxo provável, não um modelo abstrato de família.

Separe dados do responsável, do menor, da agenda e campos clínicos. Nome, contato e vínculo do adulto podem organizar o atendimento; data de nascimento ou faixa etária pode orientar a agenda. Sintomas, documentos, histórico e observações exigem justificativa própria e talvez pertençam a um canal assistencial, não à primeira tela.

Também separe destinatários. A equipe de recepção pode precisar de identificação, horário e contato. Profissionais assistenciais podem precisar de informação adicional em sistema apropriado. Marketing não precisa receber o conteúdo do pedido. Uma taxonomia de resultados de agendamento permite medir estados operacionais sem reproduzir dados pediátricos.

O que a LGPD e o artigo 14 dizem

A LGPD trata dados de saúde como dados pessoais sensíveis e estabelece hipóteses legais específicas no artigo 11. O artigo 14 dispõe que o tratamento de dados pessoais de crianças e adolescentes deve ocorrer em seu melhor interesse. Seus parágrafos também contêm regras sobre consentimento específico e em destaque por pelo menos um dos pais ou responsável legal para dados de crianças, esforços razoáveis de verificação, transparência e limites à exigência de dados para participação em jogos, aplicações ou outras atividades.

Essas disposições não devem ser lidas isoladamente. O Enunciado CD/ANPD nº 1/2023 estabelece que o tratamento de dados de crianças e adolescentes pode ser realizado com base nas hipóteses legais dos artigos 7º ou 11, desde que o melhor interesse seja observado e prevaleça no caso concreto. Portanto, a equipe precisa identificar a hipótese apropriada para cada finalidade, além de demonstrar por que o desenho protege o menor.

Não transforme o enunciado em uma autorização geral. Ele não diz que qualquer base serve, nem elimina as demais obrigações do artigo 14. Também não transforme a menção a consentimento em regra para toda atividade pediátrica. Atendimento, obrigação regulatória, proteção da vida, tutela da saúde e marketing são finalidades diferentes e podem exigir análises diferentes.

Melhor interesse precisa aparecer nas decisões de produto

“Melhor interesse” não pode ficar apenas no aviso. Registre como cada escolha reduz risco: necessidade do dado, acesso, retenção, correção e possíveis expectativas diferentes entre responsável e adolescente.

Documente idade provável, vulnerabilidade, sensibilidade, impacto de erro, risco de exposição, autonomia progressiva, relação com o responsável e alternativa menos invasiva. A conclusão precisa ser específica. Repetir uma justificativa em cadastro, atendimento, pesquisa e campanha não demonstra avaliação real.

Para o primeiro contato, prefira um conjunto mínimo: identificação necessária, faixa etária quando suficiente, contato adequado, unidade, horário e tipo amplo de atendimento. Evite campo aberto obrigatório para descrever condição. Se a clínica precisa de triagem clínica antes da marcação, mova essa etapa para canal e equipe próprios, com controles compatíveis.

Essa é uma recomendação editorial de implementação. A lei não prescreve esse esquema de campos. A clínica deve ajustar o desenho ao serviço, à obrigação profissional e à avaliação jurídica aplicável.

Consentimento parental não é universal nem descartável

Duas simplificações falham. Exigir consentimento para tudo mistura finalidades e pode sugerir escolha inexistente em etapas necessárias. Concluir que o enunciado tornou consentimento sempre desnecessário também erra: o artigo 14 continua vigente, e certas finalidades podem depender de consentimento específico.

Construa uma matriz por finalidade. Para solicitar horário, indique dados, titular, hipótese considerada, necessidade e melhor interesse. Faça o mesmo para lembretes, documentos, triagem, pesquisa e marketing. Se houver consentimento, registre quem consentiu, vínculo declarado, versão do aviso, finalidade, momento e mecanismo de retirada. Avalie esforços razoáveis para verificar a pessoa responsável quando essa regra incidir.

Não use a autorização para agendar como licença para publicidade. Uma mensagem necessária sobre horário não equivale a campanha promocional. Da mesma forma, aceitar termos do serviço não torna dados de saúde elegíveis para uma plataforma de anúncios. O artigo sobre base legal e Customer Match em saúde explica essa separação.

Quando avaliar o ECA Digital

A Lei nº 15.211/2025, conhecida como ECA Digital, estabelece regras de proteção de crianças e adolescentes em ambientes digitais. Seu escopo inclui produtos ou serviços de tecnologia da informação direcionados a crianças e adolescentes ou de acesso provável por eles. A análise não depende só do texto “para maiores de 18 anos” ou de quem assina o formulário.

O parágrafo único do art. 1º indica três situações de acesso provável: suficiente probabilidade de uso e atratividade do produto ou serviço por crianças e adolescentes; considerável facilidade de acesso e utilização por esse público; e significativo grau de risco à privacidade, à segurança ou ao desenvolvimento biopsicossocial, especialmente em produtos ou serviços voltados à interação social e ao compartilhamento de informações em larga escala.

A partir desses critérios legais, verifique se adolescentes são convidados a acessar o serviço, se campanhas chegam a menores, se a linguagem fala com eles, se a jornada admite conta própria e se é provável o uso sem mediação. Um portal para responsáveis pode diferir de um aplicativo adolescente. A especialidade pediátrica, sozinha, não decide.

Se o produto for direcionado a menores ou provavelmente acessado por eles, avalie as obrigações atuais da lei e a regulamentação da ANPD. A lei enfatiza proteção integral, melhor interesse, prevenção, informação, privacidade, segurança e desenho compatível com o público. A página temática da ANPD reúne o material regulatório vigente e deve ser revisada porque orientações podem evoluir.

Este é um teste independente da base legal da LGPD. Um tratamento pode ter hipótese legal e ainda exigir ajustes de produto sob o ECA Digital. O inverso também vale: classificar o serviço fora do escopo específico do ECA Digital não encerra LGPD, regras profissionais, contratos ou proteção do consumidor.

Desenho recomendado para uma jornada pediátrica contida

Depois da análise jurídica, traduza o resultado em fronteiras técnicas. Um desenho editorial possível é:

  1. Identifique a pessoa usuária: responsável, adolescente ou outro contato autorizado, sem forçar uma resposta incompatível com o serviço.
  2. Separe titulares: não grave telefone do responsável como se pertencesse automaticamente à criança.
  3. Peça o mínimo: use categorias amplas e adie detalhes clínicos para o canal assistencial.
  4. Mostre aviso contextual: explique finalidade, destinatários e próximos passos perto da coleta.
  5. Controle mensagens: lembrete operacional e marketing têm preferências e templates separados.
  6. Limite integrações: envie a cada destino apenas os campos aprovados para sua finalidade.
  7. Defina retenção: trate pedidos abandonados, duplicados e não confirmados com regra própria.
  8. Registre mudanças: novo campo, canal ou público reabre a avaliação.

Mensuração pode usar contagens e estados sem detalhes da consulta. Veja como medir comparecimento sem conteúdo clínico. Também preserve a diferença entre origem do agendamento e origem de marketing, pois a mesma pessoa pode chegar por um canal e concluir o pedido em outro.

Controles de acesso, comunicação e evidência

O banco deve representar o vínculo sem acesso amplo. Recepção administra agenda; equipe assistencial acessa o necessário ao cuidado; marketing recebe apenas sinais aprovados e não clínicos. Logs registram acesso e mudança de estado sem copiar texto sensível. Exportações seguem a autorização da tela.

Em mensagens, evite revelar especialidade, condição ou procedimento na notificação de bloqueio de tela. Confirme o canal antes de enviar detalhes. Quando o contato pertence ao responsável, deixe isso explícito no cadastro. Quando o adolescente usa contato próprio, avalie segurança, expectativa de confidencialidade e regras profissionais do caso.

Guarde evidência suficiente para explicar a decisão: versão do fluxo, matriz de finalidade e base, avaliação do melhor interesse, teste de escopo do ECA Digital, campos publicados, destinatários, retenção e aprovações. Evidência não significa acumular todos os dados enviados. Significa provar a regra e sua execução.

Perguntas frequentes

O agendamento de criança sempre exige consentimento parental?

Não como regra universal. O Enunciado CD/ANPD nº 1/2023 admite hipóteses dos artigos 7º e 11, desde que o melhor interesse prevaleça no caso concreto. Consentimento e demais requisitos do artigo 14 ainda precisam ser avaliados para a finalidade específica.

O ECA Digital se aplica a toda clínica pediátrica?

Não automaticamente. Teste se o produto ou serviço digital é direcionado a crianças e adolescentes ou provavelmente acessado por eles. Especialidade, marketing, interface e uso esperado são fatos relevantes, não atalhos conclusivos.

Posso usar a mesma autorização para agendamento e marketing?

Não presuma. São finalidades diferentes. Separe necessidade assistencial, comunicação operacional e promoção; identifique a hipótese, o aviso e a escolha apropriados para cada uma.

É adequado pedir o motivo detalhado da consulta no primeiro formulário?

Somente se houver necessidade demonstrada e canal compatível. Uma categoria ampla ou etapa assistencial posterior pode reduzir exposição. A decisão depende do serviço e das obrigações profissionais.

Como provar que o melhor interesse foi considerado?

Documente riscos, alternativas, necessidade de campos, acesso, retenção, transparência, autonomia e impacto sobre a criança ou adolescente. Depois teste se o produto implementa a decisão registrada.

Referências

Analytics global sem copiar dados de saúde para uma região central

cmsapointoo on August 16, 2026

Uma visão global de desempenho não exige, por padrão, copiar eventos de saúde de todos os tenants para um único data warehouse. Uma arquitetura mais contida calcula métricas na região de origem de cada tenant e envia ao plano global somente um contrato mínimo de resultados, com dimensões limitadas e sem texto clínico. Essa é uma recomendação editorial de arquitetura, não uma exigência universal de HIPAA, LGPD ou Google Cloud.

O desenho ainda precisa de análise jurídica e técnica. Um total agregado não é automaticamente anônimo. Além disso, consultas multirregionais podem movimentar dados. Na documentação atual de preview, o BigQuery Global Queries executa subconsultas remotas e copia os dados remotos para tabelas temporárias na região primária, onde ficam por 24 horas. A palavra “global” não deve ser lida como “sem transferência”.

Separe eventos operacionais de métricas globais

Operação local e gestão global costumam ser tratadas como uma necessidade só. A primeira pode exigir eventos por agendamento, estado, horário e unidade. A segunda talvez precise apenas de contagens, taxas e tendências. Se o painel global não usa registros individuais, copiá-los amplia acesso sem acrescentar valor.

Em um modelo contido, cada tenant mantém eventos detalhados na região aprovada para sua operação. Um job local transforma esses eventos em um esquema pequeno, por exemplo: período, tenant, unidade autorizada, identificador de métrica, numerador, denominador, versão da regra e estado de qualidade. O repositório global recebe somente essas linhas calculadas. Texto livre, motivo clínico, especialidade rara e identificadores diretos ficam fora desse contrato.

Essa fronteira deve ser verificável. Use uma lista positiva de campos, validação de tipos e rejeição de colunas desconhecidas. Versione a definição de cada métrica para não comparar regras diferentes sob o mesmo nome. Para resultados de agenda, a taxonomia de resultados de agendamento mostra como limitar estados antes de alimentar relatórios.

Agregado não significa automaticamente anônimo

Em HIPAA, 45 CFR 164.514 prevê dois caminhos para determinar que health information não identifica um indivíduo: determinação por pessoa com conhecimento e experiência apropriados, com risco muito pequeno documentado, ou remoção dos identificadores enumerados no método Safe Harbor, desde que não haja conhecimento de que a informação restante possa identificar a pessoa. Somar registros não cria um terceiro caminho automático.

Uma célula com poucos casos, combinada com unidade, data e condição rara, pode permitir inferência mesmo sem nome. O risco depende do contexto, dos dados auxiliares disponíveis e de quem recebe o relatório. Não invente um tamanho universal de célula. Documente o método adotado e valide se dimensões, filtros e exportações preservam a conclusão.

A LGPD também exige cuidado. O artigo 12 trata dados anonimizados como fora do regime de dados pessoais, salvo quando a anonimização puder ser revertida com meios próprios ou esforços razoáveis, considerando fatores objetivos como custo, tempo e tecnologia disponível. Logo, “agregado” descreve uma transformação; não prova, sozinho, anonimização irreversível ou razoavelmente resistente.

Se a equipe não concluiu e documentou anonimização ou desidentificação aplicável, trate a métrica como dado potencialmente pessoal. Isso significa aplicar controle de acesso, finalidade, retenção, segurança e avaliação de transferência. É uma postura editorial conservadora para implementação, não uma conclusão de que toda métrica agregada identifica alguém.

O que o BigQuery Global Queries faz hoje

A documentação atual descreve Global Queries como recurso de preview, sujeito a termos de oferta pré-GA. O fluxo usa uma consulta na região primária, executa subconsultas nas regiões remotas e copia os resultados remotos para tabelas temporárias na região primária. Essas tabelas permanecem por 24 horas. A consulta final é executada na região primária usando as cópias temporárias.

Pushdowns podem reduzir a quantidade copiada, pois filtros e agregações compatíveis rodam perto da origem. Ainda assim, a própria documentação alerta que o volume transferido pode ser grande e recomenda testar com subconjunto pequeno. Um plano não deve depender da suposição de que o otimizador sempre enviará apenas o resultado mínimo. Confirme o plano, os jobs remotos, bytes processados, região primária e tabelas temporárias em um teste representativo.

A configuração regional enable_global_queries_execution controla se o projeto pode executar consultas globais naquela região. A configuração enable_global_queries_data_access controla se consultas globais podem copiar dados da região do projeto que os contém. Essas opções do BigQuery são distintas das constraints do Organization Policy discutidas abaixo. O recurso também tem limitações atuais, incluindo incompatibilidade com endpoints regionais e Assured Workloads. Texto da consulta pode aparecer no histórico dos jobs remotos. Antes de adotar o preview, compare essas propriedades com obrigações contratuais e requisitos de acesso.

Se a regra é “nenhum dado derivado sai da região”, Global Queries não atende essa regra apenas por ter execução distribuída. Se a regra permite transferência de um conjunto mínimo para região primária, o recurso ainda precisa de aprovação explícita quanto ao conteúdo, destino e retenção temporária. Essa conclusão decorre do comportamento documentado do produto, não de uma interpretação ampla da palavra “global”.

Política de localização não é garantia completa de residência

O Organization Policy Service oferece constraints de localização para limitar onde recursos compatíveis podem ser criados. A documentação do Google Cloud ressalta limites importantes: a política vale para recursos com atributo de localização suportado, não é retroativa para recursos existentes e não restringe recursos globais ou tipos não suportados.

Também há uma distinção entre localização do recurso e local de armazenamento ou processamento. Alguns serviços podem armazenar ou processar dados em local diferente da localização do recurso. A documentação diz que organization policies não são, por si, compromissos de armazenamento de dados. Portanto, uma constraint aprovada é uma camada de prevenção, não a prova inteira da residência.

O controle precisa combinar política de organização, configuração do dataset, localização do job, contrato do serviço, documentação do produto e teste de execução. Revise recursos existentes separadamente, porque a aplicação de nova política não os move. Para sistemas que atravessam UE e Brasil, consulte também a análise de adequação entre regiões e regimes.

Arquitetura editorial para métricas mínimas

Uma implementação de referência pode ter quatro estágios. Eles são uma proposta de engenharia para reduzir movimento e exposição, não uma receita jurídica universal:

  1. Zona operacional local: recebe eventos detalhados, com acesso limitado ao tenant e retenção definida pela finalidade.
  2. Transformação local: calcula métricas aprovadas e rejeita dimensões, texto e identificadores fora da lista positiva.
  3. Gate de publicação: avalia qualidade, risco de células pequenas, versão da métrica e destino permitido.
  4. Plano global: armazena apenas linhas publicáveis, com acesso separado, trilha de versão e prazo de retenção próprio.

O identificador do tenant pode continuar sendo dado confidencial, mesmo quando não identifica paciente. Não use nome de clínica em arquivos públicos ou dashboards sem necessidade. Para comparações, avalie se a audiência precisa ver cada tenant ou apenas uma coorte. Mantenha totais que permitam calcular taxas, mas evite dimensões tão granulares que recriem o evento original.

Em métricas de comparecimento, por exemplo, numerador e denominador por período podem bastar. O artigo sobre medição da taxa de comparecimento sem detalhes da consulta apresenta uma forma de separar resultado operacional de conteúdo clínico.

Controles que tornam a fronteira testável

  • Esquema allowlist: falhar quando aparecer campo não declarado, em vez de propagá-lo.
  • Região explícita: definir e registrar localização de datasets e jobs, sem depender de padrão implícito.
  • Identidade separada: conta local lê eventos; conta publicadora escreve somente métricas aprovadas.
  • Sem texto livre: impedir observações, URLs completas, termos de busca e campos clínicos no payload global.
  • Teste de inferência: revisar filtros, combinações e exportações que possam isolar indivíduos.
  • Retenção por camada: definir prazos distintos para eventos locais, staging, cópias temporárias e métricas globais.
  • Observabilidade sem conteúdo: registrar versão, contagem e erro, evitando reproduzir dados sensíveis em logs.

Inclua um teste negativo: tente publicar coluna clínica, identificador direto e dimensão não aprovada. O pipeline deve recusar. Inclua também um teste de localização que consulte metadados dos jobs e confirme onde houve execução ou cópia. Prints de configuração não substituem evidência do fluxo real.

Decisão por fluxo, não por slogan de arquitetura

“Data mesh”, “federado” e “global” não definem o resultado jurídico. Registre fonte, transformação, hipótese de anonimização, região de cálculo, conteúdo transferido, destino, retenção, audiência e possibilidade de drill-down. Se o painel volta ao evento individual, não é apenas uma camada agregada.

Também separe analytics interno de uso publicitário. Um campo permitido no warehouse não é automaticamente elegível para upload em mídia. A distinção entre base legal e política de Customer Match ajuda a manter essas decisões independentes.

Perguntas frequentes

Uma contagem por clínica já é anônima?

Não automaticamente. O risco depende da granularidade, das combinações possíveis, da audiência e dos dados auxiliares. Aplique o método jurídico e técnico pertinente e documente a conclusão.

Global Queries mantém todos os dados na região original?

Não segundo a documentação atual de preview. Resultados de subconsultas remotas são copiados para tabelas temporárias na região primária e mantidos por 24 horas antes da expiração.

Uma policy de localização impede qualquer processamento fora da região?

Não. Ela limita a criação de recursos suportados conforme a constraint. A documentação alerta que recursos globais ou não suportados ficam fora e que localização do recurso pode diferir do armazenamento ou processamento.

É obrigatório adotar a arquitetura proposta aqui?

Não. Ela é uma recomendação editorial para reduzir dados movimentados. Requisitos contratuais, legais, operacionais e do provedor podem exigir outro desenho ou impedir determinado fluxo.

Qual evidência revisar antes da produção?

Esquema publicado, plano e metadados dos jobs, regiões, bytes copiados, identidades, tabelas temporárias, retenção e testes de rejeição. Revalide a documentação porque o recurso está em preview.

Referências

BAA, DPA e contrato de operador LGPD: qual documento cobre cada relação

cmsapointoo on August 16, 2026

BAA, DPA e contrato entre controlador e operador não são três nomes intercambiáveis para o mesmo documento. Cada instrumento nasce de um regime e de uma relação específica. Um BAA responde à relação regulada pela HIPAA entre entidade coberta e business associate. As cláusulas do artigo 28 do GDPR disciplinam o tratamento feito por processor em nome de controller. Na LGPD, o contrato entre controlador e operador registra instruções, limites e responsabilidades coerentes com as atividades reais.

Escolher um título conhecido não resolve a classificação das partes. Mapeie dados, finalidades, decisões e operações antes de escolher o instrumento. Um fornecedor pode exercer papéis diferentes no mesmo projeto, mas cada papel precisa ser demonstrado, não presumido pelo cabeçalho.

Comece pela relação real, não pela sigla

Antes de selecionar um modelo, desenhe o percurso dos dados. Identifique quem define por que o tratamento acontece, quem escolhe os meios essenciais, quem executa instruções e quem usa os dados para finalidade própria. Inclua recepção, armazenamento, suporte, exportação, exclusão, análise e acesso por subcontratados. Essa matriz costuma revelar que um único rótulo comercial esconde relações distintas.

O guia da ANPD sobre agentes de tratamento adota uma leitura funcional: a definição de controlador e operador decorre das atividades efetivamente realizadas. Um contrato pode registrar a distribuição de funções, mas não transforma uma parte em operadora quando ela decide finalidade própria. Da mesma forma, chamar qualquer aditivo de DPA não informa, sozinho, se o texto busca cumprir o GDPR, documentar uma relação da LGPD ou combinar obrigações de mais de um regime.

Para compras e jurídico, a pergunta útil não é “tem DPA?”. É “qual relação este documento disciplina, para quais dados e operações?”. Para produto e engenharia, a pergunta complementar é “o sistema respeita as instruções e restrições que o contrato descreve?”. O contrato e a arquitetura precisam contar a mesma história.

BAA cobre uma relação delimitada pela HIPAA

A regra contratual da HIPAA em 45 CFR 164.504 descreve o conteúdo exigido para contratos ou outros arranjos entre uma entidade coberta e um business associate, e também alcança relações de business associate com subcontratados pertinentes. O instrumento deve estabelecer usos e divulgações permitidos ou exigidos, impedir usos incompatíveis, exigir salvaguardas e determinar a comunicação de usos, divulgações ou violações conhecidos.

O texto regulatório também trata de acesso, alteração e accounting of disclosures quando essas obrigações forem aplicáveis à função delegada. Exige que subcontratados aceitem restrições equivalentes, prevê disponibilização de práticas e registros ao Department of Health and Human Services e disciplina devolução ou destruição de protected health information ao término, quando viável. O descumprimento material também precisa ter consequência contratual.

Isso não significa que um BAA cubra todos os produtos de uma empresa ou toda informação relacionada à saúde. É necessário verificar a entidade, a atividade, o produto contratado e o dado envolvido. Também não se deve transferir automaticamente a lógica do BAA para publicidade, CRM ou analytics. Para entender esse limite em uma pilha de marketing, veja como separar obrigações por regime e fluxo.

Artigo 28 do GDPR exige um contrato com conteúdo próprio

Quando um processor trata dados pessoais em nome de um controller, o artigo 28 do GDPR exige contrato ou outro ato jurídico vinculante. O documento deve indicar objeto e duração, natureza e finalidade, tipos de dados, categorias de titulares e direitos e obrigações do controller. O processor deve agir segundo instruções documentadas, inclusive quanto a transferências, salvo obrigação legal aplicável que imponha outro tratamento.

O artigo também cobre confidencialidade, medidas do artigo 32, condições para contratar outro processor, assistência ao controller, devolução ou eliminação ao fim da prestação e informações necessárias para demonstrar conformidade e permitir auditorias. A autorização para subprocessadores pode ser específica ou geral, mas alterações precisam seguir o mecanismo previsto. Obrigações equivalentes devem chegar ao subprocessador.

Transferência internacional não se resolve apenas porque existe uma cláusula de processor. A instrução deve ser compatível com o capítulo V e com o mecanismo aplicável. Um modelo contratual pode reunir cláusulas diferentes, mas a equipe deve saber qual seção responde a qual obrigação. Esse cuidado evita que um contrato amplo pareça cobrir uma operação que exige avaliação própria.

Na LGPD, contrato controlador-operador é boa prática, não atalho de classificação

A LGPD define controlador como quem toma decisões referentes ao tratamento e operador como quem trata dados em nome do controlador. O guia orientativo da ANPD informa que a lei não determina expressamente a celebração de um contrato entre esses agentes, mas considera boa prática estabelecer as atividades do operador, limites de atuação, responsabilidades e relações com suboperadores.

Esse ponto exige precisão. A ausência de uma exigência contratual expressa não torna o documento dispensável em uma contratação sensível. Também não autoriza inventar uma obrigação textual que a lei não contém. O contrato serve para traduzir instruções, facilitar prestação de contas e reduzir ambiguidades operacionais. A qualificação jurídica continua dependente dos fatos.

O guia também recomenda autorização formal do controlador para suboperadores. Em saúde, o inventário deve alcançar hospedagem, suporte, mensageria, observabilidade e equipes com acesso a dados pessoais. Se surgir finalidade própria, como enriquecer uma base comercial sem instrução compatível, reavalie papel e fundamento. Um anexo de segurança não legitima a nova finalidade.

Cláusulas mínimas devem seguir o ciclo de vida do dado

Um checklist útil acompanha o dado do ingresso ao encerramento. Ele não substitui análise jurídica, mas reduz omissões entre contrato, configuração e operação:

  • Escopo: serviços, sistemas, categorias de dados, titulares, finalidades e duração claramente delimitados.
  • Instruções: canal autorizado, processo para mudanças e tratamento de instruções potencialmente incompatíveis com a lei.
  • Segurança: controles proporcionais ao risco, gestão de acesso, registro, continuidade e processo de avaliação.
  • Subcontratação: aprovação, lista atualizada, fluxo de obrigações e responsabilidade pela cadeia.
  • Incidentes: evento reportável, prazo, conteúdo inicial, atualização e responsáveis pela coordenação.
  • Direitos e auditoria: assistência, evidências, limites de auditoria e acesso a registros pertinentes.
  • Saída: exportação, devolução, eliminação, retenções legais e comprovação do encerramento.
  • Localização e transferências: regiões, destinatários, mecanismos e mudanças sujeitas a revisão.

O nível de detalhe deve refletir a operação. “Medidas adequadas” sem controles verificáveis pode ser insuficiente. Prometer um controle inexistente, por sua vez, cria obrigação que a arquitetura não cumpre. Compras obtém evidência, engenharia confirma capacidade técnica e jurídico ajusta a linguagem ao regime.

Documento assinado não torna um fluxo de marketing elegível

Contratos e regras de plataforma respondem a perguntas diferentes. Uma clínica pode ter base legal para uma operação e ainda não poder enviar dados de saúde a um produto publicitário. Hash ou pseudonimização tampouco apagam automaticamente o caráter pessoal ou sensível. O artigo sobre base legal e elegibilidade no Customer Match separa as duas análises.

Antes de ativar integrações, classifique cada destino. Diferencie sistemas assistenciais, infraestrutura contratada, analytics operacional e plataformas de mídia. Para mensuração, prefira resultados operacionais definidos, como “agendamento confirmado”, sem detalhes clínicos no payload. Uma taxonomia de resultados de agendamento ajuda a limitar campos e evita que texto livre chegue ao fluxo publicitário.

Essa é uma recomendação editorial de implementação, não uma regra universal dos três regimes. A decisão final depende dos fatos, das leis aplicáveis, do contrato do produto e das políticas vigentes. Registre a conclusão por fluxo, não por fornecedor inteiro.

Como revisar uma contratação sem misturar regimes

  1. Mapeie entidades, produtos, dados, finalidades, regiões e subcontratados.
  2. Classifique papéis separadamente para cada atividade, registrando quem decide e quem executa.
  3. Teste o escopo de HIPAA, GDPR e LGPD sem usar o resultado de um teste como resposta para outro.
  4. Associe cada cláusula à obrigação e ao controle técnico que a sustenta.
  5. Verifique anexos de segurança, listas de subprocessadores, mecanismos de transferência e processos de incidente.
  6. Faça um teste de saída: exportação, eliminação, revogação de acesso e evidência de conclusão.

O resultado pode ser um BAA, cláusulas do artigo 28, um contrato controlador-operador, mais de um instrumento ou nenhum deles para determinada relação. O importante é documentar a razão. A separação entre origem do agendamento e origem de marketing oferece um exemplo de como uma distinção de finalidade pode virar fronteira técnica verificável.

Perguntas frequentes

Um DPA é sempre um contrato do artigo 28 do GDPR?

Não necessariamente. DPA é uma expressão usada no mercado para documentos diferentes. Leia o conteúdo, identifique as partes, o regime invocado e as atividades cobertas. Se houver relação controller-processor sujeita ao GDPR, o instrumento precisa cumprir o artigo 28.

Um BAA substitui o contrato entre controlador e operador da LGPD?

Não. O BAA responde a uma relação definida pela HIPAA. A LGPD exige análise própria de agentes, finalidade e obrigações. Um documento combinado pode conter ambos os conjuntos de cláusulas, desde que os escopos estejam claros.

A LGPD obriga sempre um contrato escrito entre controlador e operador?

O guia da ANPD afirma que a LGPD não estabelece expressamente essa obrigação, mas recomenda o contrato como boa prática para delimitar atividades e responsabilidades. Outras obrigações contratuais ou setoriais podem incidir no caso concreto.

O fornecedor escolhe seu papel no contrato?

Não de forma conclusiva. A redação é evidência relevante, mas a classificação segue as atividades reais. Se o fornecedor decide finalidade própria, a equipe precisa reavaliar o papel correspondente a esse tratamento.

Qual é o primeiro teste antes de assinar?

Compare o mapa de dados com o escopo do serviço. Se o documento não cobre uma operação, região, subprocessador ou finalidade que existe no sistema, ajuste o fluxo ou o contrato antes da produção.

Referências

Base legal da LGPD não torna Customer Match elegível em contextos de saúde sensível

cmsapointoo on August 16, 2026

Uma base legal da LGPD e a elegibilidade para Customer Match respondem a perguntas diferentes. A LGPD disciplina o tratamento de dados pessoais sensíveis. O Google decide quais recursos seus produtos de publicidade suportam. Aprovação em um lado não comprova aprovação no outro.

Em contextos de saúde sensível, a política de publicidade personalizada classifica conteúdo de saúde pessoal como categoria sensível e indica Customer Match como não suportado para anunciantes que o promovem. Isso não proíbe todo anúncio de saúde, nem permite escolher uma base da LGPD para contornar a política.

Por que existem dois gates independentes?

O gate jurídico pergunta se o tratamento pretendido tem fundamento, finalidade específica, necessidade, transparência e demais condições aplicáveis. O gate da plataforma pergunta se o produto permite aquele uso dentro de suas políticas e requisitos técnicos. A organização precisa passar pelos dois. Não existe uma ordem em que a aprovação de um apaga a reprovação do outro.

Uma clínica pode ter análise jurídica favorável para certo tratamento e continuar impedida de usar Customer Match em conteúdo de saúde pessoal sensível. O painel também pode mostrar o recurso disponível sem decidir base legal, transparência ou necessidade.

Gate Pergunta Quem define Resultado seguro
LGPD O tratamento de dados sensíveis é lícito para esta finalidade? Lei aplicável e análise qualificada Documentar ou manter bloqueado
Customer Match A conta e os dados atendem aos requisitos do recurso? Política do Google Usar apenas se todos os requisitos forem cumpridos
Saúde em publicidade personalizada O anúncio promove conteúdo de saúde pessoal sensível? Política do Google Não usar Customer Match quando o recurso estiver indicado como não suportado
Implementação O fluxo real corresponde ao uso analisado? Controlador, operadores e responsáveis técnicos Validar campos, contas, acesso e bloqueios

O quadro elimina dois atalhos falsos: “a LGPD permite, então o Google aceita” e “o Google aceitou, então está legal”.

O que a LGPD diz sobre dados de saúde?

O artigo 5º, inciso II, da LGPD inclui dados referentes à saúde na definição de dado pessoal sensível quando vinculados a uma pessoa natural. A categoria não se limita a diagnóstico ou prontuário. A análise deve considerar se o conjunto de dados revela informação de saúde, inclusive pela finalidade, pelo contexto e pela associação com a pessoa.

O artigo 11 estabelece as hipóteses em que o tratamento de dados pessoais sensíveis pode ocorrer. Ele inclui consentimento específico e destacado para finalidades específicas e também situações sem consentimento, desde que sejam indispensáveis e atendam às condições legais correspondentes. Citar o número do artigo não basta. A organização precisa avaliar o tratamento concreto, seus papéis e as demais obrigações.

Este artigo não recomenda consentimento, tutela da saúde ou outra hipótese. A escolha depende dos fatos e de análise qualificada. A análise sobre adequação UE-Brasil aplica o mesmo limite: um mecanismo jurídico não aprova todo o fluxo.

O que a política de Customer Match exige?

A política de Customer Match exige que o anunciante use informações coletadas em contexto próprio, como interações diretas em site, aplicativo, loja física ou outra relação direta. Ela também exige divulgação adequada na política de privacidade, consentimento para o compartilhamento quando a lei ou a política aplicável exigir, uso de API ou interface aprovada e conformidade com leis e políticas do Google.

A política também exige histórico adequado de conformidade e pagamentos e traz requisitos adicionais para certos recursos. Esses critérios não tornam qualquer lista própria permitida. Origem, consentimento quando aplicável e habilitação técnica não afastam restrições sobre categorias sensíveis.

A política proíbe anúncios que indiquem conhecimento de informações pessoais ou sensíveis, listas estreitas demais e certos produtos sensíveis em Customer Match. Documente anúncio, página, serviço, lista e segmentação antes de discutir upload.

Qual é a fronteira de saúde na publicidade personalizada?

Na página Health in personalized advertising consultada em 16 de agosto de 2026, o Google descreve conteúdo de saúde pessoal como categoria de interesse sensível. Os exemplos incluem condições físicas ou mentais, tratamentos para condições crônicas, questões relacionadas a funções íntimas, procedimentos invasivos e deficiências. A classificação depende do conteúdo promovido, não apenas do nome escolhido para a audiência.

Para anunciantes que promovem conteúdo dentro dessa categoria sensível, a página separa audiências predefinidas do Google e audiências selecionadas pelo anunciante. Customer Match aparece entre os recursos não suportados no segundo grupo. A equipe deve retirar Customer Match da segmentação se o anúncio, site ou aplicativo cair nessa categoria, salvo se uma revisão da própria plataforma concluir que houve erro de classificação.

A regra não proíbe toda publicidade de clínicas. Ela trata de conteúdo de saúde pessoal sensível e da segmentação correspondente. Não estenda a conclusão a palavras-chave, localização, audiências predefinidas ou conteúdo fora da categoria sem verificar cada política.

Por que consentimento não supera a política do Google?

Consentimento pode ser relevante em uma análise jurídica, mas não altera os recursos que a plataforma declara suportar. A própria política de Customer Match exige consentimento quando a lei ou as políticas aplicáveis o exigem e, ao mesmo tempo, mantém restrições para categorias sensíveis. Portanto, apresentar uma caixa marcada ou uma cláusula de privacidade não responde ao gate da plataforma.

Também não se deve presumir que aplicar hash resolve o problema. Hash muda a representação técnica de alguns identificadores; não muda a finalidade da campanha, o conteúdo promovido nem a origem sensível da relação. O artigo sobre hash e formulários de clínicas explica por que transformação técnica e elegibilidade são avaliações diferentes.

Quando Customer Match não é suportado, remova esse uso. Não reformule a base legal para mantê-lo. A clínica pode medir resultados internamente e avaliar outras formas permitidas de publicidade.

Um roteiro de decisão sem escolher a base legal

A equipe de mídia pode registrar fatos sem emitir conclusão jurídica. Dúvida em qualquer gate mantém o fluxo bloqueado.

  1. Defina a finalidade. Descreva o uso pretendido sem rótulos genéricos como “marketing” ou “melhoria”.
  2. Mapeie os dados. Liste origem, campos, titulares, retenção, compartilhamentos, acessos e destino.
  3. Classifique o contexto. Registre se a lista ou o conteúdo revela relação com saúde pessoal sensível.
  4. Encaminhe a análise da LGPD. Peça aos responsáveis qualificados que avaliem artigo 11, princípios e obrigações aplicáveis.
  5. Verifique Customer Match. Confirme origem própria, divulgações, consentimento quando exigido, elegibilidade da conta e políticas vigentes.
  6. Revise anúncio e destino. Compare serviço, texto, página e segmentação com a categoria de saúde sensível.
  7. Decida de forma independente. Registre resultado jurídico e resultado da plataforma em campos separados.
  8. Bloqueie por padrão. Não faça upload quando qualquer gate estiver reprovado, incerto ou vencido.

O registro deve conter fonte, data, responsável, versão do fluxo e próximo momento de revisão. Uma planilha com apenas “consentido” ou “aprovado” não identifica qual gate foi analisado. Se o caso envolver eventos de conversão em vez de audiência, consulte a arquitetura de formulários e Data Manager, pois a política de mensuração exige análise própria.

Erros que confundem legalidade com elegibilidade

  • Usar “dado próprio” como sinônimo de dado permitido em Customer Match.
  • Escolher uma base legal sem examinar finalidade, necessidade, contexto e papéis.
  • Tratar consentimento como renúncia às políticas da plataforma.
  • Presumir que hash remove o significado sensível do uso.
  • Concluir que toda publicidade de saúde está proibida.
  • Confundir política de audiência com política de mensuração de conversões.
  • Interpretar disponibilidade no painel ou sucesso da API como aprovação jurídica.
  • Guardar detalhes de atendimento em listas, nomes de audiência ou logs de mídia.

Resultados de saúde ou tratamento podem continuar em modelos internos sem entrar no payload ou na audiência. O guia sobre aceitação de tratamento como valor interno mostra como preservar a utilidade operacional sem expor esse detalhe ao Google Ads.

Perguntas frequentes

Uma base legal do artigo 11 autoriza Customer Match?

Não por si só. O artigo 11 trata das condições legais para tratamento de dados sensíveis. Customer Match tem requisitos e restrições próprios. A organização precisa de conclusão válida nos dois gates, e uma resposta favorável em um deles não substitui a outra.

Consentimento específico torna Customer Match permitido para saúde?

Não automaticamente. Consentimento pode integrar a análise da LGPD, conforme os fatos, mas não altera a classificação ou os recursos suportados pelo Google. Para conteúdo de saúde pessoal sensível, Customer Match aparece como não suportado na política consultada.

O Google proíbe todos os anúncios de clínicas?

Não é isso que a fonte diz. A página examinada trata de conteúdo de saúde pessoal sensível e das opções de segmentação associadas. Cada anúncio, serviço, destino e recurso precisa ser comparado com as políticas vigentes, sem transformar uma restrição específica em proibição geral.

Se Customer Match não for usado, o problema jurídico desaparece?

Não. A clínica ainda precisa avaliar qualquer tratamento de dados pessoais sensíveis que realize. Retirar um recurso da plataforma resolve apenas aquela parte do desenho. Coleta, armazenamento, acesso, compartilhamento e retenção continuam sujeitos à análise aplicável.

Referências

Adequação UE-Brasil: o que muda e o que não muda para dados de saúde

cmsapointoo on August 16, 2026

A adequação entre jurisdições pode simplificar uma transferência internacional, mas não transforma qualquer fluxo de dados de saúde em operação aprovada. No regime brasileiro, uma decisão de adequação reconhece que o destino oferece nível de proteção equivalente ao previsto pela LGPD. Esse reconhecimento responde à pergunta sobre o mecanismo da transferência. Finalidade, base legal, necessidade, transparência, segurança, contratos e governança continuam exigindo análise própria.

A expressão “adequação UE-Brasil” também pode sugerir uma reciprocidade que não deve ser presumida. Este artigo examina a perspectiva brasileira documentada pela ANPD: a transferência do Brasil para destino reconhecido como adequado. Uma decisão brasileira não substitui a análise da regra aplicável ao fluxo no sentido inverso. Registre direção, exportador, importador e sistemas envolvidos antes de citar a adequação.

O que uma decisão de adequação muda?

A Resolução CD/ANPD nº 19/2024 regulamenta a transferência internacional de dados e descreve a decisão de adequação como um dos mecanismos disponíveis. Segundo a página temática da ANPD, o reconhecimento permite transferências para o país ou organismo internacional adequado sem a adoção de mecanismos adicionais de transferência internacional. A simplificação é relevante: a organização não precisa encaixar aquele mesmo fluxo em cláusulas-padrão, cláusulas específicas ou outra hipótese de mecanismo apenas para superar a fronteira internacional.

Em 2026, a ANPD reconheceu a União Europeia como organismo internacional adequado por meio da Resolução CD/ANPD nº 32/2026, conforme informa sua página oficial sobre transferências. Esse efeito precisa ser descrito de forma estreita: a organização deve confirmar que destino, entidade e direção do fluxo estão dentro da decisão vigente, além de registrar eventuais condições. A Resolução nº 19/2024 prevê análise do nível de proteção da jurisdição estrangeira e permite revisão da decisão quando as condições relevantes mudam.

Na prática, a equipe ganha uma resposta para a coluna “mecanismo de transferência” do inventário. Não ganha uma aprovação geral para toda finalidade, todo fornecedor ou todo conjunto de dados. Essa distinção evita que uma decisão pública seja usada como atalho para uma decisão interna que nunca aconteceu.

O que a adequação não aprova automaticamente?

O artigo 4º da Resolução atribui ao controlador a verificação da caracterização da transferência, da aplicação da norma, da base legal válida e do mecanismo aplicável. O artigo 9º exige finalidade legítima, específica, explícita e informada, base legal prevista na LGPD e limitação ao mínimo necessário. Portanto, mesmo quando a adequação resolve o mecanismo internacional, as demais perguntas continuam abertas.

Pergunta O que a adequação responde O que continua separado
O destino tem proteção reconhecida? Sim, dentro do escopo da decisão vigente Confirmar entidade, direção e condições
Existe mecanismo de transferência? A decisão pode cumprir essa função Documentar por que ela alcança o fluxo concreto
O tratamento tem base legal? Não Identificar a base aplicável ao tratamento de dados de saúde
A finalidade é válida e transparente? Não Definir uso, comunicação e expectativa do titular
Os dados são mínimos e seguros? Não Reduzir campos e testar acesso, retenção e resposta a incidentes

Consentimento, contrato ou interesse operacional também não devem ser tratados como palavras mágicas. A base adequada depende do papel das partes e do tratamento efetivo. Uma equipe técnica pode documentar o fluxo e os controles, mas a qualificação jurídica precisa ser feita por responsáveis habilitados para o caso.

Como analisar dados de saúde sem ampliar o escopo?

Comece pelo fluxo, não pelo nome do fornecedor. Liste origem, destino, objetivo, categorias de dados, titulares, acessos humanos, retenção, exclusão, suporte, logs e cópias de recuperação. Depois separe o que fica no Brasil, o que cruza a fronteira e o que pode ser acessado remotamente a partir de outra jurisdição. O desenho deve mostrar também filas, exportações e ambientes de teste.

Dados de saúde recebem proteção reforçada na LGPD. A análise deve identificar a base do artigo 11 aplicável ao tratamento, além das demais obrigações pertinentes. Adequação não cria uma nova base legal. Se o objetivo é medir marketing, por exemplo, a equipe não deve concluir que o mecanismo internacional permite enviar detalhes de atendimento a uma plataforma externa. Consulte a arquitetura de formulários de clínica e Google Ads para manter coleta própria separada de qualquer destino publicitário.

A minimização precisa ser verificável. Compare cada campo com a finalidade documentada. Remova texto livre, detalhes clínicos e identificadores quando não forem indispensáveis. Defina retenção por sistema e finalidade, não por conveniência. Para resultados de marketing, a abordagem de medição de comparecimento sem detalhes da consulta mostra como obter sinal agregado sem copiar o conteúdo do atendimento.

Fornecedores e transferências posteriores continuam no mapa

Uma decisão de adequação alcança o destino nos termos em que foi emitida. Ela não torna invisível a cadeia de processamento. Identifique operador, subprocessadores, hospedagem, suporte, observabilidade, backup e recuperação. Confirme onde cada serviço trata ou permite acesso aos dados e se existe transferência posterior para outra jurisdição.

Contratos e instruções operacionais devem acompanhar o desenho real. Verifique finalidade, confidencialidade, controles de acesso, notificação de incidente, exclusão, devolução, auditoria e mudança de subcontratado. Não presuma que uma região de nuvem resolve os acessos de suporte, os logs globais ou uma exportação manual. O escopo técnico precisa corresponder ao registro jurídico e ao inventário de ativos.

Essa disciplina também ajuda quando um sistema externo controla um ponto do percurso. Se um link público ou agenda estiver em conta de terceiro, documente quem controla o link de agendamento no Google antes de avaliar a transferência. Titularidade da conta, destino do formulário e propriedade do banco podem pertencer a organizações diferentes.

Um teste em sete passos para cada fluxo

  1. Fixe a direção. Registre país de origem, país de destino, exportador, importador e possibilidade de acesso remoto.
  2. Defina a finalidade. Explique o resultado necessário sem recorrer a rótulos genéricos como “analytics” ou “melhoria”.
  3. Confirme a base legal. Separe a base do tratamento da escolha do mecanismo internacional.
  4. Verifique a adequação. Guarde o ato oficial, a data, o destino coberto, as condições e a justificativa de aplicação.
  5. Minimize. Revise campos, logs, anexos, identificadores, índices, backups e retenção.
  6. Mapeie a cadeia. Inclua operadores, subprocessadores, suporte e transferências posteriores.
  7. Aprove e monitore. Nomeie responsáveis, preserve evidências e defina gatilhos para reavaliação.

O registro final deve ser reproduzível por alguém que não participou da decisão. Uma frase como “destino adequado” é insuficiente. Prefira uma ficha com fonte oficial, versão do fluxo, sistemas, categorias de dados, fundamento, controles, contratos, questões abertas e aprovadores. Se um item estiver incerto, a saída segura é manter o fluxo bloqueado até a revisão.

Quando reabrir a análise?

Reabra a decisão quando mudar a finalidade, o conjunto de campos, a direção, o fornecedor, o subcontratado, a região, a política de retenção ou a forma de acesso. Faça o mesmo após incidente, mudança normativa ou revisão da decisão de adequação. Uma aprovação antiga não deve acompanhar silenciosamente uma arquitetura nova.

Use datas nas alegações voláteis. Em 16 de agosto de 2026, a página da ANPD apresenta o regime brasileiro e suas decisões no contexto da Resolução nº 19/2024. Antes de ativar um fluxo, volte às fontes oficiais e confira o ato específico aplicável. O inventário interno deve apontar para a fonte, não copiar uma conclusão sem contexto.

Perguntas frequentes

A adequação autoriza qualquer envio de dados de saúde para a União Europeia?

Não. Ela pode cumprir o requisito do mecanismo internacional para um fluxo dentro de seu escopo. Base legal, finalidade, necessidade, transparência, segurança, contratos e cadeia de fornecedores permanecem separados.

Uma decisão brasileira vale automaticamente para o fluxo da União Europeia ao Brasil?

Não presuma reciprocidade. Registre a direção do fluxo e verifique a decisão emitida pela autoridade competente para essa direção. Este artigo trata da perspectiva brasileira documentada pela ANPD.

Adequação elimina a necessidade de contrato com o operador?

Não. O mecanismo internacional não substitui a definição de papéis, instruções, segurança, retenção, incidentes, exclusão e supervisão da cadeia operacional.

Qual é a evidência mínima para uma decisão interna?

Guarde a fonte oficial datada, o mapa do fluxo, a finalidade, a base legal avaliada, a decisão de adequação aplicável, as medidas de minimização e segurança, os fornecedores envolvidos, as questões abertas e a aprovação responsável.

Referências