Обучение на медицинских данных

Обучение на медицинских данных — одна из наиболее чувствительных операций в IT-инфраструктуре. Медицинские сведения о пациенте относятся к специальным категориям по ст. 10 ФЗ-152: их обработка по общему правилу запрещена без явного согласия. Добавьте к этому требования ФСТЭК по Приказу № 21, уровни защищённости УЗ-1..4 из ПП РФ № 1119 и обязанность локализовать базы в России по ч. 5 ст. 18 ФЗ-152 — и получите юридически сложный проект, где технические ошибки стоят дороже, чем в любом другом сегменте. В этом материале — практическая карта: от правового основания до выбора метода обезличивания и архитектуры SaaS в облаке.

Почему медицинские данные — особый случай по ФЗ-152?

Статья 10 ФЗ-152 относит сведения о состоянии здоровья, поставленных диагнозах, применяемом лечении к специальной категории персональных данных. Обрабатывать их оператор вправе только при наличии одного из оснований, закрытый перечень которых установлен ч. 2 ст. 10: явное согласие субъекта, необходимость защиты жизни и здоровья, осуществление медицинской деятельности профессиональным участником и ряд других. Исследовательские и продуктовые цели в этот перечень автоматически не попадают.

Для CTO это означает следующее: если датасет для обучения содержит хотя бы одно поле, позволяющее идентифицировать пациента (ФИО, дату рождения, номер полиса, результаты анализов), — вы обрабатываете спецкатегорию. Правовое основание «исполнение договора» по п. 5 ч. 1 ст. 6 ФЗ-152 здесь не работает: ч. 2 ст. 10 требует специального основания.

Параллельно действует ст. 13 Федерального закона № 323-ФЗ «Об основах охраны здоровья граждан»: сведения о факте обращения за медицинской помощью и о состоянии здоровья составляют врачебную тайну. Передача таких сведений третьим лицам — в том числе IT-подрядчику, обучающему модель, — без письменного согласия пациента нарушает одновременно два закона.

Дополнительный риск возник с 11.12.2024: ст. 272.1 УК РФ (введена ФЗ-421) криминализировала незаконное использование, передачу, сбор или хранение компьютерной информации, содержащей ПДн. Максимальное наказание по ч. 5 — лишение свободы до 10 лет. Это не административный штраф, от которого можно откупиться, — это уголовное дело на конкретного разработчика или CTO, подписавшего техническое задание.

Как выбрать уровень защищённости УЗ-1..4 для медицинской ИСПДн?

Постановление Правительства РФ № 1119 устанавливает четыре уровня защищённости информационных систем персональных данных. Выбор уровня зависит от трёх переменных: категория ПДн, тип угроз (угрозы 1-го, 2-го или 3-го типа) и число субъектов. Медицинские данные относятся к специальным категориям — это автоматически повышает базовый уровень.

Практическая матрица для CTO:

• УЗ-1 — актуальны угрозы 1-го типа (недокументированные возможности системного ПО) + спецкатегория + более 100 000 субъектов. Типичен для федеральных МИС и ЕГИСЗ-сегментов.
• УЗ-2 — угрозы 2-го типа (НДВ прикладного ПО) + спецкатегория любого масштаба, либо угрозы 1-го типа + менее 100 000 субъектов. Встречается в региональных медицинских ИС и крупных частных клиниках.
• УЗ-3 — угрозы 3-го типа + спецкатегория + более 100 000 субъектов, либо более широкие комбинации для иных категорий. Наиболее частый вариант для коммерческих МИС, телемедицинских платформ и ML-пайплайнов на обезличенных медданных.
• УЗ-4 — угрозы 3-го типа + общие или биометрические ПДн + менее 100 000 субъектов. Применим для небольших лабораторий с ограниченным датасетом.

Критически важный момент для ML-инфраструктуры: если обучение происходит в облаке, необходимо учитывать, что облачный провайдер становится лицом, осуществляющим обработку по поручению (п. 3 ч. 1 ст. 6 ФЗ-152). Это поручение оформляется договором с перечнем обрабатываемых данных, целей и мер защиты. Провайдер обязан соответствовать тому же УЗ, что и оператор. Облако в РФ — не само по себе достаточное условие: нужна аттестация или лицензия ФСТЭК.

Приказ ФСТЭК № 21 от 18.02.2013 задаёт конкретный состав мер по каждому уровню: 15 групп мер (идентификация и аутентификация, управление доступом, защита носителей, регистрация событий, антивирусная защита, обнаружение вторжений и др.). Для УЗ-3 обязателен базовый набор всех 15 групп; для УЗ-1 и УЗ-2 — расширенный с дополнительными компенсирующими мерами. Если ML-пайплайн обрабатывает данные до обезличивания — он входит в периметр ИСПДн и подпадает под Приказ № 21 в полном объёме.

Что такое обезличивание медицинских данных для ML и как его применять правильно?

Обезличивание — это совокупность действий, в результате которых связь между ПДн и конкретным субъектом становится невозможной без использования дополнительной информации, хранящейся отдельно. После обезличивания данные перестают быть персональными по смыслу ст. 3 ФЗ-152, и к ним не применяются требования закона о защите ПДн — в том числе требование специального правового основания по ст. 10.

С 2025 года методы обезличивания регламентированы подзаконным актом Роскомнадзора. Утверждены пять методов:

• Введение идентификаторов — замена прямых идентификаторов (ФИО, СНИЛС, номер полиса) на синтетические ключи. Таблица соответствия хранится изолированно от датасета.
• Изменение состава и семантики — удаление или замена отдельных атрибутов (например, точной даты рождения заменяется возрастной группой).
• Декомпозиция — разбиение датасета на непересекающиеся фрагменты, каждый из которых не позволяет идентифицировать субъекта.
• Перемешивание — нарушение связей между атрибутами разных субъектов внутри одного датасета.
• Обобщение и агрегация — замена точных значений диапазонами (возраст «38 лет» → «35–40 лет», диагноз МКБ-10 на уровень класса заболевания вместо точного кода).

Для ML-задач наиболее применим метод введения идентификаторов в комбинации с обобщением. Однако здесь скрыта операционная ловушка: переобученная модель способна косвенно восстанавливать идентичность субъекта из паттернов, если датасет мал или несбалансирован. Регулятор ещё не накопил практику по атакам реидентификации, но уголовный состав по ст. 272.1 УК потенциально покрывает ситуацию, когда ML-система de facto деобезличивает данные.

Как организовать поручение обработки и мультиарендность в SaaS на медданных?

В SaaS-продуктах для медицины часто возникает вопрос о разграничении ролей: кто является оператором, а кто — лицом, обрабатывающим ПДн по поручению. Если платформа предоставляется клинике, а сама клиника передаёт в систему данные пациентов — клиника остаётся оператором, а SaaS-компания выступает обработчиком (процессором) по договору-поручению. Это разграничение критически важно с точки зрения ответственности.

Договор поручения должен содержать: перечень категорий ПДн, перечень действий, цели обработки, обязанности процессора по конфиденциальности, требования к мерам защиты, условия уничтожения данных по окончании договора. Без этого договора SaaS-компания де-факто становится самостоятельным оператором со всеми вытекающими обязанностями — включая отдельное уведомление РКН по ст. 22 ФЗ-152.

В мультиарендной архитектуре добавляется требование изоляции: данные одного арендатора (клиники) не должны пересекаться с данными другого ни на уровне хранилища, ни в процессе обучения ML-модели. Совместное обучение на объединённом датасете нескольких клиник без согласия каждой на передачу данных иным операторам нарушает ст. 5 ФЗ-152 (принцип недопустимости объединения баз с несовместимыми целями).

Для облачной инфраструктуры критически важен вопрос локализации. Статья 18 ч. 5 ФЗ-152 требует, чтобы первичная запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ осуществлялись в базах, расположенных на территории России. Использование иностранного облака (AWS, GCP, Azure зарубежные регионы) для хранения медицинских данных российских пациентов — нарушение локализации. Штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽, при повторном нарушении по ч. 9 — от 6 до 18 млн ₽.

Как применялись требования на практике: два сценария

Сценарий 1. Телемедицинская платформа без договора-поручения. IT-компания (Центральный ФО, начало 2026) предоставляла SaaS-решение для сети частных клиник: запись пациентов, хранение анамнеза, аналитика обращений. Клиники передавали в систему данные о диагнозах и назначениях. В ходе внеплановой проверки РКН установил, что договор-поручение с SaaS-провайдером отсутствует, а облачная инфраструктура развёрнута на зарубежном хостинге. По результатам составлены протоколы: по ч. 8 ст. 13.11 КоАП (нарушение локализации) и по ч. 1 ст. 13.11 (обработка без законного основания). Итоговый штраф для юридического лица — в диапазоне нескольких миллионов рублей. SaaS-провайдер переносил инфраструктуру в российское облако в течение трёх месяцев под контролем регулятора.

Сценарий 2. ML-модель на необезличенном датасете клиники (кейс из общей практики DATUM). Технический директор исследовательского стартапа (Северо-Западный ФО, осень 2025) получил от клиники-партнёра выгрузку историй болезни для обучения модели предиктивной диагностики. Данные передавались «как есть», без применения обезличивания. Внутренний аудит, инициированный по запросу инвестора, выявил: ПДн относятся к спецкатегории, правовое основание по ч. 2 ст. 10 ФЗ-152 не оформлено, договор с клиникой не содержит поручения на обработку. Юристы DATUM подготовили ретроспективный пакет документов: акт обезличивания по методу введения идентификаторов, договор-поручение с клиникой, дополнение к уведомлению РКН. Проверка регулятора инициирована не была; стартап привёл документацию в соответствие до начала коммерческих продаж.

Услуги DATUM по теме

• DPIA (оценка воздействия на ПДн) — для ML-проектов на спецкатегориях: идентификация рисков и выбор правового основания.
• Аудит соответствия 152-ФЗ — от 100 000 ₽, чек-лист 38 пунктов, приоритизированный план устранения.
• Комплект ОРД под ключ — договор-поручение, акт обезличивания, политика, приказы, регламент реагирования.

Частые вопросы

1. Какой УЗ выбрать для SaaS, обрабатывающего медицинские данные?

Минимальный уровень защищённости для системы, обрабатывающей специальные категории ПДн (медицинские данные), — УЗ-3 по ПП РФ № 1119 при угрозах 3-го типа и любом числе субъектов. Если актуальны угрозы 2-го типа (недокументированные возможности прикладного ПО) или число субъектов превышает 100 000 при угрозах 3-го типа — УЗ-2. Тип актуальных угроз определяется в процессе моделирования угроз по методике ФСТЭК и закрепляется в техническом паспорте ИСПДн. Для большинства коммерческих медицинских SaaS без связи с ЕГИСЗ актуален УЗ-3.

2. Можно ли использовать иностранные облака для обучения ML-моделей на медданных?

Нет, если датасет содержит идентифицируемые данные российских пациентов. Статья 18 ч. 5 ФЗ-152 обязывает хранить и обрабатывать (в том числе извлекать для обучения) ПДн граждан РФ только в базах на территории России. Обезличенные данные после подтверждённого обезличивания формально не являются ПДн и могут обрабатываться за рубежом, однако граница между обезличенными и псевдоанонимизированными данными на практике размыта. За нарушение локализации — штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽.

3. Что такое обезличивание для ML и чем оно отличается от анонимизации?

Обезличивание по смыслу ФЗ-152 и утверждённых РКН методов — это обратимый процесс: связь между данными и субъектом разрывается, но при наличии дополнительной информации (таблицы соответствия) может быть восстановлена. Анонимизация — необратима. Для ML регулятор признаёт обезличенные данные выведенными из-под режима ФЗ-152 при условии, что метод применён корректно и таблица соответствия хранится изолированно. Риск — атаки реидентификации через обученную модель; эта область пока не имеет устойчивой судебной практики в РФ.

4. Кто является оператором ПДн в мультиарендной SaaS для клиник?

Клиника, которая передаёт данные пациентов в SaaS-систему, остаётся оператором и несёт ответственность перед регулятором и субъектами. SaaS-компания выступает обработчиком (лицом, осуществляющим обработку по поручению) по п. 3 ч. 1 ст. 6 ФЗ-152. Поручение оформляется договором с обязательным перечнем: категории ПДн, действия, цели, меры защиты, условия уничтожения. Если договор-поручение отсутствует, РКН вправе квалифицировать SaaS-компанию как самостоятельного оператора — с обязанностью подать уведомление по ст. 22 ФЗ-152 и нести ответственность за нарушения самостоятельно.

5. Какие СЗИ обязательны для ML-инфраструктуры на медданных?

Приказ ФСТЭК № 21 определяет состав мер в 15 группах (ИАФ, УПД, ОПС, ЗНИ, РСБ, АВЗ, СОВ, АНЗ, ОЦЛ, ОДТ, ЗСВ, ЗТС, ЗИС, УКФ, ОПО). Для УЗ-3 обязателен базовый набор всех 15 групп. Конкретные средства защиты информации (СЗИ) выбираются на основании модели угроз; при обработке спецкатегорий в государственных системах требуется сертифицированное ПО. Для коммерческого SaaS сертификация ФСТЭК не обязательна, но оператор должен подтвердить, что применяемые меры соответствуют требованиям выбранного УЗ — в том числе через аттестацию или экспертную оценку.

Итог

Обучение ML-моделей на медицинских данных требует одновременного закрытия трёх контуров: правового основания по ч. 2 ст. 10 ФЗ-152, технических мер защиты по ПП РФ № 1119 и Приказу ФСТЭК № 21, а также корректного обезличивания с документальным подтверждением применённого метода. Пропуск любого из контуров создаёт риски по ст. 13.11 КоАП (от 3 до 500 млн ₽ при повторном инциденте) и по ст. 272.1 УК РФ (до 10 лет лишения свободы).

Специалисты DATUM сопровождают ML-проекты на чувствительных данных: от моделирования угроз и выбора УЗ до оформления договора-поручения с облачным провайдером и подачи уведомления в РКН.