Arquitectura del consentimiento

El consentimiento no es una casilla de verificación.

El RGPD lo exige desde 2018; EHDS Article 71 lo hizo exigible el año pasado. Decentralized Key Management es la única arquitectura capaz de honrar la retirada del consentimiento a través de las fronteras institucionales.

Reserve una revisión de arquitectura del consentimiento de 30 minutos

Cinco regímenes convergiendo en una ventana de 24 meses

El consentimiento ya no es un complemento organizativo deseable. En Europa y Suiza, cinco regímenes reguladores independientes han convertido la exclusión voluntaria en una obligación legal estricta — y cada uno fue redactado de forma independiente de los demás. Comparten una característica: asumen que el responsable del tratamiento puede dejar de usar datos identificables a demanda, propagar esa parada a todas las partes posteriores y demostrarlo después. La infraestructura de identidad centralizada nunca fue diseñada para ninguna de esas garantías.

  • EHDS Article 71

    En vigor el 26 de marzo de 2025

    La exclusión voluntaria como derecho legal; Article 71(8) impide los registros de reidentificación; Recital 54 exige la reversibilidad.

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

    En vigor desde el 25 de mayo de 2018

    La retirada debe ser tan fácil como otorgar el consentimiento; los responsables deben propagar la supresión a todos los destinatarios posteriores.

  • eIDAS 2.0 Article 5a

    En vigor el 20 de mayo de 2024; carteras para el 4.º trimestre de 2026

    Carteras de identidad controladas por el ciudadano con divulgación selectiva y obligaciones de no vinculabilidad para las partes que confían.

  • FADP / HFG suiza

    FADP en vigor el 1 de septiembre de 2023; enmienda HFG en consulta

    Obligación de retirada del consentimiento para uso secundario en investigación; prohibición expresa de reidentificación de datos seudonimizados.

  • PDSG alemán

    En vigor desde el 20 de octubre de 2020

    Acceso controlado por el paciente a los registros ePA; exclusión voluntaria granular por categoría de datos exigible ante todos los proveedores.

Cada uno por separado es asumible. Juntos hacen insuficiente la arquitectura CA centralizada.

Los cinco invariantes de ingeniería

Lea los cinco regímenes como lo haría un ingeniero. Elimine el lenguaje jurídico y lo que queda es una lista de cinco invariantes técnicos que la infraestructura de implementación debe satisfacer. Ninguno es opcional. Ninguno puede eliminarse mediante un lenguaje contractual razonable. Cada uno está nombrado, por cláusula, en el derecho primario.

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparación: qué arquitectura satisface qué invariante de ingeniería. X.509 satisface cero. La federación satisface cero (la propagación únicamente violando la no vinculabilidad). DKMS satisface los cinco. Invariante de ingeniería X.509 PKI IAM federado DKMS Identificadores vinculados a la persona ✗ i ✗ ✓ Exclusión voluntaria verificable con marca de tiempo ✗ ✗ ✓ Reversibilidad sin reidentificación ✗ ✗ ✓ Propagación entre responsables ✗ i ✗ i ✓ i No vinculabilidad ✗ 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

Haga clic en una (i) para el razonamiento · Haga clic para ampliar el diagrama

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparación: qué arquitectura satisface qué invariante de ingeniería. X.509 satisface cero. La federación satisface cero (la propagación únicamente violando la no vinculabilidad). DKMS satisface los cinco. Invariante de ingeniería X.509 PKI IAM federado DKMS Identificadores vinculados a la persona ✗ i ✗ ✓ Exclusión voluntaria verificable con marca de tiempo ✗ ✗ ✓ Reversibilidad sin reidentificación ✗ ✗ ✓ Propagación entre responsables ✗ i ✗ i ✓ i No vinculabilidad ✗ 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 qué X.509 no puede ofrecer identificadores vinculados a la persona

X.509 identifica a las entidades mediante certificados emitidos por una Autoridad de Certificación, no mediante claves controladas por el sujeto. El ciudadano carece de agencia arquitectónica en la raíz de confianza — la CA decide quién es quién. EHDS Recital 54 y eIDAS 2.0 Article 5a exigen identificadores controlados por el sujeto; X.509 satisface este requisito solo envolviendo la PKI en una ceremonia del lado del sujeto que el protocolo subyacente no soporta de forma nativa.

Por qué X.509 no puede propagar la retirada

X.509 carece de primitiva nativa de propagación. La revocación se propaga mediante CRL y servidores OCSP que cada verificador debe optar explícitamente por consultar — y no existe forma de empujar una revocación hacia atrás a los datos ya compartidos. Una vez que un certificado ha firmado la autorización para un flujo de datos, la retirada queda a discreción del verificador.

Por qué X.509 viola la no vinculabilidad

Cada certificado X.509 lleva un número de serie estable y un DN de emisor visibles para cada verificador. Dos partes que confían pueden correlacionar al mismo sujeto entre transacciones comparando números de serie. La seudonimización exige una nueva emisión, que resulta operativamente costosa — la vinculabilidad aquí es una decisión de diseño, no un defecto.

Por qué la federación solo satisface parcialmente la propagación

El IAM federado satisface la propagación entre responsables únicamente violando la no vinculabilidad — el proveedor de identidad ve cada inicio de sesión en las partes que confían, creando una superficie de correlación entre RP prohibida (eIDAS 2.0 Art 5a(16)(b)). Por tanto, la propagación mediante federación se considera no satisfecha.

Por qué la federación no puede ofrecer no vinculabilidad

Un proveedor de identidad federado ve cada intento de inicio de sesión en cada parte que confía. Aunque las credenciales individuales sean seudónimas, el IdP mantiene por construcción el grafo de correlación entre RP. eIDAS 2.0 Article 5a(16)(b) prohíbe precisamente esta superficie.

Cómo DKMS propaga la retirada

Las autorizaciones se encadenan al Registro de Eventos de Clave (Key Event Log, KEL) del sujeto. Cuando el sujeto rota las claves, cada verificador aguas abajo que vuelve a comprobar el KEL en el momento del procesamiento ve la rotación y trata las credenciales obsoletas como inválidas. Sin push del operador, sin registro central — la propagación es verifier-pull en el momento de uso.

Cómo DKMS preserva la no vinculabilidad

Los sujetos pueden acuñar un AID nuevo para cada parte que confía. El KEL detrás de cada AID es independiente — no existe registro central de identidad ni IdP que vea cada transacción. La correlación entre RP requiere que el sujeto vincule deliberadamente los AID.

  1. Identificadores vinculados a la persona

    El identificador que controla el interesado debe ser la raíz de confianza, no un identificador emitido por una parte que confía. Tanto EHDS Recital 54 como eIDAS 2.0 Article 5a lo establecen directamente: el ciudadano debe poder actuar sin que el responsable tenga que buscarlo en un registro separado. Toda arquitectura que dependa de que el responsable acuñe y almacene el identificador fracasa aquí desde el primer día.

  2. Exclusión voluntaria verificable con marca de tiempo

    La retirada debe ser un evento firmado criptográficamente y con marca de tiempo que el regulador (y un tribunal futuro) puedan verificar sin necesidad de confiar en los registros del responsable. GDPR Article 7(3) lo establece explícitamente: el responsable carga con la prueba. Una fila en una base de datos interna no es evidencia en ningún foro en el que el responsable sea el demandado.

  3. Reversibilidad sin reidentificación

    Recital 54 del EHDS exige que la exclusión voluntaria sea reversible — el ciudadano puede volver a incluirse — sin que nadie tenga que reidentificar los registros subyacentes. Eso requiere que la exclusión voluntaria opere sobre una credencial que controla el interesado, no contra una tabla de mapeo en el servidor. Los registros de consentimiento centralizados fracasan aquí estructuralmente.

  4. Propagación entre responsables

    Tanto GDPR Article 17(2) como EHDS Article 71 exigen que la retirada se propague a todos los destinatarios posteriores. En la práctica, esto significa que el responsable original no puede simplemente actualizar su fila local — toda parte que haya recibido los datos alguna vez debe reautenticar la autorización y descubrir que ha sido revocada. La federación solo puede hacerlo compartiendo identificadores, lo que viola el siguiente invariante.

  5. No vinculabilidad

    eIDAS 2.0 Article 5a exige que las partes que confían sean incapaces de correlacionar al mismo ciudadano en transacciones separadas sin consentimiento. Article 71(8) del EHDS impide el identificador centralizado interorganizativo que haría trivial la propagación federada. Los dos invariantes juntos — propagar, pero no correlacionar — son los que destruyen las arquitecturas convencionales.

X.509 satisface cero. La federación satisface la propagación violando la no vinculabilidad. DKMS satisface los cinco.

La trampa del Article 71(8)

La respuesta intuitiva de ingeniería ante "respetar la exclusión voluntaria en la red" es mantener una lista de identificadores que han optado por excluirse — un registro centralizado de no tratar que cada sistema posterior consulta antes de acceder a un registro. Article 71(8) del EHDS prohíbe específicamente esta construcción. La cláusula prohíbe a los titulares de datos adquirir o almacenar datos de identificación adicionales exclusivamente con el fin de respetar las exclusiones voluntarias.

El razonamiento, explicitado en Recital 54, es que el propio registro se convierte en una base de datos de reidentificación — el daño preciso que la regulación pretendía prevenir. Una vez que se mantiene una lista de "personas que han optado por excluirse", se ha reconstruido el honeypot central. La implicación estructural es ineludible: la señal de exclusión voluntaria debe viajar con una credencial que controla el interesado, no en una lista que mantiene el responsable.

The DKMS thesis DKMS es la respuesta

Decentralized Key Management es el primer fundamento estructuralmente sólido para honrar la retirada del consentimiento de extremo a extremo en condiciones interorganizativas, posdivulgación, bajo supervisión regulatoria.

(Decentralized Key Management se basa en KERI, una especificación abierta de Trust over IP Foundation.)

Cómo funciona:

  1. El AID de control del usuario es la raíz de confianza. Las autorizaciones se encadenan a ella criptográficamente, no a una cuenta emitida por el responsable.
  2. Cada autorización está anclada en el Key Event Log (KEL) del AID — un registro de solo adición y encadenado por hash cuyo estado el interesado puede demostrar de forma unilateral.
  3. La retirada es una rotación de clave que realiza el propio interesado. La clave antigua queda invalidada; el evento de rotación está firmado y con marca de tiempo en el KEL.
  4. Las partes posteriores que posean credenciales desactualizadas deben reautenticarse contra el estado más reciente del KEL. La retirada se propaga cerrándose en fallo en cada verificador posterior.

Nada en el protocolo requiere un operador central. Nada requiere que las partes que confían compartan identificadores. Nada requiere que el regulador confíe en los registros del responsable por encima de los del interesado. Cada uno de los cinco invariantes se satisface por construcción, no mediante auditoría.

Dónde DKMS domina — y dónde no ofrece ventajas

La honestidad sobre el alcance es lo que hace defendible la tesis. DKMS domina cuatro condiciones: flujos de datos interorganizativos, retirada posdivulgación, tratamiento bajo supervisión regulatoria y contrapartes adversariales. Fuera de esas condiciones — cargas de trabajo de único inquilino, artefactos derivados como pesos de modelos de ML entrenados, copias de seguridad ya realizadas antes de la retirada y contrapartes únicas deshonestas que actúan solas — DKMS proporciona detección forense pero no prevención.

Dónde DKMS domina Dónde DKMS no ofrece ventajas Flujos de datos interorganizativos Haga clic en una fila para el razonamiento Persistencia del consentimiento posdivulgación Haga clic en una fila para el razonamiento Custodia determinada por el regulador Haga clic en una fila para el razonamiento Las partes componen DKMS de extremo a extremo Haga clic en una fila para el razonamiento Derivados (analítica, pesos de modelos de ML) Haga clic en una fila para el razonamiento Copias de seguridad ya realizadas Haga clic en una fila para el razonamiento Contraparte única deshonesta Haga clic en una fila para el razonamiento Cargas de trabajo de único inquilino Haga clic en una fila para el razonamiento Dónde DKMS domina — y dónde no ofrece ventajas. Haga clic en una fila para el razonamiento.

Flujos de datos interorganizativos

La supresión del lado del operador no puede alcanzar datos ya compartidos con partes posteriores. DKMS extiende el keying controlado por el titular a lo largo de la cadena de tratamiento — cada receptor vuelve a verificar el KEL en el momento del uso. La CMK centralizada proporciona supresión únicamente dentro del límite de inquilino del operador.

Persistencia del consentimiento posdivulgación

EUDIW ARF §6.6 reconoce explícitamente que la retirada no deshace retroactivamente el tratamiento previo lícito. DKMS reduce esta brecha: los verificadores vuelven a comprobar el KEL publicado en el momento del tratamiento, de modo que las credenciales desactualizadas son auditables como tales. La primitiva arquitectónica es impulsada por el titular, no por el operador.

Custodia determinada por el regulador

Schrems II / EDPB Recommendations 01/2020 Caso de uso 3 exigen que el importador de datos NO posea las claves. La CMK centralizada falla esta prueba por definición (por ejemplo, datos de salud de EE. UU. en Azure bajo acceso FISA 702). DKMS convierte la custodia de claves en una propiedad del lado del titular — el importador no puede descifrar sin el estado KEL continuado del titular.

Las partes componen DKMS de extremo a extremo

La arquitectura solo importa cuando todas las partes la aplican. Un verificador que ignora el KEL anula la cadena. Cuando todas las partes componen DKMS, la retirada se propaga mediante simple reverificación — ningún operador necesita "empujar" la supresión.

Derivados (analítica, pesos de modelos de ML)

EDPB Opinion 28/2024 confirma explícitamente que las obligaciones de supresión no se propagan limpiamente a los pesos del modelo una vez realizado el entrenamiento. DKMS no ofrece mejor cobertura que la CMK aquí. La retirada no puede deshacer retroactivamente los resultados de analítica ni los informes regulatorios ya presentados.

Copias de seguridad ya realizadas

Ninguna arquitectura puede recuperar datos ya replicados en medios de copia de seguridad sin conexión o inmutables. El cifrado en reposo junto con la destrucción de claves gestiona los residuos en la ventana de retención; no recupera archivos a largo plazo. DKMS no cambia esta propiedad fundamental.

Contraparte única deshonesta

DKMS proporciona detección forense (las firmas posteriores a la rotación de clave publicada son auditables como desactualizadas) pero no prevención. Un subencargado completamente no cooperativo que descifra texto en claro y lo almacena fuera del sobre cifrado anula la cadena — DKMS hace visible la infracción en lugar de bloquearla.

Cargas de trabajo de único inquilino

Para un SaaS bajo un único responsable, la supresión criptográfica de NIST SP 800-88 §2.5 mediante CMK centralizada es adecuada y más sencilla. Cambiar a DKMS añade carga operativa sin ningún beneficio arquitectónico cuando no hay fronteras de dominio de confianza cruzadas.

Fuera de las cuatro condiciones en las que DKMS domina, la CMK centralizada es racional. Decirlo hace la tesis más sólida.

Prueba en producción

HIN — Health Info Net — es la columna vertebral suiza de la información sanitaria, que conecta hospitales, clínicas y proveedores especializados más allá de las fronteras cantonales. SEAL, la capa de entrega de correo electrónico verificable que Vereign proporciona dentro de HIN, está hoy en producción y transporta más de 800.000 mensajes verificados al mes, prueba de que Vereign ya opera infraestructura de grado productivo dentro del sistema sanitario suizo.

Stargate, el runtime de Decentralized Key Management que lleva a uso operativo el mecanismo de retirada en cuatro pasos descrito arriba, entra en producción temprana en junio de 2026.

La capa FHIR de Stargate — las mismas garantías aplicadas al intercambio de historias clínicas, no solo a los mensajes — es hoy arquitectónica. Llevarla a producción depende del onboarding por parte de los hospitales; la fecha más realista es septiembre de 2026.

Cinco incidentes que demuestran el patrón estructural

  1. Kaiser Foundation Health Plan — acuerdo de demanda colectiva por USD 47,5 millones (2026). Datos del portal de pacientes filtrados a plataformas publicitarias mediante píxeles de seguimiento integrados. La arquitectura no tenía ningún mecanismo para que el interesado retirara la propagación posterior.
  2. Sutter Health — acuerdo de demanda colectiva por USD 21,5 millones (2026). El mismo patrón: etiquetas de terceros en el portal, ninguna primitiva de revocación controlada por el interesado, ninguna forma de demostrar el no tratamiento a posteriori.
  3. NHS National Data Opt-Out (2021) — reconocimiento de no retroactividad; el programa GPDPR se retrasó porque la arquitectura no podía respetar la retirada respecto a datos ya compartidos con investigadores posteriores.
  4. SingHealth (2018) — 1,5 millones de registros vulnerados porque los datos de los pacientes residían en una única base de datos monolítica sin fronteras criptográficas del paciente. El interesado no tenía nada que revocar; no había ninguna clave que rotar.
  5. DigiNotar (2011) — el compromiso de la CA raíz llevó a los navegadores a dejar de confiar en todos los certificados que la CA había emitido. Los interesados no tenían ninguna agencia arquitectónica: sus identificadores y relaciones de confianza estaban completamente bajo el control del operador.

Cada incidente centralizado comparte una característica: el usuario no tenía agencia arquitectónica.

Por dónde empezar

Si su organización trata datos de salud, financieros o datos personales regulados identificables y está expuesta a cualquiera de los cinco regímenes anteriores, el siguiente paso es una revisión de arquitectura de 30 minutos. Trazamos su flujo de consentimiento actual frente a los cinco invariantes, identificamos las brechas y le decimos honestamente si DKMS es la respuesta adecuada para su entorno.

Reserve una revisión de arquitectura del consentimiento de 30 minutos Descargue la tesis del consentimiento (PDF, 24 páginas)

Para su sector

Aplicación del consentimiento en sanidad

Leer más

Aplicación del consentimiento en finanzas

Leer más

Preguntas frecuentes

¿Qué exige EHDS Article 71?
EHDS Article 71 (en vigor el 26 de marzo de 2025) otorga a todo ciudadano de la UE el derecho a excluirse del uso secundario de datos de salud identificables. Article 71(8) prohíbe a los titulares de datos adquirir datos de identificación adicionales exclusivamente para respetar la exclusión voluntaria — lo que impide las implementaciones de tipo "lista de IDs excluidos" porque la propia lista es un registro de reidentificación prohibido. Recital 54 exige que la exclusión voluntaria sea reversible y de libre formato.
¿Por qué no puede funcionar un registro de consentimiento centralizado?
Article 71(8) lo prohíbe explícitamente. El propio registro se convierte en un registro de reidentificación — exactamente lo que la regulación pretendía prevenir. La respuesta estructural requiere identificadores controlados por el interesado, no una lista controlada por un operador central.
¿Garantiza DKMS la aplicación del consentimiento?
No. DKMS es el primer fundamento estructuralmente sólido para honrar la retirada del consentimiento de extremo a extremo en condiciones interorganizativas, posdivulgación, bajo supervisión regulatoria. Fuera de esas condiciones — cargas de trabajo de único inquilino, derivados como pesos de modelos de ML, copias de seguridad ya realizadas, contrapartes únicas deshonestas — DKMS proporciona detección forense pero no prevención.
¿Cómo interopera DKMS con contrapartes X.509 / S/MIME?
A través de puentes S/MIME anclados en KERI que permiten que la retirada se propague a través de las partes que usan X.509. El puente ancla el certificado X.509 a un AID de KERI; la retirada del consentimiento desencadena la rotación de la clave del AID; los verificadores X.509 posteriores deben recuperar y reautenticar.