Понедельник, 11:30 утра. Гульнара из юридического отдела крупной алматинской компании открывает электронное письмо и чувствует, как холодеет затылок. Адвокат бывшего клиента пишет сухим деловым языком: «Предоставьте всю переписку с нашим доверителем за период с января по март 2023 года. Документы необходимы для судебного разбирательства. Ожидаем ответа в течение 10 рабочих дней».
Гульнара берёт телефон и звонит Данияру из IT. Тот приходит через пять минут с кружкой кофе, смотрит на экран и честно говорит: «Слушай, у нас диалоги старше полугода автоматом удаляются. Так систему настроили ещё при запуске, года три назад. А это же... восемь месяцев назад было?» Гульнара кивает. Данияр разводит руками: «Извини. Данных больше нет».
В этот момент Гульнара понимает: компания только что потеряла ключевые доказательства в свою защиту. Переписка могла бы подтвердить, что клиент был предупреждён о всех рисках, что все условия были согласованы, что претензии необоснованны. Но данных нет. Потому что когда-то кто-то решил «давайте хранить полгода, этого хватит», не подумав о последствиях.
А теперь перенесёмся в другой офис. Другая компания, противоположный подход: они хранят всё. Абсолютно всё. Каждое сообщение в WhatsApp, каждый чат на сайте, каждую запись звонка за последние десять лет. Терабайты данных, за хранение которых платится солидная сумма каждый месяц. И вот приходит письмо от клиента: «Удалите все мои персональные данные согласно закону о защите персональных данных. У вас три рабочих дня». Системный администратор Аскар смотрит на эту задачу и не знает, с чего начать. Данные разбросаны по пяти системам, часть — в бэкапах, часть — в архивах. Где искать? Что удалять? Как убедиться, что удалил всё?
Две истории. Два крайних подхода. Одна и та же проблема: отсутствие продуманной политики хранения данных. Data retention — это не бинарный выбор «хранить всё или удалить всё». Это искусство балансирования между бизнес-потребностями, законодательными требованиями и здравым смыслом. Это про то, как спать спокойно, зная, что у вас есть нужные данные, когда они нужны, и нет лишних, когда их быть не должно.
«Политика хранения данных — это не бюрократия ради бюрократии. Это страховка. Когда приходит регулятор, суд или просто разгневанный клиент — у вас есть чёткий ответ: вот правила, вот сроки, вот журнал действий. Ничего личного, просто процедура»
Принцип прозрачности
Data Governance
Почему политика хранения диалогов стала критичной
Ещё лет пять назад эта тема была где-то на периферии внимания. Клиенты преимущественно звонили по телефону или писали на email. Объёмы были вполне управляемыми. Если что-то нужно было найти — ну, поищем, найдём. Никто особо не парился. А сегодня ситуация изменилась радикально, и data retention из категории «когда-нибудь разберёмся» переместился в «это нужно было сделать ещё вчера». Почему?
Каналов стало слишком много
WhatsApp, Telegram, Instagram Direct, чат на сайте, голосовые боты — и каждый из них что-то записывает. Один клиент за месяц может написать вам в пяти разных местах. А у вас таких клиентов — тысячи. Чувствуете, как растёт снежный ком?
Боты помнят всё
Чат-бот честно записывает каждое сообщение — такая у него работа. Только вот в этих сообщениях клиенты иногда пишут номера паспортов, банковские реквизиты, жалобы на здоровье. И всё это лежит у вас годами. Звучит не очень, правда?
Законы стали строже
Казахстанский закон о персональных данных постоянно дополняется. GDPR касается всех, кто работает с европейцами. Штрафы уже не символические. А фраза «мы не знали» регуляторов больше не трогает — они только пожимают плечами.
Деньги за воздух
Облако — штука платная. Каждый гигабайт стоит денег, каждый месяц. И когда финансовый директор видит счёт за хранение чатов пятилетней давности, у него возникает резонный вопрос: «А мы точно это всё ещё используем?»
Добавьте к этому ещё один фактор: клиенты стали гораздо грамотнее в вопросах своих прав. Раньше запрос «удалите все мои данные из вашей системы» был чем-то экзотическим. Сегодня это рутина. Человек прочитал пару статей про GDPR, узнал, что имеет право на забвение, и пишет вам письмо. И если у вас нет процесса обработки таких запросов — вы начинаете бегать по офису, собирать данные из разных систем вручную, и каждый такой случай превращается в мини-кризис с привлечением половины команды.
Кстати, о защите данных и приватности в контексте AI-решений мы подробно рассказывали в статье про конфиденциальность персональных данных в эпоху ботов.
Законодательные требования: что говорит закон
Ладно, хватит пугать — давайте к делу. Прежде чем рисовать красивые схемы удаления, стоит разобраться, что вообще говорит закон. Потому что можно придумать гениальную систему, а потом узнать, что она нарушает пять статей сразу. В Казахстане свои правила, у GDPR — свои. Если работаете с европейскими клиентами — придётся учитывать и то, и другое.
Казахстан: Закон о персональных данных
Основной документ — Закон РК «О персональных данных и их защите». Ключевые моменты для хранения диалогов:
Храни только нужное
Закон чётко говорит: данные нужны для конкретной цели. Достигли цели — удаляйте. «А вдруг пригодится» — это не цель, это отмазка. Регуляторы такое не принимают.
Сколько хранить?
Тут интересно: закон не даёт волшебной цифры. Бухгалтерия — 5 лет, трудовые книжки — 75. А вот для переписок с клиентами — тишина. Сами решайте и будьте готовы объяснить почему.
Клиент сказал «удали»
Если клиент попросил стереть его данные — у вас три рабочих дня. Отказать можно, только если есть весомая причина: судебный спор, проверка, действующий договор. Просто проигнорировать нельзя.
Утечка? Звони всем
Если данные утекли — придётся признаться: и регулятору, и самим клиентам. И вот здесь простая математика: чем больше храните, тем больше людей надо обзвонить. А это репутация, нервы и деньги.
GDPR и международные клиенты
Если работаете с клиентами из ЕС или обрабатываете данные граждан ЕС — GDPR применяется к вам, даже если вы в Алматы.
часа на уведомление
об утечке
дней на ответ
на запрос клиента
оборота — максимальный
штраф
Важно: GDPR требует «права на забвение» — полное удаление данных по запросу клиента. Если ваши данные разбросаны по десяти системам без единого реестра — выполнить это требование будет очень сложно.
Подробнее о требованиях GDPR и 152-ФЗ (который часто берётся за основу в Казахстане для локальных политик) мы разбирали в статье AI, GDPR и 152-ФЗ: практическое руководство.
Как определить сроки хранения для разных типов данных
Окей, с законами разобрались. Теперь самое интересное — как всё это применить на практике? Универсального рецепта нет, но есть здравый смысл и опыт тех, кто уже набил шишки. Простое правило: чем деликатнее информация, тем быстрее от неё избавляйтесь (если только закон не требует обратного).
| Тип данных | Рекомендуемый срок | Обоснование | Примечания |
|---|---|---|---|
| Чаты поддержки общие вопросы |
6-12 месяцев | Достаточно для анализа качества, обучения команды и разрешения споров | После — удаление или анонимизация для аналитики |
| Диалоги с ботом автоматические ответы |
3-6 месяцев | Нужны для улучшения бота и отладки. Дольше — избыточно | Персональные данные можно анонимизировать раньше |
| Транзакционные чаты покупки, заказы |
3-5 лет | Привязаны к финансовым документам, нужны для бухгалтерии и налоговой | Срок = сроку хранения связанных документов |
| Претензии и жалобы конфликтные ситуации |
3-5 лет | Могут понадобиться для судебных разбирательств (срок исковой давности) | Рассмотреть legal hold для активных споров |
| Записи звонков голосовые диалоги |
6-12 месяцев | Для контроля качества и обучения. Занимают много места | Транскрипты можно хранить дольше, аудио — удалять |
| Чувствительные данные здоровье, финансы |
Минимум | Хранить только пока необходимо для обработки запроса | Отдельные политики для медицины, финансов |
Но давайте начистоту: эти цифры — не священное писание. Ваш бизнес уникален. Онлайн-магазин футболок может смело удалять чаты через полгода — что там особенного? А вот страховщикам приходится хранить переписки годами: клиент может прийти с претензией через пять лет, и придётся доказывать, что всё было согласовано.
И вот что действительно важно: не столько сами сроки, сколько ваша способность их объяснить. Представьте: приходит проверяющий, смотрит строго и спрашивает: «Почему год?» А вы спокойно отвечаете: «У нас гарантия на товар — 12 месяцев. Храним переписку чуть дольше, чтобы закрыть все возможные споры. Вот документ, подписанный юристами и директором». Всё, вопрос снят. Потому что вы не с потолка взяли цифру, а подумали головой.
Legal Hold: когда удалять нельзя
А теперь про штуку, о которой почему-то редко думают заранее. Вот у вас всё красиво: автоудаление через год, скрипты работают, данные чистятся. Идиллия! И тут — бах — клиент подаёт в суд. Разбирательство может тянуться полтора-два года. А ваша умная система не знает про суд и через год честно удаляет все диалоги. Доказательств больше нет. Упс.
Для таких случаев придумали legal hold — это такая «юридическая заморозка». Как если бы вы повесили на папку табличку «Руками не трогать!». Помечаете нужные данные, и система их обходит при автоочистке, сколько бы времени ни прошло. Звучит просто, но может реально спасти компанию.
Когда активируется Legal Hold
Судебный иск
Пришла повестка? Претензионное письмо? Даже намёк на возможный иск? Всё, стоп-кран: замораживаем всю переписку с этим клиентом. Лучше перестраховаться.
Проверка регулятора
Налоговая решила заглянуть? Антимонопольщики интересуются? Пока проверка не закончится — ни байта не удаляем. Даже если очень хочется.
Внутреннее расследование
Подозреваете, что сотрудник что-то мутит? Кажется, была утечка? Сначала замораживаем, потом разбираемся. Не наоборот.
Потенциальный риск
Клиент пишет гневные посты в соцсетях? Угрожает адвокатом? Не ждите официальных бумаг — замораживайте на всякий случай. Снять hold всегда можно, а вот восстановить удалённое — нет.
Как реализовать Legal Hold технически
В идеале система должна позволять ставить флаг «не трогать» на отдельные записи. Но по-честному — не все CRM это умеют из коробки. Не беда, есть обходные пути:
Флаг в базе данных
Добавляете к каждому диалогу поле legal_hold = true/false. Скрипт удаления первым делом проверяет флаг: стоит true — идём мимо. Просто, дёшево и работает.
Отдельное хранилище
Нужные данные копируем в отдельное защищённое место, куда мало кто имеет доступ. В основной базе всё чистится по плану, а копия лежит нетронутой до конца разбирательства.
Реестр Legal Hold
Ведём простую таблицу: кто поставил заморозку, когда, зачем, на какие данные, когда снимать. Без этого через год никто не вспомнит, почему вот эти чаты нельзя трогать.
Типичная ошибка
Угадайте, что чаще всего идёт не так? Компании честно ставят legal hold — молодцы! Проходит время, дело закрывается, все выдыхают... и забывают снять заморозку. Год, два, пять — а данные всё лежат. Место занимают, деньги стоят, толку никакого.
Поэтому железное правило: на каждый hold — ответственный человек. Раз в полгода он открывает реестр и задаёт простой вопрос: «Это ещё нужно?» Если нет — снимаем. Иначе ваш legal hold превратится в кладбище забытых файлов.
Нужна помощь с политикой хранения данных?
Поможем разработать data retention policy, настроить автоматическое удаление и legal hold в вашей CRM. Учтём специфику бизнеса и законодательство Казахстана.
Обсудить проектКонтроль доступов: кто видит диалоги
Хорошо, разобрались с тем, сколько хранить и когда не удалять. Но вот вопрос, который часто упускают: а кто вообще видит все эти данные? Потому что в переписках с клиентами — не просто «привет-пока». Там телефоны, адреса, иногда банковские карты и жалобы на личные проблемы. Хранить это в системе, куда имеет доступ полофиса — так себе идея.
Принцип минимальных привилегий
Принцип простой: человек видит только то, что ему нужно для работы. Оператору не нужны финансовые отчёты, бухгалтеру — личные переписки клиентов. Каждому — своё.
Оператор поддержки
Видит свои чаты и чаты своей команды. Что делали коллеги из соседнего отдела — не его дело. История глубже месяца — тоже закрыта.
Руководитель отдела
Видит переписки своей команды — надо же контролировать качество. Но кнопки «удалить» у него нет. Смотреть можно, трогать нельзя.
Compliance/Безопасность
Эти ребята могут всё — включая доступ к архивам и установку legal hold. Но зато каждый их чих записывается в лог. За большую власть — большая ответственность.
Ролевая модель доступов (RBAC) — ваш друг. Определите роли, определите права для каждой роли, настройте в системе. Подробнее об этом можно прочитать в статье про RBAC и аудит в CRM.
Особые случаи доступа
Запрос самого клиента
Клиент вправе попросить «покажите мне всё, что вы обо мне храните». Придётся показать. Но сначала — убедиться, что это правда он, а не мошенник.
Запрос правоохранителей
Только по официальной бумаге с печатью. Отдаём ровно то, что просят — ни байтом больше. И записываем всё: кто попросил, когда, что отдали.
Увольнение сотрудника
Первое, что делаем — отключаем доступ. Буквально в тот же день. Диалоги передаём новому человеку, а если уволенный вёл что-то секретное — проверяем, кто ещё это видел.
Подозрение на утечку
Сначала — тихо закрыть доступ подозреваемому (чтобы не спугнуть). Потом — legal hold на всё, что он трогал. И только потом — смотрим логи и разбираемся, что случилось.
Журналирование: фиксируем всё
Переходим к теме, которую многие считают скучной, но которая спасает в критический момент. Представьте: понедельник, 9 утра, кофе ещё не допит — а вам звонят и говорят, что данные клиента утекли. Паника, беготня, руководство требует ответов. Вы открываете систему, чтобы разобраться... и понимаете, что разбираться не в чем. Логов нет. Кто заходил? Неизвестно. Кто качал файлы? Бог весть. Вы как слепой котёнок в тёмной комнате.
Логи — это не бюрократия ради галочки. Это ваша страховка и ваше алиби одновременно. Когда что-то идёт не так, именно логи расскажут: что случилось, кто виноват, как это не допустить снова. А ещё они работают как профилактика: сотрудники знают, что каждое действие записывается, и трижды подумают, прежде чем делать что-то сомнительное.
Что обязательно журналировать
Доступ к данным
- Кто просматривал диалог
- Когда (точное время)
- С какого устройства/IP
- Какие записи просматривал
Изменения данных
- Редактирование диалогов
- Удаление записей
- Экспорт данных
- Изменение статуса (legal hold)
Административные действия
- Изменение прав доступа
- Создание/удаление пользователей
- Изменение политик хранения
- Установка/снятие legal hold
Автоматические действия
- Автоудаление по расписанию
- Массовая анонимизация
- Бэкапы и восстановления
- Синхронизации с внешними системами
Практические рекомендации по логам
- Логи — на отдельном сервере. Если хакер пробрался в CRM, он не должен добраться до журналов и подчистить следы. Разные системы, разные доступы.
- Записал — не трогай. Логи должны быть неизменяемыми. Write-once хранилище или что-то похожее. Никто не должен иметь возможность «подправить» историю задним числом.
- Логи живут дольше данных. Храните диалоги год? Логи — полтора минимум. Иначе через год не сможете доказать, что удалённые данные действительно были удалены по регламенту.
- Не просто копите — анализируйте. Кто-то скачал 500 файлов за час? Вход в систему в 3 ночи? Это красные флаги. Если их никто не видит — какой смысл в логах?
Подробнее о наблюдаемости и логировании AI-систем читайте в статье наблюдаемость LLM-систем: логи, трассировка и аудит.
Автоматизация: настраиваем и забываем (почти)
Теперь давайте честно поговорим о ручном управлении удалением данных. Это путь в никуда. Сегодня Айгуль вспомнила — почистила. Завтра она в отпуске — никто не почистил. Через неделю пришёл новый сотрудник, нажал не туда — удалил что-то важное. Ещё через месяц никто уже не помнит, что вообще должно было происходить.
Единственный нормальный вариант — автоматизация. Один раз настроили, протестировали, убедились, что работает — и забыли. Ну, почти забыли. Иногда заглядываем проверить, что всё идёт по плану. Вот что стоит автоматизировать в первую очередь:
Автоудаление по расписанию
Простой скрипт, который запускается каждую ночь или раз в неделю. Проверяет возраст записей, удаляет старые. Тихо, без шума и пыли.
Важно: перед удалением — проверка на legal hold, отсутствие активных тикетов, прошедшее окно возможного отката.
Анонимизация вместо удаления
Бывает, что удалять совсем нельзя — данные нужны для аналитики или отчётов. Тогда просто убираем личную информацию, а остальное оставляем.
"Алексей +7777123456" → "User_8a3f2b phone_masked"
Алерты и уведомления
Система сама напоминает о важном: «Через неделю удалятся данные по проекту Х» или «Legal hold на клиента Y висит уже полгода — проверьте».
Интеграция со Slack/Teams/Email для оперативного реагирования.
Автоэкспорт по запросу
Клиент попросил выгрузку своих данных? Нажимаете одну кнопку — система сама находит всё по этому клиенту и формирует архив. Никакой беготни по базам.
Экономит часы ручной работы при обработке GDPR-запросов.
Пошаговый план внедрения политики
Ладно, теория — это хорошо. Но когда садишься за компьютер и думаешь «ну и с чего тут начинать?» — всё сразу кажется сложнее. Поэтому вот вам конкретный план. Мы по нему работали с одной казахстанской компанией. Не идеальный, но проверенный на практике.
Инвентаризация данных
Сначала разберитесь, что у вас вообще есть. Какие диалоги, где лежат, в каком формате, сколько места занимают. Без этой карты всё остальное — гадание на кофейной гуще.
1-2 неделиОпределение сроков и категорий
Разбейте данные на группы: обычные чаты, финансовые переписки, жалобы и т.д. Для каждой группы — свой срок. Обязательно согласуйте с юристами и запишите, почему решили именно так.
1 неделяНастройка RBAC и логирования
Кто что видит? Кто может удалять? Кто ставит legal hold? Пропишите роли, настройте в системе. И включите логирование — чтобы каждый чих записывался.
2-3 неделиАвтоматизация удаления
Пишем скрипты, которые будут чистить данные. Сначала гоняем на тестовой базе — мало ли что. Обязательно с логами и возможностью откатить, если что-то пойдёт не так.
2-4 неделиLegal Hold процедуры
Пишем инструкцию: юрист видит риск → пишет заявку → IT ставит флаг → данные заморожены. И обратный процесс: дело закрыто → юрист подтверждает → снимаем hold.
1 неделяПилотный запуск
Не надо сразу на всё. Возьмите один канал или один тип данных. Запустите, понаблюдайте пару недель, соберите отзывы. Исправьте косяки. И только потом — дальше.
2-4 неделиМасштабирование и мониторинг
Когда пилот заработал — раскатываем на остальные системы. Делаем дашборд, чтобы видеть картину. И ставим напоминание: раз в год пересматриваем политику — вдруг что-то изменилось.
ПостоянноРеальный кейс: как это работает на практике
А теперь хочу рассказать реальную историю — без прикрас и преувеличений. Прошлым летом к нам обратилась компания, которая занимается онлайн-образованием в Казахстане. Крупная, несколько тысяч студентов, курсы от программирования до дизайна. Общение с клиентами идёт через WhatsApp (потому что студентам так удобнее), Telegram (там учебные группы) и чат на платформе (для технических вопросов).
Проблема была классическая: никакой политики хранения. Вообще. Всё просто копилось годами. База данных раздулась до неприличных размеров, расходы на облако росли, а когда кто-то просил удалить свои данные — начинался квест с поиском по всем системам вручную.
Что сделали
категории данных
сокращение объёма
инцидентов за год
- Общие чаты поддержки: хранение 6 месяцев, потом автоудаление. Для аналитики — анонимизированные данные без привязки к студенту.
- Переписка по платежам: хранение 5 лет, привязка к финансовым документам. Legal hold при любых спорах.
- Персональные консультации: хранение 2 года после завершения курса. Студент может запросить удаление раньше.
Что получили в итоге? Во-первых, расходы на хранение упали примерно на 60% — просто потому что убрали весь информационный мусор. Во-вторых, когда приходит запрос от клиента «удалите мои данные», они тратят на это 20-30 минут вместо прежних нескольких часов. В-третьих, и это самое важное — они спят спокойно. Потому что знают: если завтра придёт проверка или клиент подаст в суд, у них есть чёткая политика, всё задокументировано, всё по правилам. Это дорогого стоит.
Готовы навести порядок в данных?
Поможем разработать и внедрить политику хранения диалогов: от аудита текущего состояния до автоматизации удаления и настройки legal hold.
Обсудить проектЧто ещё почитать по теме
Data retention — часть более широкой темы AI governance и безопасности. Вот статьи, которые дополняют эту тему:
- AI governance в CRM: политики, роли и аудит — pillar-статья о комплексном подходе к управлению AI-рисками
- Incident response для AI — что делать, если что-то пошло не так: утечка, ошибки бота, репутационные риски
- DLP для AI: маскирование PII и политики хранения — технические аспекты защиты персональных данных
- Аудит AI-решений: чек-лист для службы безопасности — как проверить, что ваша AI-система соответствует требованиям
- Threat modeling для LLM-бота — 12 угроз и как их закрывать архитектурно
Остались вопросы?
Напишите нам — обсудим вашу ситуацию и подскажем, с чего начать. Первичная консультация бесплатная.
Задать вопрос