Почему облачный ИИ – это риск по 152-ФЗ
Когда вы ищете «ИИ-агента для автооформления приёмов», по факту вам предлагают один из двух типов систем. Первый – облачная обёртка: голос или текст приёма уходит на сервер провайдера (иногда за пределы РФ), там обрабатывается, а обратно возвращается черновик. Второй – локальная система, которая считает всё у вас. Разница между ними для закона огромна.
Три факта задают рамку 152-ФЗ:
- Данные о здоровье – специальная категория персональных данных. К ним закон предъявляет повышенные требования по сравнению с обычными ПД (ст. 10 152-ФЗ, комментарий Роскомнадзора).
- Локализация в России. Персональные данные граждан РФ должны храниться в базах на территории РФ (п. 5 ст. 18 152-ФЗ). С 1 июля 2025 года ответственность за нарушение локализации ужесточили – появились оборотные штрафы (по материалам ConsultantPlus и юридических обзоров, напр. Lidings).
- Оператор отвечает за маршрут данных. Клиника как оператор обязана знать и контролировать, куда уходят данные, и иметь согласие пациента на обработку.
Отсюда главный вывод: вопрос не «можно ли использовать ИИ», а «куда уходят данные пациента, когда ИИ работает». Облачный ИИ по своей архитектуре отвечает на этот вопрос неудобно: данные покидают клинику.
Разбор договора поручения и его пределов
Обычный аргумент продавца облачного решения звучит так: «мы заключим с вами договор поручения обработки (ст. 6 152-ФЗ), и всё законно». Договор поручения действительно легализует передачу данных обработчику – но у него есть жёсткие пределы, о которых умалчивают.
- Договор не отменяет ответственность оператора. Даже при поручении именно клиника остаётся тем, к кому придут с проверкой и к кому применят штраф. Обработчик – ваша зона ответственности, а не щит от неё.
- Договор не отменяет требование локализации. Если сервер обработчика или его субподрядчика находится за пределами РФ, бумага этого не исправляет. Нужно документально подтверждать, где физически лежат и считаются данные.
- Согласие пациента должно покрывать передачу третьему лицу. Стандартное согласие на обработку в клинике не всегда покрывает передачу данных о здоровье внешнему ИИ-сервису и тем более трансграничную передачу.
- Договор не отменяет врачебную тайну (об этом ниже). Поручение по 152-ФЗ и режим тайны по 323-ФЗ – это две разные плоскости, и первая не закрывает вторую автоматически.
Проще говоря, договор поручения – это надстройка над архитектурой, а не замена ей. Вы строите весь процесс на допущении, что данные уезжают, и пытаетесь это допущение обвесить бумагами. Грамотный юрист или IT-директор клиники такую конструкцию срежет, потому что она хрупкая: меняется субподрядчик у провайдера, меняется юрисдикция сервера – и вы уже в нарушении, не зная об этом.
Надёжнее не «получать разрешение отправлять данные наружу», а сделать так, чтобы они наружу не уходили вообще.
Что такое on-prem ИИ-консилиум и закрытый контур инференса
On-prem (от on-premises, «на своих мощностях») означает, что ИИ работает на сервере, который физически стоит в клинике или в арендованной вами стойке в российском ЦОД, и находится под вашим контролем. Инференс (то есть сам расчёт ответа ИИ) происходит внутри вашего контура. Данные пациента не выходят в интернет, потому что модель, которая их обрабатывает, лежит рядом – на том же сервере.
Это называют закрытым контуром инференса: у сервера может не быть выхода в интернет вообще, либо он ограничен так, что данные наружу технически не могут уйти. Модель развёрнута локально, обновления и телеметрия отключены или контролируются, журнал фиксирует каждое обращение.
Теперь про важное отличие метода. Когда говорят «ИИ-агент для медкарт», обычно имеют в виду одну модель, которая читает приём и выдаёт черновик. Но одна модель – какой бы сильной она ни была – склонна к двум опасным для медицины вещам: она может галлюцинировать (уверенно придумать то, чего не было) и соглашаться с ошибкой во вводе вместо того, чтобы её заметить. Один агент = одна модель = одна точка отказа.
ИИ-консилиум решает это иначе. Это не один чат-бот, а несколько ИИ-ролей, которые проверяют друг друга перед тем, как показать черновик врачу. Как врачебный консилиум: несколько независимых мнений надёжнее одного. Одна роль формирует черновик, другая ищет в нём противоречия и пропуски, отдельный детерминированный валидатор сверяет наличие обязательных формулировок. Такой подход не обещает «ноль ошибок» – честно говорить об этом важно – но он резко снижает долю ошибок и пропусков по сравнению с одиночной моделью.
Ключевой момент для нашей темы: консилиум точно так же разворачивается on-prem. Несколько ИИ-ролей крутятся на вашем сервере, взаимная проверка идёт внутри контура, данные пациента наружу не уходят. То есть надёжность метода (консилиум вместо одного агента) и требование закона (данные в клинике) достигаются одновременно, без компромисса. Подробнее об архитектуре надёжности – в разделе [безопасность и закон](/security).
И ещё одна граница, которую задаёт метод и которую мы соблюдаем строго: консилиум проверяет ОФОРМЛЕНИЕ карты, а не ставит диагноз. Он следит за полнотой записи, наличием обязательных элементов, непротиворечивостью, но клиническое решение принимает и подписывает врач. Это принципиально и для доверия, и для юридического статуса (см. раздел про 181н).
Чек-лист: как проверить, что система не сливает данные
Это самый практичный раздел. Дайте эти вопросы потенциальному поставщику ИИ и своему IT-специалисту. Если хотя бы на первый пункт ответ «в облаке провайдера» – дальше можно не продолжать.
1. Где физически обрабатывается запрос?
- Спросите прямо: когда ИИ читает приём и готовит черновик, на каком сервере идёт расчёт? Ответ должен быть «на сервере клиники» или «в вашей стойке в РФ-ЦОД под вашим контролем», а не «в нашем облаке».
- Попросите указать конкретное физическое расположение оборудования и подтверждение локализации в РФ.
2. Есть ли исходящие внешние вызовы?
- Ключевой технический тест: посадите систему в изолированную сеть без выхода в интернет и проверьте, что она продолжает работать. Настоящий on-prem работает без интернета.
- Попросите показать список сетевых соединений сервера ИИ. В идеале исходящих соединений к внешним адресам при обработке карты быть не должно.
- Проверьте, отключена ли телеметрия, автообновления «по воздуху» и отправка логов вовне. Обновления должны ставиться контролируемо, вами.
3. Где хранятся данные и черновики?
- Уточните, где лежат аудиозаписи приёмов, распознанный текст и черновики карт. Всё должно оставаться в вашем хранилище.
- Спросите про политику удаления: удаляется ли исходное аудио после обработки, и кто этим управляет.
4. Ведётся ли журнал доступа?
- Система должна вести журнал: кто, когда и к какой записи обращался, когда ИИ читал данные, кто из врачей утвердил черновик. Это и требование хорошей практики ИБ, и ваш аудит-след на случай проверки.
- Журнал должен быть защищён от изменения задним числом.
5. Кто и как делает обезличивание, если оно нужно?
- Если данные используются для настройки или аналитики, обезличивать их должна сама клиника (оператор) у себя, а не передавать «сырые» данные подрядчику наружу.
6. Был ли независимый аудит информационной безопасности?
- Запросите результаты независимой проверки ИБ: пентест, аудит сетевой изоляции, проверку отсутствия скрытых каналов передачи.
- Для критичных внедрений имеет смысл заказать собственный аудит у профильной ИБ-компании – это не формальность, а проверка того, что «on-prem» в маркетинге совпадает с «on-prem» в реальности.
Аудио приёмов – это отдельная чувствительная тема. Насколько безопасно передавать аудио ИИ? Ответ тот же, что и по тексту: безопасно ровно настолько, насколько это аудио не покидает клинику. Если распознавание речи и обработка идут на вашем сервере, а исходный файл не уходит во внешний сервис, риск минимален. Если аудио стримится в облако для распознавания – это ровно тот случай, где данные о здоровье оказываются у третьей стороны. Разница снова в архитектуре, а не в обещаниях. Сравнение классов решений по этим критериям – в [сравнении решений](/compare).
152-ФЗ, 323-ФЗ и 181н простыми словами: что требуется, а что нет
Три закона задают рамку. Разберём, что каждый требует и чего НЕ требует.
152-ФЗ – о персональных данных
Требует: данные о здоровье считать специальной категорией ПД, хранить в базах на территории РФ (локализация), иметь согласие пациента, контролировать маршрут данных, вести необходимую документацию оператора.
Не требует: запрещать ИИ как таковой. Закон нигде не говорит «нельзя использовать ИИ». Он говорит про то, куда и как уходят данные. On-prem-архитектура, где данные не покидают клинику, снимает основной пласт этих рисков естественным образом.
323-ФЗ – о врачебной тайне
Требует: сведения о факте обращения, диагнозе и состоянии пациента составляют врачебную тайну; их разглашение третьим лицам без согласия пациента запрещено (ст. 13 323-ФЗ «Об основах охраны здоровья граждан»).
Ключевая мысль: передача данных приёма внешнему ИИ-сервису – это потенциально предоставление сведений третьему лицу. Договор поручения по 152-ФЗ сам по себе не закрывает вопрос врачебной тайны – это разные правовые режимы. А вот когда ИИ работает on-prem внутри клиники и данные никому не передаются вовне, вопрос разглашения третьему лицу в принципе не возникает: сведения остаются внутри медорганизации, которая и так является их законным держателем.
181н – о медицинских изделиях
Приказ Минздрава № 181н (и связанная с ним номенклатура) регулирует программное обеспечение, которое относится к медицинским изделиям. ПО становится медизделием, когда оно предназначено для диагностики, профилактики, лечения – то есть влияет на клиническое решение.
Здесь и проходит наша граница. Система, которая помогает оформить карту – проверить полноту записи, наличие обязательных формулировок, непротиворечивость текста – и при этом не ставит диагноз и не назначает лечение, находится вне контура медизделия по 181н. Именно поэтому мы строго держим позицию: консилиум проверяет ОФОРМЛЕНИЕ, клиническое решение принимает и подписывает врач.
Требует (если вы делаете медизделие): регистрацию в Росздравнадзоре, соответствие требованиям к медизделиям, клинические испытания.
Не требует (если вы вне медизделия): всего перечисленного, при условии что система честно остаётся ассистентом по оформлению и не подменяет врача в постановке диагноза. Это не лазейка, а осознанное проектное решение: врач всегда в контуре принятия решения.
> Важно: это информационный материал, а не юридическая консультация. Перед внедрением получите заключение профильного юриста под вашу конкретную конфигурацию – особенно по тонкой границе «ассистент по оформлению / система поддержки принятия врачебных решений».
Какое железо нужно клинике и порядок внедрения
Про железо (ориентиры, не жёсткие цифры)
Точная конфигурация зависит от нагрузки – числа врачей, объёма приёмов, требований к скорости ответа. Ниже – ориентиры, а не гарантированные требования; финальная спецификация считается под вашу клинику.
- Сервер с GPU. Для локального инференса ИИ нужен сервер с одной или несколькими видеокартами. Начальная конфигурация для пилота на одной специальности заметно скромнее, чем для сети филиалов – это оценка, зависящая от выбранного метода развёртывания.
- Модели разного размера под задачу. Для оформления карт не всегда нужна самая тяжёлая модель. Часто рациональнее развернуть модели помельче, но собранные в консилиум с взаимной проверкой – это надёжнее, чем одна большая модель без проверки, и дешевле по железу (оценка).
- Размещение. Два варианта: сервер физически в клинике, либо ваша выделенная стойка в российском ЦОД под вашим контролем. Оба сохраняют данные в РФ-контуре; выбор – вопрос удобства эксплуатации и бюджета.
- Изоляция сети. Сервер ИИ настраивается так, чтобы данные технически не могли уйти во внешний интернет.
Порядок внедрения
- Аудит и юридическая рамка. Зафиксируйте, где сейчас хранятся данные, какие согласия есть, кто оператор. Получите заключение юриста по границе «оформление / медизделие».
- Выбор специальности для пилота. Начните с одной специальности, где документация однотипна и объём приёмов даёт быструю обратную связь. Так дешевле и нагляднее.
- Развёртывание в закрытом контуре. Установка сервера, разворачивание консилиума on-prem, настройка сетевой изоляции, интеграция с вашей МИС через тонкий коннектор.
- Настройка обязательных элементов. Валидатор настраивается под ваши шаблоны и требования к оформлению карт.
- Обучение врачей и роль чемпиона. Один врач-энтузиаст помогает команде принять инструмент. Врач всегда проверяет и утверждает черновик – ИИ не подписывает карту за него.
- Замер и масштабирование. Сравните время оформления и полноту карт до и после, затем расширяйтесь на другие специальности и филиалы.
- Независимый аудит ИБ перед выходом на полную нагрузку – подтверждение, что контур действительно закрыт.
Разобрать вашу конфигурацию и посчитать смету можно на [пилоте и разборе](/pilot).
FAQ
Можно ли по 152-ФЗ вообще использовать ИИ с данными пациентов? Да. Закон не запрещает ИИ – он регулирует маршрут данных. Если ИИ работает on-prem и данные не покидают клинику, основной пласт рисков снимается архитектурой.
Безопасно ли передавать аудио приёмов ИИ? Безопасно ровно настолько, насколько аудио не выходит из клиники. Если распознавание речи идёт на вашем сервере и файл не уходит во внешний сервис – риск минимален. Если аудио стримится в облако – это передача данных о здоровье третьей стороне.
Как быстро проверить, что система не сливает данные? Отключите серверу интернет и убедитесь, что ИИ продолжает работать. Настоящий on-prem работает без сети. Плюс запросите журнал доступа и результаты независимого аудита ИБ.
Это медизделие? Нужна регистрация в Росздравнадзоре? Если система проверяет оформление карты и не ставит диагноз – она вне контура медизделия по 181н, регистрация не требуется. Клиническое решение всегда за врачом. Точную границу подтверждает ваш юрист.
Чем ИИ-консилиум лучше одного ИИ-агента? Один агент – это одна модель и одна точка отказа: она может галлюцинировать или согласиться с ошибкой. Консилиум из нескольких ИИ, проверяющих друг друга, резко снижает долю ошибок и пропусков. Мы не обещаем «ноль ошибок» – мы обещаем взаимную проверку и проверяемость результата.
Договор поручения обработки решает проблему облака? Нет, не полностью. Он легализует передачу, но не снимает ответственность оператора, требование локализации и режим врачебной тайны. Это надстройка над архитектурой, а не замена ей.
Источники
- Федеральный закон № 152-ФЗ «О персональных данных», ст. 6 (поручение обработки), ст. 10 (специальные категории ПД), ст. 18 п. 5 (локализация в РФ) – текст на ConsultantPlus.
- Ужесточение ответственности за нарушение локализации и обработки ПД с 01.07.2025 (оборотные штрафы) – обзоры юридических компаний, напр. Lidings; материалы ConsultantPlus.
- Категории персональных данных, данные о здоровье как специальная категория – разъяснения Роскомнадзора.
- Федеральный закон № 323-ФЗ «Об основах охраны здоровья граждан в РФ», ст. 13 (врачебная тайна) – текст на ConsultantPlus.
- Приказ Минздрава России № 181н и номенклатурная классификация ПО как медицинского изделия – официальные публикации Минздрава РФ и Росздравнадзора.
Материал носит информационный характер и не является юридической консультацией. Перед внедрением получите заключение профильного юриста под вашу конфигурацию.