Удаление данных у провайдера: что запросить до закупки

Почему слов провайдера мало

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

У LLM-провайдера риск выше, чем кажется. Даже если сервис не хранит текст запроса в основной системе, его копии часто остаются в соседних слоях. Это не редкий сбой, а обычная часть эксплуатации. Следы данных могут жить в access logs, error logs, трассировках, мониторинге, резервных копиях, очередях повторной отправки и временных дампах.

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

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

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

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

Надежный признак простой: провайдер заранее фиксирует, что удаляет, где удаляет, в какой срок и чем это подтверждает. Если этого нет до подписания, после запуска лучше не станет.

Что считать данными

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

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

Дальше идут файлы и служебные поля. К данным относятся PDF, изображения, аудио, CSV, а также имена файлов, user ID, project ID, request ID, IP-адрес, время запроса, выбранная модель, токены и теги маршрутизации. Если вы работаете через API-шлюз, один и тот же запрос может появиться и у шлюза, и у конечного провайдера модели. Обещание про удаление нужно проверять по всей цепочке, а не только по основному интерфейсу.

Отдельная зона риска - логи и трассировка ошибок. Когда запрос падает, разработчики нередко пишут в debug-логи часть тела запроса, имя файла или ответ модели. Поддержка потом ищет проблему по этим записям. На словах провайдер может не хранить "контент", но тот же контент лежит в логах, APM, системе алертов или тикетах поддержки.

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

Последний слой - бэкапы и снапшоты. Команда удаляет запись из основной базы и считает вопрос закрытым, хотя копия еще 30, 60 или 90 дней лежит в резерве. Сам по себе такой срок не всегда критичен, если порядок очистки описан ясно. Проблема начинается, когда провайдер говорит только про удаление из "активной системы" и молчит про все остальное.

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

Что закрепить в договоре

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

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

Отдельно зафиксируйте срок удаления. Один срок нужен после запроса клиента, второй - после окончания договора. Формулировка вроде "в разумный срок" не помогает. Нужны числа. Например, 30 дней для рабочих систем и 90 дней для резервных копий, если провайдер не может чистить их быстрее.

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

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

Для команд из Казахстана это особенно чувствительный пункт. Часто нужно показать не только факт удаления, но и путь данных внутри инфраструктуры.

Если вы подключаете LLM через шлюз вроде AI Router, сразу проверьте цепочку ответственности. Кто удаляет данные в самом шлюзе, кто отвечает за внешнего модельного провайдера и кто дает подтверждение, если запрос прошел через несколько систем.

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

Если поставщик не готов закрепить это на бумаге, его обещание об удалении мало что значит.

Какие технические сигналы запросить

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

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

Обычно достаточно запросить пять вещей:

1. Схему движения данных по всем системам - от входящего запроса до логов, бэкапов и внешних провайдеров.
2. Таблицу сроков хранения по каждому слою, где отдельно указаны runtime-логи, debug-логи, кэш, файлы, бэкапы и аудит-лог.
3. Список подрядчиков с простой ролью каждого: кто хранит, кто обрабатывает, кто видит метаданные, а кто получает полный запрос.
4. Пример аудит-лога по удалению одной записи с отметкой времени, ID запроса, системой, результатом и человеком или сервисом, который запустил удаление.
5. Порядок маскирования PII в логах: что именно скрывают, на каком этапе и может ли полный текст попасть в debug-канал до маскирования.

Хорошая схема движения данных не сводится к одному прямоугольнику "облако". Она показывает каждый слой отдельно. Если вы закупаете LLM-провайдера, на схеме должны быть входной эндпоинт, маршрутизация, кэш промптов, журнал ошибок, аналитика, хранилище вложений и нижестоящие модели. Именно в этих местах часто остаются копии, хотя основную запись уже удалили.

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

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

С маскированием PII провайдер тоже должен отвечать прямо. Спросите, маскируются ли телефоны, email, ИИН, номера карт и имена до записи в лог или уже после. Если сначала сохраняют полный текст, а потом "чистят", это слабое место.

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

Как проверить это по шагам

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

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

Дальше полезно идти по простому сценарию:

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

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

Хороший сигнал - когда провайдер показывает не просто письмо "все удалено", а нормальное подтверждение с временем заявки, временем исполнения, перечнем затронутых систем и сроком очистки бэкапов. Если у сервиса есть выгрузка аудит-логов по запросу, попросите пример заранее.

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

Где команды ошибаются чаще всего

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

Вторая ошибка появляется, когда проверяют только то, что видно в интерфейсе. В кабинете может быть кнопка удаления, статус disabled logging или короткая настройка retention. Но закупке нужен ответ не про экран, а про бэкенд: что происходит с запросом после API-вызова, где он временно лежит, кто пишет аудит-логи, сколько живут трассировки и как чистят служебные таблицы.

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

Еще одна типичная ошибка: вместо точного ответа принимают общий сертификат или красивую политику безопасности. SOC 2, ISO или внутренний security deck полезны, но они не отвечают на прямой вопрос: какие именно данные удаляются, из каких систем, в какой срок и как это подтверждается. Если провайдер не может назвать таблицы, хранилища, типы логов и сроки retention, у вас нет проверки, у вас есть обещание.

Пятая ошибка касается подрядчиков. Многие LLM-провайдеры сами маршрутизируют запросы дальше: к модели, в облако, в лог-пайплайн, систему мониторинга или внешнее хранилище. Тогда удаление нужно проверять не у одного контрагента, а по всей цепочке. Иначе основной провайдер удалит данные у себя, а копия останется у downstream-партнера.

Тревожные сигналы обычно выглядят так: вам отвечают только "we do not train on your data"; не дают сроки удаления по каждой системе; не описывают политику по backup и disaster recovery; скрывают список subprocessors; вместо ответа присылают общий PDF про compliance.

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

Простой сценарий перед закупкой

Банк тестирует LLM-сервис, который подсказывает оператору ответ в чате поддержки. Команда не пускает в пилот живые обращения клиентов. Сначала она собирает обезличенный набор диалогов: убирает ФИО, номера счетов, телефоны, адреса и все, по чему можно узнать человека.

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

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

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

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

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

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

Решение о закупке стоит принимать только после такого теста. Если провайдер тянет с ответами, путается в сроках или не может назвать все хранилища, это тоже результат пилота.

Короткий чек-лист перед подписанием

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

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

• В договоре есть срок удаления в днях. Не "в разумный срок", а конкретное число для рабочих данных, логов и временных файлов.
• Провайдер дает список систем, где могут остаться копии данных: основная база, логи, кэш, очереди задач, резервные копии и тестовые среды.
• Описан порядок очистки бэкапов. Если мгновенно удалить запись из архива нельзя, провайдер должен прямо сказать, когда архив перезапишется и кто имеет к нему доступ до этого момента.
• Есть журнал действий по запросу клиента. Нужна запись о том, кто принял запрос на удаление, когда запустил процесс и чем он завершился.
• Назван ответственный и канал эскалации. Если вопрос зависнет между аккаунт-менеджером и поддержкой, срок удаления теряет смысл.

Хороший признак - когда один и тот же порядок описан и в договоре, и в технических материалах. Плохой - когда юристы обещают удаление за 30 дней, а инженеры говорят, что бэкапы живут 90.

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

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

Что делать дальше

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

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

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

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

При сравнении кандидатов не смотрите только на цену и список моделей. Для закупки LLM-провайдера часто важнее локальное хранение, аудит-логи и маскирование PII. Именно на этих пунктах проекты чаще всего стопорятся в банках, телекоме и госсекторе.

Для команд в Казахстане разница между "региональным хранением" и хранением данных внутри страны часто принципиальна. Поэтому спрашивайте прямо: данные остаются в Казахстане или уходят в другой регион, есть ли пометки контента по требованиям AI-закона, доступны ли аудит-логи, можно ли включить маскирование PII.

Если вы сравниваете шлюзы вроде AI Router, проверяйте те же вещи по документам и по тесту, а не по общим обещаниям. У airouter.kz заявлены хранение данных внутри Казахстана, маскирование PII, аудит-логи, rate limits на уровне ключа и единый OpenAI-совместимый эндпоинт, но даже в этом случае решают конкретные условия договора и подтверждающие артефакты.

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