Когда вы подключаете ИИ-агента к заявкам, CRM или базе документов, данные перестают жить в одном месте. Карточка клиента лежит в CRM, текст его сообщения уходит в модель, копия диалога остаётся в логах, а ответ — в Telegram. Обычно на вопрос «где хранятся наши данные?» подрядчик отвечает «в облаке», и на этом разговор заканчивается. В этой статье — как разложить автоматизацию на конкретные точки хранения, какие вопросы задать про регион и сроки, как построить карту доступов и что из этого можно проверить своими руками до запуска.
Юридическую часть — что требует закон Узбекистана о персональных данных после поправок 2026 года — мы разобрали в отдельной статье «Закон о персональных данных и ИИ-автоматизация». Здесь — техническая сторона: что именно и где физически лежит.
«В облаке» — это не ответ
Облако — это чужие серверы в конкретной стране, у конкретной компании, с конкретными людьми, у которых есть доступ. Чтобы оценить риск, нужно знать три вещи про каждую точку, где оказываются данные:
- Где: провайдер и регион (страна или группа стран), где лежат данные и где они обрабатываются. Это не всегда одно и то же: храниться данные могут в одном регионе, а модель может обрабатывать запрос в другом.
- Сколько: срок хранения и что происходит после него — удаление, архив, обезличивание.
- Кто: какие учётные записи имеют доступ, с какими правами, и кто их выдаёт и отзывает.
Если подрядчик не может ответить на эти три вопроса по каждой точке, значит, карту данных никто не рисовал. Это не обязательно злой умысел — чаще просто не дошли руки. Но запускать без неё не стоит.
Пять мест, где оказываются данные
Типичная автоматизация — например, агент, который отвечает на заявки в Telegram и заносит их в CRM — проводит данные через пять мест. Вот как выглядит карта на условном примере. Подставьте свои системы.
| Точка | Что там лежит | Где физически | Сколько хранится | Кто имеет доступ |
|---|---|---|---|---|
| Источник: CRM, таблица, 1С | Карточки клиентов, сделки, история | Облако вендора CRM или ваш сервер | Пока вы не удалите | Ваши сотрудники + сервисная учётка агента |
| Сервер интеграции (оркестратор) | Промежуточные данные, очереди, ключи доступа | Облачный сервер в выбранном регионе | Зависит от настройки: часто без ограничения, если не задать | Тот, кто администрирует сервер |
| Языковая модель (API) | Текст запроса и ответа | Дата-центры провайдера модели | По условиям провайдера, обычно ограниченный срок | Провайдер — в рамках своих правил |
| Логи и база знаний | Копии диалогов, фрагменты документов, векторный индекс | Там же, где сервер интеграции, или отдельная база | Часто бессрочно, если не настроить | Разработчики, иногда весь подрядчик |
| Канал общения: Telegram, WhatsApp, почта | Переписка с клиентом | Серверы мессенджера | По правилам мессенджера | Админы бота, менеджеры в чате |
Самая недооценённая строка — логи. Модель забыла запрос через свой срок, CRM защищена паролями и ролями, а в логах сервера за полгода лежат полные тексты всех диалогов с телефонами, и доступ к ним есть у любого, кто заходит на сервер отлаживать код.
Регион: что выбирать и что проверять
Регион — это первый вопрос, который задают юристы и крупные клиенты. На практике выбор складывается из трёх частей.
Сервер интеграции и базы
Здесь регион выбираете вы или подрядчик, явно, при создании сервера. Крупные облачные провайдеры дают выбор между странами Европы, США, Азии; локальные провайдеры дают размещение в Узбекистане. Если для части данных у вас есть требование хранить их внутри страны, логично держать базу с ними у локального провайдера или на своём сервере, а в облако отдавать только то, что нужно для конкретной операции.
Модель
С моделями сложнее: провайдер сам решает, в каком дата-центре обработать запрос. Некоторые провайдеры дают выбор региона для корпоративных клиентов. Например, OpenAI позволяет включить европейское размещение данных для нового проекта в API — для существующего проекта это сделать нельзя, это настройка при создании (объявление OpenAI). Условия меняются, поэтому проверяйте актуальную документацию провайдера на момент подписания, а не пересказ в блоге — включая этот.
Что проверить самостоятельно
- В панели облачного провайдера: в каком регионе стоит сервер и база — это видно в карточке ресурса.
- В аккаунте модели: на кого он зарегистрирован, какой регион у проекта, включены ли настройки хранения.
- В договоре: перечислены ли все сторонние сервисы (субподрядчики обработки) с указанием страны.
Сроки хранения: где данные остаются дольше, чем вы думаете
Провайдеры моделей, работающие через API, по умолчанию не используют данные корпоративных клиентов для обучения и хранят запросы ограниченное время — для контроля злоупотреблений. У OpenAI по умолчанию это до 30 дней, а режим без хранения (zero data retention) доступен по отдельному согласованию (документация OpenAI). У других провайдеров цифры свои — их стоит выписать в карту данных из первоисточника.
Но чаще проблема не в модели, а в вашей собственной обвязке. Вот что обычно хранится дольше нужного:
- Логи отладки. На этапе разработки пишут всё, потом забывают выключить.
- История диалогов для контекста. Агенту нужна память о последних сообщениях клиента, но не за три года.
- Загруженные документы. Договоры и прайсы для базы знаний остаются в хранилище после того, как их заменили новыми версиями.
- Резервные копии. Удалили запись из базы — а она живёт в бэкапах ещё долго.
Решение простое по сути: для каждой строки карты данных записать срок и настроить автоматическое удаление. Например: полные тексты диалогов — 90 дней, дальше остаётся только итог в CRM; логи — без персональных данных, телефоны и имена маскируются до записи. Цифры условные, подберите под свои процессы и требования.
Карта доступов: кто, к чему и с какими правами
Второй по важности вопрос — не где лежат данные, а кто может их открыть. Хорошая карта доступов умещается в одну таблицу.
| Учётная запись | Система | Права | Кто выдал и отзывает |
|---|---|---|---|
| Сервисная учётка агента | CRM | Создавать лиды, менять этап; не удалять, не выгружать базу | Ваш администратор CRM |
| Ключ API модели | Провайдер модели | Только вызов модели, отдельный проект на этот процесс | Владелец аккаунта — лучше вы, не подрядчик |
| Инженер подрядчика | Сервер интеграции | Именная учётка с двухфакторной защитой | Вы; отзыв при окончании работ |
| Менеджер отдела продаж | Чат с ботом, CRM | Как сейчас, без изменений | Руководитель отдела |
Три принципа, которые стоит закрепить:
- Аккаунты на вас. Облачный сервер, аккаунт модели, бот в Telegram регистрируются на вашу компанию. Подрядчику выдаётся доступ, а не наоборот. Иначе при расставании вы будете просить свои же данные.
- Минимальные права. Агенту, который записывает заявки, не нужно право выгрузить всю базу клиентов. Если CRM позволяет создать отдельную роль — создайте.
- Именные учётки, без общих паролей. Чтобы в журнале было видно, кто что делал, и чтобы отозвать доступ одного человека, не меняя пароль всем.
Разделение доступа по ролям и компаниям — часть того, как мы сами строили свою ERP на Supabase: несколько бизнесов в одной базе, но каждый видит своё за счёт правил на уровне строк. Подробности — в кейсе «ERP на четыре бизнеса».
Пошаговый план до запуска
- Нарисуйте путь одной заявки. От первого сообщения клиента до закрытой сделки: через какие системы проходит текст и какие поля. Это час работы с подрядчиком.
- Заполните карту данных. По таблице выше: точка, что лежит, регион, срок, доступ.
- Уберите лишнее. Модели для ответа «есть ли доставка в Самарканд» не нужен паспорт клиента. Передавайте в модель минимум полей.
- Задайте сроки и автоудаление. Для логов, истории диалогов и загруженных документов.
- Оформите аккаунты на компанию и выдайте подрядчику именной доступ.
- Зафиксируйте в договоре список сервисов, регионы, сроки и порядок удаления данных после окончания работ.
- Через месяц после запуска проверьте, что автоудаление работает и в логах нет телефонов. Настройки на бумаге и в коде расходятся чаще, чем кажется.
Если вы выбираете подрядчика, эти пункты удобно превратить в вопросы на первой встрече — список вопросов есть в статье «Как выбрать подрядчика по ИИ-автоматизации». Другие материалы о том, как проходит внедрение, — в разделе «Внедрение».
Частые вопросы
Можно ли сделать так, чтобы данные вообще не покидали Узбекистан?
Сервер интеграции и базы — да, при размещении у локального провайдера или на вашем сервере. С моделью сложнее: сильные модели работают в зарубежных дата-центрах. Варианты — передавать в модель обезличенный текст без имён и телефонов или использовать открытую модель на своём сервере, но она требует мощного железа и обычно уступает по качеству.
Обучается ли модель на наших диалогах?
У крупных провайдеров при работе через API по умолчанию — нет, это закреплено в их условиях для бизнес-клиентов. Но это относится к API. Если сотрудники вставляют данные клиентов в бесплатный чат-бот через браузер, там правила другие — это отдельный вопрос внутренней политики.
Что будет с данными, если мы прекратим работу с подрядчиком?
Это нужно прописать до начала: в какой срок подрядчик удаляет копии, что передаёт вам (код, настройки, выгрузки) и как подтверждает удаление. Если аккаунты изначально оформлены на вас, большая часть вопроса снимается сама.
Как это устроено у вас?
Карту данных и доступов мы составляем на старте любого проекта и согласуем с клиентом до подключения к его системам — как часть работы над ИИ-агентами. Если хотите разобрать свой процесс, напишите нам: на первом разговоре посмотрим, какие данные реально нужны агенту, а какие можно не передавать.