El consentimiento no es una casilla: el artículo 71 de EHDS lo convirtió en ley. Nosotros lo hicimos funcionar.
Tres acuerdos se cerraron en el primer trimestre de 2026. En conjunto suman USD 69 millones y algo más consecuente: una prueba estructural de fracaso.
Kaiser Permanente se conformó por USD 47,5 millones. Sutter Health se conformó por USD 21,5 millones. ING Bank Śląski se conformó por EUR 4,375 millones. En sanidad y finanzas, en tres jurisdicciones diferentes. Cada organisación había redactado políticas de privacidad. Cada una tenía un panel de control de consentimiento funcional. Los usuarios podían iniciar sesión, alternar preferencias, actualizar sus registros. La infraestructura de consentimiento estaba, en el sentido convencional, presente y funcional.
Sin embargo, cada organisación perdió la capacidad de honrar el consentimiento en el momento en que los datos cruzaron un límite institucional.
El caso Kaiser documenta la secuencia con precisión: la exclusión de uso secundario de un paciente fue registrada en el sistema de gestión de consentimiento, reconocida por el proveedor de atención primaria, y luego descartada silenciosamente cuando el registro se trasladó aguas abajo a un agregador de investigación. La exclusión no fue anulada. No fue ignorada. Simplemente fue invisible para el controlador aguas abajo — arquitectónicamente inaccesible. El mismo patrón se repite en los escritos de Sutter e ING. Una preferencia de consentimiento que existe en un sistema no puede ser leída por otro sistema que ya ha recibido los datos.
Esto no es un fracaso de política. Es un fracaso arquitectónico. Y explica por qué los acuerdos de 2026 tienen el aspecto que tienen.
La trampa que el artículo 71(8) estableció
El artículo 71 de EHDS entró en vigor el 26 de marzo de 2025, conforme al Reglamento (UE) 2025/327. Convierte la exclusión de uso secundario en un derecho legal, no en una característica de cortesía. Una persona puede retirar el consentimiento para el uso de sus datos sanitarios para investigación, estadísticas o capacitación — en cualquier momento, siendo el retiro vinculante para todo controlador que tenga sus datos.
La respuesta ingenieril evidente es una lista centralizada: mantener un registro de identificadores excluidos, verificar todo uso aguas abajo contra la lista, bloquear en caso de coincidencia. Rápido, auditable, manejable.
El artículo 71(8) cierra esa puerta. Explícitamente prohíbe registros de re-identificación — el mecanismo exacto que hace que funcione una lista centralizada de exclusión. La lógica detrás de la prohibición es sólida: una lista de identificadores correlacionados con decisiones de exclusión es en sí misma un conjunto de datos sensible. Su existencia crea riesgo de re-identificación. La regulación fue redactada para prevenir exactamente ese riesgo, por lo que no puede permitir el camino de implementación más evidente para honrar el derecho que crea.
Esta es la trampa. El controlador no puede mantener una lista de quién se excluyó sin recrear el daño que la regulación fue redactada para prevenir. El artículo 71 crea una obligación legal de honrar la exclusión a través de límites institucionales. El artículo 71(8) previene el enfoque arquitectónico que haría que esto fuera viable para infraestructura centralizada. El Considerando 54 añade que la exclusión debe ser reversible y libremente ejercible — sin fricción, sin re-registro, sin período de espera.
La regulación es precisa. La implicación arquitectónica es radical.
Cinco invariantes. Cero arquitecturas que las satisfagan todas — hasta ahora.
Elimine el lenguaje legal y lea lo que los reguladores realmente requieren. En el artículo 71 de EHDS, los artículos 7(3) y 17(2) de GDPR, y el artículo 5a de eIDAS 2.0, aparecen cinco invariantes ingenieriles:
Identificadores de ámbito de persona. La exclusión debe ser atribuible a una persona específica, no a una sesión, dispositivo o cuenta. El identificador debe sobrevivir a los límites institucionales.
Exclusión timestamped verificable. Un controlador debe poder probar cuándo fue registrada la exclusión y que no ha sido alterada. Los registros auto-reportados son insuficientes; se requieren pruebas criptográficas.
Reversibilidad sin re-identificación. El artículo 71(8) de EHDS lo nombra explícitamente. La persona puede revertir su exclusión sin que la reversión requiera la creación de un registro de identidad vinculable.
Propagación entre controladores. El artículo 17(2) de GDPR requiere que un retiro de consentimiento llegue a todo procesador aguas abajo. La obligación no se detiene en el controlador que recibió el consentimiento original.
No vinculabilidad. El artículo 5a(16)(b) de eIDAS 2.0 requiere que las interacciones de identidad sean no vinculables a través de contextos, de modo que la exclusión no pueda ser explotada para construir un perfil entre instituciones.
Estos cinco invariantes están nombrados en la ley primaria. No son posiciones interpretativas. Y crean una prueba precisa para cualquier arquitectura de consentimiento: ¿satisface los cinco?
X.509 PKI satisface cero. Una cadena de certificados puede confirmar la identidad de un servidor, pero no proporciona mecanismo alguno para identificadores de ámbito de persona que sobrevivan a límites institucionales, sin registro criptográfico de exclusión independiente de los propios registros del controlador, y sin no vinculabilidad — por diseño, X.509 depende de que la CA sepa quién es usted.
La identidad federada satisface propagación — cuando un proveedor federado recibe una exclusión, puede propagarla a partes que confían. Pero satisface propagación solo violando no vinculabilidad. El proveedor de federación tiene una vista completa de qué persona interactuó con qué institución. Esa vinculabilidad es lo que hace funcionar la propagación. También es lo que el artículo 5a(16)(b) prohíbe.
DKMS satisface los cinco.
Por qué DKMS es la respuesta — y qué significa eso en la práctica
La Gestión Descentralizada de Claves es el primer fundamento estructuralmente sólido para honrar la exclusión de extremo a extremo en condiciones entre organisaciones, post-divulgación y vigiladas por reguladores. La frase calificativa importa. En cargas de trabajo de un solo inquilino, dentro del perímetro de una sola institución, enfoques más simples son adecuados. El problema estructural solo aparece cuando los datos han cruzado un límite — cuando la persona que ejerce su exclusión ya no está interactuando con el primer controlador.
El mecanismo funciona de la siguiente manera. Cada persona tiene un identificador auto-certificante — un Identificador Autónomo, o AID — que sirve como raíz criptográfica de sus autorizaciones de consentimiento. Este AID no está registrado con ninguna autoridad central. Es auto-generado y controlado completamente por la persona que lo posee. DKMS está construido sobre KERI, una especificación abierta de la Fundación Trust over IP, que define cómo funcionan estos identificadores y cómo se propagan los cambios en ellos.
Junto al AID se encuentra un Registro de Eventos de Clave — un registro a prueba de alteraciones, encadenado criptográficamente, de toda autorización y retiro. Cuando una persona se excluye de uso secundario, ese retiro se registra como un evento de clave: con timestamp, firmado y añadido al registro. Cualquier controlador aguas abajo que tenga los datos de la persona puede verificar el estado actual de la autorización leyendo el registro directamente — sin registro central, sin llamada a una base de datos compartida, sin re-identificación.
Cuando una persona revierte su exclusión, esa reversión es también un evento de clave. El sujeto impulsa la rotación. La obligación del controlador es verificar, no mantener su propia interpretación del estado.
La propagación entre controladores se sigue de la estructura del registro. La institución B, que recibió datos de la institución A, no necesita recibir una notificación de la institución A. Puede leer el registro ella misma. La propagación está basada en tirada y lista para auditoría.
Donde DKMS no entrega
La honestidad sobre el alcance es lo que hace la tesis defendible.
Los datos que han sido utilizados para entrenar un modelo no pueden ser desaprendidos por una rotación de clave. Un conjunto de datos derivado — un agregado, un subconjunto anonimizado, un artefacto estadístico — no retiene conexión alguna al AID de la persona original. La exclusión no puede llegar a esos derivados. DKMS puede proporcionar detección forense de cuándo fueron utilizados los datos antes de que el retiro fuera registrado; no puede deshacer el uso.
Las copias de seguridad tomadas antes de la exclusión están sujetas a los mismos límites. La copia de seguridad existe fuera de la cadena de autorización. Alcanzarla requiere una decisión de política separada, que DKMS puede informar pero no hacer cumplir autónomamente.
Una sola contraparte deshonesta puede ignorar el registro. DKMS no es una función de cumplimiento forzado para actores que eligen violar sus obligaciones legales. Lo que proporciona es un registro auditable que hace la violación visible y demostrable — que es exactamente lo que reguladores y tribunales necesitan para asignar responsabilidad. Los acuerdos de 2026 fueron difíciles de resolver precisamente porque el estado de consentimiento era ambiguo en cada límite institucional. DKMS elimina esa ambigüedad.
Las cargas de trabajo de un solo inquilino dentro del perímetro de una sola institución no necesitan DKMS para la ejecución de consentimiento. Los sistemas de gestión de consentimiento existentes funcionan adecuadamente cuando los datos nunca cruzan un límite. El requisito estructural entra en vigor en el límite.
Decir esto de manera frontal no es debilidad. Es lo que distingue un argumento arquitectónico de un reclamo de producto.
En producción
El despliegue de Vereign con Health Info Net AG de Suiza maneja más de 800.000 mensajes verificados por mes. Esa cifra representa comunicaciones procesadas por SEAL — el sistema de entrega de enjambre encriptado que sirve como canal seguro de HIN para destinatarios fuera de la red profesional. Es la prueba de producción de que la arquitectura subyacente se escala a cargas de trabajo institucionales en sanidad.
Stargate — la infraestructura de confianza completa que añade capas de identidad descentralizada, autorización y sendas criptográficas de auditoría sobre ese canal seguro — entró en producción temprana desde junio de 2026. La narrativa de lanzamiento masivo estará disponible después del verano de 2026 conforme el despliegue se amplía.
FHIR-over-Stargate es arquitectónico — el despliegue de producción depende de la incorporación de hospitales; lo más temprano septiembre de 2026. El intercambio de datos clínicos vía FHIR con la capa de ejecución de consentimiento de Stargate en línea es la arquitectura objetivo para cumplimiento del artículo 71 de EHDS. Las piezas están en su lugar. El cronograma depende de la incorporación institución por institución, no de ingenierización adicional.
Esa es la imagen honesta. La arquitectura es sólida. La línea de base de producción existe. El camino desde la producción actual al cumplimiento completo del artículo 71 de EHDS está definido y en progreso.
La revisión de arquitectura de consentimiento
La tesis técnica completa — cinco invariantes, detalle de mecanismo, citas regulatorias, advertencias de límite de honestidad, tabla de comparación en X.509 / IAM federado / DKMS — está en /consent/.
Si su organisación está trabajando a través de implementación del artículo 71 de EHDS, obligaciones de propagación del artículo 17(2) de GDPR, o decisiones de arquitectura de consentimiento que vienen con intercambio de datos basado en FHIR, una revisión de arquitectura de consentimiento de 30 minutos asigna su situación específica contra estos invariantes. Reserves una aquí.