Политика хранения данных

Политика хранения данных — это определённый, обычно автоматизированный набор правил, устанавливающий, как долго различные категории данных хранятся, прежде чем быть перенесёнными в более дешёвое хранилище или окончательно удалёнными, вместо того чтобы накапливаться бесконечно по умолчанию. Почему это важно для разработчиков AI/SaaS-продуктов: политика хранения находится на пересечении контроля затрат, комплаенса и доверия к продукту — неограниченный рост данных незаметно раздувает затраты на хранение и (для всего, что индексируется, например векторных эмбеддингов) на запросы со временем; такие регуляции, как GDPR, предоставляют пользователям законное право на удаление своих персональных данных по запросу, и продукт должен быть технически способен это выполнить, а не просто обещать; а специфичные для AI категории данных — сырые промпты/completion'ы LLM, потенциально содержащие чувствительный пользовательский ввод, загруженные документы, поданные в RAG-пайплайны, сгенерированные изображения/аудио — часто несут обязательства по хранению или ожидания пользователей, существенно отличающиеся от обычных логов приложения компании. Проектировать политику хранения постфактум, когда за годы неструктурированные данные накопились в десятке систем без чёткого владения, — существенно более сложная задача, чем закладывать её с самого начала. Как это работает: правила хранения обычно реализуются через сочетание политик жизненного цикла объектного хранилища (автоудаление или автопереход в другой класс хранения объектов старше N дней — механизм, описанный в разделе про объектное хранилище/S3), запланированных задач базы данных, которые удаляют или архивируют старые строки по истечении заданного TTL, и — критически важно для комплаенса — определённого процесса каскадного распространения запроса на удаление по всем системам, хранящим копию данных пользователя, включая производные данные вроде векторных эмбеддингов, сгенерированных из его документов, закэшированных ответов LLM, содержащих его ввод, и любых резервных копий. Важный и распространённый нюанс: «удалить строку пользователя» — не то же самое, что «удалить данные пользователя» в системе, где векторный поиск, кэширование и резервные копии потенциально хранят независимые копии или производные исходного контента — по-настоящему GDPR-совместимый процесс удаления должен учитывать всё это, а не только основную запись в базе данных. Практический пример: AI-SaaS определяет политику хранения, где сырые загруженные документы удаляются из объектного хранилища через 30 дней после отмены подписки, сгенерированные AI-результаты хранятся 1 год для справки клиента, и — что критически важно — запрос «удалить мой аккаунт» запускает каскадную задачу, которая удаляет строку пользователя, его документы из S3, его эмбеддинги из пространства имён векторного хранилища и очищает любые закэшированные ответы LLM, привязанные к его контенту, причём весь этот каскад логируется для целей комплаенс-аудита, вместо того чтобы полагаться на единственный оператор `DELETE`, затрагивающий только основную таблицу базы данных.