O consentimento não é uma caixa de seleção: Artigo 71 do EHDS tornou-o lei. Nós tornámo-lo funcional.
Três acordos chegaram no primeiro trimestre de 2026. Em conjunto somam USD 69 milhões e algo mais consequencial: uma prova estrutural de falha.
Kaiser Permanente chegou a acordo por USD 47,5 milhões. Sutter Health chegou a acordo por USD 21,5 milhões. ING Bank Śląski chegou a acordo por EUR 4,375 milhões. Abrangendo saúde e finanças, em três jurisdições diferentes. Cada organização tinha políticas de privacidade escritas. Cada uma tinha um painel de consentimento funcional. Os utilizadores podiam iniciar sessão, alternar preferências, atualizar os seus registos. A infraestrutura de consentimento estava, no sentido convencional, presente e funcional.
No entanto, cada organização perdeu a capacidade de honrar o consentimento no momento em que os dados cruzaram uma fronteira institucional.
O caso Kaiser documenta a sequência com precisão: uma rejeição de utilização secundária do paciente foi registada no sistema de gestão de consentimento, reconhecida pelo fornecedor de cuidados primários, e depois silenciosamente descartada quando o registo foi movido a jusante para um agregador de investigação. A rejeição não foi anulada. Não foi ignorada. Foi simplesmente invisível para o controlador a jusante — arquitetonicamente inacessível. O mesmo padrão repete-se nos processos de Sutter e ING. Uma preferência de consentimento que existe num sistema não pode ser lida por outro sistema que já recebeu os dados.
Esta não é uma falha de política. É uma falha de arquitetura. E explica por que razão os acordos de 2026 têm este aspeto.
A armadilha que o Artigo 71(8) criou
O Artigo 71 do EHDS entrou em vigor em 26 de março de 2025, sob o Reg. (UE) 2025/327. Torna a rejeição de utilização secundária um direito legal, não uma funcionalidade de cortesia. Uma pessoa pode retirar consentimento para a utilização dos seus dados de saúde para investigação, estatística ou formação — em qualquer momento, com a rejeição vinculativa para cada controlador que detenha os seus dados.
A resposta de engenharia óbvia é uma lista centralizada: manter um registo de identificadores rejeitados, verificar cada utilização a jusante em relação à lista, bloquear numa correspondência. Rápido, auditável, tratável.
O Artigo 71(8) fecha essa porta. Proíbe explicitamente registos de re-identificação — o mecanismo exato que torna uma lista centralizada de rejeição funcional. A lógica por trás da proibição é sólida: uma lista de identificadores correlacionados com decisões de rejeição é em si um conjunto de dados sensível. A sua existência cria risco de re-identificação. O regulamento foi escrito para evitar exatamente esse risco, pelo que não pode permitir o caminho de implementação mais óbvio para honrar o direito que cria.
Esta é a armadilha. O controlador não pode manter uma lista de quem rejeitou sem recriar o dano que o regulamento foi escrito para evitar. O Artigo 71 cria uma obrigação legal de honrar a rejeição através de fronteiras institucionais. O Artigo 71(8) impede a abordagem arquitetónica que tornaria isto viável para infraestrutura centralizada. O Considerando 54 acrescenta que a rejeição deve ser reversível e livremente exercível — sem fricção, sem re-registo, sem período de espera.
O regulamento é preciso. A implicação arquitetónica é radical.
Cinco invariantes. Zero arquiteturas que as satisfaçam todas — até agora.
Retire a linguagem legal e leia o que os reguladores realmente exigem. Em todo o Artigo 71 do EHDS, Artigos 7(3) e 17(2) do GDPR, e Artigo 5a do eIDAS 2.0, cinco invariantes de engenharia emergem:
Identificadores com âmbito de pessoa. A rejeição deve ser atribuível a uma pessoa específica, não a uma sessão, dispositivo ou conta. O identificador deve sobreviver a fronteiras institucionais.
Rejeição verificável com marca temporal. Um controlador deve conseguir provar quando a rejeição foi registada e que não foi adulterada. Registos auto-reportados são insuficientes; provas criptográficas são necessárias.
Reversibilidade sem re-identificação. O Artigo 71(8) do EHDS nomeia isto explicitamente. A pessoa pode reverter a sua rejeição sem que a reversão exija a criação de um registo de identidade vinculável.
Propagação entre controladores. O Artigo 17(2) do GDPR exige que uma rejeição de consentimento chegue a cada processador a jusante. A obrigação não para no controlador que recebeu o consentimento original.
Não-vinculabilidade. O Artigo 5a(16)(b) do eIDAS 2.0 exige que as interações de identidade sejam não-vinculáveis em contextos, de modo que a rejeição não possa ser explorada para construir um perfil inter-institucional.
Estas cinco invariantes estão nomeadas em lei primária. Não são posições interpretativas. E criam um teste preciso para qualquer arquitetura de consentimento: satisfaz todas as cinco?
X.509 PKI satisfaz zero. Uma cadeia de certificados pode confirmar a identidade de um servidor, mas não fornece mecanismo para identificadores com âmbito de pessoa que sobrevivam a fronteiras institucionais, nenhum registo de rejeição criptográfico independente dos próprios registos do controlador, e nenhuma não-vinculabilidade — por design, X.509 depende da CA conhecer quem você é.
A identidade federada satisfaz propagação — quando um fornecedor federado recebe uma rejeição, pode propagá-la aos fornecedores de confiança. Mas satisfaz propagação apenas violando não-vinculabilidade. O fornecedor de federação tem uma visão completa de qual pessoa interagiu com qual instituição. Essa vinculabilidade é o que torna a propagação funcional. É também o que o Artigo 5a(16)(b) proíbe.
DKMS satisfaz todas as cinco.
Por que razão DKMS é a resposta — e o que isso significa na prática
Decentralized Key Management é a primeira fundação estruturalmente sólida para honrar a rejeição ponta a ponta em condições inter-organizacionais, pós-divulgação, sob vigilância regulatória. A frase qualificadora é importante. Em cargas de trabalho de um único inquilino, dentro do perímetro de uma única instituição, abordagens mais simples são adequadas. O problema estrutural apenas aparece quando os dados cruzaram uma fronteira — quando a pessoa que exerce a sua rejeição já não está a interagir com o primeiro controlador.
O mecanismo funciona da seguinte forma. Cada pessoa detém um identificador auto-certificante — um Identificador Autónomo, ou AID — que serve como raiz criptográfica das suas autorizações de consentimento. Este AID não é registado com qualquer autoridade central. É auto-gerado e controlado integralmente pela pessoa que o detém. DKMS é construído sobre KERI, uma especificação aberta da Trust over IP Foundation, que define como estes identificadores funcionam e como as mudanças se propagam.
Junto ao AID está um Registo de Eventos-Chave — um registo resistente a adulterações, criptograficamente encadeado, de cada autorização e rejeição. Quando uma pessoa rejeita utilização secundária, essa rejeição é registada como um evento-chave: com marca temporal, assinado, e anexado ao registo. Qualquer controlador a jusante que detenha os dados da pessoa pode verificar o estado atual da autorização lendo o registo diretamente — nenhum registo central, nenhuma chamada para uma base de dados partilhada, nenhuma re-identificação.
Quando uma pessoa reverte a sua rejeição, essa reversão é também um evento-chave. O sujeito impulsiona a rotação. A obrigação do controlador é verificar, não manter a sua própria interpretação do estado.
A propagação entre controladores resulta da estrutura do registo. A Instituição B, que recebeu dados da Instituição A, não precisa de receber uma notificação da Instituição A. Pode ler o registo ela própria. A propagação é baseada em pull e pronta para auditoria.
Onde DKMS não entrega
Honestidade sobre o âmbito é o que torna a tese defensável.
Os dados que foram utilizados para treinar um modelo não podem ser desaprendidos por uma rotação de chaves. Um conjunto de dados derivado — um agregado, um subconjunto anonimizado, um artefato estatístico — não retém qualquer conexão ao AID da pessoa original. A rejeição não pode chegar a esses derivados. DKMS pode fornecer deteção forense de quando os dados foram utilizados antes da rejeição ser registada; não pode desfazer a utilização.
As cópias de segurança feitas antes da rejeição estão sujeitas aos mesmos limites. A cópia de segurança existe fora da cadeia de autorização. Alcançá-la requer uma decisão de política separada, que DKMS pode informar mas não pode aplicar autonomamente.
Uma única contraparte desonesta pode ignorar o registo. DKMS não é uma função de imposição de conformidade para atores que escolhem violar as suas obrigações legais. O que fornece é um registo auditável que torna a violação visível e comprovável — que é exatamente o que os reguladores e tribunais precisam para atribuir responsabilidade. Os acordos de 2026 foram difíceis de resolver precisamente porque o estado de consentimento era ambíguo em cada fronteira institucional. DKMS remove essa ambiguidade.
As cargas de trabalho de um único inquilino dentro do perímetro de uma única instituição não precisam de DKMS para aplicação de consentimento. Os sistemas existentes de gestão de consentimento funcionam adequadamente quando os dados nunca cruzam uma fronteira. O requisito estrutural ativa-se na fronteira.
Dizer isto antecipadamente não é fraqueza. É o que distingue um argumento arquitetónico de uma afirmação de produto.
Em produção
A implementação de Vereign com Health Info Net AG da Suíça processa 800.000+ mensagens verificadas por mês. Este número representa comunicações processadas por SEAL — o sistema de entrega de enxame criptografado que serve como canal seguro do HIN para destinatários fora da rede profissional. É a prova de produção de que a arquitetura subjacente é escalável para cargas de trabalho institucionais em saúde.
Stargate — a infraestrutura de confiança completa que adiciona identidade descentralizada, camadas de autorização, e trilhas de auditoria criptográficas em cima desse canal seguro — entrou em produção inicial a partir de junho de 2026. A narrativa de lançamento em massa estará disponível após verão de 2026 conforme a implementação se amplia.
FHIR-over-Stargate é arquitetónico — a implementação em produção depende da integração hospitalar; mais cedo plausível setembro de 2026. Troca de dados clínicos via FHIR com a camada de aplicação de consentimento de Stargate inline é a arquitetura alvo para conformidade com o Artigo 71 do EHDS. As peças estão no lugar. O cronograma depende da integração instituição-por-instituição, não de engenharia adicional.
Essa é a imagem honesta. A arquitetura é sólida. A linha de base de produção existe. O caminho da produção atual para conformidade total com o Artigo 71 do EHDS está definido e em progresso.
A análise de arquitetura de consentimento
A tese técnica completa — cinco invariantes, detalhe de mecanismo, citações regulatórias, ressalvas de limites de honestidade, tabela de comparação entre X.509 / IAM federada / DKMS — está em /consent/.
Se a sua organização está a trabalhar através de implementação do Artigo 71 do EHDS, obrigações de propagação do Artigo 17(2) do GDPR, ou as decisões de arquitetura de consentimento que vêm com troca de dados baseada em FHIR, uma análise de arquitetura de consentimento de 30 minutos mapeia a sua situação específica contra estas invariantes. Reserve uma aqui.