Разговоры про ИИ давно перестали быть чем-то необычным: LLM внедряют везде — от банков до ритейла. Здравоохранение не стало исключением. Но если в e-commerce ошибки алгоритма могут повлиять исключительно на конверсию, то в медицине уровень ответственности совсем другой. Поэтому процесс запуска ИИ-инструментов, способных отвечать на вопросы, связанные со здоровьем, требует особого подхода и тщательной проработки многих аспектов. 

Привет, Хабр. Меня зовут Орлан. Я ведущий специалист по обеспечению безопасности данных в команде медицинской компании СберЗдоровье. В этой статье я расскажу, как мы запускали AI-помощника по здоровью в мобильном приложении, с какими вызовами столкнулись и какие решения в итоге сработали — с точки зрения комплаенса, защиты данных и безопасности пациента.

Что такое AI-помощник?

Сперва немного контекста. СберЗдоровье — MedTech-компания №1 в России, которая предоставляет востребованные медицинские услуги: онлайн-консультации врачей, дистанционный мониторинг пациентов, запись на очный приём, анализы и обследования.

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

В основе создания AI-помощника — модель GigaChat PRO MAX, обученная на больших массивах медицинских данных. Нейросеть, обладая релевантной экспертизой по ряду специальностей, успешно сдала экзамены введущих медицинских вузов России.

Важно понимать, что наш AI-помощник не заменяет врача, не используется для постановки диагнозов или назначения лечения. Именно поэтому мы строго ограничили его роль двумя навыками.

Формирование предварительного плана действий для пациента. 

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

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

Ответы на вопросы о здоровье и ЗОЖ простым языком. 

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

Важно: в любом из сценариев мы подчеркиваем, что AI-помощник — это рекомендательный инструмент, а не «онлайн-врач».

Хочешь узнать, с какими вызовами мы ещё сталкиваемся и как их решаем? Заходи в наш ТГ-канал SberHealth IT ;)

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

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

• с одной стороны — российское законодательство: о персональных данных, об информации, медицинской деятельности и безопасности информации;

• с другой — передовые подходы к регулированию ИИ и защите данных, в том числе организационные, технические, этические.

Поскольку эти вопросы для нас являются приоритетными, мы разбили комплаенс-требования на три группы. 

1) Персональные данные

Тут классика, но со спецификой обработки чувствительных данных. Так, важны:

• законность и прозрачность обработки;

• ограничение обработки целью и сроками;

• минимизация данных;

• обеспечение конфиденциальности и безопасности (УЗ не ниже 3);

• получение письменного согласия на обработку данных.

  2) Высокорисковые ИИ-системы

Здесь уже фокус не только на данных, но и на пациенте. Требуется:

• недопущение сценариев, когда ошибка ИИ может привести к вреду здоровью;

• управление рисками при дообучении моделей;

• учет повышенных требований к архитектуре, логированию, аудиту.

  3) Кибербезопасность ИИ-системы

Важно учитывать, что ИИ сам по себе — источник новых уязвимостей, среди которых:

• галлюцинации и некорректные медицинские выводы;

• data poisoning и «заражение» модели персональными данными;

• утечки информации через ответы модели;

• использование публичных моделей, обученных на чувствительных данных и другие. 

Целевой паттерн обработки данных: какие требования мы заложили на этапе проектирования

До разработки мы сформировали целевой паттерн обработки данных — по сути, чек-лист требований к системе. Выделю основные из них:

Письменное согласие пациента. Нам нужно получать согласие пациента, подписанное электронной подписью.

Минимизация обработки. Важно применять временные (со сроком жизни) идентификаторы вместо реальных персональных данных и исключить долгосрочное хранение диалогов там, где это неоправданно.

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

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

Сам факт, что мы зафиксировали такой паттерн на старте, сильно упростил диалог с бизнесом.

Вызовы, с которыми мы столкнулись

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

Письменное согласие – это сложно и дорого

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

• разработки интерфейсов и бэкенда;

• интеграции с сервисами подписания;

• подготовки юридически корректного текста согласия;

• организации безопасного хранения и учёта согласий.

Это требует существенных затрат на разработку и вовлечения специалистов из смежных команд. При этом классический сценарий подтверждения согласия через SMS снижает конверсию.

Чтобы сбалансировать регуляторные требования и пользовательский опыт, мы:

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

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

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

Пациент может ввести всё, что угодно

Формально мы делаем всё правильно:

• используем идентификаторы со «сроком жизни»;

• не требуем вводить ФИО, паспортные данные и другую чувствительную информацию.

Вместе с этим, по факту пациент не ограничен в том, что может писать AI-помощнику, поэтому может сам ввести любые данные, в том числе ФИО, дату рождения, адрес и другую информацию.

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

Чтобы избежать этих проблем и преодолеть вызов, мы:

• чётко разделили контур выдачи ответов и контур обучения;

• обучаем модель на очищенных, доменно-специфичных данных, без ПДн;

• добавили обязательный слой фильтрации и сопоставления: система проверяет ввод пользователя, а где возможно — сопоставляет с референтными данными и отсекает/маскирует чувствительное (в обучающий контур данные попадают только после деперсонализации).

Безусловно, это дороже и сложнее, чем просто «слить персональные данные в обучение», но иначе говорить о конфиденциальности ПДн всерьёз нельзя, а для нас это критически важно.

Публичные модели vs on-prem

Бизнес мог бы рассматривать публичные LLM как способ быстрее и экономичнее запускать решения без необходимости разворачивать и поддерживать собственную тяжёлую инфраструктуру. Но это проблематично и сопряжено с рисками:

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

• при использовании публичных LLM сложно контролировать, где и как используются данные;

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

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

Да, on-prem дороже. Но мы не можем рисковать. Тем более, если посчитать стоимость юридических и репутационных рисков, рентабельность такой архитектуры становится куда более очевидной.

Дилемма качества и безопасности

Мы настроили жесткие политики безопасности, в том числе:

• агрессивные фильтры по медицинским утверждениям;

• запреты на формулировки, похожие на диагноз;

• блокировку потенциально опасных рекомендаций.

Но в результате на тестах мы начали фиксировать:

• высокий процент отказов («обратитесь к врачу», «я не могу ответить»);

• попытки модели иногда всё равно принять решение и фактически сформулировать диагноз;

• классические галлюцинации, когда ИИ говорит уверенно, но неверно.

Для исправления этой ситуации мы решили сместить фокус на «критичные политики», а не на тотальный запрет. При этом оставили возможность давать полезные, но аккуратно сформулированные рекомендации.

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

• применяем явные дисклеймеры, что AI-помощник не ставит диагноз и не заменяет врача;

• делаем акцент на том, что это рекомендательный инструмент, а не медицинское заключение.

Задача не в том, чтобы «задушить» систему до полной бесполезности, а в том, чтобы держать рабочий баланс между пользой и безопасностью.

Итоги и рекомендации на основе нашего опыта

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

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

Начните с архитектуры и данных, а не с модели. Проведите инвентаризацию данных. Поймите, где именно и какие данные обрабатываются. Разведите контуры инференса и обучения.

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

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

Будьте честны насчёт ИИ и его роли. Не называйте рекомендательный ИИ «диагностическим и лечебным инструментом» и не позволяйте системе ставить диагнозы, назначать терапию. Обеспечьте достаточное информирование пациента о том, кто и как генерирует ответы.

Закладывайте on-prem-архитектуру, если работаете с чувствительными данными. Это дороже, но даёт управляемость, юридическую защиту и возможность развития надёжного продукта.

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

А каких паттернов при запуске AI-помощников придерживаетесь вы в своей сфере? Что можете посоветовать, исходя из своего опыта? Делитесь в комментариях!