Локализация данных, суверенитет и где хранятся медданные

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

Кратко

С 1 июля 2025 года 152-ФЗ прямо запрещает записывать, систематизировать, накапливать, хранить и извлекать персональные данные граждан России с использованием баз данных за рубежом (ст. 18 ч. 5 в редакции 23-ФЗ). Любой передаче данных за границу должны предшествовать уведомление Роскомнадзора и оценка получателя (ст. 12). Для телемед-продукта «база данных» – это не только основная СУБД: копии медданных оседают в бэкапах и репликах, в хранилище записей консультаций, в логах и трекерах ошибок, в кэше CDN, в конвейерах транскрибации и ИИ, на ноутбуках подрядчиков. Практическая задача – составить карту, где физически лежит каждая копия, и собрать все копии с данными пациентов в контуре медданных: российское облако с аттестатом на нужный уровень защищённости, договор с условиями поручения, публичное раскрытие места хранения по приказу 193н. В статье – понятия, инвентаризация мест хранения и архитектурная схема; юридическая сторона трансграничной передачи разобрана в отдельной статье.

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

Где физически лежат данные пациента, теперь определяет закон. Нарушение локализации стоит юрлицу до 6 млн ₽, повторное – до 18 млн ₽ (ч. 8 и 9 ст. 13.11 КоАП). Порядок телемедицины требует раскрыть пациенту на сайте или в приложении, какие информационные системы используются и где хранятся материалы консультаций (193н, п. 37). Команды обычно уверены, что «база в России – значит, всё в порядке», и ошибаются в мелочах, которые находит первая же проверка: облачный трекер ошибок за рубежом с телефонами пациентов в стектрейсах, бэкап в зарубежном объектном хранилище, транскрибация «на пробу» через иностранный ИИ-сервис. Статья – для основателей, продакт-менеджеров и технических лидов, которые выбирают облако, размещают медиасерверы и хранилище записей и подписывают договоры с подрядчиками. Составить карту на старте дёшево, переносить данные после запуска – дорого.

Три слова, которые путают: резидентность, суверенитет, локализация

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

Резидентность данных – где физически лежит конкретная копия: в каком дата-центре, у какого провайдера, в какой стране. Это факт об инфраструктуре: «записи консультаций – в объектном хранилище в московском дата-центре». Резидентность вы выбираете сами, пока закон не лишает вас этого выбора.

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

Локализация данных – юридическое требование, которое лишает вас выбора резидентности. В России это ст. 18 ч. 5 152-ФЗ: при сборе персональных данных граждан РФ запись, систематизация, накопление, хранение, уточнение и извлечение ведутся с использованием баз данных на территории России, а с 1 июля 2025 года использовать для этого базы за рубежом прямо запрещено. Исключения узкие (отдельные основания ч. 1 ст. 6) и к обычной телемед-платформе, как правило, не подходят; проверьте это с юристом.

Аналогия. Резидентность – в каком доме стоит коробка с документами. Суверенитет – чья полиция может постучать в дверь. Локализация – закон, по которому коробка с документами россиян стоит только в российском доме. А в коробке лежат медданные: персональные данные о здоровье (специальная категория по ст. 10 152-ФЗ) и сведения, составляющие врачебную тайну по ст. 13 323-ФЗ. Напомним: врачебную тайну составляет уже сам факт обращения, поэтому имя пациента рядом со временем приёма – тоже медданные.

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

Что требует закон: два правила о месте и одно о прозрачности

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

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

Трансграничная передача (ст. 12 152-ФЗ). Любая передача персональных данных за границу требует до её начала уведомить Роскомнадзор и оценить, как получатель защищает данные; регулятор вправе передачу запретить или ограничить. Для телемед-продукта это значит, что подключение зарубежного API, SDK или подрядчика с доступом к медданным – юридическая процедура, которую одной настройкой в консоли не решить. Когда такая передача вообще возможна и как её оформить – в статье о локализации и трансграничной передаче медданных. Инженерный ответ этой статьи проще – не передавать.

Прозрачность и сроки (приказ 193н). Консультирующая организация и оператор информационной системы раскрывают пациенту, в том числе в интернете, сведения об используемых информационных системах и операторах и место хранения материалов консультаций (п. 37). Материалы подлежат хранению, документацию вносят в электронную медицинскую карту в медицинской информационной системе консультирующей организации (п. 49–50), а сопутствующие материалы – аудио- и видеозаписи, сообщения, изображения – хранятся один год (п. 51). Ваша схема хранения становится публичным текстом, а срок хранения записей – параметром системы.

Помимо места хранения, действуют требования к защите: уровень защищённости по ПП 1119 и меры по приказу ФСТЭК № 21. Их разбор – в статье о требованиях к защите ПДн в 2026 году.

Где на самом деле лежат медданные: инвентаризация

Составляя карту, спрашивайте не «где наша база», а «где каждая копия». В типичной телемед-платформе медданные оказываются минимум в восьми местах, и обычно команда помнит только о первом.

Каждую строку проверьте двумя вопросами. Есть ли в копии данные, по которым можно определить пациента, прямо или через связку идентификаторов? И где физически стоит носитель? «Да» на первый вопрос и «за рубежом» на второй – нарушение локализации, а если данные туда кто-то отправил, то ещё и вопрос трансграничной передачи. Шифрование здесь не спасает: оно определяет, кто может прочитать копию, но база от этого не переезжает.

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

Для ИИ-функций вопрос стоит особенно остро. Транскрибация, резюме визита и подсказки врачу работают на полном аудио приёма – самых чувствительных данных платформы. Крупные зарубежные ИИ-провайдеры для России официально недоступны, а отправка им медданных означает сразу и зарубежную базу, и трансграничную передачу специальной категории. Рабочие варианты – модели в собственном контуре или российские сервисы по договору-поручению; подробнее – в статье о слое комплаенса клинического ИИ.

Российские облака: что покрывает аттестат

Контур медданных почти всегда строят в российском облаке, у которого есть аттестат соответствия требованиям по защите персональных данных. На 2026 год аттестаты уровня УЗ-1 (самого строгого) заявляют Yandex Cloud, Cloud.ru (бывший SberCloud), Selectel и MWS (МТС); у VK Cloud – изолированный сегмент, уровень которого стоит уточнять у провайдера. Облако с аттестатом УЗ-1 подходит для любого уровня защищённости, который определит ваша модель угроз.

Аттестат облака – сильный, но ограниченный аргумент. Он покрывает инфраструктуру провайдера в аттестованном контуре: дата-центры, платформу виртуализации, сети. Приложение, настройки доступа, журналы, шифрование данных, обновление образов виртуальных машин остаются вашей зоной ответственности. Отсюда три практических шага. Уточните у провайдера, какие именно сервисы входят в область аттестата: управляемые базы данных, объектное хранилище и Kubernetes могут входить в неё по-разному. Подпишите договор с условиями обработки по поручению. И сохраните документы провайдера – копию аттестата и описание границ – в своём пакете для проверки.

Если заказчик – государственная клиника, добавляются правила для государственных информационных систем (приказ ФСТЭК № 117 с 1 марта 2026 года) и, возможно, для критической информационной инфраструктуры. Часть облаков из списка выше (по обзорам рынка – Cloud.ru, Selectel, MWS) заявляет аттестаты и для ГИС класса К1, но границы этих аттестатов тоже сверяйте до архитектурного решения.

Как это отражается на архитектуре

В архитектуре телемед-платформы требования проявляются в двух слоях, и по-разному. Главное – разделить данные, которые проходят через инфраструктуру, и данные, которые в ней хранятся.

Видео и аудио реального времени – по большей части транзит. Во время консультации медиапоток идёт от пациента к врачу через медиасервер. В архитектурах WebRTC это SFU (Selective Forwarding Unit) – сервер, который принимает поток каждого участника и пересылает его остальным. Если прямое соединение невозможно, трафик целиком идёт через TURN-сервер – ретранслятор, к которому устройства обращаются, когда не могут связаться напрямую. Ни SFU, ни TURN ничего не хранят, но поток медданных через них проходит. Медиасервер или TURN за рубежом означает, что видео пациента выезжает из страны, и отговорка «это же не хранение» здесь не работает: это вопрос трансграничной передачи. Инженерное решение простое – SFU и TURN только в России, ближе к пациентам. Это заодно снижает задержку; как распределять медиасерверы по регионам, мы разбираем в статье о масштабировании клинического видео.

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

Проектный принцип – контур медданных. Внутри – всё, что содержит или может содержать данные пациентов: медиасерверы, базы, хранилище записей, бэкапы, журналы, ИИ-обработка. Снаружи – только то, где персональных данных нет: маркетинговый сайт, репозитории кода и CI без продовых данных, агрегированная продуктовая аналитика. Границу пересекают в одну сторону и через один шлюз, который выпускает наружу только агрегаты без идентификаторов. Что считать достаточным обезличиванием и почему одного удаления ФИО мало – в статье об обезличивании и аналитике медданных.

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

Одна платформа, много клиник: как разделять данные

Телемед-платформа, которой пользуются несколько клиник, обрабатывает данные по поручению каждой из них, и каждая клиника – отдельный оператор. Поэтому рабочая схема – общий управляющий слой и раздельные слои данных.

Управляющий слой – часть без медданных: код, конвейер развёртывания, флаги функций и логика маршрутизации, которая решает, в каком слое данных живёт визит. Слой данных – хранилища, ключи шифрования, записи и журналы конкретной клиники или группы клиник с одинаковыми требованиями. Большинству частных клиник достаточно логического разделения в общем аттестованном контуре. Государственной клинике может понадобиться отдельный сегмент с требованиями к ГИС, а крупной сети – отдельные ключи и отдельное хранилище по договору.

Самое важное инженерное решение здесь – ключ маршрутизации: как при записи на приём определить, к какому оператору и какому слою данных относится визит. Обычно это клиника, от имени которой оказывается помощь, а не город пациента и не его текущее местонахождение. Сделайте эту классификацию верно – остальное дело техники. Ошибётесь – данные одной клиники окажутся в хранилище другой, с чужими ключами и чужим договором, и никакое шифрование этого не исправит.

Теперь о стоимости: резервная площадка в другом российском ЦОД не бесплатна. Допустим, на основной площадке работают медиасерверы, хранилище записей и базы, и это базовая месячная стоимость инфраструктуры. Резервная площадка дублирует в основном слой данных (хранилища, реплики, бэкапы), а медиасерверы и управляющий слой разворачивают на ней в минимальной конфигурации. Если слой данных составляет, скажем, 60% стоимости инфраструктуры:

Стоимость резервной площадки ≈ 60% стоимости одной площадки (только слой данных)
Две площадки ≈ 1 + 0,6 = 1,6× базы, а не 2×

Точный множитель целиком зависит от вашего стека, но принцип общий: платить приходится в основном за дублирование слоя с медданными, а не всей платформы. Это ещё один довод держать как можно больше компонентов без персональных данных. Если продукт однажды выйдет на рынки других стран, для их пациентов понадобится отдельный контур по местным правилам; правовая часть – в статье о трансграничной передаче.

Типичные ошибки

Ошибки с местом хранения, которые мы чаще всего видим в телемед-разработке. Все они предотвратимы.

• «База в России – значит, всё в порядке». Бэкапы, логи, трекеры ошибок, CDN и ИИ-сервисы – тоже места, где данные записывают и хранят. Проверяйте каждую копию, не только основную СУБД.
• Медиасервер в России, запись – у вендора. Живой звонок остаётся в стране, а запись уезжает в хранилище видеовендора с неизвестным адресом. Записи – хранимые данные, и их место – в контуре.
• Зарубежный ИИ «только для пилота». Пилот на реальных пациентах – это обработка медданных за рубежом. Пилотируйте на синтетических данных или на моделях внутри контура.
• Аттестат облака вместо собственного соответствия. Аттестат покрывает инфраструктуру провайдера. Приложение, доступы и журналы – ваша зона.
• Подрядчики вне карты. Разработчик с выгрузкой продовой базы, служба поддержки с доступом из-за рубежа – тоже места хранения и обработки. Доступ – только к системам в России и только по поручению.
• Устаревшее раскрытие по 193н. Сменили хранилище или видеовендора – обновите сведения об информационных системах и месте хранения на сайте и в приложении.

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

Фора Софт разрабатывает видеософт с 2005 года: телемедицину, видеоконференции, стриминг, e-learning и видеонаблюдение. Место хранения данных – та точка, где работа с видео в реальном времени теснее всего связана с регуляторными требованиями. Карту данных мы проектируем от требований: локализация по ст. 18 ч. 5, запрет передачи без процедуры по ст. 12, раскрытие места хранения по 193н. Затем размещаем медиасерверы, хранилище записей, бэкапы, журналы и ИИ-обработку в контуре медданных в российском облаке с аттестатом. На практике это SFU и TURN в России (сразу и ради задержки, и ради локализации), разделение слоёв данных по клиникам-операторам и чистый шлюз для аналитики. Цель – платформа, которую проверяющий примет без отдельной переделки под каждого заказчика.

Главное

• Ст. 18 ч. 5 152-ФЗ с 1 июля 2025 года прямо запрещает базы с данными россиян за рубежом: схема «мастер-копия в России, остальные где угодно» больше не работает.
• Резидентность (где лежит копия), суверенитет (чьё право и чей регулятор) и локализация (что требует закон) – три разных вопроса.
• Медданные живут не только в основной БД: бэкапы, записи, логи, CDN, ИИ, подрядчики и рассылки – проверяйте каждое место.
• Живое видео – транзит, но SFU и TURN за рубежом выводят поток из страны; держите их в России.
• Аттестат облака на УЗ-1 покрывает инфраструктуру провайдера, а не ваше приложение; сверяйте границы аттестата по сервисам.
• Контур медданных со шлюзом обезличивания, а внутри – раздельные слои данных для клиник-операторов.

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

• Локализация и трансграничная передача медданных – юридическая сторона: когда передача за рубеж возможна и как её оформить.
• Масштабирование клинического видео: регионы, мощности и пики нагрузки – как распределить медиасерверы по России.
• Эталонная архитектура телемедицинского видео – какое место контур медданных занимает в платформе целиком.