Юрист говорит: удаляй персональные данные, GDPR требует минимизации. Аудитор говорит: храни логи решений три года, иначе не докажешь. Инженер пожимает плечами: вендор хранит «сколько-то», трейсы лежат, пока диск не кончится. Все трое правы в своей системе координат — и все трое описывают один и тот же журнал AI-агента. Без единой retention-политики итог предсказуем: хранится либо всё вечно (и становится находкой для взломщика и discovery-запроса), либо ничего (и первое расследование упирается в пустоту). Разберём, как задать сроки хранения агентных записей так, чтобы сошлись регулятор, приватность и расследования.
Три силы и конфликт
Retention журнала агентов тянут три силы. Регуляторы и стандарты требуют долгого хранения доказательств: от полугода до десяти лет в зависимости от класса системы и юрисдикции. GDPR и data minimization требуют обратного: не хранить персональное дольше необходимого для цели, удалять по запросу субъекта (Article 17), документировать основания каждого срока. Операционка требует третьего: дешёвого хранения горячих логов для разбора инцидентов «здесь и сейчас» и предсказуемых затрат. Политика — это задокументированное разрешение конфликта: какой класс записей, сколько, на каком основании, кем утверждено, как удаляется. Без письменного основания любой срок — произвол, который не защитит ни в суде, ни у регулятора.
Что говорит EU AI Act
С августа 2026 года high-risk положения применяются в полную силу, и логирование — в их числе. Article 12 требует технической возможности автоматической записи событий lifelong системы; Article 19 обязывает провайдера хранить контролируемые им логи срок, соответствующий назначению, минимум шесть месяцев; Article 26(6) накладывает те же шесть месяцев на деплоера для его логов. Отдельный регламент сдвигал даты применения — детали сверяйте с актуальной редакцией, но направление однозначно: полгода — пол, а не потолок. Черновик стандарта Agent Audit Trail (август 2026) рекомендует 12 месяцев для high-risk (с запасом сверх минимума — под циклы аудита и расследований) и 6 месяцев для general-purpose, с оговоркой про более длинные отраслевые сроки. Ключевое для деплоеров: определите handoff — кто контролирует какие записи, как деплоер их забирает и хранит, как контракт сохраняет доступ. «Логи у вендора» без handoff — это отсутствие логов в день проверки.
Классы записей и сроки: матрица
Один срок на всё — главная ошибка. Рабочая матрица разводит классы:
| Класс записей | Срок | Основание |
|---|---|---|
| Audit trail high-risk решений | 3–7 лет | Colorado AI Act (3 года consequential decisions), отраслевые schedules, SOC 2 |
| Policy decision records | 3 года | Доказательство работы контролей (Type II) |
| Версии политик и конфигов | Жизнь агента + 3 года | SOC 2 CC8.1, ISO 42001; история в git |
| Идентичности агентов | Жизнь агента + 3 года | Привязка действий к субъектам |
| Impact assessments | Жизнь агента + 5 лет | EU AI Act Art. 9(7) |
| Incident reports | 5 лет | SOC 2 CC7.4, EU AI Act Art. 62 |
| Промпты и ответы с PII | 90 дней (или короче по запросу) | GDPR minimization; redaction до хранения |
| Операционные логи без PII | 1–2 года | Внутренняя политика, TTL-автоматика |
| Записи под legal hold | Расследование + 3 года | Ручной режим, подпись Legal |
Практика подтверждает вилку: Hanzo фиксирует паттерн «audit logs от 12 месяцев, промпты/ответы 90 дней – год, regulated 3–7 лет». Для каждого класса в политике: источник требования, минимум и максимум, триггер отсчёта, владелец, метод удаления, доказательства исполнения.
Дефолты вендоров: не полагаться
Карта дефолтов провайдеров (Hanzo, 2026) показывает разброс, делающий «оставить как есть» неприемлемым: от 30 дней enterprise до бессрочного хранения consumer-планов, от удаления загрузок за 48 часов до трёхлетнего хранения промптов, от zero-retention по запросу до судебных preservation order с бессрочностью. Правило: поверх вендорских дефолтов кладётся собственная политика, а расхождения фиксируются как риски. Особо — обучение на данных: если провайдер вправе использовать ваши логи для тренировки, срок «хранения» становится бесконечным в чужой модели — это отдельный пункт политики и договора.
Tombstone: удалить и сохранить цепочку
Удаление из hash-chained журнала обязано не рвать цепочку: запись заменяется tombstone — маркером с сохранением хешей, метаданных (класс, основание удаления, кто, когда) и без содержимого. Верификация цепочки проходит через tombstone, GDPR-запрос исполнен, аудитор видит не дыру, а документированное удаление. Правила: tombstone пишется тем же подписанным механизмом, что и обычные записи; содержимое удаляется из всех реплик и бэкапов в пределах backup window (обычно до 30 дней — фиксируйте в политике); удаление во время hold или расследования запрещено технически, а не инструкцией.
Legal hold как исключение
Hold приостанавливает обычную жизнь данных: при предвидении спора, расследования или регуляторной проверки удаление по TTL останавливается для охвата hold, записи фиксируются, доступ сужается. Охват обязан покрывать все AI-данные: промпты, ответы, траектории, версии политик и моделей, eval-результаты, переписку по инциденту. Операционализация: инвентарь AI-платформ (hold нельзя наложить на то, чего нет в списке); маппинг дефолтов вендоров против hold-обязательств; процедура снятия hold с возобновлением TTL; доказательства каждого шага. Retention и hold — два слоя одного фреймворка: правила по умолчанию плюс механизм исключений.
Автоматика: TTL, review, доказательства
Ручное удаление — это риск и конфликтов с hold, и «забыли удалить». Зрелость по AI Governance Institute: политика с периодами по типам и тирам риска, маппинг на регуляции, автоматические TTL с тестами enforcement, ежегодный review с DPO и Compliance, документированный hold-процесс. Хранилища подбираются под классы: immutable/WORM для production audit (legal hold из коробки), TTL-хранилища для операционных, git для версий политик, append-only для цепочки. PII в записях — шифрование at rest и доступ по ролям.
Чеклист политики
- Классы записей со сроками, основаниями, владельцами и методами удаления — письменно, с подписями Legal/DPO.
- EU AI Act: 6+ месяцев провайдер и деплоер, handoff определён и проверен сквозной записью.
- GDPR: минимизация, redaction до хранения, Article 17 через tombstone без разрыва цепочки.
- Дефолты вендоров замерены и перекрыты своей политикой; обучение на логах — отдельный пункт.
- Legal hold: инвентарь платформ, процедура наложения/снятия, TTL останавливается технически.
- TTL-автоматика с тестами; ежегодный review сроков; бэкап-окно учтено в удалении.
- Экспорт для регулятора: фильтр по агенту/пользователю/периоду, CSV/JSON, за часы, а не недели.
Где Codenik
Codenik пишет журнал сразу с retention-классами: audit trail решений — долгий класс с WORM-семантикой, операционные записи — с TTL, PII — с redaction до хранения. Удаление идёт tombstone-механизмом без разрыва hash-цепочки, hold накладывается одной кнопкой с остановкой TTL по охвату, экспорт для регулятора — фильтр и выгрузка. Политика перестаёт быть документом в вики: сроки enforced кодом, удаления доказуемы, hold нельзя «забыть снять» — у него владелец и срок пересмотра. DPO и аудитор читают одну и ту же систему с разных сторон — и оба находят своё.
Короткий вывод
Retention — это не «сколько хранить», а разрешение конфликта между «докажи» и «удали», записанное по классам записей с основаниями. Полгода минимум по AI Act, годы для high-risk и инцидентов, 90 дней для PII, tombstone для удаления, hold для споров, автоматика для всего. Напишите матрицу до первого запроса регулятора — после него писать поздно.