A Do Not Train setting is a restriction that tells an AI system not to use specified data for model training. It is usually enforced through data handling controls, contractual limits, or pipeline filters that separate training corpora from operational or customer data.
How Do Not Train works
A Do Not Train setting is a policy signal that separates governed data from model-training pipelines. It tells the AI stack to keep certain records out of training corpora, even when those records may still be used for live operations, retrieval, or service delivery.
The control matters because training data is durable. Once sensitive or restricted content enters a model-training flow, it can be copied into artefacts that are harder to inspect, roll back, or selectively delete. The practical goal is to preserve the boundary between operational use of data and model learning.
Where Do Not Train is enforced
In mature environments, Do Not Train is not a single switch. It is usually enforced through a combination of data classification, pipeline filtering, storage segregation, and contractual or policy constraints that govern which datasets may be consumed for training.
That means the setting has to survive handoffs across collection, preprocessing, labeling, feature generation, and vendor integrations. If any stage ignores the restriction, the data can still reach a training run even though the source system marked it as restricted.
It is also common for organisations to treat the setting differently across product modes. A customer or internal record may be acceptable for service operation, but still excluded from training, evaluation, or fine-tuning. That distinction is central to how the control is interpreted and audited.
Why Do Not Train matters for AI governance
Do Not Train is part of AI data-governance discipline, not just model hygiene. It helps organisations honour user expectations, contractual promises, sector-specific limits, and internal data-use policy while still allowing AI systems to operate.
The term also reflects a broader control problem: modern AI platforms often mix multiple data paths, and the organisation must prove that training inputs are bounded correctly. For governance teams, the issue is less about the label itself and more about whether the label is consistently respected across the full data lifecycle.
This is why many programmes pair the restriction with dataset inventory, provenance tracking, and review of vendor processing terms. A restriction that cannot be traced from source to pipeline to training job is weak in practice, even if it exists on paper.
What can go wrong if Do Not Train fails
When the control fails, restricted data may be absorbed into model weights, evaluation sets, or downstream derivatives. That can create privacy exposure, contractual breach, retention problems, and an inability to fully remove the impact later.
Failure often happens at the seams: a data export is reused without its policy tags, a preprocessing job strips metadata, or a third-party AI service applies broader training rights than the organisation intended. The consequence is not only unauthorized use, but also loss of control over where the data can reappear.
For teams operating customer-facing AI systems, the key question is whether restrictions are enforceable end to end, not whether a policy statement exists. A reliable Do Not Train posture depends on technical controls that match the legal and operational meaning of the restriction.
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 SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, and Manage AI Risks | Do Not Train is an AI data-governance control that manages training-use risk. |
| Recommendation — Map training-data restrictions into AI risk governance and verify they are enforced across the lifecycle. | ||
| ISO/IEC 42001:2023 | 4.2 — Understanding the needs and expectations of interested parties | Do Not Train often reflects contractual and policy obligations about AI data use. |
| Recommendation — Capture training exclusions as governed requirements and trace them through your AI management system. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Training pipelines should receive only the data they are authorised to consume. |
| CM-8 — System Component Inventory | Dataset and pipeline inventory are needed to verify where restricted data can flow. | |
| Recommendation — Restrict training pipelines to the minimum data required and block unauthorized dataset access. Maintain an inventory of datasets and pipeline components that could carry restricted training data. | ||
| GDPR | Art. 25 — Data protection by design and by default | Do Not Train can operationalize privacy-by-design limits on how personal data is reused. |
| Recommendation — Build training exclusions into system design so restricted data is not used by default. | ||
Practitioner Guidance
Why practitioners should care: Treat Do Not Train as a governance control over data movement, not as a simple preference flag. If the restriction is important enough to promise, it needs to be enforced in ingestion, preprocessing, vendor handling, and model build workflows.
What to watch for: Pay particular attention to shared datasets, copied exports, label loss during transformation, and third-party training terms that are broader than your internal policy. These are the places where a restriction most often breaks.
Practitioner takeaway: The setting is only meaningful when the operational path that touches the data can prove the data stayed out of training.
Related resources from NHI Mgmt Group
- What risks appear when enterprises train models on internal data instead of only fine-tuning them?
- How should organisations train IT teams for AI adoption?
- How should security teams train users when phishing emails are AI-generated?
- How should organisations train teams for cyber resilience in hybrid environments?