Где хранятся данные клиентов: серверы, 152-ФЗ и доступ — что должен ответить поставщик

База клиентов — ваш главный актив, а не настройка ассистента

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

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

«В облаке» — не ответ: страна серверов и рамка 152-ФЗ

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

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

Рядом стоит второй вопрос — 152-ФЗ. Закон о персональных данных отвечает на простое: как компания обращается с данными физических лиц. Имя, телефон, email, история — это персональные данные. Ведёте переписку с клиентами — вы уже оператор персональных данных, и требования конкретны: хранение на территории России, ограниченный доступ, обработка на основании согласия. Поставщик здесь должен быть не источником риска, а помощником: хранение в российском ДЦ, разграничение доступа и журналирование встроены в платформу, а не остаются задачей бизнеса. Услышали «это ваша зона ответственности, разбирайтесь сами» — второй красный флаг. Полный набор вопросов про данные до покупки мы собрали в разборе что спросить про данные до подключения ассистента.

Кто может открыть вашу переписку: роли в команде и доступ поставщика

Третий вопрос — кто конкретно видит данные. У него два уровня.

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

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

Что происходит с данными, когда вы расстаётесь с поставщиком

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

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

А если ассистент ошибётся: где проходит граница его ответственности

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

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

Три класса вопросов, которые всегда уходят человеку

Есть три темы, в которых ассистент не принимает решение в одиночку. Это не ограничение, а сознательная страховка.

• Платежи и финансовые операции. Ассистент расскажет о способах оплаты, тарифах, о том, как получить счёт. Но списать деньги, провести возврат, изменить статус оплаты — операции, которые требуют человека или проверки в финансовой системе. Автоматический ответ не должен превращаться в денежное действие без подтверждения.
• Юридически значимые ответы. Когда вопрос затрагивает обязательства, гарантии, спорные условия договора, отвечает тот, у кого есть полномочия. Ассистент сошлётся на оферту и публичные условия, но не «выдаёт обещание от лица компании» в неоднозначной ситуации.
• Медицинские, юридические и иные экспертные заключения. Если бизнес связан с медициной, правом, финансовым консалтингом, ассистент работает как навигатор по информации, а не как тот, кто ставит диагноз и решает за специалиста.

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

Передача человеку и лог диалогов: ошибка перестаёт быть невидимой

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

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

Интеграции без утечек: данные собираются, а не расползаются

Третий вопрос безопасности возникает при подключении к реальной работе: у бизнеса уже есть CRM, где ведутся клиенты, 1С с учётом, сайт с заявками, мессенджеры. Ассистент полезен настолько, насколько встроен в эту картину, — и тут появляется законная тревога: не расползётся ли база по чужим системам, не станет ли каждая интеграция новой дырой.

На практике зрелая интеграция работает наоборот — она наводит порядок. Заявка от клиента автоматически попадает в вашу CRM, на нужный этап воронки; цены и остатки ассистент берёт из 1С и отвечает по факту, а не «уточните у менеджера»; сайт отвечает через виджет по материалам компании; онлайн-запись и заявки не теряются в потоке — как это устроено, показываем в разборе записи и заявок через ассистента. Данные при этом передаются между клиентом, ассистентом и платформой по защищённым каналам, а на уровне базы действует разграничение по проектам: переписка одной компании не может случайно попасть в выдачу другой. Тот же принцип изоляции держит и сеть филиалов на одном ассистенте с раздельными данными каждого адреса. Главный эффект для безопасности: раньше переписка жила в личных мессенджерах сотрудников, случайных таблицах и почтовых ящиках — после подключения она консолидируется в одной управляемой системе с контролем доступа и понятным регламентом хранения.

Готовая интеграция против ручной сборки через API

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

Готовый коннектор — это уже собранная и сопровождаемая платформой конструкция: со стороны бизнеса остаётся указать систему и пройти короткую авторизацию. Обновления, совместимость и безопасность связки — забота платформы, а не вашего IT. В BOTIX базовый набор — CRM, AmoCRM, 1С, сайт, мессенджеры — уже в коробке; всего это 14 модулей и 24 канала в едином интерфейсе. Нестандартную внутреннюю систему при этом всё равно можно подключить через общий механизм — если у вас есть свой разработчик, ему пригодится технический разбор интеграции по API: multi-tenant, webhook и OAuth.

Восемь вопросов поставщику до договора — это 15 минут

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

1. Где физически находятся серверы — конкретная страна и регион.
2. Кто оператор персональных данных по 152-ФЗ — поставщик, вы или совместно.
3. Какие роли и права есть в системе — кто что видит внутри команды.
4. Кто из сотрудников поставщика имеет технический доступ к проекту.
5. Как фиксируются служебные доступы поставщика — есть ли журнал.
6. По каким каналам передаются данные между клиентом, ассистентом и платформой.
7. Что происходит с данными при удалении проекта — регламент и сроки.
8. Как долго живут резервные копии после удаления и как выводятся.

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

Как безопасно запустить ассистента — по шагам

Порядок простой и не требует программиста:

1. Проверьте поставщика по восьми вопросам выше — до договора, а не после. Уход хотя бы от одного пункта — повод не подписывать.
2. Загрузите базу знаний — услуги, цены-ориентиры, условия, ответы на типовые вопросы. Именно она задаёт границу, внутри которой ассистент отвечает уверенно.
3. Настройте роли доступа — владелец, администратор, сотрудник: каждый видит ровно то, что нужно для работы.
4. Пропишите правила передачи человеку — платежи, юридически значимое, экспертное и любые чувствительные темы уводите оператору.
5. Подключите свои системы — CRM, 1С, сайт, мессенджеры готовыми коннекторами, без самописных связок.
6. Проверьте в демо — задайте неудобные вопросы и посмотрите на лог: где ответил ассистент, где передал человеку, всё ли под контролем.

Зрелый поставщик отвечает спокойно, слабый обходит углы

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