Skip to main content

Data Retention Policies: How Long to Keep AI Governance Records

Data Retention Policies: How Long to Keep AI Governance Records

AI governance teams usually make one of two mistakes with retention. They keep almost nothing and cannot explain a past decision, or they keep everything indefinitely and create a second privacy problem. Keeptrusts helps you avoid both outcomes by separating provider retention, gateway decision retention, and exportable evidence workflows. That makes it easier to decide what should exist for minutes, what should exist for months, and what should be archived only when a review actually requires it.

Use this page when​

  • You need a retention policy for AI governance records such as events, exports, and review evidence.
  • You want to distinguish upstream provider retention from your own audit and compliance retention.
  • You need a practical operating model instead of a vague "keep it for compliance" instruction.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, compliance, privacy, and audit reviewers

The problem​

Retention in AI governance is easy to blur because several different stores are involved. Upstream providers may retain traffic for some period unless you explicitly constrain them. Keeptrusts itself records gateway decision events for observability and evidence. Export workflows then produce additional artifacts that may be downloaded, archived, or copied into other systems. If you talk about "the retention period" as if it were one thing, you will almost certainly over-retain some records and under-retain others.

There is also a minimization issue. Teams sometimes keep more governance data than they need because the original prompts were never sanitized properly. Once sensitive content is redacted before the provider call and high-risk terms are blocked earlier, the event record becomes easier to keep for the period you actually need. Good retention policy begins with good minimization.

Finally, auditors and incident responders do need enough history to reconstruct what happened. A retention period that is too short makes investigations weak and compliance reviews expensive. The goal is not to keep as little as possible. The goal is to keep the smallest set of records that still preserves accountability.

The solution​

Use a three-layer model.

First, control provider retention explicitly with Data Routing Policy. If a workload requires zero retention or strict maximum retention days, encode that on the provider target and let the gateway remove non-compliant routes before traffic is sent.

Second, decide how long Keeptrusts should keep gateway decision events for operational review. The kt events documentation notes that API-side retention is controlled by KEEPTRUSTS_EVENT_RETENTION_HOURS. That is the right layer for deciding how long the governed event trail should remain queryable in the platform.

Third, use kt events and kt export-jobs to create durable evidence artifacts only when a review, monthly control, or regulatory obligation requires them. That keeps the long-term archive intentional instead of automatic.

Implementation​

This is a simple operational pattern for separating platform retention from review exports:

export KEEPTRUSTS_EVENT_RETENTION_HOURS=2160

kt events export --since 30d --format json --output ai-governance-events-30d.json

kt export-jobs create --type audit-log --format csv \
  --date-from 2026-05-01 --date-to 2026-05-31

The first line sets a 90-day event-retention window in hours at the API layer. The second line produces a direct JSON export for a recent operational period. The third line creates an asynchronous audit-log export for a formal monthly review. Those are different retention acts and should be governed separately.

In policy, pair that evidence plan with strict upstream handling. If a workload should never be retained by a provider, set require_zero_data_retention: true and max_retention_days: 0 in Data Routing Policy. If a workload can tolerate a bounded provider window, encode that bound explicitly instead of relying on a contract summary.

From a records-management perspective, define at least four classes of AI governance data.

  1. Short-lived operational events used for active monitoring.
  2. Incident or review exports created for a bounded investigation window.
  3. Scheduled evidence artifacts kept for periodic audit or regulator response.
  4. Anything else that should not exist because the data was never necessary to keep.

This is where Review Alerts and Evidence and Export Evidence for a Review become operationally important. They help teams create evidence packages on purpose rather than keeping every possible record just in case.

Results and impact​

The most important outcome is that retention becomes explicit. Teams can explain which records are transient, which are preserved for audit, and which upstream paths are prohibited from retaining data at all.

The second outcome is lower long-term exposure. When event retention, export creation, and provider retention are treated as separate controls, there is less pressure to keep everything forever.

The third outcome is better review quality. Auditors and incident responders receive structured exports created for a defined window, rather than incomplete snapshots pulled from whichever system still had data available.

Key takeaways​

  • AI governance retention is not one control. It includes provider retention, platform event retention, and exported evidence retention.
  • Data Routing Policy controls the provider side of the problem.
  • KEEPTRUSTS_EVENT_RETENTION_HOURS controls how long gateway decision records remain in the platform.
  • kt events and kt export-jobs let you create evidence artifacts deliberately instead of storing everything indefinitely.
  • Good retention policy starts with good minimization through PII Detector and DLP Filter.

Next steps​