Здравоохранение без иллюзий: где ИИ разгружает систему, а где должен остановиться

От цифрового контура к AI-архитектуре

Здравоохранение и социальная сфера уже не являются «чистым листом» для цифровизации. В здравоохранении завершенный федеральный проект цифрового контура 2019–2024 годов дал масштабную инфраструктурную базу: по данным Минздрава, на конец 2024 года 100% медицинских организаций государственной и муниципальной систем здравоохранения использовали медицинские информационные системы и взаимодействовали с ЕГИСЗ; 56,487 млн граждан воспользовались сервисами личного кабинета пациента «Мое здоровье»; 1,035 млн автоматизированных рабочих мест медработников были подключены к МИС.[1]

Новая фаза — федеральный проект «Национальная цифровая платформа «Здоровье»». В его мероприятиях обозначены единая цифровая платформа управления здоровьем, защищенная сеть передачи данных для отрасли, развитие сервисов ГИС ОМС, методическая поддержка внедрения цифровых сервисов и отраслевая система информационной безопасности. Среди целевых показателей — цифровые клинические рекомендации по ряду направлений, развитие телемедицинских консультаций и формирование счетов в ГИС ОМС на основе структурированных электронных медицинских документов.[2]

Социальная сфера движется по схожей логике централизации. Минтруд указывает, что с 1 января 2024 года ЕГИССО является подсистемой единой цифровой платформы в социальной сфере, а СФР ведет раздел правового регулирования ЕГИССО ГИС ЕЦП с федеральным законом о государственной социальной помощи, постановлением о ГИС «Единая централизованная цифровая платформа в социальной сфере» и регламентами информационного взаимодействия.[3][4]

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

AI-архитектура здесь нужна не вместо ЕГИСЗ, МИС или ЕГИССО. Она нужна как слой управляемости поверх них.

Где большие языковые модели действительно полезны

В отрасли есть соблазн начинать с наиболее заметных медицинских сценариев: диагностики, лечения, интерпретации снимков, прогноза рисков. Но для больших языковых моделей это не самая зрелая стартовая зона. Регулируемый медицинский ИИ, особенно если он является медицинским изделием, попадает в отдельный контур контроля. Росздравнадзор указывает, что медицинские изделия подлежат государственной регистрации, а программное обеспечение с применением ИИ, являющееся медицинским изделием, имеет специальные правила внесения изменений в регистрационное досье и передачи информации о функционировании.[5][6]

Для больших языковых моделей в медицинской и социальной отрасли более рациональная стартовая зона — немедицинские, сервисные и управленческие процессы. Эта логика совпадает с позицией Минздрава: в 2026 году министр отдельно отметил, что сфера применения ИИ не ограничивается диагностикой и лечением, а должна включать интеллектуальное формирование расписаний, голосовой ввод и расшифровку протоколов, чат-боты для маршрутизации обращений пациентов.[7]

Практически это означает несколько групп сценариев.

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

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

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

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

Пятая — разработка и сопровождение ИС. В МИС, ЛИС, РИС, социальных реестрах и ведомственных порталах накоплены устаревшие модули, интеграции, скрипты запросов к базам данных, отчеты и ручные обходные процедуры. Большая языковая модель помогает разработчикам анализировать код, писать тесты, готовить документацию, проводить рефакторинг и быстрее переводить Excel-сводки в управляемые модули.

Данные отрасли: чувствительные, фрагментированные, неравномерные

В здравоохранении данные имеют несколько уровней чувствительности: медицинская тайна, персональные данные, электронная медицинская документация, сведения о диагнозе, обследовании и лечении, данные о медработниках, ресурсах, оборудовании, расписаниях, закупках, ОМС, обращениях. 323-ФЗ относит сведения о факте обращения за медицинской помощью, состоянии здоровья, диагнозе и данные, полученные при обследовании и лечении, к врачебной тайне.[8]

В социальной сфере чувствительность не ниже: меры поддержки, выплаты, инвалидность, семья, доходы, занятость, жизненные обстоятельства, льготный статус, сведения о детях, пожилых гражданах, ветеранах, гражданах с инвалидностью. Социальное казначейство усиливает эффект централизации: по данным Правительства, все федеральные меры были переведены в формат социального казначейства, а СФР оказывает более 320 млн услуг в год, из которых 95% — в электронном виде.[9]

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

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

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

Шлюз доступа к большим языковым моделям: шлюз между отраслью и моделью

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

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

В международной практике риски больших языковых моделей уже описаны достаточно конкретно. OWASP выделяет для приложений на базе больших языковых моделей внедрение вредоносных инструкций в запрос, раскрытие чувствительной информации, небезопасный дизайн подключаемых инструментов и другие классы угроз.[10][11] Рамка NIST по управлению рисками ИИ предлагает управлять рисками ИИ через функции Govern, Map, Measure, Manage, а профиль для генеративного ИИ помогает отдельно рассматривать риски генеративных систем.[12][13] ISO/IEC 42001 описывает систему менеджмента ИИ как способ управлять рисками и возможностями систем ИИ.[14]

Для российского здравоохранения и социальной сферы это нужно перевести на язык контуров.

Для государственных и муниципальных систем нужно учитывать не только 152-ФЗ о персональных данных и медицинскую тайну, но и требования к защите информации в ГИС и иных ИС госорганов и учреждений. ФСТЭК в 2025 году утвердила новые требования №117 для ГИС и иных ИС государственных органов, ГУП и государственных учреждений; с 1 марта 2026 года они вступили в силу.[15][16] Для ИСПДн применяются требования по мерам защиты персональных данных, утвержденные приказом ФСТЭК №21, а для значимых объектов КИИ — требования приказа №239.[17][18]

Старые системы: не заменить, а постепенно вывести из критической зависимости

В здравоохранении старый ИТ-контур проявляется не только в старом коде. Это устаревшие МИС-модули, локальные интеграции с лабораториями, PACS/РИС, ручные выгрузки из ЛИС, разные справочники, несогласованные роли, устаревшие СЭД, контакт-центр без нормальной аналитики, Excel-реестры, бумажные обходные процедуры.

В социальной сфере старый ИТ-контур часто живет в региональных реестрах, ведомственных порталах, устаревших системах учета, таблицах льготников, ручной маршрутизации обращений, локальных файлах по выплатам и межведомственных сверках.

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

Метаплатформа решает эту задачу поэтапно: описывает процесс и источники данных; фиксирует владельца и правила изменения; создает управляемый модуль вместо Excel или ручной сверки; дает программные интерфейсы для интеграции с МИС, СЭД, ЕГИСЗ, ЕГИССО, контакт-центром и порталом; подключает большие языковые модели только как интерфейс анализа, поиска, черновика или подсказки; оставляет юридически значимое действие в профильной системе и у ответственного специалиста.

Такой подход снижает риск «большого взрыва» при модернизации. Руководитель не ждет многолетней замены МИС или социальной системы целиком, а выводит из ручного режима конкретные процессы: расписания, обращения, закупочные сводки, кадровое планирование, отчеты, реестры, внутренние заявки.

Отраслевая таблица решений

Кому это дает эффект

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

Для государства — это управляемость федеральных и региональных программ, сопоставимость данных, контроль сроков, снижение ручной отчетности, прозрачность обращений и возможность видеть системные проблемы раньше, чем они становятся публичным кризисом. Национальный проект «Экономика данных и цифровая трансформация государства» прямо ориентирован на цифровую трансформацию государственного и муниципального управления, экономики и социальной сферы.[19]

Для региона или ведомства — это шанс модернизировать не все сразу, а критические узкие места: обращения, расписания, сводки, реестры, кадровое планирование, маршрутизацию, закупки, контроль исполнения. ГосТех и ГосОблако важны здесь как государственные платформенные контуры: Минцифры описывает ГосТех как облачное платформенное решение для федеральных и региональных органов власти, а ГосОблако с 2025 года функционирует вне рамок эксперимента.[20][21]

Для конечного пользователя услуги — пациента, получателя меры поддержки, родственника, заявителя — ценность не в том, что он разговаривает с «умным ботом». Ценность в том, что его обращение не теряется, маршрут понятнее, сроки прозрачнее, документы не запрашиваются повторно, специалист быстрее видит контекст, а ответ становится точнее.

Жесткая граница: что нельзя отдавать большим языковым моделям

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

Большая языковая модель не должна самостоятельно:

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

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

Опыт с медицинским ПО на базе ИИ показывает, почему контроль важен. Росздравнадзор в 2023 году сообщал о зарегистрированных медицинских изделиях с ИИ и указывал, что такое ПО подлежит пострегистрационному мониторингу безопасности и клинической эффективности; в одном из случаев служба выявила отклонения в характеристиках и приостановила применение решения из-за угрозы причинения вреда.[22]

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

Что делать руководителю в ближайшие 90 дней

1. Утвердить карту допустимых и запрещенных сценариев применения ИИ. Разделить процессы на административные, аналитические, медицинские, социально-правовые и критичные.
2. Провести инвентаризацию данных. Отдельно выделить медицинскую тайну, ПДн, социальные сведения, кадровые данные, обезличенные управленческие данные, регламенты и открытые материалы.
3. Найти 5–7 ручных процессов с быстрым эффектом. Обращения, проекты ответов, поиск по регламентам, внутренние заявки, Excel-сводки, кадровые расписания, подготовка отчетности.
4. Спроектировать шлюз доступа к большим языковым моделям. Определить политики доступа, журналирование, контуры обработки, маскирование, допустимые модели, корпус проверенных источников для ответов модели и правила ручной проверки.
5. Назначить владельцев сценариев применения ИИ. У каждого сценария должен быть владелец процесса, владелец данных, ИБ-ответственный, эксперт-проверяющий и метрика результата.
6. Выбрать контур пилота. Для первых сценариев предпочтительны закрытые административные процессы без клинических решений и без автоматического влияния на права граждан.
7. Перевести один Excel-контур в управляемый модуль. Не обсуждать цифровую зрелость вообще, а убрать конкретную зависимость от конкретной таблицы.
8. Ввести журнал решений ИИ. Фиксировать запрос, источник данных, ответ модели, проверяющего специалиста, итоговое действие и причину отклонения, если результат не принят.

Метрики успеха

Риски и ограничения

Заключение

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

Но именно поэтому большие языковые модели и метаплатформы нельзя игнорировать. В этих отраслях слишком много ручного труда, повторяющихся документов, фрагментированных справочников, устаревших модулей, Excel-сводок, обращений, межведомственных сверок и административной нагрузки. Если оставить все как есть, цифровизация будет продолжать наращивать электронный слой поверх старой организационной логики. Документ станет электронным, но процесс останется ручным. Реестр станет федеральным, но региональная сводка будет собираться в таблице. Сервис появится на портале, но специалист все равно будет искать регламент в переписке.

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

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

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