Съгласието не е отметка: EHDS Article 71 го направи закон. Ние го направихме да работи.

Три уреждания бяха постигнати в първото тримесечие на 2026 г. Заедно те събират USD 69 милиона и нещо по-съществено: структурно доказателство на неуспех.

Kaiser Permanente уреди за USD 47,5 милиона. Sutter Health уреди за USD 21,5 милиона. ING Bank Śląski уреди за EUR 4,375 милиона. В здравеопазването и финансите, в три различни юрисдикции. Всяка организация беше написала политики за приватност. Всяка имаше работещ панел за управление на съгласието. Потребителите могаха да се влезнат, да превключват предпочитанията, да актуализират записите си. Инфраструктурата за съгласие беше, в обичайния смисъл, налична и функционална.

И все пак всяка организация загуби възможността да спазва съгласието в момента, когато данните пресекоха институционална граница.

Казусът Kaiser документира последователността точно: отказът за вторично използване на пациент беше записан в системата за управление на съгласието, потвърден от първичния здравен доставчик, и след това мълчаливо отхвърлен, когато записът се преместна по-нататък към агрегатор за изследвания. Отказът не беше отхвърлен. Не беше игнориран. Той просто беше невидим на контролера по-нататък — архитектурно недостъпен. Същата схема се повтаря в документалния файл на Sutter и ING. Предпочитание за съгласие, което съществува в една система, не може да бъде прочетено от друга система, която вече е получила данните.

Това не е отказ на политиката. Това е отказ на архитектурата. И това обяснява защо уреждането на 2026 г. изглежда така.

Капканът, който Article 71(8) постави

EHDS Article 71 влезе в сила на 26 март 2025 г., под Reg. (EU) 2025/327. Това прави отказ от вторично използване законно право, не обслужване като люкс. Човек може да оттегли съгласието за използване на своите здравни данни за изследвания, статистика или обучение — в който момент, със оттеглянето обвързващо всяка страна, която притежава своите данни.

Очевидният инженерен отговор е централизиран списък: поддържайте регистър на идентификаторите, които са отказали участие, проверете всяко използване по-нататък спрямо списъка, блокирайте при съвпадение. Бързо, одитируемо, управляемо.

Article 71(8) затваря врата. Явно забранява регистрите за преидентификация — точния механизъм, който прави работещ централизиран список за отказ. Логиката зад забраната е здрава: списък на идентификаторите, корелирани с решения за отказ, е сам по себе си чувствителен набор от данни. Неговото съществуване създава риск от преидентификация. Регулацията беше написана, за да предотврати точно този риск, така че не може да позволи най-очевидния път на имплементация за спазване на правото, което създава.

Това е капканът. Контролерът не може да поддържа списък на това кой отказа без възпроизвеждане на причинената вреда, която регулацията беше написана, за да предотврати. Article 71 създава законна задължение да се спазва отказ през институционални граници. Article 71(8) предотвратява архитектурния подход, който би направил това възможно за централизирана инфраструктура. Recital 54 добавя, че отказът трябва да бъде обратим и свободно упражняван — без трение, без повторна регистрация, без период на чакане.

Регулацията е точна. Архитектурното значение е радикално.

Пет инварианта. Нула архитектури, които ги задоволяват всички — до сега.

Свалете юридическия език и прочетете какво регулаторите действително изискват. През EHDS Article 71, GDPR Articles 7(3) и 17(2), и eIDAS 2.0 Article 5a, се появяват пет инженерни инварианта:

Идентификатори с обхват на лицето. Отказът трябва да бъде приписуем на определено лице, не на сесия, устройство или сметка. Идентификаторът трябва да преживее институционални граници.

Проверяем отказ с временна мътка. Контролер трябва да може да докаже кога отказът беше записан и че не е бил манипулиран. Самозаявени логове са недостатъчни; криптографски доказателства се изискват.

Обратимост без преидентификация. EHDS Article 71(8) назовава това явно. Лицето може да отмени своя отказ без отмяната да изисква създаване на свързан идентификационен запис.

Разпространение между контролери. GDPR Article 17(2) изисква оттегляне на съгласието да достигне всеки обработчик по-нататък. Задължението не спира при контролера, който получи първоначалното съгласие.

Неразграничимост. eIDAS 2.0 Article 5a(16)(b) изисква взаимодействието на идентичност да бъде неразграничимо през контекстите, така че отказът да не може да бъде използван за изграждане на кросс-институционален профил.

Тези пет инварианта са назовани в първостепенния закон. Те не са интерпретационни позиции. И те създават точен тест за всяка архитектура на съгласието: задоволява ли всичките пет?

X.509 PKI задоволява нула. Верига сертификата може да потвърди идентичността на сървър, но не осигурява механизъм за идентификаторе с обхват на лицето, които да преживеят институционални граници, не криптографски запис за отказ независимо от собственото регистър на контролера, и не неразграничимост — по дизайн, X.509 разчита на CA да познава кой сте вие.

Федеративната идентичност удовлетворява разпространението — когато федеративен доставчик получи отказ, може да го разпространи към полагащите се страни. Но удовлетворява разпространението само чрез нарушаване на неразграничимостта. Федеративния доставчик има пълна преглед на това кое лице се взаимодействува с коя институция. Тази свързаност е това, което прави разпространението да работи. Това е също така това, което Article 5a(16)(b) забранява.

DKMS задоволява всичките пет.

Защо DKMS е отговорът — и какво означава това на практика

Decentralized Key Management е първата структурно здрава основа за спазване на отказ от край до край в кросс-организационни, пост-разкритие, под наблюдение на регулатора условия. Квалификацията важи. В еднооператорски работни натоварвания, вътре в периметъра на една институция, по-простите подходи са адекватни. Структурният проблем се появява само когато данните пресекоха граница — когато лицето, упражняващо своя отказ, вече не взаимодействува с първия контролер.

Механизмът работи както следва. Всяко лице притежава самосертифициращ се идентификатор — Автономен идентификатор, или AID — който служи като криптографски корен на своите разрешения за съгласие. Този AID не е регистриран при централна власт. Той е саморегениран и контролиран изцяло от лицето, което го притежава. DKMS е изграден на KERI, спецификация на открития Trust over IP Foundation, която определя как работят тези идентификаторе и как промените в тях се разпространяват.

Заедно с AID се намира Key Event Log — тамперпруф, криптографски верижен запис на всяко разрешение и оттегляне. Когато лицето отказа вторично използване, това оттегляне се записва като ключово събитие: с временна мътка, подписано, и добавено към регистъра. Всеки контролер по-нататък, който притежава данните на лицето, може да проверява текущото състояние на разрешението чрез директно прочитане на регистъра — без централен регистър, без повикване към съделена база данни, без преидентификация.

Когато лицето отмени своя отказ, тази отмяна е също ключово събитие. Субектът управлява ротацията. Задължението на контролера е да проверява, не да поддържа своя собствена интерпретация на състоянието.

Разпространението между контролери произтича от структурата на регистъра. Институция B, която получи данни от Институция A, не трябва да получи уведомление от Институция A. Може да прочете регистъра самостоятелно. Разпространението е на базата pull и готино за одит.

Където DKMS не доставя

Честност по отношение на обхвата е това, което прави теза защитима.

Данни, които са използвани за обучаване на модел, не могат да бъдат разучени чрез ротация на ключ. Наборът производни данни — агрегат, анонимна подмножество, статистически артефакт — запазва никаква връзка с AID на първоначалното лице. Отказът не може да достигне обратно в тези производни. DKMS може да осигури криминалистическо откритие на момента, когато данните са били използвани преди отказът да бъде записан; не може да отмени използването.

Резервни копия, направени преди отказ, са подложени на същите ограничения. Резервното копие съществува извън верига на разрешенията. Достигането до него изисква отделна решение на политиката, което DKMS може да информира, но не може да принуди автономно.

Една единствена нечестна противна страна може да игнорира регистъра. DKMS не е принудителна функция за съответствие за действащи лица, които избират да нарушат своите законни задължения. Това, което осигурява, е одитируем запис, който прави нарушението видимо и доказуемо — което е точно това, което регулаторите и съдовете трябват за приписване на отговорност. Уреждането на 2026 г. беше трудно да се реши точно защото състоянието на съгласието беше неясно на всяка институционална граница. DKMS премахва тази неясност.

Еднооператорските работни натоварвания в периметъра на една институция не имат нужда от DKMS за прилагане на съгласие. Съществуващите системи за управление на съгласието работят адекватно, когда данните никога не пресичат граница. Структурното изискване се активира при границата.

Казване на това напред не е слабост. Това е това, което разграничава аргумент на архитектурата от претенция на продукт.

В продукция

Разпределянето на Vereign със Switzerland’s Health Info Net AG обработва 800 000+ проверени съобщения месечно. Тази цифра представя комуникации, обработени от SEAL — системата за криптирана доставка на рой, която служи като HIN’s защитен канал за получатели извън професионалната мрежа. Това е доказателството в продукция, че основната архитектура се мащабира към институционални работни натоварвания в здравеопазването.

Stargate — пълна инфраструктура на доверие, която добавя децентрализирана идентичност, слоеве на разрешения, и криптографски следи на одит на този защитен канал — влезе в ранна продукция от юни 2026 г. Наративът на масово разпределяне ще бъде достъпен след лятото 2026 г., когато разпределянето се разширява.

FHIR-over-Stargate е архитектурна — разпределяне на продукция зависи от привлечение на болници; най-ранна възможност септември 2026 г. Обмен на клинични данни чрез FHIR със слой на прилагане на съгласието на Stargate вътрешно е целевата архитектура за съответствие на EHDS Article 71. Парчетата са на място. Часовата база зависи от привлечението на всяка институция, не от по-нататъшното инженерство.

Това е честната картина. Архитектурата е здрава. Линията на продукция съществува. Пътят от текущата продукция до пълно съответствие на EHDS Article 71 е определен и в ход.

Прегледът на архитектурата на съгласието

Пълната техническа теза — пет инварианта, детайл на механизма, цитати на регулатора, граници на честност, таблица за сравнение по X.509 / федеративна IAM / DKMS — е на /consent/.

Ако вашата организация работи чрез имплементация на EHDS Article 71, задължения за разпространение на GDPR Article 17(2), или решенията на архитектура на съгласието, които дойдоха с обмен на данни базирани на FHIR, преглед на архитектура на съгласието от 30 минути картографира вашата конкретна ситуация срещу тези инварианта. Запазете един тук.