Чат-бот для клиники по своей природе работает с персональными данными. Чтобы записать пациента, ему нужны ФИО, телефон, иногда дата рождения. А чтобы понять запрос и поддержать разговор, бот отправляет диалог в большую языковую модель — как правило, иностранную. Получается прямой конфликт: данные, которые закон защищает, утекают в чужой сервис за пределами страны.
Когда мы делали первого бота для клиники, этот вопрос встал ребром. Ниже — как мы его решили и почему теперь это стандарт всего парка.
Почему «просто отправить диалог в LLM» не работает
Соблазнительно сделать в лоб: берём весь диалог, шлём в модель, получаем ответ. На прототипе так и было. Но как только бот начинает собирать данные для записи, в этот самый диалог попадают ФИО и телефон пациента — и улетают в нейросеть вместе с остальным текстом. С точки зрения 152-ФЗ это передача персональных данных третьему лицу, да ещё и трансграничная.
Закрыть глаза и «как-нибудь потом разберёмся» — не наш вариант: боты работают на реальных клиниках, а не на демо. Значит, защита должна быть встроена в саму технологию, а не дописана сбоку.
Решение 1: маскирование перед моделью
Главный приём — нейросеть не видит персональных данных вообще. Никогда.
Перед тем как отправить сообщение в модель, бот прогоняет его через маскирование. ФИО превращается в токен {ФИО}, телефон — в {ТЕЛ}, дата рождения — в {ДР}. Сюда же попадает имя из профиля ВКонтакте: даже его модель видит как {ИМЯ}, а не как реального человека. Оригиналы хранятся отдельно, в служебном состоянии диалога, с коротким временем жизни — порядка часа, после чего стираются.
Модель работает с обезличенным текстом: «Запишите {ФИО}, телефон {ТЕЛ}, на четверг». Она прекрасно понимает структуру запроса — ей не нужно знать, что пациента зовут Иван Петров. Когда бот формирует ответ клиенту, токены подставляются обратно, и человек видит нормальный текст с его именем.
Получается, что персональные данные живут только там, где они действительно нужны: в диалоге с клиентом и в карточке для менеджера. В нейросеть и в журналы они не попадают.
Решение 2: исходящий трафик через свой прокси
Маскирование закрывает содержимое сообщений. Но есть ещё технический слой: сам факт обращения к иностранному API. Поэтому весь исходящий трафик к внешним сервисам — и к нейросети, и к мессенджерам — идёт через наш собственный прокси на сервере в России. Это даёт контролируемую точку выхода: мы знаем, что именно и куда уходит, и можем за этим следить.
Решение 3: запись только после подтверждения человеком
Второй принцип безопасности касается не данных, а действий. Бот никогда не создаёт запись в системе клиента сам. Мы называем это «сначала человек подтверждает, потом бот записывает».
Работает так. Бот собирает заявку: с кем хочет записаться пациент, на какую дату, нужные данные. Когда заявка готова, менеджеру в Telegram приходит карточка с кнопками «Подтвердить» и «Отменить». В этой карточке менеджер видит реальные данные — они ему нужны, чтобы оформить запись. Жмёт «Подтвердить» — и только тогда через переходник создаётся запись в CRM. Жмёт «Отменить» — бот возвращается к диалогу.
Зачем так, если можно автоматически? Затем, что языковая модель иногда ошибается — неверно поймёт дату, перепутает врача. Если бот пишет в CRM сам, ошибка модели становится кривой записью у клиента. Менеджер с кнопкой — это дешёвый и надёжный страховочный слой. А если CRM у клиента вообще нет, заявка просто уходит менеджеру, и он оформляет её руками. Клиент в любом случае получает ответ.
Согласие и контроль доступа
Для сценариев, где это требуется, в бота встроен механизм согласия на обработку персональных данных со ссылкой на политику конфиденциальности — он включается настройкой, без переписывания логики. Доступ к данным разграничен: оператор клиники видит то, что нужно для записи; нейросеть не видит ничего; в журналах хранится обезличенная история диалогов для аналитики.
Отдельно стоит сказать про то, чего клиент не получает: доступа к нашей внутренней кухне. Боты работают на нашей инфраструктуре как услуга. Клиент пользуется результатом — записями, отчётами, диалогами, — но не получает доступа к панели управления воркфлоу. Это и удобнее для клиента, и чище с точки зрения ответственности за данные.
Почему это важно
ФЗ-152 для многих звучит как бюрократия, но за ним стоит понятная вещь: данные пациента или клиента не должны бесконтрольно гулять по чужим серверам. Когда мы предлагаем клинике бота, первый вопрос её руководителя — «а это вообще законно, отправлять данные пациентов в нейросеть?». Правильный ответ: данные пациентов в нейросеть не отправляются. Никогда. Это встроено в технологию, а не обещано на словах.
Маскирование, прокси на территории России, подтверждение человеком и разграничение доступа — четыре слоя, которые работают вместе. Любой из них по отдельности — полумера; вместе они дают бота, которого не стыдно поставить в медцентр.
Если вам нужен ассистент, который собирает заявки и при этом не создаёт проблем с законом о персональных данных, — расскажите про задачу. Эта защита идёт в каждом нашем боте по умолчанию.