Arquitetura de consentimento

O consentimento não é uma caixa de verificação.

O RGPD exige-o desde 2018; EHDS Article 71 tornou-o exigível no ano passado. Decentralized Key Management é a única arquitetura capaz de honrar a retirada do consentimento através das fronteiras institucionais.

Agendar uma revisão de arquitetura de consentimento de 30 minutos

Cinco regimes a convergir numa janela de 24 meses

O consentimento deixou de ser uma conveniência organizacional. Em toda a Europa e na Suíça, cinco regimes regulatórios distintos tornaram a opt-out uma obrigação legal vinculativa — e cada um foi redigido de forma independente dos outros. Partilham uma característica: pressupõem que o responsável pelo tratamento de dados consegue interromper o uso de dados identificáveis a pedido, propagar essa paragem a todas as partes a jusante e prová-lo posteriormente. A infraestrutura de identidade centralizada nunca foi concebida para nenhuma dessas garantias.

  • EHDS Article 71

    Em vigor desde 26 de março de 2025

    Opt-out como direito legal; Article 71(8) impede registos de re-identificação; Recital 54 impõe a reversibilidade.

  • GDPR Art 7(3) + Art 17(2)

    Em vigor desde 25 de maio de 2018

    A retirada deve ser tão fácil quanto a concessão do consentimento; os responsáveis pelo tratamento devem propagar o apagamento a todos os destinatários a jusante.

  • eIDAS 2.0 Article 5a

    Em vigor desde 20 de maio de 2024; carteiras até ao 4.º trimestre de 2026

    Carteiras de identidade controladas pelo cidadão com divulgação seletiva e obrigações de não-correlação sobre as partes confiantes.

  • FADP / HFG suíço

    FADP em vigor desde 1 de setembro de 2023; revisão da HFG em consulta

    Dever de retirada do consentimento para uso secundário em investigação; proibição expressa de re-identificação de dados pseudonimizados.

  • PDSG alemão

    Em vigor desde 20 de outubro de 2020

    Acesso controlado pelo paciente aos registos ePA; opt-out granular por categoria de dados, aplicável entre prestadores.

Cada um isoladamente é gerível. Juntos, tornam a arquitetura CA centralizada insuficiente.

Os cinco invariantes de engenharia

Leia os cinco regimes como o faria um engenheiro. Retire a linguagem jurídica e o que fica é uma lista de cinco invariantes técnicos que a infraestrutura de implementação tem de satisfazer. Nenhum é opcional. Nenhum é negociável através de linguagem contratual razoável. Cada um está nomeado, por cláusula, em legislação primária.

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparação: qual arquitetura satisfaz cada invariante de engenharia. O X.509 satisfaz zero. A federação satisfaz zero (a propagação apenas violando a não-correlação). O DKMS satisfaz os cinco. Invariante de engenharia X.509 PKI IAM Federado DKMS Identificadores com âmbito pessoal ✗ i ✗ ✓ Opt-out verificável com carimbo temporal ✗ ✗ ✓ Reversibilidade sem re-identificação ✗ ✗ ✓ Propagação entre responsáveis pelo tratamento ✗ i ✗ i ✓ i Não-correlação ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Clique num (i) para a justificação · Clique para expandir o diagrama

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparação: qual arquitetura satisfaz cada invariante de engenharia. O X.509 satisfaz zero. A federação satisfaz zero (a propagação apenas violando a não-correlação). O DKMS satisfaz os cinco. Invariante de engenharia X.509 PKI IAM Federado DKMS Identificadores com âmbito pessoal ✗ i ✗ ✓ Opt-out verificável com carimbo temporal ✗ ✗ ✓ Reversibilidade sem re-identificação ✗ ✗ ✓ Propagação entre responsáveis pelo tratamento ✗ i ✗ i ✓ i Não-correlação ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Por que razão o X.509 não consegue fornecer identificadores com âmbito pessoal

O X.509 identifica entidades através de certificados emitidos por uma Autoridade de Certificação, não através de chaves controladas pelo sujeito. O cidadão não tem qualquer agência arquitetónica na raiz da confiança — a CA decide quem é quem. EHDS Recital 54 e eIDAS 2.0 Article 5a exigem identificadores controlados pelo sujeito; o X.509 satisfaz este requisito apenas envolvendo a PKI numa cerimónia do lado do sujeito que o protocolo subjacente não suporta nativamente.

Por que razão o X.509 não consegue propagar a retirada

O X.509 não dispõe de primitiva nativa de propagação. A revogação propaga-se através de CRL e respondedores OCSP que cada verificador tem de optar explicitamente por consultar — e não existe forma de empurrar uma revogação para dados já partilhados. Uma vez que um certificado tenha assinado autorização para um fluxo de dados, a retirada fica ao critério do verificador.

Por que razão o X.509 viola a não-correlação

Cada certificado X.509 contém um número de série estável e um DN do emissor visíveis a cada verificador. Duas partes confiantes podem correlacionar o mesmo sujeito entre transações comparando os números de série. A pseudonimização exige nova emissão, operacionalmente dispendiosa — a correlação é aqui uma escolha de conceção, não um defeito.

Por que razão a federação apenas satisfaz parcialmente a propagação

O IAM Federado satisfaz a propagação entre responsáveis pelo tratamento apenas violando a não-correlação — o fornecedor de identidade vê todos os inícios de sessão em cada parte confiante, criando uma superfície de correlação entre RP proibida (eIDAS 2.0 Art 5a(16)(b)). A propagação via federação é por isso considerada não satisfeita.

Por que razão a federação não consegue garantir a não-correlação

Um fornecedor de identidade federado vê todas as tentativas de início de sessão em cada parte confiante. Mesmo que as credenciais individuais sejam pseudónimas, o IdP detém por construção o grafo de correlação entre RP. eIDAS 2.0 Article 5a(16)(b) proíbe precisamente esta superfície.

Como o DKMS propaga a retirada

As autorizações encadeiam-se ao Key Event Log (KEL) do sujeito. Quando o sujeito roda as chaves, cada verificador a jusante que volta a verificar o KEL no momento do processamento vê a rotação e trata as credenciais obsoletas como inválidas. Sem push de operador, sem registo central — a propagação é verifier-pull no momento de utilização.

Como o DKMS preserva a não-correlação

Os sujeitos podem cunhar um AID novo para cada parte confiante. O KEL por trás de cada AID é independente — não existe registo central de identidade nem IdP que veja todas as transações. A correlação entre RP exige que o sujeito ligue deliberadamente os AID.

  1. Identificadores com âmbito pessoal

    O identificador que o titular dos dados controla tem de ser a raiz de confiança, e não um identificador emitido por uma parte confiante. O EHDS Recital 54 e o eIDAS 2.0 Article 5a nomeiam-no diretamente: o cidadão tem de poder agir sem que o responsável pelo tratamento o consulte num registo separado. Qualquer arquitetura que dependa de o responsável pelo tratamento cunhar e armazenar o identificador falha aqui logo no primeiro dia.

  2. Opt-out verificável com carimbo temporal

    A retirada tem de ser um evento assinado criptograficamente e com carimbo temporal que o regulador (e um tribunal futuro) possa verificar sem confiar nos registos do responsável pelo tratamento. O GDPR Article 7(3) torna isso explícito: o responsável pelo tratamento suporta o ónus da prova. Uma linha numa base de dados interna não constitui prova em qualquer fórum onde o responsável pelo tratamento seja o réu.

  3. Reversibilidade sem re-identificação

    O Recital 54 do EHDS exige que a opt-out permaneça reversível — o cidadão pode voltar a optar por participar — sem que ninguém tenha de re-identificar os registos subjacentes. Isso exige que a opt-out opere sobre uma credencial que o titular controla, e não contra uma tabela de mapeamento do lado do servidor. Os registos de consentimento centralizados falham aqui de forma estrutural.

  4. Propagação entre responsáveis pelo tratamento

    O GDPR Article 17(2) e o EHDS Article 71 exigem que a retirada se propague a todos os destinatários a jusante. Na prática, isso significa que o responsável pelo tratamento original não pode simplesmente atualizar a sua linha local — cada parte que alguma vez recebeu os dados tem de re-autenticar a autorização e verificar que foi revogada. A federação só consegue fazer isso partilhando identificadores, o que viola o próximo invariante.

  5. Não-correlação

    O eIDAS 2.0 Article 5a exige que as partes confiantes não consigam correlacionar o mesmo cidadão em transações distintas sem consentimento. O Article 71(8) do EHDS impede o identificador centralizado entre organizações que tornaria a propagação federada trivial. Os dois invariantes em conjunto — propagar, mas não correlacionar — são o que inviabiliza as arquiteturas convencionais.

O X.509 não satisfaz nenhum. A federação satisfaz a propagação violando a não-correlação. O DKMS satisfaz os cinco.

A armadilha do Article 71(8)

A resposta de engenharia intuitiva a "respeitar a opt-out em toda a rede" é manter uma lista de identificadores que optaram por sair — um registo de não-processamento mantido centralmente que cada sistema a jusante consulta antes de tratar um registo. O Article 71(8) do EHDS proíbe especificamente esta construção. A cláusula proíbe os detentores de dados de adquirir ou armazenar dados de identificação adicionais unicamente com o objetivo de respeitar as opt-outs.

O raciocínio, explicitado no Recital 54, é que o próprio registo se torna uma base de dados de re-identificação — precisamente o dano que a regulamentação visava prevenir. Ao manter uma lista de "pessoas que optaram por sair", recria-se o ponto central de vulnerabilidade. A implicação estrutural é inevitável: o sinal de opt-out tem de viajar com uma credencial que o titular controla, e não numa lista que o responsável pelo tratamento mantém.

The DKMS thesis O DKMS é a resposta

A Gestão Descentralizada de Chaves é a primeira base estruturalmente sólida para honrar a retirada do consentimento de ponta a ponta em condições inter-organizacionais, pós-divulgação, sob supervisão regulatória.

(A Gestão Descentralizada de Chaves baseia-se em KERI, uma especificação aberta da Trust over IP Foundation.)

Como funciona:

  1. O AID de controlo do utilizador é a raiz de confiança. As autorizações encadeiam-se a ele criptograficamente, e não a uma conta emitida pelo responsável pelo tratamento.
  2. Cada autorização está ancorada no Key Event Log (KEL) do AID — um registo apenas-anexável e encadeado por hash que o titular pode provar unilateralmente.
  3. A retirada é uma rotação de chaves realizada pelo próprio titular. A chave antiga é invalidada; o evento de rotação é assinado e tem carimbo temporal no KEL.
  4. As partes a jusante que detêm credenciais desatualizadas têm de re-autenticar contra o estado mais recente do KEL. A retirada propaga-se por falhar de forma segura em cada verificador a jusante.

Nada no protocolo exige um operador central. Nada exige que as partes confiantes partilhem identificadores. Nada exige que o regulador confie nos registos do responsável pelo tratamento em detrimento dos do titular. Cada um dos cinco invariantes é satisfeito pela construção, e não pela auditoria.

Onde o DKMS domina — e onde não oferece vantagem

A honestidade sobre o âmbito é o que torna a tese defensável. O DKMS domina em quatro condições: fluxos de dados entre organizações, retirada pós-divulgação, processamento sob supervisão regulatória e contrapartes adversariais. Fora dessas condições — cargas de trabalho de inquilino único, artefactos derivados como pesos de modelos de ML treinados, cópias de segurança já realizadas antes da retirada e contrapartes individualmente desonestas — o DKMS fornece deteção forense mas não prevenção.

Onde o DKMS domina Onde o DKMS não oferece vantagem Fluxos de dados entre organizações Clique numa linha para a justificação Persistência do consentimento pós-divulgação Clique numa linha para a justificação Custódia determinativa pelo regulador Clique numa linha para a justificação Partes compõem DKMS de ponta a ponta Clique numa linha para a justificação Derivados (análises, pesos de modelos de ML) Clique numa linha para a justificação Cópias de segurança já realizadas Clique numa linha para a justificação Contraparte individualmente desonesta Clique numa linha para a justificação Cargas de trabalho de inquilino único Clique numa linha para a justificação Onde o DKMS domina — e onde não oferece vantagem. Clique numa linha para a justificação.

Fluxos de dados entre organizações

O apagamento do lado do operador não consegue alcançar dados já partilhados com partes a jusante. O DKMS estende o encriptamento controlado pelo titular ao longo da cadeia de processamento — cada recetor re-verifica o KEL no momento da utilização. O CMK centralizado fornece apagamento apenas dentro do limite de inquilino do operador.

Persistência do consentimento pós-divulgação

O EUDIW ARF §6.6 admite explicitamente que a retirada não desfaz retroativamente o processamento anterior lícito. O DKMS reduz esta lacuna: os verificadores re-verificam o KEL publicado no momento do processamento, pelo que as credenciais desatualizadas se tornam auditáveis como tal. O primitivo arquitetónico é controlado pelo titular, não pelo operador.

Custódia determinativa pelo regulador

O Schrems II / EDPB Recommendations 01/2020 Caso de uso 3 exigem que o importador de dados NÃO detenha as chaves. O CMK centralizado falha este teste por definição (p. ex., dados de saúde dos EUA no Azure sob acesso FISA 702). O DKMS torna a custódia de chaves uma propriedade do lado do titular — o importador não consegue desencriptar sem o estado KEL contínuo do titular.

Partes compõem DKMS de ponta a ponta

A arquitetura só é eficaz quando todas as partes a aplicam. Um verificador que ignore o KEL anula a cadeia. Quando todas as partes compõem DKMS, a retirada propaga-se por simples re-verificação — nenhum operador precisa de "enviar" a eliminação.

Derivados (análises, pesos de modelos de ML)

O EDPB Opinion 28/2024 confirma explicitamente que as obrigações de apagamento não se propagam de forma limpa para os pesos de modelos uma vez concluído o treino. O DKMS não oferece melhor cobertura do que o CMK aqui. A retirada não pode desfazer retroativamente resultados de análises ou relatórios regulatórios já submetidos.

Cópias de segurança já realizadas

Nenhuma arquitetura consegue recuperar dados já replicados para suportes de cópia de segurança imutáveis ou offline. A encriptação em repouso mais a destruição de chaves trata os resíduos dentro da janela de retenção; não recupera arquivos de longo prazo. O DKMS não altera esta propriedade fundamental.

Contraparte individualmente desonesta

O DKMS fornece deteção forense (as assinaturas posteriores à rotação de chave publicada são auditáveis como desatualizadas) mas não prevenção. Um subcontratante totalmente não cooperante que desencripta texto em claro e o armazena fora do envelope encriptado anula a cadeia — o DKMS deteta a violação em vez de a bloquear.

Cargas de trabalho de inquilino único

Para SaaS sob um único responsável pelo tratamento, o apagamento criptográfico via CMK centralizado segundo o NIST SP 800-88 §2.5 é adequado e mais simples. Mudar para DKMS acrescenta carga operacional sem benefício arquitetónico quando não existem fronteiras entre domínios de confiança.

Fora das quatro condições em que o DKMS domina, o CMK centralizado é racional. Dizê-lo torna a tese mais forte.

Prova em produção

HIN — Health Info Net — é a espinha dorsal suíça da informação de saúde, ligando hospitais, clínicas e prestadores especializados para além das fronteiras cantonais. SEAL, a camada de entrega de email verificável que a Vereign disponibiliza dentro do HIN, está hoje em produção e transporta mais de 800.000 mensagens verificadas por mês — prova de que a Vereign já opera infraestrutura de nível produtivo dentro do sistema de saúde suíço.

Stargate, o runtime de Decentralized Key Management que coloca em uso operacional o mecanismo de retirada em quatro passos descrito acima, entra em produção antecipada em junho de 2026.

A camada FHIR do Stargate — as mesmas garantias aplicadas à troca de registos clínicos, e não apenas a mensagens — é hoje arquitetural. A sua passagem para produção depende do onboarding do lado hospitalar; a data mais realista é setembro de 2026.

Cinco incidentes que provam o padrão estrutural

  1. Kaiser Foundation Health Plan — acordo de ação coletiva de 47,5 milhões USD (2026). Dados do portal de pacientes divulgados a plataformas de publicidade através de píxeis de rastreio incorporados. A arquitetura não dispunha de mecanismo para o titular revogar a propagação a jusante.
  2. Sutter Health — acordo de ação coletiva de 21,5 milhões USD (2026). Mesmo padrão: etiquetas de terceiros no portal, sem primitiva de revogação controlada pelo titular, sem forma de provar a não-utilização após o facto.
  3. NHS National Data Opt-Out (2021) — admissão de não-retroatividade; o programa GPDPR foi adiado porque a arquitetura não conseguia respeitar a retirada contra dados já partilhados com investigadores a jusante.
  4. SingHealth (2018) — 1,5 milhões de registos comprometidos porque os dados dos pacientes residiam numa única base de dados monolítica sem fronteiras criptográficas por paciente. Não havia nada para o titular revogar; não havia chave a rodar.
  5. DigiNotar (2011) — o comprometimento da AC raiz levou os navegadores a desconfiar de todos os certificados que a AC alguma vez emitiu. Os titulares não tinham agência arquitetónica: os seus identificadores e relações de confiança eram inteiramente controlados pelo operador.

Cada incidente centralizado partilha uma característica: o utilizador não tinha agência arquitetónica.

Por onde começar

Se a sua organização trata dados identificáveis de saúde, financeiros ou pessoais regulados e está exposta a qualquer um dos cinco regimes acima, o próximo passo é uma revisão de arquitetura de 30 minutos. Mapeamos o seu fluxo de consentimento atual em relação aos cinco invariantes, identificamos as lacunas e informamos honestamente se o DKMS é a resposta certa para o seu ambiente.

Agendar uma revisão de arquitetura de consentimento de 30 minutos Descarregar a tese de consentimento (PDF, 24 páginas)

Para o seu setor

Aplicação do consentimento nos cuidados de saúde

Ler mais

Aplicação do consentimento nas finanças

Ler mais

Perguntas frequentes

O que exige o EHDS Article 71?
O EHDS Article 71 (em vigor desde 26 de março de 2025) confere a todos os cidadãos da UE o direito de se opor ao uso secundário de dados de saúde identificáveis. O Article 71(8) proíbe os detentores de dados de adquirir dados de identificação adicionais unicamente para honrar a opt-out — excluindo implementações de tipo "lista de IDs excluídos" porque a própria lista é um registo de re-identificação proibido. O Recital 54 impõe que a opt-out seja reversível e livre de condições.
Por que razão um registo de consentimento centralizado não pode funcionar?
O Article 71(8) proíbe-o explicitamente. O próprio registo torna-se um registo de re-identificação — precisamente o que a regulamentação visava prevenir. A resposta estrutural exige identificadores controlados pelo titular, e não uma lista controlada por um operador central.
O DKMS garante a aplicação do consentimento?
Não. O DKMS é a primeira base estruturalmente sólida para honrar a retirada do consentimento de ponta a ponta em condições inter-organizacionais, pós-divulgação e sob supervisão regulatória. Fora dessas condições — cargas de trabalho de inquilino único, derivados como pesos de modelos de ML, cópias de segurança já realizadas, contrapartes individualmente desonestas — o DKMS fornece deteção forense mas não prevenção.
Como é que o DKMS interopera com contrapartes X.509 / S/MIME?
Através de pontes S/MIME ancoradas em KERI que permitem a propagação da retirada entre partes que utilizam X.509. A ponte ancora o certificado X.509 a um AID KERI; a retirada do consentimento desencadeia a rotação da chave do AID; os verificadores X.509 a jusante têm de re-obter e re-autenticar.