Start by reducing unnecessary data growth, because storage, movement, and cooling drive a large share of the footprint. Classify data by business value, remove duplication, tier infrequently used information, and delete what no longer needs to exist. That approach lowers resource use without constraining legitimate AI work.
Why This Matters for Security Teams
Reducing AI’s environmental impact is not just a sustainability exercise. It is an operational efficiency issue that affects cloud spend, storage sprawl, model latency, and the amount of data that must be protected. The fastest gains usually come from eliminating waste before debating model choice or infrastructure redesign. That means treating data minimisation, lifecycle management, and usage tiering as core governance controls, not optional cleanup.
Security teams often miss that excessive data retention also expands the attack surface for secrets, prompts, logs, and training artefacts. The State of Secrets in AppSec research shows how quickly weak governance can turn into long-lived exposure, while the NIST SP 800-53 Rev 5 Security and Privacy Controls gives teams a control baseline for retention, access, and auditability. In practice, many security teams encounter AI footprint issues only after storage bills, governance exceptions, or unbounded telemetry retention have already grown into a resource problem.
How It Works in Practice
The practical goal is to reduce AI workload footprint without blocking model development or legitimate experimentation. Start with data classification, then apply disposal rules that match business value. High-value training and evaluation datasets should be curated, versioned, and protected. Low-value, duplicate, or stale data should be deleted or moved to lower-cost storage. For prompts, embeddings, logs, and trace data, retention windows should be explicit and tied to the use case rather than set indefinitely.
Current guidance suggests teams should also look at the AI pipeline itself. Large-scale pre-processing, repeated re-indexing, and unnecessary retraining can create avoidable compute and storage demand. Where possible, use smaller task-specific models, cache outputs, compress artefacts, and avoid copying datasets across multiple tools or regions. This is especially important when AI systems are connected to broader identity and secrets workflows, because duplicated operational data often includes credentials or sensitive metadata that should not be retained longer than necessary. The DeepSeek breach is a useful reminder that AI data sprawl can become both an environmental and security liability.
- Set retention periods for training data, embeddings, logs, and feedback traces.
- Tier cold datasets and archive only what has a documented reuse case.
- Deduplicate files and pipeline artefacts before storage or re-indexing.
- Use governance gates for new AI data sources, especially third-party or scraped content.
- Measure compute, storage, and data movement as part of AI workload review.
This guidance tends to break down in highly distributed environments where teams copy datasets across many clouds, notebooks, and sandboxes because there is no authoritative owner for the data lifecycle.
Common Variations and Edge Cases
Tighter data retention often increases governance overhead, so organisations have to balance sustainability gains against model reproducibility, compliance, and audit needs. That tradeoff is especially real in regulated environments, where some prompts, outputs, or lineage records must be preserved to support investigations or validation. Best practice is evolving here, and there is no universal standard for how long every AI artefact should be kept.
Edge cases include active model retraining, safety evaluation, and incident response. In those cases, deleting everything quickly can undermine investigation quality or make it impossible to reproduce a model behaviour issue. A better approach is to classify artefacts by purpose and apply different retention rules to production data, test data, and forensic snapshots. Teams should also be careful not to treat all telemetry as disposable: some logs are needed for security monitoring, but long-term retention of verbose traces can create unnecessary storage growth and expose sensitive inputs.
For teams aligning sustainability with control maturity, the important point is that reduced footprint should never mean reduced accountability. Keep the minimum artefacts required for validation, then remove the rest on a schedule that is reviewed as part of NIST SP 800-53 Rev 5 Security and Privacy Controls governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST CSF 2.0 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern function supports accountable AI lifecycle and resource decisions. | |
| NIST CSF 2.0 | GV.RM-03 | Risk management should include storage, compute, and data sprawl tradeoffs. |
| EU AI Act | AI governance can require documentation, traceability, and prudent data handling. |
Keep enough AI artefact history for compliance, but limit collection and retention to documented needs.
