Как организовать хранение медицинских данных для ИИ с учетом требований российского законодательства

18 августа 2026 г.

Евгений Левашов

Автор статьи

За последние несколько лет искусственный интеллект перестал быть экспериментальной технологией и постепенно становится частью повседневной работы медицинских организаций. Модели предиктивной диагностики по снимкам, ассистенты для расшифровки результатов анализов, платформы для геномных исследований перестали быть пилотными проектами — теперь это работающие сервисы, которые ежедневно обрабатывают петабайты данных: DICOM-снимки МРТ и КТ, электронные медицинские карты, результаты лабораторных исследований, телеметрию носимых устройств и данные телемедицины.

Проблема в том, что для большинства таких сценариев инфраструктура хранения становится узким местом раньше, чем сама модель. Файловые папки и блочные СХД, на которых исторически строились медицинские информационные системы, плохо масштабируются под объемы обучающих датасетов, дорого обходятся на «холодных» архивах и создают риски при аттестации у регулятора. Все чаще ответом на эту проблему становится объектное S3-хранилище. В этой статье разберем, почему именно оно подходит для ИИ-инициатив в здравоохранении и что нужно добавить к архитектуре, чтобы она отвечала не только общей логике «дешево и масштабируемо», но и требованиям российского законодательства.

Статья подготовлена вместе с экспертом

Алексей Медведев, старший менеджер продукта

Почему ИИ в медицине нуждается в объектном хранилище

Индустрия давно заметила, что объектное хранилище и AI/ML-нагрузки хорошо сочетаются друг с другом — и здравоохранение не исключение, а скорее одна из самых показательных иллюстраций этой связки.

Неограниченное масштабирование. Архив медицинских изображений одной крупной клиники легко переваливает за сотни терабайт, а геномные проекты считают уже петабайтами. Объектное хранилище проектируется так, чтобы рост объема не требовал пересмотра архитектуры.

Неструктурированные данные. DICOM-снимки, аудиозаписи консультаций, видео телемедицинских сессий, файлы генетических исследований (FASTQ) плохо ложатся в реляционную схему. Объектное хранилище изначально спроектировано для такого рода данных.

Богатые метаданные. Для обучения и валидации ML-моделей важно не просто хранить снимок, а связать его с контекстом: модальность, дата исследования, обезличенный идентификатор, разметка врача. В объектном хранилище эти метаданные — часть самого объекта, а не отдельная таблица, которая рискует разойтись с данными.

Гибкость on-prem и гибридных схем. Возможность держать данные на собственной инфраструктуре или в локальном облаке снижает зависимость от валютных курсов и зарубежной юрисдикции — и заодно закрывает требование локализации персональных данных.

Неизменяемость. Механизмы WORM/Object Lock защищают архивные и обучающие датасеты от случайного или намеренного изменения. Это важно не только для комплаенса, но и для доверия к самой модели: нельзя быть уверенным в результатах ИИ, если нет гарантии, что обучающие данные не были подменены.

Комплаенс-слой: во что превращается HIPAA на российской почве

У зарубежных поставщиков решений для здравоохранения есть удобный общий знаменатель — HIPAA. В России прямого аналога одного закона нет, но есть комбинация требований, которая по факту жестче.

Международная практика	Российский аналог	Что это значит для хранилища
HIPAA (защита медицинских данных пациента)	ФЗ-152 «О персональных данных» — медицинские данные отнесены к специальной категории (ст. 10)	Максимальный уровень защищенности ИСПДн, шифрование, контроль доступа
Локализация данных пациентов	Ст. 18 ФЗ-152 — первичный сбор и хранение спецкатегорий ПДн должны происходить на территории РФ	Хранилище физически размещается в российском ЦОД, регион строго RU
Врачебная тайна	ФЗ-323 «Об основах охраны здоровья граждан», ст. 13	Доступ только у лечащего врача и уполномоченных лиц; провайдер инфраструктуры технически не должен иметь возможности прочитать данные
Отраслевые сроки хранения (retention policies)	Приказы Минздрава — истории болезни хранятся 25 лет, рентгеновские снимки не менее 5 (на практике 10–25) лет	Настройка lifecycle-политик хранилища под конкретные сроки, а не универсальный дефолт
Сертифицированное шифрование	Требования ФСТЭК и ФСБ — криптография по ГОСТ Р 34.12-2015 и ГОСТ Р 34.10-2012	Server-Side Encryption должен поддерживать интеграцию с российскими KMS, а не только AES «из коробки»

Для архитектуры хранения это означает, что нельзя просто взять S3-совместимое хранилище. Нужна платформа, которая одновременно закрывает требования к локализации, поддерживает сертифицированную криптографию и дает инструменты для прохождения аттестации ИСПДн во ФСТЭК — иначе даже самый удачный ИИ-проект рискует застрять на этапе согласования со службой информационной безопасности.

Что нужно хранилищу, чтобы реально работать с DICOM, ЭМК и результатами анализов

Помимо соответствия законодательству, у хранилища для медицинского ИИ есть чисто техническая специфика:

Совместимость с DICOM и PACS. Развертывание S3 как основы для VNA (Vendor Neutral Archive) или шлюза DICOMweb (WADO-RS/QIDO-RS) поверх хранилища позволяет подключать существующие PACS-системы и рабочие станции врачей без переписывания клиентского софта.
Интеграция с EHR/EMR через открытые протоколы. Стандарт FHIR постепенно становится общим языком между МИС, хранилищем и аналитическими сервисами — это снижает vendor lock-in по сравнению с проприетарными архивами.
Индексация лабораторных результатов и метаданных отдельно от самих объектов. Быстрый поиск по пациенту, дате или типу исследования не должен требовать обращения к каждому файлу — для этого нужен отдельный каталог метаданных поверх бакетов.
Тиринг hot/cold по возрасту данных. Свежие снимки и записи должны отдаваться с минимальной задержкой, архивные — уходить в дешевый класс хранения по политике жизненного цикла.

Практические сценарии использования объектного S3-хранилища в здравоохранении

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

Кейс 1. Архивация медицинских изображений (PACS и DICOM)

Проблема. Больницы и диагностические центры генерируют петабайты данных с МРТ, КТ и рентгенов. Хранение этих данных на дорогих SAN/NAS-решениях (Primary Storage) делает экономику клиники убыточной. По закону медицинские изображения должны храниться от 5 до 25+ лет. Поиск старого снимка в ленточных архивах занимает часы, что тормозит работу врачей.

Что теряет клиника, если оставить всё как есть:

Продолжают расти капитальные расходы на SAN/NAS-диски Enterprise-класса, хотя 90%+ архива — «холодные» данные.
Растёт риск отказа от закупки нового оборудования на потом — при исчерпании ёмкости старые снимки физически некуда класть.
Поиск снимков многолетней давности по судебному запросу или повторному обращению пациента занимает часы вместо секунд.

Решение на базе S3. Использование S3 как основы для VNA (Vendor Neutral Archive) или облачного PACS. Настроенные политики Lifecycle Management автоматически переносят «горячие» данные (снимки за последние 30 дней) в стандартный класс хранения, а «холодные» (старше 30 дней) — в архивный (Glacier/Icebox). Доступ к данным осуществляется через стандартные протоколы (DICOMweb, REST API).

Типовая архитектура:

Бакет «hot» для снимков младше 30 дней — стандартный класс хранения, низкая задержка.
Бакет «cold/archive» для снимков старше 30 дней — Glacier/Archive-класс, Lifecycle-правило переноса по возрасту объекта.
DICOMweb-шлюз (WADO-RS/QIDO-RS) поверх S3 для интеграции с рабочими станциями врачей и сторонними PACS-вьюерами.
Индекс метаданных (пациент, дата, модальность) в отдельной БД для быстрого поиска без обращения к самим объектам.

Бизнес-цель. Снижение TCO (Total Cost of Ownership) инфраструктуры хранения на 40–60% при соблюдении нормативных требований к срокам хранения и обеспечении мгновенного доступа к историческим снимкам.

Кейс 2. Озеро данных для ML и персонализированной медицины

Проблема. Геномные данные, истории болезней (EHR) и результаты анализов разрозненны по отделениям и базам данных. Чтобы запустить проект по предиктивной аналитике или обучению ИИ-модели на рентген-снимках, Data Science команде приходится месяцами собирать и очищать данные. Напрямую грузить сырые данные в вычислительные кластеры дорого и неэффективно.

Что теряет клиника, если оставить всё как есть:

Data Science команда тратит до 60–80% времени проекта не на моделирование, а на поиск и очистку разрозненных данных.
Простаивающие зарезервированные GPU-мощности под данные, которые ещё не собраны — прямые потери бюджета.
Дублирование одних и тех же датасетов в разных отделах из-за отсутствия единой точки доступа.

Решение на базе S3. S3 выступает фундаментом для Medical Data Lake (озера данных). Все данные (DICOM, FHIR, геномные файлы FASTQ, CSV с анализами) складываются в S3 в исходном виде (Data Lakehouse-архитектура). Вычислительные мощности (GPU-кластеры для ИИ, сервисы аналитики) подключаются к данным в S3 напрямую по требованию, работают и отключаются.

Типовая архитектура:

Зонирование бакетов: raw (сырые данные) → curated (очищенные, размеченные) → feature store (готовые признаки для моделей).
Каталог данных (data catalog) с описанием схем FHIR/DICOM для самостоятельного поиска датасетов исследователями.
Временные GPU-кластеры (Spark/TensorFlow/PyTorch) читают данные из S3 по требованию и не хранят локальные копии постоянно.
Контроль доступа на уровне бакета/префикса — разграничение по отделам (онкология, кардиология, R&D).

Бизнес-цель. Ускорение Time-to-Market разрабатываемых ИИ-продуктов и сервисов предиктивной аналитики на 30–50% за счёт быстрого предоставления размеченных и сырых данных исследователям.

Кейс 3. Безопасный обмен данными и телемедицина (B2B2C)

Проблема. Пациенты и врачи жалуются на сложность обмена медицинскими документами. Отправка результатов анализов по email или в мессенджерах нарушает режим коммерческой тайны и требования защиты ПДн/врачебной тайны. Создание собственных файловых шлюзов для клиник — долгий и дорогой процесс разработки.

Что теряет клиника, если оставить всё как есть:

Персонал вынужден пересылать результаты анализов по email/мессенджерам — прямое нарушение режима врачебной тайны.
Собственная разработка защищённого файлового шлюза занимает месяцы разработки и требует отдельной команды поддержки.
Нет возможности быстро отозвать доступ к однажды отправленному документу — ссылки «живут» бессрочно.

Решение на базе S3. Использование S3 как бэкенда для телемедицинских порталов и пациентских приложений. Документы (PDF, фото, видео) загружаются в приватные бакеты S3. Доступ предоставляется через генерацию Pre-signed URLs (временных ссылок) со сроком жизни от нескольких минут до часов. Шифрование данных на лету (SSE) и в покое.

Типовая архитектура:

Приватный бакет на пациента/эпизод лечения, без публичного доступа по умолчанию (Block Public Access включён).
Backend-сервис генерирует Pre-signed URL с TTL от нескольких минут до часов под конкретное действие (просмотр, скачивание).
CDN перед S3 для тяжёлых файлов (видео консультаций) — снижение задержки для пользователей в разных регионах.
Access Logs и CloudTrail-подобное логирование каждого обращения к объекту для последующего аудита.

Бизнес-цель. Повышение NPS пациентов и врачей за счёт бесшовного и безопасного обмена документами, а также выход на рынок новых B2B-продуктов (интероперабельные шлюзы для других клиник) без увеличения затрат на инфраструктуру.

Кейс 4. Защита от программ-вымогателей (Ransomware) и Disaster Recovery

Проблема. Медицинские учреждения — главная мишень для Ransomware-атак. Блокировка историй болезней или данных PACS парализует работу больницы, что ставит под угрозу жизни пациентов. Классическое резервное копирование на ленты или в соседний дата-центр часто заражается вместе с основной инфраструктурой из-за отсутствия изоляции.

Что теряет клиника, если оставить всё как есть:

Единственная копия бэкапа физически доступна для перезаписи — при атаке шифруется вместе с продуктивной системой.
Время простоя при инциденте измеряется днями и неделями, что напрямую влияет на безопасность пациентов и репутацию.
Отсутствие регулярных тестов восстановления приводит к тому, что бэкап вроде бы есть, но он не восстанавливается.

Решение на базе S3. Внедрение архитектуры «Air-gapped» бэкапов с использованием S3 Object Lock (WORM — Write Once, Read Many). Резервные копии баз данных (EHR, PACS) пишутся в бакеты S3 с включённым Object Lock в режиме Compliance. В течение заданного срока (например, 7 лет) ни один пользователь, включая системного администратора или вирус, не может удалить или перезаписать эти данные.

Типовая архитектура:

Отдельный бакет для бэкапов с включённым Object Lock (режим Compliance) и версионированием объектов.
Изоляция учётных записей: сервисный аккаунт для записи бэкапов не имеет прав на удаление уже записанных объектов.
Регулярные автоматические тесты восстановления (restore drills) по расписанию
Репликация критичных бэкапов между двумя географически разнесёнными дата-центрами (Cross-Region Replication).

Бизнес-цель. Обеспечение непрерывности бизнеса (BCP) и минимизация времени простоя (RTO) до нескольких часов вместо недель, защита репутации клиники и предотвращение финансовых потерь от выкупа.

Кейс 5. Хранение и обмен данными клинических исследований (CRO / Clinical Trials)

Проблема. Спонсоры и CRO (Contract Research Organizations) ведут одновременно десятки многоцентровых исследований: eCRF, лабораторные данные, изображения, согласия пациентов. Данные поступают из множества клиник-площадок в разных форматах, должны быть защищены от несанкционированного изменения (требование GCP — Good Clinical Practice) и доступны для аудита спонсором и регулятором на протяжении всего срока хранения протокола.

Что теряет клиника, если оставить всё как есть:

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

Решение на базе S3. S3 используется как единое защищённое хранилище для всех артефактов исследования: от исходных документов площадки (source documents) до финальных наборов данных для биостатистики. Версионирование объектов и журналирование доступа обеспечивают требуемую по GCP прослеживаемость (audit trail), а разграничение прав по префиксам бакета — изоляцию данных между площадками и ролями (монитор, исследователь, спонсор).

Типовая архитектура:

Структура бакета по протоколу исследования: /study_id/site_id/domain (например, /STUDY01/site12/labs).
Версионирование объектов включено — любое изменение документа сохраняется как новая версия, старые не удаляются.
Отдельные роли доступа: исследователь площадки — только запись в свой префикс, монитор — чтение с логированием, спонсор — агрегированный доступ.
Экспорт метаданных о доступе в систему электронного trial master file (eTMF) для единого журнала аудита.

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

Кейс 6. Импортозамещение и миграция legacy МИС

Проблема. Многие медицинские информационные системы (МИС) исторически построены на зарубежном ПО хранения или файловых шарах Windows/NFS, которые больше не обновляются, не сертифицированы ФСТЭК и создают риски при аттестации. Полная замена МИС дорога и рискованна для непрерывности лечебного процесса.

Что теряет клиника, если оставить всё как есть:

Эксплуатация несертифицированного и неподдерживаемого зарубежного ПО хранения — блокирующий риск при плановой аттестации ФСТЭК.
Единомоментная миграция создаёт риск простоя лечебного процесса и потери данных.
Рост стоимости поддержки унаследованной инфраструктуры без возможности расширения.

Решение на базе S3. S3-хранилище используется как промежуточный и целевой слой данных при поэтапной миграции: сначала подключается как дополнительный бэкенд для новых данных и архива, затем — как основное хранилище для документного и файлового контура МИС, с сохранением совместимости через стандартные протоколы (S3 API, DICOMweb).

Типовая архитектура:

Прокладка S3-шлюза (S3-совместимый интерфейс) перед существующей МИС для параллельной записи новых данных.
Постепенный перенос исторических данных пакетами (batch) с контролем целостности (чек-суммы) на каждом этапе.
Двухконтурная схема на переходный период: legacy-хранилище остаётся read-only, S3 становится основным для записи.
План отката (rollback plan) на каждом этапе миграции с фиксированными контрольными точками.

Бизнес-цель. Снижение регуляторных и технологических рисков импортозамещения, поэтапный переход без остановки лечебного процесса, подготовка инфраструктуры к аттестации ФСТЭК на новом контуре.

Итог

ИИ в здравоохранении упирается не столько в качество моделей, сколько в качество и доступность данных, на которых они обучаются и работают. Объектное S3-хранилище закрывает базовые технические требования — масштаб, работу с неструктурированными данными, метаданные, неизменяемость. Но для российского рынка этого недостаточно: поверх общей логики нужна локализация, сертифицированное ГОСТ-шифрование и готовность к аттестации ИСПДн во ФСТЭК.

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