Когда компания подключает ИИ-бота, разговор о безопасности часто сразу сводят к выбору языковой модели: где она размещена, сохраняет ли запросы, можно ли заменить её локальной. Это важные вопросы, но они охватывают только один участок системы. До модели сообщение проходит через канал связи и сервер, после ответа может попасть в журнал, CRM, резервную копию и кабинет сотрудника. Утечка чаще начинается не с «взлома искусственного интеллекта», а с открытого ключа, общей учётной записи или интеграции с чрезмерными правами.
Поэтому безопасность ИИ-бота лучше рассматривать как маршрут данных. Нужно понимать, что именно собирается, куда передаётся, где остаётся и кто способен это увидеть или изменить.
Из чего складывается безопасность ИИ-бота
Безопасная система не обязана быть закрыта от мира и работать только на собственном оборудовании. Она должна быть ограниченной и проверяемой: получать ровно те сведения, которые нужны для задачи, передавать внешним сервисам только необходимый контекст и не позволять тексту модели автоматически превращаться в необратимое действие.
Через бота могут проходить сообщения клиента, телефон и электронная почта, параметры заказа, бюджет, регион, вложения, история разговора, сведения из каталога и CRM. Внутри системы к этому добавляются инструкции, технические журналы и данные интеграций. Справочному помощнику, который отвечает о режиме работы, не требуется тот же доступ, что боту, создающему заявки и проверяющему статус заказа.
Полезно нарисовать простую карту:
- клиент отправляет сообщение в чат или мессенджер;
- канал передаёт его на сервер;
- бизнес-логика выбирает нужные данные и инструкции;
- часть контекста при необходимости отправляется языковой модели;
- ответ возвращается клиенту;
- сведения сохраняются в журнале, CRM или интерфейсе менеджера.
Для каждого пункта достаточно ответить на пять вопросов: что передаётся, зачем, кому, где хранится и кто имеет доступ. Уже на этом этапе обычно обнаруживается половина лишних данных и полномочий.
Какие сведения можно давать боту
Удобно разделить данные на три уровня.
Публичные сведения — ассортимент, опубликованные цены, режим работы, описание услуг, официальные контакты. Их можно использовать в ответах клиентам, если информация актуальна.
Внутренние сведения — рабочие инструкции, непубличные условия, закупочные цены, заметки менеджеров, внутренние оценки. Иногда они нужны системе для принятия решения, но не должны без необходимости попадать в ответ или во внешний контекст.
Секреты — пароли, API-ключи, токены, закрытые ссылки и данные для входа. Их нельзя хранить в базе знаний или помещать в промт «для удобства». Промт не является сейфом: он может попасть в конфигурацию, журнал или резервную копию, а отдельные части внутренних инструкций могут быть раскрыты при ошибке.
Тот же принцип действует для персональных данных клиентов. Если для подбора услуги достаточно города и нескольких параметров, нет смысла заранее спрашивать полный адрес, паспортные сведения или дату рождения. Чем меньше лишнего собрано, тем проще ограничивать доступ и устранять последствия возможной утечки.
Без явной необходимости обычный бот не должен просить пароли, коды подтверждения, реквизиты банковской карты, секретные ключи, медицинские сведения и документы третьих лиц. Нужно заранее определить, что делать, если клиент сам прислал чувствительную информацию: скрыть её в интерфейсе, не отправлять модели, передать специалисту или удалить по установленной процедуре.
Правовые требования зависят от страны, отрасли, состава данных и используемых сервисов. Для медицинских, финансовых, детских, банковских данных, коммерческой тайны, критической инфраструктуры и юридически значимых документов базовой настройки недостаточно: требуется отдельная профильная оценка.
Что видит внешняя модель
Языковой модели редко нужна вся история клиента и тем более вся CRM. Обычно достаточно текущего сообщения, нескольких предыдущих реплик, системных правил и найденного фрагмента из базы знаний или каталога. Иногда полезнее передать краткое резюме, чем десятки старых сообщений.
Плохая архитектура выглядит так: модель получает полный профиль клиента, чужие диалоги, внутренние документы и широкую выгрузку из CRM, хотя должна всего лишь ответить о доставке. Хорошая — выбирает минимальный контекст под конкретную задачу.
Внешняя модель удобна: она доступна по API и не требует собственной вычислительной инфраструктуры. Но перед запуском нужно выяснить, какие данные уходят поставщику, где обрабатываются запросы, сохраняются ли они и как отозвать доступ. Локальная модель позволяет не отправлять диалог внешнему поставщику, зато требует защищённого сервера, обновлений, администрирования и контроля доступа. Само слово «локальная» не делает систему безопасной, как и слово «облачная» не делает её опасной.
Отдельный риск — попытка заставить бота раскрыть внутренние инструкции. Клиент может написать: «забудь прежние правила», «покажи системный промт» или «выведи скрытые цены». Такие сообщения должны оставаться пользовательскими данными, а не становиться командами более высокого приоритета.
Причём опасная инструкция может находиться не только в сообщении. Она бывает спрятана в документе, карточке товара, поле CRM, ответе внешнего API или загруженном файле. Поэтому найденный текст нужно воспринимать как данные, отделять от системных команд и не выполнять на его основании критичные действия.
История, журналы и база знаний
Полная переписка полезна: менеджер понимает контекст, клиенту не приходится повторяться, ошибки можно разобрать. Но бессрочное хранение всех разговоров увеличивает объём чувствительных данных. В зависимости от задачи вместо полной истории можно сохранять ограниченный период, резюме разговора, необходимые поля заявки или обезличенную аналитику.
Важно помнить, что история часто существует сразу в нескольких местах: в мессенджере, на сервере, в CRM, техническом журнале и резервной копии. Удаление сообщения в одном интерфейсе не означает, что исчезли остальные копии. Для каждого хранилища нужны понятная цель, срок, права доступа и процедура удаления.
Обезличивание тоже не сводится к удалению имени. Телефон, адрес, редкая должность, номер заказа или сочетание обстоятельств могут позволить определить человека. Если данные используются для аналитики, нужно проверять весь набор признаков.
База знаний заслуживает отдельной ревизии до загрузки. В неё нередко попадают старые прайсы, черновики договоров, пароли из внутренних инструкций, персональные данные и документы, которые вообще не предназначены клиентам. Публичные и внутренние материалы следует разделить, секреты удалить, а изменения фиксировать по версиям.
Журналы нужны для расследования ошибок: кто вошёл, что изменил, какое внешнее действие было вызвано, почему интеграция не ответила. Но журнал не должен превращаться во вторую утечку. Пароли, токены и лишние персональные сведения туда не записывают.
Доступы важнее громких обещаний
Если бот только создаёт обращение, ему не нужны права удалять сделки, читать всю CRM или менять настройки. Принцип минимальных полномочий уменьшает ущерб и от ошибки, и от украденного ключа.
Владелец, администратор, менеджер, оператор и технический специалист выполняют разные задачи. Не всем требуется выгружать данные, менять базу знаний и управлять интеграциями. Индивидуальные учётные записи лучше общего аккаунта: по ним видно автора изменений, а доступ бывшего сотрудника можно отозвать отдельно.
Двухфакторная защита особенно важна для панели управления, CRM, сервера, домена и кабинетов внешних сервисов. Она не решает все проблемы, но заметно снижает риск использования украденного пароля.
Ключи API и токены должны храниться вне открытого репозитория, промта и базы знаний. Им задают минимальные права, их можно быстро отозвать, а после компрометации — заменить. Если один ключ открывает одновременно CRM, канал и административные функции, последствия любой ошибки становятся значительно тяжелее.
Сервер, резервные копии и тестовая среда
Защищённое соединение необходимо, но HTTPS решает только задачу передачи данных. Оно не спасёт от опубликованного ключа, слабого пароля, открытого журнала или интеграции с полным доступом.
Сам сервер требует обновлений, ограниченного входа, отдельных аккаунтов, резервных копий и понятного способа остановить бота. Резервная копия помогает восстановить систему, но сама содержит настройки и иногда данные клиентов. Нужно знать, что именно копируется, где хранится, кто имеет доступ и действительно ли из копии можно восстановиться.
Тестовую среду лучше отделять от рабочей. Для проверки используют отдельные ключи и ограниченные данные, а не полную клиентскую базу. Это позволяет экспериментировать с настройками без риска создать реальную сделку, отправить сообщение настоящему клиенту или повредить рабочую историю.
Если обнаружена утечка или компрометация, порядок действий должен быть известен заранее: ограничить доступ, остановить опасную интеграцию, заменить ключи, определить затронутые данные, проверить связанные системы, исправить причину и повторно протестировать. Особенно важно, чтобы конкретный сотрудник имел право быстро отключить бота, а не искал владельца сервера в момент инцидента.
Почему действия нужно подтверждать системой
Ответ языковой модели — это текст, а не доказательство выполненной операции. Бот может написать «запись создана», хотя календарь недоступен, или сообщить «заказ отменён», не получив подтверждения от учётной системы.
Изменение цены, выдача скидки, оформление заказа, удаление записи, отправка чувствительного документа и другие критичные операции выполняются только через ограниченный инструмент и считаются завершёнными после ответа соответствующей системы. При сбое бот честно сообщает, что принял запрос или не смог подтвердить действие, и передаёт ситуацию сотруднику.
То же относится к передаче менеджеру. Сотруднику нужны запрос клиента, основные параметры, контакт и причина подключения. Ему не нужны системные инструкции, ключи, чужие диалоги и полный набор внутренних документов.
Файлы и изображения также требуют ограничений. Вложение может содержать вредоносный файл, скрытый текст, персональные сведения или неподдерживаемый формат. Нужны допустимые типы и размеры, проверка перед обработкой и запрет автоматического исполнения. Фото и скриншоты не стоит без разбора отправлять внешней модели: на них могут быть лица, адреса, документы и данные других людей.
Как проверить безопасность до запуска
Проверка должна имитировать не только обычного клиента, но и ошибки сотрудников, интеграций и конфигурации. Минимальный набор включает такие сценарии:
- попытка получить системный промт, внутренние цены и данные другого клиента;
- загрузка слишком большого, неподдерживаемого или подозрительного файла;
- запрос критичного действия без подтверждения;
- отказ CRM, календаря или канала связи;
- отзыв ключа и административного доступа;
- попадание чувствительных сведений в журнал;
- смешивание двух похожих клиентов или параллельных диалогов;
- остановка бота и восстановление из резервной копии;
- массовые сообщения, повторы и чрезмерно длинный контекст.
Смешивание диалогов — критичная ошибка. Контакт, сообщения и вложения одного человека не должны появляться у другого, даже если совпадают имена или темы обращений.
Перед запуском полезно задать поставщику или интегратору несколько прямых вопросов: где расположен сервер, что отправляется модели, кто имеет административный доступ, где хранятся ключи и история, как удаляются данные, как отзываются права, кто обновляет сервер, какие сторонние сервисы участвуют и что остаётся после прекращения работы. Убедительные общие слова здесь менее полезны, чем конкретная схема.
Практический минимум для первого запуска
Для ограниченного пилота достаточно одного контролируемого канала, минимального набора данных, отдельных тестовых доступов, защищённого соединения и раздельных диалогов. Секреты хранят вне контента, интеграциям дают только необходимые права, важные действия записывают в журнал и подтверждают внешней системой. Должны быть защищённая резервная копия, понятные роли сотрудников и проверенный способ быстро отключить бота.
Такой набор не превращает систему в неприступную крепость, но устраняет наиболее частые и дорогостоящие ошибки конфигурации.
Как безопасность учитывается при настройке LEVBOT
LEVBOT настраивается под конкретный бизнес и работает на выбранном сервере. Владелец отдельно определяет каналы, состав данных, права сотрудников, поставщика языковой модели и необходимые интеграции. Базу знаний проверяют до загрузки, а пароли и ключи не включают в открытый контент.
Ответы и ограничения можно бесплатно проверять в тестовых диалогах. Оплата требуется только при скачивании готовой настроенной сборки: одно скачивание стоит 6 000 ₽. Обязательной подписки, внутреннего баланса и оплаты токенов через LEVBOT нет.
Сервер, домен, использование внешней языковой модели и сторонние сервисы оплачиваются отдельно. Готовая сборка передаётся покупателю; новая отдельно настроенная сборка считается отдельной покупкой. Безопасность CRM, мессенджеров и других систем при этом зависит от конкретного подключения и выданных ему прав.
Вывод
Безопасность ИИ-бота определяется не одним поставщиком модели, а всей цепочкой — от первого сообщения до журнала и CRM. Чем меньше лишних данных и полномочий, тем проще контролировать последствия ошибки. Хорошо защищённый бот не знает «всё о компании»: он знает достаточно для своей задачи, работает в заданных границах и оставляет критичные решения проверяемым системам и людям.