ИИ в клинике: безопасный пилот начинается с административного процесса

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

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

Выберите задачу с ясной границей

Хороший первый сценарий — ответы по утверждённым организационным материалам. Например, как добраться до филиала, какие документы взять, когда работает процедурный кабинет, как подготовиться к визиту согласно опубликованной памятке. Источником должен быть канонический документ клиники с владельцем, датой актуальности и понятным процессом обновления. AiHummer умеет извлекать фрагменты из базы знаний и возвращать ссылки на источники; в документации по знаниям и RAG отдельно сказано, что точность зависит от качества источников, индексации и модели.

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

Разделите информирование и изменение записи

Ответ по памятке — операция чтения. Перенос или отмена визита — изменение состояния. Для второго сценария нужны интеграция с МИС или CRM, подтверждённая личность, проверка доступных слотов, защита от повторного выполнения и журнал. Агент не должен принимать номер телефона или дату рождения как безусловное доказательство личности. Метод подтверждения выбирает клиника, исходя из риска и текущего клиентского процесса.

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

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

Минимизируйте данные

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

Секреты интеграций — токены МИС, почты или календаря — не должны путешествовать в промпте. AiHummer предоставляет защищённое хранилище секретов, но оператор всё равно отвечает за выдачу минимальных прав, ротацию, сетевой доступ и отзыв учётной записи. Для пилота лучше отдельная техническая учётная запись, доступная только к нужному филиалу и операциям.

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

Подготовьте ответы и эскалацию

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

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

Как измерять пилот без выдуманного ROI

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

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

Ограничения

AiHummer не делает клинику автоматически соответствующей требованиям о персональных данных и не определяет правовое основание обработки. Интеграция с МИС/CRM, каналы, инструменты, роли, подтверждение личности и эскалация требуют настройки. RAG снижает риск ответа «из головы», но не гарантирует правильность: источник может быть устаревшим, извлечение — неполным, модель — ошибиться. Гейт одобрения работает только для перечисленных инструментов. Голос добавляет внешнего оператора и, возможно, STT/TTS-провайдера в карту данных.

Чек-лист запуска

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

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