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

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

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

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

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

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

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

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

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

Такому контуру можно поручить:

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

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

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

Безопасные примеры:

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

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

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

Кандидат — не пациент. Его данные и переписка не должны находиться в одном рабочем контуре с обращениями клиники.

ИИ может принять анкету, проверить заполнение полей, ответить по утверждённой памятке, согласовать время разговора, структурировать резюме для рекрутера и помочь новому сотруднику найти внутреннюю инструкцию.

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

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

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

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

Закон №152-ФЗ требует ограничивать обработку конкретными, заранее определёнными и законными целями. Объём данных должен соответствовать цели и не быть избыточным.

До интеграции нужно письменно ответить:

При сборе данных граждан России через интернет отдельно проверяются требования части 5 статьи 18 закона №152-ФЗ к использованию баз данных на территории России. Подключение внешнего облачного сервиса — не просто настройка: сначала проверяются договор, архитектура, место обработки и меры защиты.

ИИ не должен отвечать из «всего интернета» там, где клиника ждёт точности. Для каждой воронки нужен ограниченный пакет: расписание, контакты, правила записи, шаблоны сообщений, этапы найма и стоп-темы.

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

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

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

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

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

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

Ясная граница позволяет поручить автоматизации безопасную рутину и не маскировать риск словами «модель обычно отвечает правильно».

Статья 19 закона №152-ФЗ требует правовых, организационных и технических мер защиты. Постановление Правительства №1119 связывает требования к защищённости системы, в частности, с категорией данных, актуальными угрозами и масштабом обработки.

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

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

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

Хорошая AI-воронка убирает повторяемую работу и точно показывает момент, когда ответственность должен принять сотрудник.

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

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