Слой комплаенса и безопасности клинического ИИ

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

Кратко

Любая ИИ-функция в телемед-продукте – скрайб, который готовит черновик протокола, чат-бот, который собирает жалобы, модель, которая помечает тревожный показатель, – проходит одни и те же четыре проверки, и эта статья описывает их для всего продукта. Первая проверка – договор. Модель, которая видит данные пациента, обрабатывает специальную категорию персональных данных и сведения, составляющие врачебную тайну, поэтому её провайдер работает только по поручению оператора, с условиями конфиденциальности и запретом обучаться на ваших данных, – до того, как к нему попадёт первая запись. Вторая – граница медданных: они остаются на серверах в России, модель получает только необходимый минимум, а всё, что используется вне клинической цепочки, обезличивается; зарубежные ИИ-API для медданных не используются. Третья – статус медизделия, то есть граница между ПО, которое поддерживает врача, и ПО, которое ставит диагноз: медицинское назначение делает ПО медизделием, ПО с ИИ – всегда класс риска 3 с регистрацией в Росздравнадзоре, а дистанционно диагноз не ставит даже врач. Четвёртая – человек, валидация и проверка на смещение: они сохраняют функцию безопасной и законной после запуска.

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

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

Как читать эту статью

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

Коротко об охвате. Статья посвящена клинической обвязке и комплаенсу ИИ: договору, пути данных, регуляторной границе, проверке человеком. Она не о том, как модели устроены внутри: архитектура распознавания речи, суммаризации и моделей аномалий разобрана в разделе AI for Video Engineering, а общие основы защиты медданных – в статье 152-ФЗ и врачебная тайна простым языком. Мы ссылаемся на них, а не повторяем.

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

Сначала – термины

На двух терминах держится вся статья, поэтому сначала определим их.

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

Клинический ИИ здесь – любая функция продукта, которая использует модель машинного обучения и касается клинического приёма: готовит черновик протокола, транскрибирует консультацию, переводит между пациентом и врачом, собирает жалобы, резюмирует визит или помечает показание. Модель может быть вашей собственной, развёрнутой у вас, или доступной через программный интерфейс – API, удалённый сервис, которому ваш код отправляет данные и от которого получает ответ. Где работает модель, крайне важно; об этом – вторая проверка.

Проверка 1 – договор: провайдер модели работает по поручению

Начнём с проверки, которую команды пропускают чаще всего: она выглядит как бумажная работа, а не инженерия.

Оператор медданных – обычно медорганизация: она определяет цели и состав обработки и отвечает перед пациентом. Любая внешняя сторона, которая обрабатывает эти данные от её имени (ваша платформа, облако, провайдер модели), делает это по поручению оператора (ч. 3 ст. 6 152-ФЗ). Поручение – это договор, в котором перечислены данные и действия с ними, цели обработки, обязанность соблюдать конфиденциальность и требования к защите по ст. 19, включая уведомление оператора об инцидентах; по запросу оператора обработчик предоставляет документы о соблюдении требований.¹ Перед пациентом за обработчика отвечает оператор, а обработчик отвечает перед оператором (ч. 5); если обработчик – иностранное лицо, перед пациентом отвечают оба (ч. 6). Помимо 152-ФЗ действует режим врачебной тайны (ст. 13 323-ФЗ): сотрудники провайдера, которые могут увидеть данные, должны быть связаны обязательством о неразглашении.² Провайдер модели, получающий слова, показатели или анамнезы ваших пациентов, – такой же обработчик, как облачный хостинг. Нет поручения – нет данных, какой бы хорошей ни была модель.

Это правило исключает два варианта, за которые команды хватаются первыми. Потребительская версия чат-бота или речевого сервиса работает по пользовательскому соглашению с человеком, а не по поручению оператора, поэтому транскрипт пациента, отправленный туда, в момент нажатия «отправить» становится передачей медданных третьему лицу без законного основания. Зарубежные ИИ-API исключены вдвойне: записывать и хранить персональные данные россиян в зарубежных базах запрещено с 1 июля 2025 года (ч. 5 ст. 18 152-ФЗ), передача спецкатегории за рубеж – это трансграничная передача, которая требует уведомить Роскомнадзор и оценить получателя (ст. 12), а ведущие зарубежные провайдеры моделей к тому же официально недоступны в России.³ Рабочий путь – российские провайдеры (GigaChat, Alice AI в Yandex AI Studio, SaluteSpeech, Yandex SpeechKit) по договору с условиями поручения или модель, развёрнутая у вас. Но и здесь от трёх деталей зависит, защищены ли вы на самом деле:

• Поручение должно распространяться на конкретный сервис и тариф, которые вы используете. «У провайдера облако с аттестатом» – не то же самое, что «наш договор распространяется на этот API». Бизнес-API и потребительское приложение одного бренда работают на разных условиях, поэтому подтверждайте всё письменно.
• В договоре должно быть условие «без обучения». Цели обработки в поручении ограничены вашей услугой, а использование данных пациентов для обучения или улучшения моделей провайдера – это другая цель. Пропишите запрет явно, иначе медданные могут попасть в модель, которая потом ответит на чужой запрос.
• Требуйте раскрыть всю цепочку: на чьих серверах физически работает модель, где хранятся запросы и журналы и у кого ещё есть к ним доступ. Каждое звено должно находиться в России и работать на тех же условиях.

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

Проверка 2 – граница: медданные в России, модели – минимум, остальное обезличить

Договор определяет, кому разрешено держать медданные. Граница – инженерная задача: обеспечить, чтобы данные попадали только к этим сторонам и в минимальном объёме.

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

От того, где работает модель, зависит, насколько трудно удерживать границу. Честных вариантов три, а четвёртый – ловушка:

• Открытая модель у себя. Вы запускаете модель с открытыми весами на своих серверах или в аттестованном сегменте российского облака (Yandex Cloud, Cloud.ru, Selectel, MWS). Медданные не покидают ваш периметр. Максимальный контроль и максимальная ответственность: меры защиты по ПП 1119 и приказу ФСТЭК № 21 целиком на вас.
• Российский ИИ-API по поручению, без обучения, с данными в России. Медданные покидают ваши серверы, но попадают только к обработчику по договору, которому запрещено на них обучаться. Это стандартный компромисс, который можно обосновать.
• Обезличенные данные и агрегаты – для аналитики. Если данные обезличены так, что без дополнительной информации нельзя определить, кому они принадлежат (ст. 3 152-ФЗ), их можно использовать для аналитики и оценки модели вне живой клинической цепочки. Но обезличенные записи по 152-ФЗ остаются персональными данными: на них по-прежнему распространяются локализация и поручение, а из-под режима выходят только агрегаты, где ни одна ячейка не указывает на конкретного человека. Отдельный режим 233-ФЗ, по которому операторы передают обезличенные данные в ГИС Минцифры, не позволяет формировать такие наборы из специальных категорий.⁵
• Ловушка: потребительский чат-бот или зарубежный API. Поручения нет, данные уходят за пределы контура и, возможно, за рубеж. Это нарушение первой проверки, замаскированное под инженерное решение.

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

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

Проверка 3 – статус медизделия: поддержка врача или диагноз

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

По ч. 1 ст. 38 323-ФЗ медицинским изделием может быть и специальное программное обеспечение, которое производитель предназначил для профилактики, диагностики, лечения заболеваний, мониторинга состояния организма или проведения медицинских исследований; обращаться оно может только после регистрации (ч. 4).⁶ Решают назначение ПО и то, что о нём заявлено, а не сложность модели. Регистрация идёт по правилам ПП 1684, а ПО с технологиями ИИ по номенклатурной классификации Минздрава всегда относится к классу потенциального риска 3, высшему (п. 15.1.1 приказа 4н).⁷ ⁸ Это не экзотика: на август 2026 года в России зарегистрировано 59 отечественных медизделий с ИИ.⁹

Для телемедицины порядок 193н добавляет конкретики. В отложенных консультациях можно использовать системы поддержки принятия врачебных решений (СППВР) – программное обеспечение с применением технологий ИИ, являющееся медицинским изделием и зарегистрированное в установленном порядке (п. 17); СППВР допускаются и при дистанционном наблюдении (п. 45).¹⁰ Иными словами, ИИ, который помогает врачу принять клиническое решение, в телемедицине законен именно как зарегистрированное медизделие.

В этих рамках в телемедицине чаще всего встречаются две ошибки. Первая связана с адресатом. Консультация «врач – пациент» допускается только для ограниченного круга целей: профилактики, сбора жалоб и анамнеза, оценки эффективности лечения, наблюдения и решения об очном приёме (ч. 2 ст. 36.2 323-ФЗ), а без очного приёма заключение может содержать только рекомендации по обследованию, диагноз дистанционно не ставится (п. 40 193н).¹¹ Функция, которая выдаёт пациенту вывод о его болезни (например, симптом-чекер, говорящий «у вас, скорее всего…»), не просто становится медизделием: она делает то, чего в дистанционном формате не вправе сделать и живой врач. Вторая ошибка – чёрный ящик. Отдельного правового критерия «объяснимости» мы не нашли, но документы телемедконсультации медработник подписывает УКЭП (ч. 7 ст. 36.2), и ответственность за вывод лежит на нём. Рекомендация, основание которой врач не может проверить, превращает подпись в формальность: «так сказал ИИ» – не то основание, под которым можно расписаться.

Отсюда практический тест для продуктовой команды: функция упорядочивает информацию для врача, который может её проверить, или выдаёт клинический вывод, на который кто-то должен отреагировать? Сравните две формулировки вывода одной и той же модели. «Вот тренд АД пациента и выдержка из клинических рекомендаций» – это поддержка. «У этого пациента гипертонический криз; начните лечение» – территория медизделия. Случай триажа подробно разобран в статье об ИИ-триаже.

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

Если ваша функция является медизделием, это не тупик, а задача, которую нужно планировать. ИИ-изделия меняются по мере дообучения моделей, и правила ПП 1684 содержат отдельный порядок внесения изменений в ПО с ИИ (п. 112–136), а для ИИ-анализа рентгеновских снимков, КТ и маммографии предусмотрен ускоренный порядок регистрации (п. 101–109).⁸ До 31.12.2027 медизделия можно регистрировать по национальным правилам вместо правил ЕАЭС.¹² Разрабатывать ИИ-функцию уровня медизделия – значит с первого дня планировать регистрацию, систему качества и порядок обновления модели, а не обнаружить эту работу после запуска.

Проверка 4 – человек, валидация и проверка на смещение

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

Человек в цепочке. Для любой функции поддержки квалифицированный медработник проверяет вывод и отвечает за него до того, как тот повлияет на лечение. Скрайб готовит черновик – врач подписывает. Триаж предлагает очерёдность – врач может её изменить. Это не только безопаснее: как показано в разделе о третьей проверке, контрольная точка, где человек проверяет вывод, – часть того, что удерживает функцию в зоне инструмента для врача. Безопасное поведение по умолчанию – передавать случай человеку, а не действовать молча: если модель не уверена, она отдаёт случай медработнику, а не принимает решение сама.

Честная валидация без опоры на среднее. Одна общая цифра точности скрывает важные провалы. Посчитаем, прежде чем доверять модели. Допустим, заявленная точность модели – 94% на 9 000 пациентов. Разбейте по подгруппам: 8 000 пациентов из большинства дают 96%, а 1 000 из слабо представленной группы – 79%. Общая цифра – (8 000 × 0,96 + 1 000 × 0,79) ÷ 9 000 = (7 680 + 790) ÷ 9 000 ≈ 94,1%, та самая цифра с презентации. «94%» – правда, но бесполезная: она усредняет сильный результат на многих и опасный на немногих. Валидация, которая не разбивает качество по подгруппам пациентов, прячет худшее поведение модели за лучшим.

Проверка на смещение – вопрос клинической безопасности. Качество зарегистрированного медизделия с ИИ подтверждено при регистрации, но на данных разработчика, а ваша популяция может от них отличаться по возрасту, полу, сопутствующим заболеваниям, оборудованию и регионам. Хрестоматийный пример – пульсоксиметрия, которая у пациентов с тёмной кожей чаще пропускает скрытую гипоксемию; любая модель, обученная на смещённом сигнале, наследует смещение и подводит именно тех пациентов, которых данные и так подводят.¹³ Для систем ИИ в клинической медицине есть серия национальных стандартов ГОСТ Р 59921; какие её части применимы к вашему изделию, уточняйте при регистрации. Обязанность и одновременно инженерная практика – измерять качество по подгруппам, документировать найденное и устранять разрывы, а не считать модель справедливой только потому, что справедлива математика.

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

Все проверки вместе: варианты развёртывания

Когда вы выбираете, как запускать модель, четыре проверки сводятся к одному практическому вопросу: какой вариант развёртывания сохраняет обработку медданных законной, остаётся в зоне поддержки врача и поддаётся валидации? Таблица ниже сводит выбор воедино. Начните со столбца «Договор»: без поручения на конкретный сервис остальные столбцы строки уже не важны.

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

Распространённая дорогая ошибка

Типичный провал клинического ИИ – «удобное» упрощение, которое проваливает сразу три проверки: команда подключает функцию для пациентов к бесплатному публичному чат-боту или зарубежному API, потому что так быстрее и ответы получаются гладкими. Одним решением она отправила медданные стороне без поручения, возможно за рубеж и туда, где на них могут обучаться (нарушены первая и вторая проверки), и запустила инструмент, который сообщает пациенту, что с ним не так (провалена третья). Функция, которая должна была радовать пользователей, превратилась в утечку, о которой нужно уведомить Роскомнадзор в течение 24 часов, и в незарегистрированное медизделие, которое вдобавок ставит дистанционный диагноз.

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

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

Клиническая ИИ-функция должна держать каждую запись пациента внутри контура в России (у вас или у обработчика по поручению), отправлять модели только минимум, оставаться в зоне поддержки врача (если только она не разработана и не зарегистрирована как медизделие) и поставляться с контрольной точкой для врача, честной валидацией по подгруппам и проверкой на смещение. Фора Софт с 2005 года разрабатывает ПО для видео реального времени, конференций, стриминга и решений с ИИ, в том числе телемед-платформы, где ИИ-функция, граница медданных вокруг неё и проверка врачом связаны в один рабочий процесс. Мы встраиваем ИИ так, чтобы он проходил все четыре проверки: открытая модель в вашем контуре или российский API по поручению без обучения, чёткая позиция «поддержка, а не диагноз» и врач, который отвечает за вывод. Мы не прикручиваем модель к продукту в надежде, что комплаенс подтянется потом.

Что меняется в 2026–2027 годах

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

• 243-ФЗ «О поддержке развития технологий ИИ в РФ» действует с 1 сентября 2026 года. Он касается в основном больших фундаментальных моделей (суверенных и национальных, с требованиями к локализации данных) и не меняет классификацию медизделий: ваша ИИ-функция по-прежнему подчиняется 323-ФЗ, ПП 1684 и приказу 4н.¹⁴
• Проект замены приказа ФСТЭК № 21 (опубликован в июле 2026 года) предлагает отдельные меры для ИИ, контейнеров и API, требования к обработчикам и регулярную оценку защищённости. На конец сентября 2026 года он не подписан и действует приказ № 21, но закладывать эти меры в архитектуру разумно уже сейчас.¹⁵ Подробности – в статье требования к защите ПДн в 2026 году.
• Пострегистрационный мониторинг ИИ-изделий с автоматической передачей данных в Росздравнадзор обсуждается, но не принят; отрасль также просит пересмотреть правило «ИИ – всегда класс 3». Ни то ни другое пока не действует.
• Регистрация по национальным правилам вместо правил ЕАЭС возможна до 31.12.2027; после этой даты планируйте регистрацию по единым правилам союза.¹²

Главное

• Каждая клиническая ИИ-функция проходит одни и те же четыре проверки: договор, граница медданных, статус медизделия, человек.
• Модель, которая видит медданные, – обработчик по поручению; нет поручения с запретом обучения – нет данных.
• Медданные остаются в России, модель получает минимум, зарубежные ИИ-API и потребительские чат-боты исключены.
• Клинический вывод делает ИИ-функцию медизделием класса 3, а вывод о болезни для пациента ещё и нарушает 193н.
• Одно среднее значение точности скрывает провал на подгруппе, поэтому валидируйте и проверяйте смещение по подгруппам.
• Держите врача в цепочке, сообщайте об использовании ИИ и заранее стройте мониторинг качества модели.

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

• Где ИИ встраивается в телемед-продукт – карта
• Амбиентное клиническое документирование: ИИ-скрайб
• Своя разработка или покупка ИИ-функций: что и сколько стоит