Чек-лист для команды в РФ: резидентность данных для LLM, хостинг, логи, бэкапы, доступы и удаление. Поможет подготовиться к аудиту.
Резидентность данных в LLM-проектах важна не только банкам и госструктурам. В России это быстро становится базовым требованием для многих команд, если в работе есть персональные данные, коммерческая тайна, внутренние документы или переписка сотрудников.
Проверку лучше делать до прототипа. После первых интеграций перенос хостинга, пересборка логирования и пересмотр процессов хранения обычно обходятся дороже, чем кажется.
Если не задать вопросы заранее, риски появляются сразу. Проект могут остановить на согласовании у ИБ или юристов. Может выясниться, что часть данных уходит во внешние сервисы, а вернуть контроль сложно. Логи и резервные копии начнут жить дольше, чем вы планировали. А доступы окажутся шире, чем нужно, и это всплывет только после инцидента.
На практике заказчик и служба безопасности обычно проверяют простые вещи: где физически расположены серверы и базы, кто из подрядчиков имеет доступ, что пишется в журналы, как делаются бэкапы, как удаляются данные и как быстро это можно подтвердить. Эти вопросы одинаково важны, делаете ли вы чат по документам, голосового помощника или внутреннего бота.
Ниже - чек-лист, который помогает подготовиться к разговору с платформой, интегратором и ИБ до старта работ. Он не заменяет юридическую консультацию и не привязан к одному вендору, но дает понятный минимум, который стоит зафиксировать в требованиях и договоренностях. Если вы выбираете платформу с размещением в РФ, эти пункты все равно нужны, просто ответы должны быть проще и конкретнее.
В LLM-проекте данные - это не только текст, который вводит пользователь. Данные появляются в нескольких местах, и каждое важно для резидентности и согласований.
Удобно мыслить слоями:
Ввод: сообщения в чате, поля в форме, голос, а также файлы (договоры, сканы, таблицы).
Вывод: ответы модели и любые сгенерированные документы.
Метаданные: время запроса, язык, размер файла, идентификаторы пользователя, версия модели, параметры промпта.
Производные данные: векторные представления, индексы поиска, память ассистента, черновики, кэш.
Важно договориться о терминах, чтобы все участники говорили об одном и том же:
Отдельно отличайте контент от техданных. Контент - это сообщения и файлы пользователей, ответы модели, документы. Техданные - логи, трассировки, метрики, телеметрия, события безопасности. В логах часто случайно оказывается контент (например, промпт целиком), и тогда журналы становятся такими же чувствительными, как и исходные документы.
В обсуждении обычно участвуют четыре роли. Бизнес описывает сценарий и ценность данных. ИБ определяет риски и контроль доступа. Юристы фиксируют условия обработки и сроки хранения. Разработка описывает реальную схему компонентов, включая сторонние сервисы. Если кого-то из этих ролей нет, картина почти всегда будет неполной.
Когда в компании обсуждают резидентность данных для LLM, обычно всплывает не один закон, а набор требований: нормативы, договоры с клиентами и внутренние правила. Если это не зафиксировать в начале, архитектуру придется переделывать после прототипа.
Состав данных бывает разным, и требования к ним тоже.
Персональные данные обычно требуют самого строгого режима: где хранятся, кто имеет доступ, как удаляются. Коммерческая тайна и служебная информация часто регулируются внутренними положениями и NDA. Там ключевой вопрос не только про страну хранения, но и про круг лиц, которые могут видеть содержимое.
Помогает простое разделение:
Записывайте требования в виде проверяемых пунктов. Например:
Юриста и ИБ лучше подключать до прототипа, если вы работаете с ПДн, банковскими или медицинскими данными, или если по договору нельзя использовать внешние сервисы. Тогда вы заранее поймете, какие ограничения критичны, а где достаточно обезличивания и минимизации данных.
Если вы работаете в РФ, полезно начать не с выбора модели, а с простого рисунка: откуда данные приходят, куда уходят и где остаются. Такая карта быстро показывает, есть ли риск, что данные уедут не туда или начнут копиться в неожиданных местах.
Возьмите лист или доску и выпишите все источники: формы на сайте, чаты поддержки, CRM, почта, таблицы, папки с документами, загружаемые файлы, записи звонков. Даже если источник кажется внутренним, отметьте его отдельно: он может синхронизироваться с облаком или внешними сервисами.
Дальше рядом с каждым источником подпишите тип данных. Это помогает не спорить в общем, а решать по категориям: есть ли ПДн, финансовые данные, договоры, коммерческая тайна, данные сотрудников, внутренние базы. Для LLM-проекта важно понимать, какие поля нельзя отправлять в модель целиком (например, паспортные данные или реквизиты).
Затем нарисуйте путь данных: где они появляются (ввод в чат, загрузка файла), где обрабатываются (сервер, LLM, агенты), где сохраняются (БД, кэш, файловое хранилище) и кто их видит (оператор, админ, подрядчик). Отдельно пометьте интеграции и сторонние сервисы: аналитика, антифрод, распознавание речи, внешние базы.
В конце отметьте то, что должно быть отключаемым по требованию: хранение истории диалогов, телеметрия, обучение на данных клиента, выгрузка логов, сохранение вложений.
Если вы рассматриваете платформы вроде TakProsto, этот разговор лучше провести до старта: где хранится история, как устроены снапшоты и откат, как работает экспорт кода и что окажется в окружении при деплое.
Первое, что стоит выяснить до договора, - где физически расположены серверы и как это подтверждается. В идеале вы должны получить простой ответ: страна, площадка (дата-центр), кто владелец железа или облака, и какие документы или пункты договора фиксируют размещение и запрет на вынос данных.
Дальше проверьте разделение окружений. Если у команды есть тестовый контур, прод и песочница, важно понимать, какие данные туда попадают. Частая ошибка: в тест заливают реальные документы или переписки. Потом они оказываются в другом месте хранения или с более слабым контролем доступа.
Перед подписанием удобно пройтись по короткому набору вопросов:
Пример: вы делаете чат-ассистента для отдела продаж и храните коммерческие предложения. Если платформа поддерживает экспорт исходников и развертывание у вас, заранее закрепите, какие компоненты остаются у провайдера (например, хостинг и мониторинг), а какие данные вы забираете полностью.
У TakProsto заявлены экспорт кода, деплой и хостинг, кастомные домены, а также снапшоты и откат. Это удобно, но для ИБ важно заранее договориться, где лежат артефакты, как ограничены доступы к окружениям и кто может выполнять операции вроде отката.
Логи - частый источник утечек в LLM-проектах: туда легко попадает то, что вы не планировали сохранять. Если вам важна резидентность данных, проверьте логирование до первой интеграции, а не после инцидента.
Чаще всего пишутся тексты запросов и ответов, ошибки, коды статусов, трассировка (какой сервис кого вызвал и сколько это заняло), а также технические метаданные (время, идентификаторы сессий, IP, user-agent). В проектах с документами в логах нередко оказываются фрагменты договоров или ФИО, потому что текст запроса попал в error-лог при падении обработки.
Чтобы этого не было, заранее договоритесь о правилах: маскирование полей, вырезание персональных данных, отключение логирования тела запросов, ограничение трассировки, выборочное логирование (sampling). Важно, чтобы маскирование было не только в приложении, но и на уровне прокси, API-шлюза и инструментов мониторинга.
Проверьте это коротким набором вопросов:
Даже если вы используете платформу с хостингом в РФ, эти ответы лучше фиксировать письменно: место хранения логов и правила доступа часто отличаются от места исполнения модели.
Бэкапы часто включают по умолчанию, а потом выясняется, что копии лежат в другом регионе или восстановить их может слишком широкий круг людей. Для LLM-проектов это риск: в копиях оказываются база, файлы, переписки и служебные данные.
Начните с простых вопросов: где физически хранятся резервные копии, кто провайдер и как подтверждается, что хранение именно в РФ. Отдельно уточните шифрование: что шифруется (файлы, дампы БД, снапшоты), где лежат ключи и кто имеет к ним доступ.
Дальше проверьте правила жизни бэкапов. Срок хранения и право на восстановление должны быть понятны и проверяемы: не просто «админы могут», а конкретные роли, условия, журнал действий.
Короткий чек-лист для согласования:
Снапшоты и откаты версии требуют отдельного разговора. Уточните, что входит в снимок: база, загруженные файлы, конфигурация, секреты, промпты. Главный нюанс: при откате не должны «воскресать» уже удаленные данные. Например, клиент попросил удалить переписку и документы, а откат релиза вернул старый снапшот с теми же данными.
Если вы используете платформу с функциями снапшотов и rollback, закрепите в процессе, как проверяется этот риск и как проводится безопасное восстановление.
В теме резидентности часто фокусируются на серверах и бэкапах, но доступы решают не меньше. Если слишком много людей имеют доступ к продакшену, данные могут утечь даже при правильном хостинге.
Сначала зафиксируйте модель доступа: роли, права и принцип минимальных привилегий. У каждого пользователя должна быть ровно та возможность, которая нужна для работы: поддержка видит только заявки, аналитик - только агрегаты, разработчик - тестовые данные. Доступ к реальным документам клиентов должны получать единицы и по заявке.
Проверьте, как выдаются и отзываются доступы. Удобный процесс - это не только про создание аккаунта, но и про увольнение: доступы в админку, в базы, к выгрузкам кода, к снапшотам и к хранилищам логов должны закрываться в один день, а лучше сразу.
Ответьте на вопросы до старта:
Если вы делаете внутренний чат-ассистент и подключаете базу с документами, заранее отделите окружения: тестовое с обезличенными файлами и рабочее с реальными. Для рабочего окружения включите аудит действий: кто запускал сбор контекста, кто делал экспорт исходников, кто выполнял откат снапшота. Так проще объяснить, кто реально видел данные и почему.
Если сроки хранения и правила удаления не зафиксировать до старта, дальше почти всегда начинается путаница: часть данных удалили, часть осталась в логах, а часть уехала в резервные копии и живет там месяцами.
Сначала определитесь, что именно считается удалением. Для LLM-проекта это обычно несколько мест сразу: записи в базе данных, файлы (загруженные документы, вложения), кэш и индексы, журналы событий, а также резервные копии. Формулировка «удаляем данные» без уточнений почти ничего не значит.
Задайте сроки для каждой категории и причину, зачем вы вообще храните это так долго. Например, переписку с ассистентом можно хранить 30 дней для улучшения качества поддержки, а документы клиента - ровно до выполнения услуги. Отдельно подумайте про технические данные: логи ошибок часто нужны дольше, но в них не должно быть содержимого запросов и персональных данных.
Набор вопросов, который стоит утвердить письменно:
Опишите процесс: кто принимает запрос (клиент, DPO, служба поддержки), кто подтверждает личность, кто запускает удаление и кто фиксирует результат.
Важно договориться и о проверке: что считается доказательством удаления. Это может быть запись в журнале действий без персональных данных, акт либо техническая проверка, что ID записи не находится в базе и в хранилище файлов.
Самый сложный вопрос - бэкапы. Обычно из резервных копий точечно удалить нельзя, поэтому фиксируют правило: данные исчезают после времени жизни бэкапа (например, 30-90 дней), а восстановление делается с учетом повторного удаления. Это лучше проговорить заранее, иначе вы пообещаете то, что технически не выполните.
Отдельно разберите тестовые данные и копии для разработки. Лучший вариант - не переносить реальные данные в dev-окружения. Если без этого никак, заранее установите маскирование, ограниченный доступ и короткий срок хранения, а также запрет на выгрузку на личные устройства.
Шифрование помогает выполнять требования не только за счет места хранения, но и за счет контроля доступа. Начните с базового: шифрование при передаче (TLS) и шифрование на диске. Во многих облаках и платформах часть этого включена, но важно понимать, что именно покрыто, а что остается на вашей стороне.
Отдельный разговор - ключи шифрования. Если ключи хранит провайдер и его администраторы могут их использовать, это другой уровень риска. Попросите описать, где лежат ключи, кто к ним имеет доступ, как ведется аудит и что происходит при смене сотрудников или подрядчика.
Для действительно чувствительных полей (паспорт, ИНН, номер договора, адрес) иногда нужно шифрование на уровне полей в базе, а не только шифрование диска. Это усложняет поиск и аналитику, зато снижает ущерб при утечке.
Обезличивание часто дает самый быстрый эффект: модели редко нужна фамилия или точный номер документа. Перед отправкой запроса можно заменять такие данные на маркеры, а сопоставление хранить отдельно.
Проверьте себя:
Проверка резидентности данных для LLM проще всего проходит, когда у вас есть один владелец процесса и понятный артефакт на выходе: таблица вопросов и короткий документ с рисками.
Соберите требования от бизнеса, ИБ и юристов. Зафиксируйте типы данных (персональные, коммерческая тайна, документы, переписка) и что точно нельзя отправлять вне РФ.
Сделайте единую таблицу вопросов по блокам: хостинг, логи, резервные копии, доступы, удаление. Сразу пропишите, какие доказательства принимаете (регламенты, схема архитектуры, описания процедур), а не просто ответы в презентации.
Запросите подтверждения у подрядчика или платформы: где физически находятся серверы, где хранятся журналы, кто администраторы, как устроены бэкапы, как выполняется удаление.
Если вы рассматриваете TakProsto, в запросе отдельно уточните размещение на серверах в России и порядок доступа к проектам. По описанию платформы takprosto.ai использует российскую инфраструктуру и не отправляет данные в другие страны, но для согласования в компании все равно полезно получить это в виде формулировок и процедур.
Проведите мини-тест на стенде: включите логирование и проверьте, не попадают ли туда тексты запросов; попробуйте экспортировать данные; смоделируйте восстановление из бэкапа; удалите тестовые данные и проверьте, что они исчезли из интерфейса и хранилищ.
Оформите итог: что подтверждено, что под вопросом, какие риски остаются, кто владелец каждого риска и срок закрытия. Так согласование идет быстрее, и неприятные сюрпризы не всплывают в конце.
Самая частая проблема - проверяют только «где стоит приложение», но не проверяют, куда уезжают логи, бэкапы и служебные копии. В итоге проект формально «в России», а часть данных живет в другом месте или хранится дольше, чем вы думали.
Ошибки повторяются из проекта в проект и почти всегда находятся уже после запуска, когда менять больнее:
Небольшой пример: команда делает чат-ассистента для продаж, логирует все диалоги для «контроля качества», а затем получает запрос на удаление данных клиента. Диалоги стираются из кабинета, но остаются в логах и в ночной копии базы.
Если вы используете платформу вроде TakProsto, заранее проверьте, как устроены экспорт кода, хранение снапшотов и откат, чтобы правила удаления и хранения были понятны еще до старта.
Если времени мало, цель простая: понять, уедут ли данные за пределы РФ и кто сможет к ним добраться. Этот быстрый опрос часто помогает отсеять рискованные варианты на старте и не переделывать архитектуру позже.
Ответы лучше фиксировать письменно: в переписке, в ТЗ или в договоре. Для темы резидентности устные обещания почти всегда заканчиваются спором.
Если слышите одно из этого, закладывайте время на доработки или меняйте решение:
Если вы делаете чат для клиентских документов, удобнее сразу выбирать решения, которые изначально рассчитаны на размещение в РФ. В TakProsto, например, акцент сделан на работе на серверах в России и использовании локализованных моделей. Но даже в этом случае стоит отдельно пройтись по логам, срокам хранения и доступам: именно там чаще всего находятся сюрпризы.
Представьте внутренний чат-ассистент для отдела продаж. Менеджер пишет: «Собери краткое резюме по клиенту и подготовь черновик КП», а затем прикрепляет файл: договор, коммерческое предложение или переписку. Такой сценарий быстро упирается в резидентность данных, потому что в запросах и вложениях часто есть персональные и коммерческие сведения.
Какие данные обычно всплывают: ФИО, телефоны, email, реквизиты, суммы и условия, сканы договоров, заметки менеджеров, а также история диалога, где менеджер может случайно вставить больше, чем нужно.
Перед стартом задайте провайдеру конкретные вопросы:
Решение часто простое: хранить минимум. Например, сохранять только итоговый текст КП, а историю чатов отключить или ограничить сроком. Документы прогонять через обезличивание (убрать ФИО, телефоны) или хранить у себя, а в модель отправлять только нужные выдержки.
Зафиксируйте результат в коротком документе:
Начните с карты потоков данных: откуда приходит контент, где обрабатывается, где хранится и кто видит. Потом задайте провайдеру конкретные вопросы про физическое размещение серверов, логи, бэкапы, доступы и удаление, и попросите подтверждения в виде пунктов договора или описания процедур.
Потому что после первых интеграций данные начинают расползаться по логам, кэшу, индексам, резервным копиям и тестовым окружениям. Перенос хостинга и пересборка процессов хранения позже обычно дороже и рискованнее, чем сделать минимальную проверку и зафиксировать требования до прототипа.
Потоки часто проходят не только через основной сервис, но и через аналитику, мониторинг, распознавание речи, уведомления и почтовые шлюзы. Плюс остаются «следы» в логах, трассировках, бэкапах и снапшотах, где легко оказываются фрагменты запросов и документов.
Контент — это сообщения, файлы, ответы модели и сгенерированные документы. Техданные — это логи, метрики, трассировки, события безопасности; они должны быть без содержимого запросов, но на практике туда часто попадает промпт целиком. Поэтому логи нужно считать потенциально чувствительными и настраивать отдельно.
Проверьте, пишутся ли тексты запросов и ответов, а также фрагменты документов, и можно ли это отключить. Заранее договоритесь про маскирование полей, запрет на логирование тела запросов, ограничение трассировки и срок хранения логов с автоудалением.
Не только «где лежат копии», но и кто может их восстановить и как это фиксируется. Уточните шифрование, место хранения, срок жизни бэкапов и правило, что удаленные данные не должны «воскресать» при восстановлении или откате снапшота.
Попросите список ролей и прав, включите 2FA, аудит входов и действий, а также процесс временных доступов с автоматическим истечением. Важно заранее решить, может ли поддержка или админы провайдера видеть содержимое, и как оформляется такой доступ — по заявке, с причиной, сроком и следом в журнале.
«Удаление» обычно означает очистку сразу в нескольких местах: база, файлы, кэш/индексы, логи и резервные копии. Зафиксируйте сроки хранения по типам данных и процесс удаления по запросу, а для бэкапов — правило, что данные исчезают после срока жизни копий и повторно удаляются после восстановления.
Используйте проверяемые формулировки: где физически размещены прод, тест и бэкапы, куда уходят логи, кто администрирует доступы и какие внешние сервисы участвуют. Важно заранее определить, какие доказательства принимаются: схема архитектуры, описание процедур, пункты договора, а не устные обещания.
Начните с минимизации: не отправляйте в модель лишние поля, маскируйте ФИО, телефоны, email и номера документов, храните таблицу соответствий отдельно и с узким доступом. Для особо чувствительных полей рассмотрите шифрование на уровне полей, а прототип лучше делать на синтетических или обезличенных данных.
