Artifact Retention and Redaction в 2026: сколько хранить traces, screenshots и tool outputs

Короткая версия

Хорошая artifact policy в 2026 обычно задаёт:

1. Что именно логировать
2. Что редактировать до записи
3. Где хранить raw vs sanitized artifacts
4. Сколько времени держать каждый класс
5. Кто может это видеть

Что особенно важно

• screenshots и tool outputs почти всегда требуют отдельной retention policy;
• redaction лучше делать до записи, а не post hoc;
• raw artifacts и production observability не должны жить в одном trust zone без ограничений;
• короткий retention иногда безопаснее и дешевле, чем бесконечный "debug archive".

Что опаснее: не сохранить один debug trace или бессрочно хранить raw screenshots и tool outputs?

1. AI-артефакты нужно делить по классам

Полезная базовая классификация:

• prompt / response text;
• retrieved context fragments;
• tool args and outputs;
• screenshots and browser artifacts;
• human review comments;
• observability spans and metadata;
• derived summaries and scores.

У каждого класса свой risk profile и своя полезность для debugging.

2. Redaction лучше делать до записи

Post-hoc masking полезна как дополнительный слой, но самый сильный путь:

• обнаружить sensitive field до записи;
• замаскировать raw value;
• сохранить safe placeholder;
• optionally держать raw copy в отдельно ограниченной зоне и только если это правда нужно.

Особенно полезно это для:

• tokens and secrets;
• personal data;
• financial identifiers;
• browser screenshots;
• copied documents.

3. Raw и sanitized layers лучше разводить

Практически полезно иметь:

Sanitized operational layer

Для обычной observability, alerting и product analytics.

Restricted raw layer

Для incident response, legal/compliance review и коротких forensic задач.

Такой split снижает шанс, что каждый инженер, reviewer или analyst будет видеть слишком много.

4. TTL должен зависеть от класса артефакта

Не все данные одинаково полезны и одинаково опасны.

Примерно:

• sanitized traces можно хранить дольше;
• raw screenshots и browser artifacts — заметно меньше;
• approval packets — по operational и audit-надобности;
• temporary tool outputs — часто совсем недолго;
• derived metrics and counters — дольше всех.

5. Human review artifacts тоже чувствительны

Часто забывают, что review queue накапливает:

• screenshots;
• snippets customer text;
• human edits;
• internal comments;
• escalation notes.

Если этот слой не covered by retention/redaction policy, privacy и tenant risk быстро возвращаются с другой стороны.

6. Что особенно часто ломают команды

Log everything forever

Самый классический anti-pattern.

Screenshot exceptionalism

К скриншотам относятся как к harmless debug aid, хотя они часто содержат максимум чувствительных данных.

Redaction after export only

Внутри основного хранилища raw уже лежит без ограничений.

No ownership for deletion

Непонятно, кто отвечает за cleanup и retention expiry.

Same access for all artifacts

Score card и raw browser session живут под одинаковыми правами.

7. Какие метрики полезны

Минимальный artifact dashboard обычно включает:

• percent of artifacts redacted at ingest;
• raw artifact retention age;
• screenshot volume and TTL compliance;
• access to restricted raw artifacts;
• deletion / expiry success rate;
• incidents caused by over-retention.

Пример retention policy

artifacts:
  sanitized_traces:
    ttl_days: 30
  raw_screenshots:
    ttl_days: 3
    access: restricted
  tool_outputs_raw:
    ttl_days: 7
    redact_before_store: true
  derived_metrics:
    ttl_days: 180

Простой ingest redaction hook

def sanitize_trace(payload):
    payload = redact_tokens(payload)
    payload = redact_emails(payload)
    payload = redact_payment_data(payload)
    return payload

Практический совет: retention policy должна начинаться не с вопроса "что удобно сохранить", а с вопроса "какой минимальный набор артефактов реально нужен для debugging и compliance". Всё остальное стоит считать кандидатом на более короткий TTL или полное отсутствие логирования.