Децентрализованный медицинский ИИ: роевое обучение

Анатомия цифровизации здравоохранения | узнать больше Роевое обучение: архитектура, клиническая валидация и границы безопасности децентрализованного медицинского ИИ

О материале. Это просветительский обзорно-аналитический материал, подготовленный экспертами КБФИТ — организации, работающей на пересечении разработки, big-data-аналитики и просветительства в здравоохранении. Цель — познакомить читателя с технологией Swarm Learning, её архитектурой, клинической валидацией и границами применимости, а не заменить независимую экспертизу. Оценки, выводы и интерпретации основаны на открытых источниках с использованием средств ИИ и отражают позицию авторов. Для критических решений (выбор технологии, оценка регуляторных рисков, инвестиционное планирование) необходима внешняя экспертиза и дополнительная проверка.

Цифровая трансформация здравоохранения упирается в фундаментальное противоречие: для обучения надёжных ИИ-моделей нужны большие объёмы данных, но медицинские данные защищены законодательством о персональной информации и не могут свободно передаваться между учреждениями. Федеративное обучение предложило компромисс — обучать модели локально, обмениваясь только весами. Однако классическая схема сохраняет центральный сервер, который остаётся единой точкой отказа. Роевое обучение (Swarm Learning, SL) заменяет постоянный центральный сервер на динамически выбираемого лидера, что снижает, но не полностью устраняет риск централизации де-факто (см. раздел 2).

Swarm Learning не упоминается в тексте Регламента EHDS и не является предписанной технологией. Это один из возможных подходов к выполнению функциональных требований к защищённым средам обработки (Secure Processing Environments, SPE).

1. Постановка проблемы: данные, которые нельзя передать

Классическое федеративное обучение (Federated Learning, FL), формализованное McMahan et al. (Google) в 2017 году [24], строится на принципе «данные не покидают узел»: каждый участник обучает модель локально, а центральный сервер собирает и агрегирует весовые коэффициенты. Идея распределённого обучения на локальных данных существовала и ранее (например, в работах по распределённой оптимизации), однако канонической публикацией, закрепившей термин «федеративное обучение», считается статья McMahan et al. «Communication-Efficient Learning of Deep Networks from Decentralized Data» (AISTATS 2017) [24]. Эта архитектура решает проблему передачи сырых данных, но сохраняет центрального координатора — единую точку отказа и потенциальную цель компрометации.

Swarm Learning, разработанный Hewlett Packard Labs и описанный в Nature (Warnat-Herresthal et al., 2021) [1], устраняет центральный сервер. Согласно аннотации, SL «объединяет edge computing, блокчейн-based peer-to-peer networking и координацию, сохраняя конфиденциальность без необходимости в центральном координаторе, тем самым выходя за пределы федеративного обучения» [1].

Два фундаментальных различия между SL и FL:

• Передача информации. В FL узлы отправляют параметры центральному серверу; в SL — обмениваются напрямую через peer-to-peer-сеть на базе блокчейна.
• Центральный сервер. FL требует постоянного координатора; SL не требует постоянного координатора, однако временный лидер, выбираемый в каждом раунде, может играть функционально близкую роль (см. раздел 2 о «гонке за лидерство»).

Д-р Энг Лим Го (Eng Lim Goh), старший вице-президент и CTO по ИИ в HPE: «Роевое обучение позволяет каждой больнице продолжать обучаться локально. Но на каждом цикле мы собираем выученные веса нейронных сетей, усредняем их и отправляем обратно всем больницам. После нескольких циклов больницы учатся друг у друга, устраняя смещения, не обмениваясь приватными данными пациентов» [2]. Цитата приводится по пресс-релизу HPE (апрель 2022); полный контекст интервью в открытых источниках не раскрыт.

2. Архитектура и технический стек Swarm Learning

Swarm Learning построен на трёх технологических компонентах:

• Распределённое машинное обучение. Каждый узел (Swarm edge node) обучает модель локально на своих данных. Согласно документации HPE [4][5], поддерживаются модели на PyTorch и Keras (с TensorFlow 2 backend); все узлы должны использовать одну платформу. Оговорка про ONNX. Теоретически кросс-платформенная агрегация возможна через промежуточные форматы (ONNX), однако практическая реализация упирается в нерешённую проблему: агрегация весов предполагает поэлементное усреднение тензоров, и корректность такого усреднения при конвертации между фреймворками не гарантирована (различия в порядке слоёв, именовании, инициализации). В стандартной документации HPE этот сценарий не описан и не валидирован; для продакшн-применения он требует отдельного исследования.
• Permissioned-блокчейн (на базе открытой версии Ethereum) — обеспечивает безопасный онбординг участников, динамический выбор лидера и слияние параметров модели. Блокчейн используется только для координации, а не для хранения медицинских данных. Поддержание блокчейн-инфраструктуры требует собственных вычислительных ресурсов (узлы, хранение состояния, газ-механизм в permissioned-варианте); количественные оценки этих затрат в открытой документации HPE отсутствуют.
• Swarm Learning Library (SLL) — библиотека-оркестратор, которая управляет итеративным циклом обучения: запуск локального обучения → извлечение весов → передача в сеть → агрегация → возврат обновлённых весов [5].

Сеть создаётся из от 3 до 32 обучающих узлов в экспериментальных конфигурациях, описанных в литературе [1]. Это не технологический лимит платформы, а диапазон, использованный в исследовании. Документация HPE не фиксирует верхнюю границу в 32 узла как архитектурное ограничение; масштабируемость за пределы этого диапазона требует отдельной проверки. Каждый узел представляет собой Docker-контейнер с доступом к GPU.

Пошаговый процесс:

1. Локальное обучение на источнике. Сырые медицинские данные физически никогда не покидают локальный защищённый сервер конкретной больницы. Модель обучается на локальном GPU.
2. Обмен весами через блокчейн. По завершении эпохи обучения модель генерирует только матрицу математических весов — обезличенные коэффициенты, которые в общем случае не позволяют напрямую реконструировать исходные данные, однако возможность частичной реконструкции зависит от архитектуры модели, размера батча и наличия дополнительных мер защиты (см. раздел 4 о градиентных инверсионных атаках [23]). Эти веса отправляются в децентрализованную сеть.
3. Глобальная агрегация. Динамически выбранный узел-лидер объединяет веса со всех госпиталей-участников, формируя глобальную модель, и возвращает обновлённые коэффициенты обратно на локальные серверы. Процесс повторяется итеративно.

Механизм выбора лидера и флаг SL_MAKE_ME_ADMIN. В документации HPE Swarm Learning (community edition) и связанных материалах [4][5] описан соревновательный механизм: «первый SL-узел, завершивший локальное обучение в данном раунде синхронизации, избирается лидером» [4]. Это упрощённая реализация, ориентированная на скорость вычислений. Переменная SL_MAKE_ME_ADMIN позволяет исключить медленные узлы из выборов: «If user doesn't want to make a slow node (with less compute power, network bandwidth etc) as a leader, then this can be set to 'False'» [5].

Оговорка о расхождении с патентом. Патентная заявка HPE (US 2021/0398017 A1) [26] описывает иной механизм выборов: каждый узел регистрирует в блокчейне случайное число, и лидером становится узел с наименьшим (или иным заданным) значением. Это не «первый завершивший обучение», а вероятностный протокол, устойчивый к манипуляциям со стороны самых мощных узлов. Какой именно механизм реализован в community edition 1.2.0/2.0.0 — требует проверки. Возможно, документация описывает упрощённую версию, а патент — более сложную, ещё не реализованную в открытом коде. CIO, проектирующему рой, следует уточнить это у вендора.

Практическое следствие для гетерогенных сетей: крупные федеральные центры с мощными GPU-кластерами берут на себя инфраструктурную нагрузку (агрегацию), устанавливая SL_MAKE_ME_ADMIN = True. Малые региональные клиники с дефицитом аппаратных ресурсов устанавливают SL_MAKE_ME_ADMIN = False и остаются исключительно в роли поставщиков локальных весов, разгружая сеть и процессор.

Уязвимость «гонки за лидерство». Соревновательный механизм выбора лидера порождает проблему систематического смещения (Leader Bias). Если узел с мощным GPU-кластером постоянно агрегирует веса, он не только потребляет больше сетевого трафика, но и в случае его скрытой компрометации становится идеальной точкой для атак на подмену глобальных коэффициентов. Более того, если лидер предсказуем, архитектура не является полностью децентрализованной де-факто: постоянный лидер выполняет роль, функционально близкую к центральному серверу, что подрывает ключевое заявленное преимущество SL. HPE частично адресует эту проблему через механизм Leader Failure Detection and Recovery (LFDR): при отказе лидера выбирается новый узел для продолжения агрегации [20]. Однако это не устраняет риск компрометации узла-лидера и не решает проблему систематического доминирования наиболее мощного участника.

Гомоморфное шифрование в HPE Swarm Learning. Согласно патентной заявке HPE (US 2021/0398017 A1, опубл. 23.12.2021) [26], процесс агрегации использует гомоморфное шифрование: merge leader запрашивает у key manager публичный ключ, каждый узел шифрует свои параметры, leader выполняет гомоморфное сложение над зашифрованными значениями, а отдельно избранный decryptor (не совпадающий с leader) расшифровывает результат. После завершения раунда key manager уничтожает ключи [26]. Это означает: (1) merge leader не видит открытые параметры узлов; (2) компрометация leader не приводит к утечке параметров без одновременной компрометации decryptor; (3) атака на подмену глобальных коэффициентов через leader затруднена.

Оговорка о реализации (требующая проверки). Патентная заявка описывает заявленный механизм, а не его фактическое наличие в конкретных версиях продукта. Отчёт PriSyn — официального демонстратора на базе HPE Swarm Learning Community Edition — гомоморфное шифрование не упоминает: три технологических столпа демонстратора — это Swarm Learning API, SPIFFE/SPIRE и mTLS в service mesh [30]. Это конкретное свидетельство в пользу необходимости проверки. Рекомендуемый способ проверки для CIO: запросить у вендора подтверждение функциональности для используемой версии, а также проверить наличие соответствующих переменных окружения или параметров конфигурации в документации к конкретному релизу. Это требование по силе согласовано с оговоркой о machine unlearning (см. раздел 6).

Связь с «гонкой за лидерство». Даже если гомоморфное шифрование реализовано, оно не устраняет риски де-факто-централизации. Leader по-прежнему: (1) видит, какие узлы отправили параметры (метаданные); (2) контролирует порядок и состав агрегации — может исключить узел или изменить последовательность; (3) в случае систематического доминирования становится точкой цензуры для узлов, чьи данные он считает «аномальными» (см. «Византийский тупик» в разделе 4). Гомоморфное шифрование защищает содержание параметров, но не метаданные и не процесс агрегации.

Математика агрегации. SL использует взвешенное среднее (weighted mean), также известное как weighted federative averaging. Это стандартный метод агрегации, применяемый и в классическом федеративном обучении (FedAvg, McMahan et al., 2017) [24]; его использование не является уникальной особенностью SL. Ключевое отличие SL от FL заключается в механизме координации (блокчейн и динамический выбор лидера вместо центрального сервера), а не в математике агрегации. Глобальное обновление весов:

Ω^t+1 = Σ (|D_i| / |D_total|) · ω_i^t

Лидер обязан записать хэш-сумму вычисленной глобальной модели в блокчейн для верификации остальными узлами.

Ограничение по версиям. Упоминаемые в материале архитектурные параметры (лимиты узлов, поддерживаемые фреймворки, переменные окружения) могут различаться между версиями HPE Swarm Learning (в тексте упоминаются 1.2.0 и 2.0.0). Перед практическим внедрением необходимо сверяться с документацией конкретной версии.

3. Клиническая валидация: DZNE, ODELIA, FinOMOP

DZNE / Nature (2021). Первое масштабное подтверждение работоспособности Swarm Learning в медицине [1]. Команда под руководством профессора Йоахима Шультце (Немецкий центр нейродегенеративных заболеваний, DZNE) использовала SL для разработки классификаторов четырёх заболеваний: двух вариантов лейкемии (ОМЛ и ALL), туберкулёза и COVID-19.

Масштаб данных: более 16 400 транскриптомов крови из 127 клинических исследований и более 95 000 рентгеновских снимков грудной клетки [1]. Данные были распределены по 3–32 узлам с неравномерным распределением случаев и контролей (non-IID). Согласно аннотации, «Swarm Learning classifiers outperform those developed at individual sites» [1]. Это утверждение относится к сравнению SL с моделями, обученными на данных отдельных узлов, и не означает превосходства над централизованным обучением на объединённом наборе данных. Точность классификации для транскриптомных данных составила около 90% в среднем по всем четырём заболеваниям; для рентгеновских снимков — от 76 до 86% [1].

Профессор Шультце: «Наше исследование доказывает, что Swarm Learning можно успешно применять к самым разным данным — геномным, рентгеновским, мозговой визуализации или другим сложным данным» [7]. Цитата приводится по пресс-релизу DZNE; полный контекст интервью в открытых источниках не раскрыт.

ODELIA (2023–2026). Проект финансируется программой Horizon Europe (грант № 101057091), объединяет 12 партнёров из 8 стран [9]. Цель — создать open-source фреймворк для Swarm Learning и применить его к диагностике рака молочной железы по МРТ-снимкам.

Ключевое исследование — Saldanha O. et al. Swarm Learning for breast cancer detection in MRI // Communications Medicine. — 2025 [8]. Прямая ссылка на публикацию: Nature Communications Medicine. Модели обучались на более чем 1 300 МРТ-исследованиях из США, Швейцарии и Великобритании, с валидацией на более чем 600 исследованиях из Германии и Греции [8]. Результат: модели, обученные через SL в реальном межцентровом сценарии, превзошли локально обученные модели [8]. Как и в случае DZNE, сравнение проводилось с локальными моделями, а не с централизованным обучением.

Согласно руководству ODELIA по запуску SL в клинической среде [9], для развёртывания требуется выделенный сетевой сегмент, изолированный от клинической сети больницы, mesh-based VPN для шифрования данных и открытие от одного до четырёх TCP/IP портов на каждом узле.

FinOMOP (2024–2025). Пилотный проект в Финляндии, объединяющий три крупнейших университетских госпиталя (HUS в Хельсинки, VARHA в Турку, PIRHA в Тампере), охватывающих около 70% населения страны [10]. Данные гармонизированы по модели OMOP CDM.

Задача: прогностическая deep-learning модель для острого миелоидного лейкоза (ОМЛ) на основе клинических рутинных данных [10]. Система прошла аудит Финского национального органа данных (Findata). Согласно заявлению участников проекта, сертификация Findata стала первым случаем одобрения децентрализованной системы для использования реальных больничных данных [10]. Регулятор признал риск приемлемым на основе предоставленных доказательств; конкретный аргументарий в открытых материалах проекта не раскрывается. Это означает, что прецедент нельзя ни проверить, ни экстраполировать на другие юрисдикции: он доказывает, что сертификация была возможна в Финляндии при конкретных условиях, а не что она возможна в принципе.

PriSyn (2022–2025). Завершённый проект, финансировавшийся BMBF (Германия), выполненный HPE совместно с DZNE, CISPA и QuantPi [30]. Проект использовал Swarm Learning как компонент: децентрализованное обучение на локальных данных сочеталось с дифференциально-приватными генеративными моделями для синтеза данных и FPGA-ускорением. Демонстратор архитектуры был построен на базе HPE Swarm Learning Community Edition с добавлением mTLS, SPIFFE/SPIRE и блокчейн-аудита [30].

PriSyn не является независимой от SL технологией — это последующий инженерный проект, развивающий SL в направлении синтетических данных с гарантиями приватности. Ключевой вывод отчёта: децентрализованный анализ технически осуществим и экономически перспективен в немецком медицинском контексте [30]. Однако, как и другие проекты, PriSyn не приводит прямого сравнения SL с централизованным обучением на объединённых данных — его задача состояла в демонстрации работоспособности комбинации SL + дифференциальная приватность + FPGA.

О таблице и перечне публикаций. Таблица выше охватывает клинические проекты применения SL в медицине — включая как рецензируемые публикации, так и пилотные проекты (KatherLab, PriSyn). Перечень публикаций Nature Portfolio, приведённый в разделе 7, — это отдельный срез: он охватывает только рецензируемые статьи в изданиях Nature Portfolio. KatherLab публикуется в других изданиях; PriSyn — отчёт о завершённом проекте, а не рецензируемая публикация.

Сравнение с централизованным обучением. Среди рассмотренных клинических проектов ни один не приводит прямого сравнения SL с централизованным обучением на объединённом наборе медицинских данных. Однако в смежной области — прогнозировании инфраструктурных ресурсов (CPU/RAM) — магистерская диссертация UPC (2025) на реальном датасете Alibaba показала, что Swarm Learning достигает точности, сопоставимой с централизованной моделью, при сокращении времени обучения до 47% [31]. Это означает: на задачах инфраструктурного прогнозирования SL уже демонстрирует результаты, сопоставимые с централизованным обучением, при выигрыше в скорости; на клинических медицинских датасетах прямых сравнений по-прежнему нет. Единственное упоминание сравнения на клинических данных — проект SwarmMAP (npj Systems Biology and Applications, 2026) [15] на данных single-cell RNA-секвенирования, где SL достиг средней производительности 0,907, статистически не отличаясь от централизованного обучения (p = 0,937, Mann-Whitney U) [15]. Однако на редких типах клеток с крайне малым числом образцов производительность SL снижается [15].

4. Границы безопасности: специфические векторы атак

Ниже приведены векторы атак, релевантные для SL, с оценкой по трём параметрам: специфичность для SL, наличие экспериментального подтверждения, доступные меры защиты.

Ограниченность модели угроз. Раздел опирается преимущественно на работу Yang et al. (2022) [3] для описания backdoor-атак и SSE. Более поздние обзоры угроз федеративного и роевого обучения (2023–2025) не привлекаются. Для полноценной модели угроз требуется систематический обзор с оценкой воспроизводимости.

Проблема «Византийского тупика». Применение алгоритмов защиты вроде Krum или Trimmed Mean (отсечение аномальных весов) в медицине натыкается на проблему: как отличить атаку от уникального клинического случая? Следующее рассуждение является аналитической интерпретацией авторов, а не выводом из конкретного источника. Если одна из клиник специализируется на редчайших патологиях, её локально обученные веса будут радикально отличаться от весов «стандартных» больниц. Защитные алгоритмы лидера могут ошибочно принять эту уникальность за poisoning-атаку и выбросить данные из общего пула, заблокировав развитие глобальной модели в области орфанных заболеваний. Конкретные параметры, при которых Krum, Trimmed Mean или Bulyan начинают отбрасывать валидные, но статистически «выбивающиеся» веса, в литературе не систематизированы; это направление требует отдельного исследования.

Проблема «безбилетника» (free-riding) на институциональном уровне. Помимо технических атак, SL сталкивается с институциональным дисбалансом: кто платит за инфраструктуру и кто получает выгоду? В FL центральный сервер может отслеживать вклад узлов и применять механизмы стимулирования. В SL постоянного координатора нет: merge leader выбирается динамически, и единого органа, который бы фиксировал вклад каждого узла на протяжении всего проекта, не существует. Это создаёт риск, при котором малые клиники с недостатком данных участвуют в рое преимущественно как получатели глобальной модели, внося минимальный вклад. Крупные центры при этом несут инфраструктурные затраты (GPU-серверы, электроэнергия, поддержка), а выгоду получают все участники пропорционально доступу к глобальной модели.

Обратная сторона проблемы. Контрдовод: для малых учреждений с недостатком данных участие в рое может быть единственным способом получить доступ к качественной модели. Исследование FACT (NeurIPS 2024) на реальном сценарии обучения классификатора рака кожи показало, что потери участвующих больниц снижаются почти на 66% относительно локального обучения [32]. Это означает, что проблема free-riding не односторонняя: малые участники могут вносить меньше, но ценность кооперативной модели для них может значительно превышать то, что они могли бы достичь самостоятельно. Суть проблемы — не «кто наживается», а как механизмы стимулирования отражают структуру вклада и выгод разных участников. Проблема free-riding хорошо изучена в федеративном обучении [12]; для SL конкретных исследований механизмов стимулирования на момент подготовки материала не обнаружено. Это открытая институциональная задача: без прозрачной модели распределения затрат и выгод устойчивое участие крупных центров в долгосрочных роях может оказаться под вопросом.

Non-IID и деградация производительности. Когда данные распределены неравномерно между узлами, SL сталкивается с деградацией производительности. Обзор 2024 года (arXiv-препринт 2405.00556v2, опубликованный в ACM Transactions on Privacy and Security в 2026 году) [11] отмечает, что при увеличении степени non-IID точность падает. Проект SwarmMAP (npj Systems Biology and Applications, 2026) [15] на данных single-cell RNA-секвенирования показал, что Swarm Learning достигает средней производительности 0,907, статистически не отличаясь от централизованного обучения (p = 0,937, Mann-Whitney U), однако на редких типах клеток с крайне малым числом образцов (например, эпикардиальные клетки, 217/0/9/61) производительность снижается [15]. Предлагаемое решение для non-IID — генеративная аугментация (SL-GAN): синтетические данные генерируются локально для балансировки распределения перед агрегацией весов [11]. Даты препринта (2024) и журнальной публикации (2026) различаются; при цитировании следует указывать обе во избежание путаницы.

Ограничения ML-фреймворков. Согласно документации HPE [4], SL поддерживает только параметрические модели на Keras (с TensorFlow 2 backend) или PyTorch. Все узлы должны использовать одну платформу. Поскольку SL работает путём обмена весами, архитектура нейросети на всех узлах должна быть совместима для корректной агрегации: невозможно объединить в один рой узел, обучающий ResNet-50, и узел с DenseNet-121. Это требует централизованного управления репозиториями моделей (Model Governance).

5. EHDS, TEHDAS2 и место Swarm Learning в регуляторном ландшафте

EHDS (Regulation (EU) 2025/327) [16] не упоминает Swarm Learning и не предписывает конкретную технологию децентрализованного обучения. Регламент требует обработки данных в защищённых средах (SPE), но выбор метода остаётся за участниками.

Конкретные требования EHDS к SPE (Article 73 и связанные положения). Регламент устанавливает, что доступ к электронным медицинским данным для вторичного использования предоставляется через защищённые среды обработки [16].

Ключевые требования:

• SPE должны обеспечивать автоматизированный контроль доступа: пользователь получает доступ только к тем данным, на которые у него есть разрешение (data permit) [16].
• SPE должны вести журналы аудита всех операций с данными, включая доступ, копирование, выгрузку [16].
• SPE должны быть интероперабельными — данные, полученные в одной SPE, должны быть совместимы с другими средами в рамках EHDS [16].
• SPE должны поддерживать федеративные вычисления — то есть возможность обучения моделей без выгрузки сырых данных за пределы исходной среды [16].

Практическое следствие для SL. EHDS Article 73 устанавливает требования к SPE как к среде обработки, а не к инфраструктуре координации. TEHDAS2 D7.4 [21] уточняет, что спецификации SPE «does not aim to serve as a complete practical implementation manual or prescribe specific technologies or architectural solutions» [21]. Для SL это означает: блокчейн-слой не является SPE и не подпадает под Article 73 напрямую. Локальные узлы, на которых хранятся и обрабатываются сырые данные, должны соответствовать SPE-требованиям — если они используются для вторичной обработки в рамках EHDS. SL не упоминается в EHDS и не является предписанной технологией; его применимость зависит от того, признает ли конкретная конфигурация SPE блокчейн-слой частью среды обработки. Вопрос о том, подлежат ли смарт-контракты и валидаторы блокчейна какой-либо форме сертификации, в TEHDAS2 не раскрыт и остаётся открытым для имплементационных актов.

TEHDAS2 (2026) [21] определяет функциональные требования к SPE: автоматизированный контроль доступа, журналы аудита, интероперабельность, поддержка федеративных вычислений. При этом TEHDAS2 в документе D7.4 (Executive Summary) прямо указывает, что федеративные вычисления остаются областью активных исследований (still an active research area) [21]. Это означает: SL относится к «целевой экосистеме», а не к «минимальному соответствию». D7.4 — это draft, и его статус не раскрыт; отнесение SL к «целевой экосистеме» является интерпретацией авторов, а не прямой цитатой. В документе, скорее всего, говорится о федеративных вычислениях в целом, а не о SL конкретно.

6. Применимость в российской системе здравоохранения

Инфраструктурный барьер. Требования SL (GPU 24–48 ГБ, 32–64 ГБ RAM, 4–8 ТБ NVMe) делают технологию применимой для крупных федеральных центров, но не для региональных ЛПУ. Флаг SL_MAKE_ME_ADMIN позволяет частично смягчить этот барьер: малые клиники могут участвовать в обучении, не принимая на себя агрегацию, но минимальные требования к GPU остаются.

Законодательные ограничения. ФЗ-152 [25] не содержит конструкции «data permit», аналогичной EHDS. Доступ к медицинским данным для исследовательских целей осуществляется через обезличивание и согласие субъекта. Сертификация FinOMOP [10] не имеет автоматического эквивалента в российском праве.

Статус весов модели по ФЗ-152. Закон определяет обезличивание как действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность данных субъекту (ст. 3, п. 5) [25]. Официальная публикация разъяснений регулятора о том, является ли уникальный идентификатор персональными данными без привязки к ФИО, не обнаружена; для юридически значимых решений требуется самостоятельная проверка. Ключевой вопрос: являются ли веса модели «обезличенными персональными данными» или «обезличенными данными» в смысле закона? В проекте поправок к ФЗ-152 предлагалось ввести разграничение: «обезличенные персональные данные» — информация, которая без дополнительной информации не позволяет определить субъекта; «обезличенные данные» — информация, которая не позволяет определить субъекта даже при использовании дополнительной информации. Веса модели, если они сохраняют принципиальную возможность реконструкции исходных данных (см. раздел 4 о gradient inversion [23]), ближе к первой категории. Это означает, что их передача третьим лицам может требовать согласия субъекта или иного законного основания.

Практический вывод: до появления нормативного разъяснения или судебной практики передача весов между клиниками в РФ должна сопровождаться DPIA и, при необходимости, согласием субъектов.

Конкретные нормы ФЗ-152, релевантные для SL:

• Ст. 3, п. 1 — определение персональных данных. Любая информация, относящаяся прямо или косвенно к определённому или определяемому физическому лицу [25]. Если веса модели позволяют (хотя бы теоретически) реконструировать данные пациента, они могут квалифицироваться как персональные данные.
• Ст. 3, п. 5 — обезличивание. Действия, в результате которых невозможно определить принадлежность персональных данных конкретному субъекту [25]. Статус весов модели как «обезличенных» не определён; необходима экспертиза.
• Ст. 7 — конфиденциальность персональных данных. Оператор обязан не раскрывать третьим лицам персональные данные без согласия субъекта [25]. Передача весов между клиниками может квалифицироваться как раскрытие, если веса признаны персональными данными.
• Ст. 14 — право субъекта на уничтожение данных. Если пациент отзывает согласие, как это отражается на глобальной модели, уже обученной на его данных? Механизм «машинного забывания» (machine unlearning) в SL, по всей видимости, не реализован (см. ниже).
• Ст. 12 — трансграничная передача. Если P2P-сеть выходит за пределы РФ, применяются дополнительные требования к трансграничной передаче персональных данных [25]. Детальный разбор применимых требований ст. 12 (уведомительный или разрешительный порядок, перечень «адекватных» юрисдикций) выходит за рамки настоящего материала и планируется в отдельной публикации; для применения в конкретном проекте требуется юридическая экспертиза.
• Подзаконные акты о защите медицинских данных. Конкретные требования к аттестации локальных контуров, шифрованию, журналированию устанавливаются приказами Минздрава России и ведомственными актами; их анализ выходит за рамки настоящего материала и требует отдельной юридической проработки.

Практический риск: machine unlearning (аналитическая интерпретация, требующая проверки). Ст. 14 ФЗ-152 даёт субъекту право требовать уничтожения его персональных данных [25]. Если пациент отзывает согласие после того, как модель уже обучена на его данных, возникает вопрос: как удалить вклад этого пациента из глобальной модели? В стандартных реализациях SL механизм «машинного забывания» (machine unlearning), по всей видимости, отсутствует: глобальная модель представляет собой агрегат весов, и обратное «вычитание» вклада одного узла технически нетривиально.

Однако в научной литературе активно развиваются методы federated unlearning, применимые к децентрализованным архитектурам. Обзоры по федеративному обучению и роевому интеллекту систематизируют подходы к машинному забыванию в федеративных и роевых системах, включая perturbation techniques, model decomposition и incremental learning [27]. Отдельные работы предлагают решения для роевых consumer-систем (FL + Fuzzy Unlearning), демонстрируя принципиальную возможность удаления вклада без центрального сервера. Важная оговорка: большинство методов federated unlearning (FedEraser, FedRecover и др.) предполагают наличие центрального координатора, который управляет процессом забывания. В SL постоянного центрального сервера нет — merge leader выбирается динамически, decryptor каждый раунд разный. Поэтому прямой перенос методов FU на SL требует перепроектирования координационного механизма. Конкретных исследований, тестирующих federated unlearning непосредственно на HPE Swarm Learning, на момент подготовки материала не обнаружено — это остаётся открытой задачей.

Важное юридическое предупреждение. ФЗ-152 и подзаконные акты Минздрава не содержат понятия «веса модели», и статус таких данных как обезличенных/не-персональных не определён ни одним нормативным актом или судебным прецедентом. Приравнивание весов к «обезличенным данным» — это авторская интерпретация, которая не может служить основанием для принятия юридически значимых решений. Более того, как показано в разделе 4, градиентные инверсионные атаки демонстрируют принципиальную возможность частичной реконструкции обучающих данных из весов или градиентов [23]. Поэтому тезис «веса не являются персональными данными» не может приниматься как универсальный: он требует оценки конкретной архитектуры модели, размера батча, наличия дифференциальной приватности или безопасной агрегации. Любое внедрение SL в российской юрисдикции требует обязательного согласования с регулятором (Роскомнадзор, Минздрав) и проведения DPIA.

Наблюдение: пилоты SL в России (в рамках поискового охвата настоящего анализа). В рамках поискового охвата настоящего анализа публичных российских пилотов Swarm Learning в здравоохранении не обнаружено. Это не исключает наличия непубличных внутренних экспериментов или корпоративных внедрений. Однако отсутствие публичных кейсов — само по себе значимый факт, указывающий на то, что российская практика применения SL в медицине пока находится на стадии теоретического интереса, а не развёрнутых пилотов.

Проблема ЕГИСЗ и централизации. Текущий вектор Минздрава РФ направлен на централизацию данных в ГИСЗ субъектов и ВМИС. Swarm Learning предлагает альтернативную, гибридную парадигму: вместо централизации всех сырых медицинских карт в единое федеральное озеро данных, Минздрав может выступать «архитектором смарт-контрактов» в блокчейне, координируя локальное обучение ИИ на мощностях региональных ЦОДов. Однако это утверждение является спекулятивным и не подкреплено анализом российского законодательства о блокчейне и смарт-контрактах, оценкой готовности Минздрава к такой роли или прецедентами. Оно отражает технологическую парадигму, выгодную консультантам и интеграторам, и не должно восприниматься как нейтральная рекомендация.

Что учесть при оценке бюджета. Внедрение SL требует значительных затрат, которые удобнее рассматривать не как готовую смету, а как перечень статей, требующих уточнения под конкретный проект. Конкретные цифры зависят от выбранной конфигурации GPU, региона, наличия существующей инфраструктуры и условий поставщиков; прямых публичных расчётов TCO для SL-проектов на момент подготовки материала не опубликовано. Указанные цены носят ориентировочный характер, основаны на публичных коммерческих источниках и требуют проверки у поставщиков.

Приведённый перечень — это ориентир для формирования запроса на бюджет, а не готовая смета. Для конкретного проекта требуется детальная проработка с учётом региональных цен, существующей инфраструктуры и условий поставщиков. Без централизованной поддержки региональные ЛПУ не смогут участвовать в федеративных вычислениях.

Кадровый дефицит. Эксплуатация SL-узлов требует квалифицированных специалистов по машинному обучению, блокчейн-инфраструктуре и информационной безопасности. В региональных ЛПУ такие компетенции, как правило, отсутствуют.

Организационные барьеры и юридическая ответственность. Не решены вопросы: доверия между клиниками-участниками (кто гарантирует, что партнёр не использует уязвимости?), согласования модели управления (Model Governance) между разными организациями. Особый вопрос — юридическая ответственность при ошибке глобальной модели. Если SL-модель выдаёт неверный диагноз, который приводит к врачебной ошибке, кто несёт ответственность: клиника, где модель применялась? Клиника, чьи данные исказили глобальную модель? Разработчик SL-фреймворка? Оператор блокчейн-инфраструктуры? В российской практике аналогичных прецедентов нет; в ЕС этот вопрос также не урегулирован. Возможные направления решения: (1) договорная модель, где ответственность распределяется между участниками пропорционально вкладу данных; (2) страхование ответственности для операторов SL; (3) регуляторное закрепление ответственности за клиникой, применяющей модель, с правом регресса к другим участникам. Ни один из этих подходов не апробирован.

7. Итоги и выводы

Swarm Learning — одна из технологий децентрализованного обучения, получивших наибольшее внимание в медицинских приложениях за последние пять лет. Три рецензируемые публикации в изданиях Nature Portfolio и один сопроводительный пресс-релиз за 2021–2026 гг. напрямую посвящены применению SL в медицинских сценариях:

1. Warnat-Herresthal S. et al. Swarm Learning for decentralized and confidential clinical machine learning // Nature. — 2021 [1]. Первое масштабное подтверждение применимости SL в клинических исследованиях.
2. Saldanha O. et al. Swarm Learning for breast cancer detection in MRI // Communications Medicine (Nature Portfolio). — 2025 [8]. Применение SL к диагностике рака молочной железы по МРТ-снимкам.
3. SwarmMAP: Swarm Learning for single-cell RNA sequencing // npj Systems Biology and Applications (Nature Portfolio). — 2026 [15]. Применение SL к аннотации типов клеток в данных single-cell RNA-секвенирования; препринт на bioRxiv (2025).

Сопроводительный материал: пресс-релиз DZNE [7] к публикации 2021 года. Он не является самостоятельной рецензируемой публикацией, но фиксирует ключевые формулировки о применимости SL к разным типам медицинских данных.

Дополнительно: проект HPE PriSyn (2022–2025) [30] использовал Swarm Learning как компонент, комбинируя его с дифференциальной приватностью и FPGA-ускорением. Это не независимая от SL технология, а последующий инженерный проект, подтверждающий техническую осуществимость децентрализованного анализа в немецком медицинском контексте.

Три крупных клинических проекта (DZNE [1], ODELIA [8][9], FinOMOP [10]) и два пилотных проекта (PriSyn [30], KatherLab [12][13]) демонстрируют применимость SL. KatherLab и PriSyn присутствуют в таблице проектов раздела 3, но не входят в перечень публикаций Nature Portfolio: KatherLab публикуется в других изданиях, PriSyn — отчёт о завершённом проекте.

Однако это не означает превосходства SL над альтернативами: сравнение с split learning, secure multi-party computation (SMPC), гомоморфным шифрованием, gossip-based federated learning и decentralized SGD в литературе не систематизировано. Ниже — краткая характеристика ключевых альтернатив:

SL не является требованием EHDS и не решает автоматически вопросы безопасности и регуляторного соответствия. Технология остаётся экспериментальной: для продакшн-внедрения требуется решение проблем non-IID, безопасности и сертификации.

Ключевые выводы:

• Архитектурное отличие от FL. SL устраняет постоянный центральный сервер, но механизм выбора лидера создаёт скрытую иерархию по вычислительной мощности. Если лидер предсказуем, архитектура не является полностью децентрализованной де-факто. Флаг SL_MAKE_ME_ADMIN — критически важный инструмент для гетерогенных сетей. Если гомоморфное шифрование реализовано в используемой версии, оно снижает риск утечки параметров через лидера, но не устраняет риск манипуляции составом агрегации; наличие механизма требует проверки (см. раздел 2).
• Клиническая валидация и сравнение с централизованным обучением. DZNE подтвердил, что SL-классификаторы превосходят модели отдельных узлов [1]; ODELIA подтвердил применимость к МРТ-диагностике [8]; FinOMOP получил первую регуляторную сертификацию Findata для федеративной системы [10]; PriSyn подтвердил техническую осуществимость комбинации SL + DP + FPGA [30]. На задачах инфраструктурного прогнозирования SL показывает результаты, сопоставимые с централизованным обучением, при выигрыше в скорости [31]; на клинических медицинских датасетах прямых сравнений нет. Единственное сравнение на клинических данных (SwarmMAP) показало статистическое отсутствие различий [15], но на редких типах клеток SL уступает.
• Границы безопасности. Backdoor-атаки с распространением (Yang et al., 2022) [3], стратегия SSE, градиентные инверсионные атаки [23], poisoning, Sybil-атаки и компрометация блокчейн-инфраструктуры формируют комплексную модель угроз. Утверждение о безопасности весов требует оценки конкретной конфигурации, а не принимается как универсальное.
• Институциональный дисбаланс. Проблема free-riding в SL не решена: кто платит за инфраструктуру и кто получает выгоду? В отличие от FL, где центральный сервер может отслеживать вклад, в SL единого органа мониторинга нет. Однако проблема не односторонняя: для малых учреждений участие в рое может снижать потери модели почти на 66% относительно локального обучения [32]. Механизмы стимулирования для SL на момент подготовки материала не разработаны.
• Отношение к EHDS. Регламент не предписывает SL [16]. Технология может использоваться для выполнения функциональных требований к SPE, но выбор метода остаётся за участниками. TEHDAS2 [21] относит федеративные вычисления к целевой экосистеме, а не к минимальным требованиям. D7.4 — это draft, и его статус не раскрыт.
• Российский контекст. Применимость ограничена инфраструктурой, законодательством и бюджетными возможностями. В рамках поискового охвата настоящего анализа публичных российских пилотов SL в здравоохранении не обнаружено — российская практика находится на стадии теоретического интереса. Swarm Learning может рассматриваться как альтернатива централизации данных в ЕГИСЗ только при условии аттестации локальных контуров, проведения DPIA и подтверждения регулятором. Приравнивание весов к обезличенным данным не имеет нормативного основания [25]. Механизм machine unlearning, необходимый для compliance со ст. 14 ФЗ-152 [25], в стандартных реализациях SL, по всей видимости, отсутствует; это аналитическая интерпретация, требующая проверки в документации или у вендора. Конкретных исследований, тестирующих federated unlearning непосредственно на HPE Swarm Learning, не обнаружено — это открытая задача.

Чек-лист для CIO перед запуском пилота на SL:

• Проверить открытость портов для P2P-сигналов gRPC через корпоративные межсетевые экраны.
• Оценить локальный объём VRAM (требуется от 24 ГБ на узловую GPU).
• Провести аудит структуры данных на соответствие единой модели (например, OMOP CDM или внутреннему жёсткому регламенту).
• Определить роли узлов: какие центры будут агрегаторами (SL_MAKE_ME_ADMIN = True), а какие — только поставщиками весов (False).
• Проверить совместимость ML-платформы (Keras или PyTorch) на всех узлах.
• Провести оценку воздействия на защиту данных (DPIA) с учётом риска градиентных инверсионных атак [23].
• Сформировать перечень статей бюджета (см. таблицу «Что учесть при оценке бюджета» в разделе 6) и уточнить цифры под конкретный проект.
• Проверить наличие квалифицированных кадров для эксплуатации SL-узлов.
• Согласовать с регулятором (Роскомнадзор, Минздрав) статус весов модели как данных.
• Проверить, требуется ли механизм machine unlearning для compliance со ст. 14 ФЗ-152 [25]; при необходимости — оценить, реализуем ли он в выбранной архитектуре SL.
• Проработать договорную модель ответственности между участниками на случай ошибки глобальной модели.
• Заранее определить модель распределения затрат и выгод между участниками роя (проблема free-riding).

Ограничения и область применения. Настоящий просветительский обзорно-аналитический материал покрывает архитектуру Swarm Learning, клиническую валидацию, модель угроз, регуляторный контекст (EHDS, TEHDAS2) и российскую специфику. Он не является систематическим обзором литературы, независимой технической оценкой HPE Swarm Learning, юридическим заключением или инвестиционным анализом. Ключевые пробелы, которые читатель должен закрыть самостоятельно или с привлечением внешних экспертов:

1. Сравнение SL с централизованным обучением на клинических данных — на задачах инфраструктурного прогнозирования сравнение уже есть [31]; на клинических медицинских датасетах прямых сравнений по-прежнему нет.
2. Стоимость владения — перечень статей расходов требует детализации под конкретный проект; готовых публичных расчётов TCO для SL не опубликовано.
3. Регуляторное соответствие в РФ — анализ основан на действующих нормах, но не учитывает возможные изменения (поправки к ФЗ-152, имплементационные акты EHDS). Детальный разбор ст. 12 и приказов Минздрава планируется в отдельной публикации.
4. Модель угроз — опирается на ограниченный набор источников; для полноценной оценки требуется систематический обзор.
5. Роль гомоморфного шифрования — механизм, заложенный в патентной заявке HPE [26], существенно меняет оценку рисков, связанных с компрометацией лидера; в отчёте PriSyn [30] гомоморфное шифрование не упоминается; наличие механизма в конкретной версии продукта требует проверки.
6. Machine unlearning — утверждение об отсутствии механизма является аналитической интерпретацией, требующей проверки в документации или у вендора; применимость методов federated unlearning к SL требует перепроектирования координационного механизма.
7. Институциональная модель распределения затрат — проблема free-riding в SL не решена; механизмы стимулирования не разработаны.

Для кого этот материал. CIO и руководители ИТ-служб медицинских организаций, оценивающие перспективы участия в децентрализованных вычислениях. Эксперты, разрабатывающие регуляторные требования к медицинским данным. Исследователи, начинающие работу с Swarm Learning.

Не для: принятия инвестиционных решений без дополнительной due diligence; юридических заключений; выбора технологии без сравнения с альтернативами (split learning, SMPC, гомоморфное шифрование, gossip-based FL).

Источники

Анализ, приведённый в материале, выполнен с использованием технологий искусственного интеллекта (анализ и структурирование открытых данных), а также с учётом экспертного опыта автора в области автоматизации медицинских организаций федерального уровня. Ниже приведены источники, включая ссылки, документацию, нормативные акты и прочие материалы, упомянутые в материале. Информация актуальна на момент публикации; для применения в конкретной ситуации рекомендуется сверяться с действующей редакцией документов.