Перейти к содержимому
6 мин чтения

Доказательства хранения данных в Казахстане проверяют фактами

Какие доказательства хранения данных в Казахстане запросить у LLM-поставщика: схема потоков, адреса ЦОД, копии, журналы и удаление.

Доказательства хранения данных в Казахстане проверяют фактами

Фраза поставщика «данные хранятся в Казахстане» ничего не доказывает, пока он не покажет, какие именно данные, в какой системе и по какому адресу лежат. В LLM-сервисе один запрос быстро распадается на несколько объектов: исходный промпт, вложение, ответ модели, технический журнал, трассировка, запись для контроля качества, кэш и резервная копия. У каждого объекта может быть свой маршрут и срок жизни.

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

Сначала определите, что именно обязано остаться в стране

Требование к месту хранения нужно привязать к категориям данных и роли вашей организации, иначе спор сведется к словам. Пункт 11 Правил сбора и обработки персональных данных говорит, что персональные данные хранятся собственником, оператором и третьим лицом в базе, находящейся на территории Республики Казахстан. Закон «О персональных данных и их защите» относит к обработке накопление, хранение, изменение, использование, обезличивание, блокирование и уничтожение. Из этого не следует, что любое вычисление для любого вида информации автоматически запрещено за рубежом. Зато ясно, что одной локальной базы недостаточно, если рабочая копия персональных данных постоянно появляется в иностранном журнале.

Статья 16 того же закона отдельно регулирует трансграничную передачу. Поэтому хранение и передача требуют двух разных проверок. Поставщик может держать основную базу в Алматы, но отправлять промпт зарубежной модели. Он также может обрабатывать запрос внутри страны, но выгружать трассировки в иностранную систему наблюдаемости. В обоих случаях заявление о казахстанской базе остается буквально верным и практически неполным.

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

Полезно зафиксировать четыре решения:

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

Такой реестр не заменяет заключение юриста. Он дает архитектору проверяемые границы и не позволяет поставщику самому решить, что ваш промпт «не считается хранившимся».

Схема потоков должна показывать каждую копию

Хорошая схема потоков отвечает на вопрос, где появляется байтовая копия запроса от входного API до окончательного уничтожения. Картинка с прямоугольниками «клиент», «облако» и «LLM» для проверки бесполезна. Просите схему уровня компонентов с границами стран, юридических лиц и сред исполнения.

На схеме должны присутствовать API-шлюз, балансировщик, очередь, сервис маскирования, маршрутизатор моделей, сервер инференса, объектное хранилище, рабочая база, кэш, система журналирования, трассировка, мониторинг, резервное хранилище и инструменты поддержки. Для каждого ребра нужны протокол, шифрование, категория данных и условие передачи. Для каждого узла нужны оператор, физическое размещение, срок хранения и идентификатор связанного договора или приложения.

Не принимайте фразу «данные проходят транзитом» без технического определения. Буфер процесса, очередь повторной доставки, дамп при сбое и кэш ответа создают копии, пусть и короткоживущие. Спросите, пишется ли тело HTTP-запроса при ошибках 4xx и 5xx, попадает ли оно в distributed tracing и может ли инженер скачать его в тикет. Именно аварийный путь чаще всего расходится с аккуратной схемой нормальной работы.

Попросите исходник схемы и таблицу потоков, а не только PDF. Минимальная строка таблицы выглядит так:

flow_id: F-017
source: api-gateway-kz
source_location: Kazakhstan, Almaty, DC-1
destination: inference-cluster-kz
data: prompt_redacted, model_parameters
purpose: inference
transport: TLS 1.3
persistence_at_destination: none
logs_body: false
subprocessor: Vendor Legal Name
retention: process_memory_only
evidence: config-export-2026-07-15

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

Адрес ЦОД подтверждают не сертификатом, а цепочкой владения

Физический адрес дата-центра должен доходить до стойки или выделенного сегмента, где исполняется сервис. Сертификат оператора ЦОД подтверждает область его аудита, но не доказывает, что именно ваши данные находятся в проверенном здании. Точно так же договор с казахстанским облаком ничего не говорит о внешнем API модели, подключенном из этого облака.

Запросите юридическое наименование владельца площадки, почтовый адрес, обозначение основного и резервного ЦОД, сторону договора колокации или аренды облака и описание выделенных ресурсов. Если номер стойки нельзя раскрыть по соображениям безопасности, поставщик может показать его аудитору под NDA или дать аттестационный отчет, где ваш сервис входит в область проверки. Полный отказ назвать хотя бы город, юридическое лицо и площадку делает заявление непроверяемым.

Правила организации деятельности центра обработки данных определяют ЦОД как объект инфраструктуры с вычислительными ресурсами, телекоммуникационным оборудованием и системами хранения и обработки. Это полезная рамка: адрес офиса или регистрации компании не заменяет адрес такого объекта. Выписка о регистрации казахстанского ТОО подтверждает юрисдикцию контрагента, а не местоположение дисков.

Сопоставьте четыре документа:

  • договор или письмо оператора площадки с адресом и услугой;
  • актуальный перечень активов с кластерами, томами и хранилищами;
  • область сертификата или технического аудита, где названа площадка;
  • архитектурная схема, в которой эти активы связаны с вашим API.

Даты и названия должны совпадать. Старый сертификат на выведенный из эксплуатации ЦОД, счет за аренду одной стойки и схема с тремя кластерами не складываются в доказательство. Попросите объяснить разрыв и сохраните ответ в материалах проверки.

Фотографии серверной, геометка телефона и экскурсия дают слабое дополнительное подтверждение. Они не показывают маршрутизацию конкретного tenant. Гораздо сильнее работает выборка ресурсов из панели управления или реестра конфигурации, подписанная ответственным сотрудником и связанная с вашими идентификаторами проекта.

Резервные копии и журналы часто нарушают красивую историю

Основная база может находиться в Казахстане, пока резервные копии, журналы и диагностические выгрузки покидают страну. Эти системы проектируют отдельные команды, и поставщик иногда отвечает за них отдельными договорами. Проверяйте их как самостоятельные места хранения, а не как приложение к основной базе.

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

Особое внимание уделите неизменяемым копиям. Защита от удаления полезна против вымогателей, но она конфликтует с обещанием удалить данные клиента немедленно. Поставщик должен честно назвать максимальный срок, в течение которого удаленный объект остается в защищенной копии, и объяснить, как блокирует его восстановление в рабочую среду. Обещание «удалим везде за 24 часа» не сходится с тридцатидневным неизменяемым архивом.

По журналам нужна отдельная карта полей. Безопасная запись с кодом статуса, числом токенов, идентификатором модели и случайным request ID отличается от записи полного промпта. Спросите о журналах API-шлюза, приложений, WAF, трассировки, систем обнаружения атак, биллинга и поддержки. Поле может называться message, payload, exception или span.attribute; название «технический журнал» не делает содержимое обезличенным.

Проведите контролируемый тест: отправьте уникальную строку вроде RESIDENCY-CHECK-8F31, затем попросите поставщика найти ее во всех доступных системах. Ожидаемый результат важен в обе стороны. Если тела не журналируются, поиск должен вернуть ноль совпадений, а поставщик показывает настройки исключения полей. Если строка нужна для отладки и сохранилась, вы получаете список систем, сроки и доступы, которые надо согласовать.

Субподрядчик начинается там, где чужая система видит данные

Запрет лишних запросов
Rate-limits на уровне ключа ограничивают доступ к выбранному LLM-маршруту.

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

Разделите поставщиков моделей и инфраструктурных исполнителей. Один предоставляет GPU и модель, другой хранит резервные копии, третий принимает журналы, четвертый ведет обращения поддержки. Даже если основной поставщик называет последнего «техническим партнером», доступ к выгрузке с промптами делает его частью цепочки обработки.

Для маршрутизатора с несколькими моделями обычного списка мало. Попросите матрицу: модель, провайдер, endpoint, страна исполнения, режим сохранения запросов, использование данных для обучения, доступность режима без хранения и правила fallback. Автоматический fallback способен вывести запрос за пределы разрешенного контура во время сбоя. Его нужно запретить политикой маршрутизации для чувствительного класса, а не обещанием менеджера.

Договор должен требовать предварительного уведомления о новом субподрядчике и давать заказчику разумный способ возразить. Приложение со списком надо версионировать. Для каждого изменения поставщик показывает оценку влияния на потоки и локализацию до включения компонента в продакшене.

Есть неудобный вопрос: видит ли данные поддержка иностранного разработчика оборудования или ПО во время удаленной диагностики? Поставщик должен описать bastion-доступ, одобрение сессии, запись действий, запрет выгрузки и аварийный порядок. Утверждение «у них нет постоянного доступа» не отвечает на вопрос о временном доступе администратора.

Удаление проверяют одним объектом до последней копии

Политика удаления имеет смысл только тогда, когда связывает событие, техническую операцию и доказательство. Формулировка «данные удаляются по окончании целей обработки» не говорит, кто запускает удаление, как быстро оно доходит до реплик и что происходит в резервной копии.

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

Лучший приемочный тест использует синтетический объект, который легко узнать и нельзя спутать с реальными данными. Создайте запрос с уникальным идентификатором, дождитесь его появления в разрешенных хранилищах, затем отправьте запрос на удаление. Поставщик должен показать последовательность:

  1. заявка получила номер, время и подтвержденного заявителя;
  2. рабочая база, объектное хранилище, кэш и поисковый индекс больше не возвращают объект;
  3. журналы содержат только допустимый идентификатор операции без исходного текста;
  4. резервная копия либо очищена, либо объект заблокирован до естественного истечения копии;
  5. подписанное подтверждение перечисляет проверенные системы и известные остатки.

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

Отдельно спросите о производных данных: эмбеддингах, индексах, кэшах, наборах оценки и примерах для разметки. Если поставщик утверждает, что обезличенная производная больше не относится к субъекту, запросите метод обезличивания и оценку возможности обратной идентификации. Замена ИИН на стабильный хеш часто оставляет запись связуемой и не превращает ее автоматически в анонимную.

Договор превращает презентацию в обязательство

Журнал для проверки маршрута
Аудит-логи сохраняют проверяемый след работы API на уровне ключа.

Технические материалы быстро устаревают, поэтому существенные утверждения надо перенести в договор и приложения. Предметом обязательства становятся не слова «локальный сервис», а конкретные территории, категории данных, системы и действия при изменениях.

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

Право на аудит не обязательно означает свободный вход вашей команды в ЦОД. Рабочая конструкция допускает несколько уровней: ежегодный независимый отчет, удаленную проверку конфигураций, выборку доказательств по запросу и очный аудит при существенном инциденте. Важно определить сроки ответа, допустимое сокрытие чужих данных и обязанность устранить несоответствие.

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

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

Проверка должна воспроизводиться, а не зависеть от доверия

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

Для утверждения «промпты чувствительного класса обрабатываются только в Казахстане» пакет может включать строку схемы потоков, правило маршрутизации, список разрешенных endpoint, сетевой лог тестового запроса и договор с оператором локального кластера. Каждый документ по отдельности имеет пробел. Вместе они подтверждают проект, конфигурацию и фактическое поведение.

Сетевой тест проводите со своей стороны и, если возможно, с наблюдением поставщика. Запишите DNS-ответы, адрес назначения, TLS-соединение, request ID, выбранную модель и метку маршрута. Геолокация IP дает подсказку, а не окончательное доказательство: адрес может обслуживаться через anycast или прокси. Сопоставьте наблюдение с конфигурацией и данными владельца сети.

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

Удобная шкала качества доказательств проста. Самодекларация описывает намерение. Политика задает процесс. Конфигурация показывает текущее правило. Журнал и тест показывают исполнение. Независимый аудит проверяет выборку и границы контроля. Не заменяйте один уровень другим и не называйте сертификат доказательством факта, которого нет в его области.

Красные флаги видны в точности ответов

Хранение внутри страны
Выберите локально размещенные open-weight модели для потоков, которым нужна data residency.

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

Особенно настораживают противоречия. В политике написано, что журналы живут семь дней, в интерфейсе поиска доступны данные за месяц, а договор срока не содержит. Менеджер обещает режим zero retention, но инженер объясняет обязательную диагностическую запись при ошибке. Не выбирайте удобную версию. Зафиксируйте расхождение как дефект и запросите единый исправленный ответ с доказательством.

Фраза «модель обучается не на ваших данных» отвечает только на один риск. Данные могут храниться для контроля злоупотреблений, ручной проверки, биллинга или отладки. Спросите отдельно о каждом назначении, сроке и получателе. Аналогично шифрование не доказывает локализацию: зашифрованная копия за границей остается копией за границей, а место ключа создает отдельный вопрос доступа.

Отказ от теста удаления тоже показателен. Продакшен можно защитить от произвольных действий, но поставщик способен провести тест в выделенном tenant или показать свежий протокол сопоставимой проверки. Если процесс нельзя продемонстрировать нигде, скорее всего, его никто не проверял после последнего изменения архитектуры.

Не требуйте идеального документа сразу. Допускайте закрытие пробела в оговоренный срок, если риск временно ограничен технически. Но не подменяйте доказательство дорожной картой. Будущая локальная площадка не подтверждает текущий маршрут.

Итогом должен быть проверяемый пакет приемки

Решение о допуске LLM-сервиса принимают по пакету взаимосвязанных доказательств, а не по одному письму поставщика. В пакете должны лежать утверждения о границах, схема и таблица потоков, адреса площадок, реестр активов, настройки резервирования и журналов, список субподрядчиков, процедура удаления, договорные условия и результаты тестов. У каждого пробела есть риск, владелец и срок закрытия.

Разделите вердикт по классам данных и маршрутам. Сервис может подходить для публичных текстов через внешние модели и не подходить для персональных данных. Локальный кластер может получить допуск для чувствительных промптов, пока зарубежный fallback заблокирован. Такой вывод точнее общего «поставщик соответствует» и легче превращается в правило API-шлюза.

В AI Router команды могут выбрать модели на собственной GPU-инфраструктуре в Казахстане, когда им нужны хранение внутри страны и локальная обработка, а маскирование PII, аудит-логи и лимиты на уровне ключа помогают закрепить границы доступа. Эти возможности все равно надо проверить на вашем tenant тем же набором схем, конфигураций, договоров и тестов, который вы потребовали бы у любого поставщика.

Закройте приемку контрольным объектом. Отправьте синтетический промпт, сохраните request ID, подтвердите выбранный маршрут, найдите разрешенные следы, инициируйте удаление и получите отчет об остатках в копиях. Если поставщик может воспроизвести этот путь через полгода после обновления платформы, у вас есть работающий контроль. Если не может, красивый адрес казахстанского ЦОД остается адресом, а не доказательством судьбы ваших данных.

Часто задаваемые вопросы

Достаточно ли письма поставщика о хранении данных в Казахстане?

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

Считается ли временная обработка за рубежом нарушением локализации?

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

Какие данные LLM-сервис может записывать помимо промпта?

Ответ модели, вложения, request ID, параметры маршрута, трассировки, ошибки, кэш и обращения поддержки. Поле журнала с нейтральным названием иногда содержит полное тело запроса, поэтому просите карту полей и тест с уникальным маркером.

Доказывает ли сертификат дата-центра местонахождение наших данных?

Только если площадка и ваш сервис входят в область проверки, а активы можно связать с вашим tenant. Общий сертификат оператора ЦОД без этой цепочки подтверждает слишком мало.

Нужно ли раскрывать точный адрес резервного хранилища?

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

Как проверить режим zero retention у поставщика модели?

Найдите обязательство в договоре, настройку конкретного endpoint и конфигурацию журналов. Затем отправьте уникальный маркер и проверьте, что поиск по доступным системам не находит тело запроса.

Что делать с данными в неизменяемых резервных копиях после удаления?

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

Нужно ли включать зарубежную техническую поддержку в список субподрядчиков?

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

Как часто повторять проверку хранения данных?

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

Можно ли допустить LLM-сервис только для части данных?

Да, и это часто разумнее общего запрета или общего разрешения. Свяжите классы данных с разрешенными маршрутами, заблокируйте внешний fallback для чувствительных запросов и проверяйте правило технически.