Локализация и трансграничная передача медданных: что можно отправлять за рубеж и как

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

В российском праве вопрос «можно ли отправить медданные за рубеж» распадается на два разных правила, с разными статьями и разными штрафами. Первое – локализация: с 1 июля 2025 года при сборе персональных данных граждан России их запись, систематизация, накопление, хранение, уточнение и извлечение с использованием баз данных за пределами страны прямо запрещены (ст. 18 ч. 5 152-ФЗ в редакции 23-ФЗ); штраф – до 6 млн ₽, повторно – до 18 млн ₽ (ч. 8–9 ст. 13.11 КоАП). Второе – трансграничная передача (ст. 12): до её начала оператор получает от иностранного получателя сведения о мерах защиты и подаёт в Роскомнадзор отдельное уведомление. В страны из перечня государств с адекватной защитой передавать можно сразу после уведомления, в остальные – только после 10 рабочих дней рассмотрения, и регулятор вправе передачу запретить или ограничить. Для медданных к этому добавляются основание для специальной категории (письменное согласие) и письменное согласие на раскрытие врачебной тайны, а иностранный обработчик по поручению отвечает перед пациентом вместе с оператором (ст. 6 ч. 6). На практике это значит: зарубежные SaaS для аналитики, отслеживания ошибок, видеосвязи и ИИ вообще не получают медданных; у зарубежной команды разработки нет доступа к продакшну; второе мнение зарубежной клиники – редкий, задокументированный и минимальный по составу поток через отдельный шлюз. В статье – порядок действий, расчёт сроков, шесть сценариев и архитектурный паттерн «весь контур данных в России».

Зачем это читать

Почти любой цифровой продукт собран из чужих сервисов, и у многих из них серверы за рубежом: счётчик аналитики, трекер ошибок, сервис рассылок, CDN, видео-API, большая языковая модель, таск-трекер подрядчика. Пока продукт не связан со здоровьем, этим занимаются по остаточному принципу. В телемедицине каждый такой сервис – возможный канал, по которому специальная категория персональных данных и врачебная тайна уходят за границу. С 2025 года цена ошибки выросла: прямой запрет зарубежных баз данных, оборотные штрафы за утечки, уголовная ст. 272.1 УК РФ. Статья для основателей, CTO и ответственных за обработку ПДн, которые выбирают стек, нанимают распределённую команду или слышат от клиники вопрос: «А куда у вас уходят данные пациентов?» Мы разведём два правила – локализацию и трансграничную передачу, – переведём каждое на язык продуктовых решений, разберём шесть типичных зарубежных зависимостей и покажем архитектурный паттерн, который закрывает их все.

Два правила, а не одно

Для начала важно понять, что локализация и трансграничная передача регулируют разные вещи.

Локализация (ст. 18 ч. 5 152-ФЗ) – о том, где находятся базы данных, когда оператор собирает данные граждан России. Это требование к архитектуре хранения: оно касается основной базы, реплик, бэкапов, журналов и любых других хранилищ, куда записываются собранные ПДн.

Трансграничная передача (ст. 12) – о том, кому передаются данные: «передача персональных данных на территорию иностранного государства органу власти иностранного государства, иностранному физическому лицу или иностранному юридическому лицу» (ст. 3 п. 11). Это требование к потокам данных: кто получатель, на каком основании, уведомлён ли регулятор.

Одна и та же зависимость может нарушать оба правила сразу. Зарубежный SaaS-сервис аналитики, в который приложение пишет события с идентификаторами пациентов, – это и запись данных россиян в зарубежную базу при сборе (локализация), и передача иностранному юрлицу (трансграничная передача), и, раз речь о медданных, раскрытие специальной категории и врачебной тайны без основания. А вот передача копии выписки зарубежной клинике по просьбе пациента, когда первичная запись сделана в российской базе, – вопрос ст. 12 и согласия, а не локализации. От этого различия зависит, что делать: в первом случае менять архитектуру, во втором – оформлять передачу.

Кроме двух правил, есть ещё два вопроса, специфичных для медицины. Основание: для специальной категории нужно письменное согласие или медицинские цели у лица, обязанного хранить врачебную тайну (ст. 10 ч. 2 152-ФЗ). Врачебная тайна: раскрытие сведений другим лицам – с письменного согласия пациента, в том числе в целях медицинского обследования и лечения (ст. 13 ч. 3 323-ФЗ). И отдельный вопрос – роль получателя: если зарубежная сторона обрабатывает данные по вашему поручению, она становится иностранным обработчиком, а это влечёт свои последствия (ст. 6 ч. 6).

Нажмите, чтобы увеличить

Два уточнения терминов сэкономят время на каждой встрече с юристом. Во-первых, «оператор» и «лицо, обрабатывающее данные по поручению», – те же роли, что в статье о 152-ФЗ и врачебной тайне: медорганизация обычно оператор, ваша платформа – обработчик, и обязанность соблюдать конфиденциальность и требования к защите, включая хранение в России, переходит к обработчику через поручение (ст. 6 ч. 3). Во-вторых, доступ – тоже форма передачи: предоставление ПДн закон определяет как «действия, направленные на раскрытие персональных данных определённому лицу или определённому кругу лиц» (ст. 3 п. 6). Поэтому удалённый доступ иностранного специалиста к базе с данными пациентов разумно считать трансграничной передачей, даже если ни один файл не был скопирован за рубеж.

Локализация: что запрещено с 1 июля 2025 года

До 2025 года норма была сформулирована как обязанность оператора использовать базы данных в России. 23-ФЗ от 28.02.2025 добавил прямой запрет: при сборе персональных данных, в том числе через интернет, запись, систематизация, накопление, хранение, уточнение (обновление, изменение) и извлечение персональных данных граждан России с использованием баз данных, находящихся за пределами страны, «не допускаются». Исключения – случаи из п. 2, 3, 4 и 8 ч. 1 ст. 6; телемедицинскому продукту рассчитывать на них без заключения юриста не стоит.

Для инженеров отсюда три следствия.

«База данных» – не только основная СУБД. Реплика для чтения в зарубежном регионе, бэкап в иностранном объектном хранилище, журнал приложения в зарубежном SaaS для логов, поисковый индекс, кэш, CRM, хелпдеск, сервис рассылок со списком адресов, таблица в зарубежном облачном офисе – всё это базы, в которые пишутся собранные данные. Карта хранилищ – первое, что нужно для любой проверки локализации.

Обработчик тоже обязан соблюдать локализацию. Требование приходит к подрядчику через поручение: если ваша платформа по поручению клиники пишет данные пациентов в зарубежный сервис, нарушение совершает оператор, а претензии оператора получаете вы. Юристы отмечают, что отдельного состава ответственности за нарушение локализации для обработчиков в КоАП нет, но это слабое утешение, когда клиника расторгает договор.

Где кончается локализация и начинается передача – вопрос толкования. Формально новая ч. 5 говорит о действиях при сборе и не упоминает передачу, поэтому передача за рубеж после сбора данных в российскую базу по правилам ст. 12 не исключена. Но представители Госдумы публично высказывали и позицию, что изменения означают полный запрет трансграничной передачи; окончательного толкования регулятора на дату проверки мы не нашли. Инженерное решение, которое выдерживает оба прочтения: все хранилища медданных находятся в России, а любая передача за рубеж – исключение, оформленное отдельно, минимальное по составу и не превращающееся во второе постоянное хранилище.

Цена нарушения: ч. 8 ст. 13.11 КоАП – до 6 млн ₽ для юрлица, повторно (ч. 9) – до 18 млн ₽. И это без учёта того, что неправомерная передача медданных может одновременно оказаться инцидентом по ст. 21 ч. 3.1 со своими сроками уведомления и штрафом до 15 млн ₽ за утечку специальной категории (ч. 16 ст. 13.11).

Нажмите, чтобы увеличить

Трансграничная передача по ст. 12: порядок по шагам

Если передача за рубеж действительно нужна, действует уведомительный порядок по ст. 12 152-ФЗ (в редакции 266-ФЗ, с 1 марта 2023 года). Шаги в том порядке, в котором их выполняют:

1. Основание и цель. Передача – тоже обработка, и для данных о здоровье нужно основание по ст. 10: на практике это письменное согласие пациента, оформленное отдельным документом, где названы получатель, страна, цели и состав данных. Для сведений, составляющих врачебную тайну, – письменное согласие на их раскрытие (ст. 13 ч. 3 323-ФЗ).
2. Сведения от получателя. До подачи уведомления оператор обязан получить от иностранного получателя сведения о принимаемых им мерах защиты и условиях прекращения обработки, его реквизиты, а если страна не входит в перечень государств с адекватной защитой, – сведения о её правовом регулировании в области ПДн (ст. 12 ч. 5). Это и есть оценка получателя: её дата указывается в уведомлении.
3. Уведомление Роскомнадзора. Подаётся до начала передачи и отдельно от уведомления о начале обработки по ст. 22. В нём – реквизиты оператора, правовое основание и цели, категории и перечень данных, категории субъектов, перечень стран и дата оценки получателя (ч. 3–4).
4. Ждать или нет. В страны из утверждённого Роскомнадзором перечня (критерий – соответствие принципам Конвенции Совета Европы о защите физических лиц при автоматизированной обработке персональных данных, № 108) передавать можно сразу после уведомления. В остальные – только после истечения 10 рабочих дней, отведённых на его рассмотрение, кроме случаев защиты жизни и здоровья. Роскомнадзор может запросить у оператора сведения из п. 2 – на ответ даётся 10 рабочих дней с продлением не более чем на 5, – и рассмотрение на это время приостанавливается.
5. Запрет или ограничение. Регулятор вправе запретить или ограничить передачу, в том числе в целях защиты здоровья и прав граждан; тогда оператор обязан обеспечить уничтожение получателем ранее переданных данных.

Посчитаем сроки на примере:

«Уведомление подано и получено Роскомнадзором в понедельник, 5 октября 2026 года. Получатель в стране из перечня: передавать можно после подачи уведомления, не дожидаясь решения. Получатель вне перечня: 10 рабочих дней (6–9, 12–16 и 19 октября) истекают в понедельник, 19 октября; первая передача – не раньше 20 октября. Если Роскомнадзор запросит сведения, рассмотрение приостановится до ответа: если отвечать все 10 рабочих дней, срок сдвинется ещё на две рабочие недели, к началу ноября.»

Схема «уведомили в пятницу – передаём в понедельник» работает только для стран из перечня. Для остальных закладывайте в план запуска минимум две рабочие недели плюс запас на запрос и не начинайте интеграцию на реальных данных до истечения срока.

Иностранный обработчик: двойная ответственность

Когда зарубежная компания обрабатывает данные по вашему поручению (хостинг, поддержка, транскрибация, разработка с доступом к данным), по ст. 6 ч. 6 152-ФЗ она отвечает перед пациентом вместе с оператором. Если обработчик российский (ч. 5), перед пациентом отвечает только оператор, а обработчик отвечает перед оператором. Добавьте локализацию (база иностранного обработчика за рубежом – запрещённая база) и уведомление по ст. 12, и станет понятно, почему для медданных иностранный обработчик почти всегда неверный архитектурный выбор. Если без зарубежного подрядчика не обойтись, лучше не оформлять поручение, а ограничить его доступ так, чтобы медданные до него вообще не доходили (сценарий 5 ниже). Как устроено поручение для российских подрядчиков, описано в статье о поручении обработки и договорах с подрядчиками.

Три мифа о локализации

Миф 1 – «Сервер в России, значит, всё локализовано». Основная база в российском облаке ещё ничего не говорит о десятке сервисов вокруг неё. Аналитический SDK в мобильном приложении, SaaS-трекер ошибок со стектрейсами, хелпдеск со скриншотами, сервис рассылок со списком пациентов, бэкапы в иностранном хранилище – каждый из них может оказаться зарубежной базой с данными пациентов.

Миф 2 – «Уведомили Роскомнадзор, значит, можно». Уведомление по ст. 12 – процедура, а не основание. Оно не заменяет согласие на обработку специальной категории и на раскрытие врачебной тайны, не отменяет запрета зарубежных баз при сборе и не гарантирует, что регулятор не ограничит передачу.

Миф 3 – «Обезличили, значит, можно отправлять куда угодно». Обезличенные записи по-прежнему остаются в сфере 152-ФЗ, а хэш телефона или СНИЛС обезличиванием вовсе не является. Безопасно выпускать наружу, и тем более за рубеж, можно только агрегаты без ПДн; подробности – в статье об обезличивании и аналитике медданных.

Шесть сценариев: что делать с зарубежными зависимостями

Приложим теорию к реальному стеку. Шесть ситуаций встречаются почти в каждом телемедицинском проекте.

Сценарий 1 – зарубежная SaaS-аналитика и маркетинговые SDK. Что уходит: IP, идентификаторы устройств, URL со специальностью врача, события записи на приём. Что нарушается: локализация (запись в зарубежную базу при сборе), передача без основания, врачебная тайна. Что делать: убрать их из аутентифицированного приложения; продуктовую аналитику перевести на собственный сбор событий и хранилище в России (двухзонный конвейер из статьи об обезличивании); на публичных страницах использовать инструменты, хранящие данные в России, и не передавать им данные пациентов.

Сценарий 2 – отслеживание ошибок, логи и мониторинг. Что уходит: стектрейсы с фрагментами запросов, URL консультаций, ID пациентов, тела ответов API, пользовательские атрибуты в контексте ошибки. Что делать: развернуть open-source трекер ошибок и стек логирования и метрик (например, Prometheus и Grafana) в вашем контуре в России; очищать ПДн на клиенте и на сервере до отправки; собирать метрики без идентификаторов. Подробнее об эксплуатационном стеке – в статье о наблюдаемости и эксплуатации телемед-платформы.

Сценарий 3 – видео-API и CPaaS. Что уходит: сам медиапоток консультации (лицо и голос пациента), записи в облачном хранилище провайдера, метаданные сессий, чат. TURN- и медиасерверы провайдера могут стоять за рубежом, даже если у него есть российский офис продаж. Что делать: собственный SFU (mediasoup, Janus, LiveKit OSS, Jitsi) в российском облаке или российский провайдер (Voximplant, SaluteJazz SDK, VK Звонки API, TrueConf) с письменным подтверждением того, где идёт медиатрафик, где хранятся записи и подписывает ли провайдер поручение. Сравнение вариантов – в статье свой видеослой или готовое решение.

Сценарий 4 – ИИ-API: языковые модели и распознавание речи. Что уходит: аудио консультации, транскрипт, жалобы, анамнез – сплошь специальная категория. Ряд крупнейших зарубежных LLM-провайдеров официально недоступен в России, но даже там, где технический доступ есть, отправка медданных в зарубежный ИИ-API означает трансграничную передачу специальной категории и конфликт с локализацией. Что делать: использовать российские модели и сервисы (GigaChat, Alice AI в Yandex AI Studio, SaluteSpeech, Yandex SpeechKit, в том числе в on-prem-варианте) по поручению или open-source модели (например, Whisper) на своих серверах. Подробнее – в статье о том, где ИИ встраивается в телемед-продукт.

Сценарий 5 – зарубежная команда разработки. Что уходит: удалённый доступ к продакшн-базе, дампы для отладки, логи, скриншоты в тикетах, данные в тестовых средах. Доступ иностранного специалиста к данным пациентов разумно считать трансграничной передачей, а если он работает по договору с доступом к данным, то ещё и поручением иностранному лицу со всеми последствиями ст. 6 ч. 6. Что делать: доступ к продакшну с медданными – только у сотрудников в России, через бастион с журналированием; зарубежная команда работает в средах с синтетическими или обезличенными данными; ошибки в продакшне отлаживают по воспроизведённым сценариям и метрикам без ПДн; дампы и выгрузки за пределы контура запрещены технически, а не только регламентом. Как распределить роли – в статье о команде телемед-продукта.

Сценарий 6 – второе мнение у зарубежной клиники. Единственный из шести сценариев, где передача медданных за рубеж – сама цель. Что уходит: выписки, результаты исследований, изображения в DICOM, иногда запись консультации. Что делать: оформить это как отдельный процесс, а не как кнопку «поделиться»:

1. письменное согласие пациента отдельным документом на передачу конкретному получателю в конкретной стране и письменное согласие на раскрытие врачебной тайны в целях обследования и лечения;
2. сведения от клиники-получателя и уведомление Роскомнадзора по ст. 12 – один раз на пару «получатель – цель», с ожиданием для стран вне перечня;
3. минимизация: только документы, нужные для консультации; в DICOM-заголовках – без лишних тегов (ФИО, адрес, номера документов), вместо них – псевдоним случая;
4. передача по защищённому каналу с журналированием; оригиналы и сам факт передачи – в медкарте в России;
5. ответ зарубежной клиники возвращается в российский контур.

Зарубежная клиника не связана российской врачебной тайной, тем важнее передавать ей только необходимое.

Таблица 1. Шесть зарубежных зависимостей телемедицинского продукта. Первые пять сценариев решаются архитектурой (медданные туда не попадают), шестой – процессом.

И мелочь, о которой часто забывают: push-уведомления мобильных платформ и многие сервисы рассылок работают через зарубежные серверы. Уведомление «У вас приём у психиатра в 15:00» – это передача сведений о факте обращения. Делайте уведомления нейтральными («Новое сообщение в приложении»), а подробности показывайте после входа.

Нажмите, чтобы увеличить

Одна платформа – один российский контур данных: архитектурный паттерн

Рано или поздно каждая команда с распределённым стеком задаётся вопросом: как сделать, чтобы эти правила соблюдались не за счёт героических усилий, а благодаря устройству системы? Большую часть работы делают четыре хода.

Ход 1 – весь контур данных в России. Серверы приложения, медиасерверы (SFU/TURN), хранилище записей, базы и реплики, бэкапы, журналы, поисковые индексы, аналитическое хранилище и ИИ-сервисы – в российском облаке с аттестатом на нужный уровень защищённости (Yandex Cloud, Cloud.ru, Selectel, MWS) или на своих серверах. Инженерные детали (где физически хранятся ключи, реплики и бэкапы, как устроен доступ поддержки) разобраны в статье о локализации данных и том, где хранятся медданные.

Ход 2 – исходящий трафик по белому списку. По умолчанию из контура данных нет выхода в интернет. Каждый внешний домен, к которому разрешено обращаться бэкенду, веб-приложению или мобильному клиенту, – строка в реестре с владельцем, страной и классом данных. CI проверяет список SDK в мобильных сборках и Content Security Policy веб-приложения; новый внешний сервис добавляется через pull request с ревью, как новое аналитическое событие.

Ход 3 – реестр потоков вместо памяти. Одна таблица на все внешние зависимости: что за сервис, страна обработки, есть ли поручение, попадают ли туда ПДн и медданные, нужна ли трансграничная передача и подано ли уведомление, дата последней проверки. Этот реестр – исходные данные для модели угроз (подробнее – в статье о требованиях к защите ПДн в 2026 году) и готовый ответ на первый вопрос клиники-заказчика.

Ход 4 – исключения через один шлюз. Если зарубежные потоки медданных всё же нужны (сценарий 6), они идут через один сервис экспорта, а не через десяток интеграций. Шлюз проверяет наличие согласий и уведомления по ст. 12 для пары «получатель – цель», применяет правила минимизации, шифрует, журналирует каждую передачу и не хранит копий. Всё, что не прошло проверку, не уходит, и обеспечивает это техника, а не регламент.

Таблица 2. Матрица вендоров для российского контура. Условия зависят от вендора, продукта и тарифа: прежде чем передавать медданные, подтверждайте их письменно.

Нажмите, чтобы увеличить

Сколько стоит отдельный российский контур

Бывает и обратная задача: у продукта уже есть зарубежная инсталляция (для пациентов из других стран или доставшаяся по наследству), и российских пациентов нужно вынести в отдельный контур. (Для выхода на другие рынки нужен отдельный анализ их законодательства; здесь речь только о российской стороне.) Посчитаем по модели стоимости телемед-платформы. Пусть существующая инсталляция стоит ≈ 380 тыс. ₽ в месяц: ≈ 110 тыс. ₽ – управляющий контур (CI/CD, мониторинг парка серверов, стейджинг) и ≈ 270 тыс. ₽ – контур данных (медиасерверы SFU ≈ 120 тыс. + хранилище записей ≈ 50 тыс. + база ≈ 60 тыс. + TURN ≈ 40 тыс.). Российский контур дублирует только контур данных: 380 + 270 = ≈ 650 тыс. ₽ в месяц, рост на 71%, а не на 100%. Но только при условии, что управляющий контур действительно не касается данных пациентов: в нём нет ПДн, логов с идентификаторами и доступа к продакшн-базам российского контура. Если касается, управляющий контур для российской части тоже придётся разворачивать в России, и экономия исчезает. Добавьте разовые инженерные работы по маршрутизации пациентов между контурами, раздельным ключам шифрования и автотестам локализации (ориентировочно 6–10 недель) и регулярные расходы: модель угроз и оценка эффективности мер для российского контура, реестр потоков, уведомления. Это плановые цифры, а не смета: разброс зависит от объёмов медиа, а цены сверяйте с прайсом провайдера.

Где здесь Фора Софт

Мы разрабатываем видеопродукты с 2005 года: 250+ выпущенных проектов в телемедицине, видеоконференциях, стриминге, видеонаблюдении и e-learning. Паттерн «весь контур данных в России» мы не только описываем, но и внедряем. Сначала составляем карту хранилищ и внешних зависимостей продукта, затем проектируем контур данных в российской инфраструктуре, белый список исходящего трафика, реестр потоков, цепочку поручений и маршрут медиатрафика WebRTC так, чтобы видео пациента не покидало страну. Видеослой мы строим сами (выбор SFU, топология TURN, конвейеры записи), поэтому граница локализации проходит вокруг реальных компонентов, а не нарисована на слайде. Если в вашем бэклоге есть задача «заменить зарубежный SaaS» или «дать доступ подрядчику из-за рубежа», её стоит вынести на архитектурное ревью уже сейчас.

Главное

• Локализация и трансграничная передача – два разных правила: первое определяет, где находятся базы при сборе данных (ст. 18 ч. 5), второе – кому передаются данные (ст. 12).
• С 1 июля 2025 года собирать данные россиян в зарубежные базы запрещено: штраф до 6 млн ₽, повторно – до 18 млн ₽.
• Перед передачей за рубеж нужны сведения от получателя и уведомление РКН; если страны нет в перечне государств с адекватной защитой, придётся ждать 10 рабочих дней.
• Для медданных нужны письменное согласие на обработку специальной категории и на раскрытие врачебной тайны; иностранный обработчик отвечает перед пациентом вместе с оператором.
• Зарубежные SaaS (аналитика, ошибки, CPaaS, ИИ-API) не получают медданных; зарубежная команда разработки не видит продакшн.
• Паттерн: весь контур данных в России, исходящий трафик по белому списку, реестр потоков и один шлюз для исключений.

Что читать дальше

• Локализация данных, суверенитет и где хранятся медданные – инженерия размещения: регионы облака, ключи, бэкапы и доступ поддержки.
• Поручение обработки ПДн и договоры с подрядчиками – российская половина матрицы вендоров: что писать в поручении и как проверить подрядчика.
• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек – как устроена граница медданных, которую эта статья удерживает внутри страны.