ИИ в медицине: где заканчивается цифровой помощник и начинается медицинское изделие

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

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

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

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

В марте 2026 года вопросы правового регулирования ИИ в здравоохранении отдельно обсуждались в Государственной Думе с участием представителей регуляторов и отраслевых экспертов. Среди проблем назывались использование медицинских данных для развития ИИ, мониторинг работы медицинских изделий с искусственным интеллектом и место таких технологий непосредственно в системе оказания медицинской помощи

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

Первый вопрос, который стоит задать и клинике, и разработчику:

Что именно делает алгоритм?
Сам факт использования искусственного интеллекта еще не превращает программный продукт в медицинское изделие.

Например, клиника может использовать ИИ для:

• записи пациентов;
• работы call-центра;
• расшифровки телефонных разговоров;
• составления расписания врачей;
• подготовки писем;
• поиска информации во внутренних документах;
• анализа загрузки кабинетов;
• подготовки черновика текста медицинского заключения.
• Большая часть таких решений относится прежде всего к автоматизации бизнес-процессов.

Совершенно другая ситуация возникает, если система:

• анализирует медицинские изображения;
• выявляет признаки патологии;
• рассчитывает вероятность заболевания;
• прогнозирует развитие состояния пациента;
• рекомендует вариант лечения;
• оценивает медицинские риски;
• осуществляет мониторинг состояния здоровья;
• непосредственно влияет на клиническое решение врача.

Здесь необходимо отдельно проверять, не становится ли программное обеспечение медицинским изделием

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

Одна из распространенных ошибок технологических команд выглядит примерно так:
«Мы не ставим диагноз. Мы только помогаем врачу»

Само по себе такое описание проблему не решает.

При определении правового статуса продукта необходимо смотреть не только на дисклеймер, но и на его назначение и фактическую функциональность

Если AI-сервис разработан для диагностики, профилактики заболеваний, мониторинга состояния организма или решения других медицинских задач, необходимо анализировать требования законодательства об обращении медицинских изделий

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

Поэтому крайне важна синхронизация четырех вещей:

1. Фактической функциональности продукта.
Что алгоритм действительно умеет делать.

2. Технической документации.
Как заявлено его назначение.

3. Договора с клиникой или другим заказчиком.
Как описан результат, который получает пользователь.

4. Маркетинга.
Что разработчик обещает рынку.

Представим, что на сайте продукта написано:
«ИИ выявляет онкологические заболевания на ранней стадии».

А в договоре:
«Программное обеспечение носит исключительно информационный характер и не предназначено для диагностики».

Такое противоречие само по себе создает риск.
Юридическая модель MedTech-продукта должна проектироваться одновременно с продуктовой.

Следующий сложный вопрос — место искусственного интеллекта непосредственно в медицинском процессе

В самой простой модели алгоритм предоставляет врачу дополнительную информацию, а врач самостоятельно ее оценивает

Но AI-продукты становятся сложнее.
Допустим, система анализирует КТ и сообщает врачу: вероятность патологии — 96%.

Формально решение остается за человеком.

Но дальше возникают вопросы:

• Может ли врач самостоятельно проверить вывод алгоритма?
• Получает ли он исходное изображение?
• Понимает ли основания, по которым система пришла к такому выводу?
• Что должен сделать врач, если его мнение расходится с результатом ИИ?
• Обязан ли он зафиксировать такое расхождение?
• Может ли медицинская организация использовать алгоритм таким образом, что решение фактически принимается автоматически?

Именно поэтому формулировка human-in-the-loop — участие человека в принятии решения постепенно превращается из технологического принципа в юридический.

Недостаточно написать в договоре:
«Окончательное решение принимает врач».

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

Представим ситуацию:
AI-система анализирует медицинское изображение и не выявляет патологию. Врач основывается в том числе на ее результате. Через несколько месяцев заболевание диагностируют на более поздней стадии.

• Кто отвечает?
• Врач?
• Медицинская организация?
• Разработчик?
• Производитель медицинского изделия?
• Поставщик данных?
• Или сразу несколько участников?

Специальной универсальной конструкции ответственности за «ошибку искусственного интеллекта» российское право пока не создает.

Поэтому придется устанавливать фактическую цепочку событий.

Например:
Какова была заявленная функция системы?
Если программа предназначалась только для сортировки исследований, одна модель риска. Если для выявления патологии — другая.

Как был организован медицинский процесс?

Должен ли врач был самостоятельно анализировать снимок или система фактически заменила первичный анализ?

Какие показатели качества гарантировал разработчик?

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

Обновлялся ли алгоритм?

Какие данные поступили на вход системы?

Была ли ошибка связана с самой моделью или с качеством данных?

Логировались ли действия пользователя и результаты работы системы?

Была ли возможность обнаружить ошибку до причинения вреда пациенту?

Отсюда важный практический вывод:
ответственность за медицинский ИИ невозможно нормально распределить одним стандартным разделом договора «Ответственность сторон».

Она проектируется через архитектуру продукта, процессы его использования, документацию и только затем — через договор

Особенно сложный блок — данные

Для развития медицинских AI-систем нужны большие массивы информации. Причем наиболее ценными часто оказываются реальные клинические данные

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

Поэтому нельзя рассуждать так:
«У клиники уже есть данные пациентов, значит мы можем использовать их для обучения собственного AI-сервиса».

Необходимо отдельно определить:

• для какой цели первоначально собирались данные;
• кто является оператором;
• кто получает доступ к данным;
• передаются ли они разработчику;
• для какой именно цели осуществляется новая обработка;
• есть ли для нее законное основание;
• требуется ли дополнительное согласие;
• могут ли использоваться обезличенные данные;
• возможно ли восстановление связи данных с конкретным пациентом;
• где находятся информационные системы;
• привлекаются ли внешние технологические провайдеры.

Особенно аккуратно необходимо относиться к ситуации, когда данные собирает медицинская организация для оказания медицинской помощи, а затем их предполагается передавать отдельной IT-компании для обучения коммерческой AI-модели

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

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

Есть еще одна зона, которую часто вообще не воспринимают как внедрение медицинского ИИ.
Клиника не покупала специальную AI-систему

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

С точки зрения информационной безопасности и персональных данных это может быть гораздо опаснее официального внедрения специализированного сервиса

Возникают вопросы:
Какие сведения отправлены внешнему провайдеру?
Можно ли было их передавать?
Используются ли запросы для дальнейшего обучения модели?
Где находятся серверы?
Кто имеет доступ к информации?
Можно ли идентифицировать пациента?
Какие условия использования сервиса принял сотрудник?
И главное — знает ли вообще медицинская организация, что врачи используют такие инструменты?

Поэтому политика «мы пока не внедряли ИИ» уже не означает, что в компании ИИ не используется

Вероятнее всего, сотрудники начали использовать его раньше, чем компания успела принять соответствующее решение.

Поэтому следующим этапом развития внутренних документов медицинских организаций, на наш взгляд, станет AI-playbook — правила использования искусственного интеллекта сотрудниками

Это должен быть не декларативный документ «об ответственном использовании ИИ».
Он должен отвечать на вполне практические вопросы

Какие AI-сервисы разрешены:
Может ли врач использовать публичные нейросети?
Есть ли корпоративный сервис?

Какие данные можно загружать
Можно ли использовать медицинскую документацию?
Необходимо ли предварительное обезличивание?
Можно ли загружать изображения?
Аудиозаписи?
Лабораторные исследования?

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

Как проверять результат
Использование generative AI создает отдельный риск: система способна сформировать убедительный, логичный и при этом неверный ответ. Поэтому фраза «результат ИИ требует проверки» должна быть переведена в конкретную процедуру.

Как фиксировать использование ИИ
Для критичных процессов может потребоваться логирование:

• использованной системы
• версии модели
• исходных данных
• результата
• решения сотрудника

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

Для обычного программного обеспечения регулярные обновления — нормальная часть жизненного цикла

Для медицинского ИИ ситуация сложнее

Разработчик может:

• дообучить модель
• изменить датасет
• изменить алгоритм
• подключить новую базовую модель
• изменить логику принятия решений
• добавить новые категории данных
• существенно повысить или снизить чувствительность системы

Но если ПО является зарегистрированным медицинским изделием, возникает вопрос:
насколько обновленный продукт остается тем же продуктом, эффективность и безопасность которого оценивались при регистрации?

Российское регулирование уже специально выделяет изменения регистрационного досье программного обеспечения с ИИ. Кроме того, в 2026 году Росздравнадзор утвердил порядок автоматической передачи информации об обрабатываемых данных и результатах работы программного обеспечения с ИИ, являющегося медицинским изделием.
Это важная тенденция

Регулятор постепенно переходит от модели: «один раз зарегистрировали продукт» к модели постоянного контроля его функционирования

Для AI-разработчика это означает необходимость заранее создавать не только сам алгоритм, но и систему управления изменениями — AI Change Management.

Еще одна ошибка — использовать для медицинского AI-продукта обычный договор предоставления доступа к программному обеспечению

Формально он может быть юридически корректным.
Но он не описывает основные риски сторон.

Для медицинской AI-системы стоит отдельно определить как минимум:

Назначение продукта
Что именно система делает и для чего ее можно применять

Регуляторный статус
Является ли программное обеспечение медицинским изделием и кто обеспечивает соблюдение соответствующих требований

Границы использования
Какие сценарии разрешены и какие запрещены

Роль врача
Какие решения требуют обязательной проверки медицинским работником

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

Показатели работы системы
Какие характеристики заявляет разработчик и каким образом они измеряются

Версионность
Как фиксируется используемая версия модели

Обновления
В каких случаях разработчик обязан заранее уведомлять медицинскую организацию

Логирование
Какая информация о работе алгоритма сохраняется и на какой срок

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

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

Именно эти положения в спорной ситуации позволят восстановить реальный механизм принятия решения.

Мы бы начинали юридический аудит AI-продукта с семи вопросов

1. Что именно делает ИИ?
Не «используем искусственный интеллект», а конкретная функция алгоритма

2. Может ли эта функция относить ПО к медицинским изделиям?
Это должно оцениваться до вывода продукта на рынок

3. Какие данные использует система?
Откуда они получены и на каком основании используются

4. Кто принимает решение?
Алгоритм, врач или врач с использованием результата алгоритма

5. Может ли человек проверить результат ИИ?
И предусмотрена ли такая проверка самим процессом

6. Кто и как контролирует изменение модели?
Особенно после обновлений и дообучения

7. Что произойдет, если алгоритм ошибется?
Можно ли будет восстановить цепочку событий и определить ответственность

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

Проблема глубже: не сформирована юридическая архитектура AI-продукта.

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

Поэтому начинать внедрение медицинского ИИ только с разработки алгоритма — уже рискованная стратегия

Юридическая модель должна проектироваться одновременно с продуктом

Для разработчика это означает:
функция → регуляторный статус → данные → медицинский процесс → контроль модели → договоры → ответственность

Для медицинской организации:
выбор AI-сервиса → проверка его статуса → правила работы с данными → роль врача → внутренний AI-playbook → контроль результатов и инцидентов

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

«Добавим дисклеймер, что ИИ носит рекомендательный характер»

Следующий этап развития медицинского ИИ — это не только более точные модели.
Это создание вокруг них полноценной юридической инфраструктуры доверия