Stage 1
Acquire
Collect or license candidate material from public sources, partnerships, internal datasets, human demonstrations, or generated examples.
Don't stop here
Hand-picked guides our readers explore right after this one.
Data analysis workflows with prompt engineering
Read the guideExpert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideMaster xAI Grok with real-time web access, deep reasoning, and X/Twitter integration prompts
Read the guideAI foundations guide · Checked August 13, 2026
Understand collection, filtering, licensing, human feedback, synthetic data, retrieval, provenance, bias, memorization, and why a fluent answer does not prove a model knows the truth.
Michael Okeje
AI data and model-development research · Last updated August 13, 2026
When people ask what an AI model was trained on, they often imagine a folder of documents that the model can open whenever it needs an answer. That is not the most useful mental model. Training usually adjusts a large set of parameters so the system becomes better at predicting, transforming, classifying, or generating patterns. The data shapes the model, but the finished model is not normally a searchable library with a neat record for every source.
The answer also depends on the stage. Pretraining gives a model broad exposure to language, code, images, audio, or other patterns. Post-training uses demonstrations, preference comparisons, safety examples, tool traces, and human feedback to make the system more useful and controllable. Retrieval adds current external material at answer time without necessarily changing the model's parameters. Evaluation data measures the system and may be deliberately kept out of training.
I think about training data as a chain of decisions rather than a single ingredient. Someone decides what to acquire, what can be used, how to represent it, what to remove, how to mix domains, how to label it, which examples to reward, and which failures to test. Those decisions affect capability, bias, memorization, privacy, copyright risk, and the limits users encounter. A model's fluent response can hide that chain unless the provider documents it and the deployer tests it.
Stage 1
Collect or license candidate material from public sources, partnerships, internal datasets, human demonstrations, or generated examples.
Stage 2
Record provenance, rights, permissions, language, domain, time period, and restrictions so later decisions are auditable.
Stage 3
Remove or reduce duplicates, unsafe material, corrupted files, personal information, low-quality text, and examples outside the intended scope.
Stage 4
Choose the proportions of domains, languages, modalities, quality levels, and synthetic or human data used for the training objective.
Stage 5
Use the data to adjust parameters or teach a model a task, with checkpoints, validation, and compute decisions.
Stage 6
Use demonstrations, preference data, feedback, tool traces, safety examples, and evaluations to shape behavior.
Stage 7
Test capability, factuality, robustness, bias, safety, privacy, memorization, and performance on representative tasks.
Stage 8
Watch real use, feedback, drift, incidents, new data requirements, and whether the model's limits are understood.
Data acquisition begins with a purpose. A general language model may need broad text and code; a medical system needs domain-specific evidence and careful validation; a speech model needs varied accents, noise conditions, and languages; a document assistant may get more value from a small, current retrieval corpus than from retraining a foundation model. More data is not automatically better. Data that is duplicated, stale, irrelevant, or poorly represented can add cost without adding useful capability.
Filtering commonly includes file and format checks, language identification, quality scoring, deduplication, safety classification, personal-data reduction, and source or domain rules. The exact pipeline is usually proprietary. Filtering can remove harmful or low-value content, but it can also remove minority language, dialect, technical, or cultural material if the quality rule mistakes unfamiliarity for noise. A clean dataset is not a neutral dataset.
Deduplication matters for both quality and evaluation. Repeated copies can give a model disproportionate exposure to a phrase, source, or style. Near-duplicate contamination can also make a benchmark look easier because similar material appeared in training. A responsible pipeline checks overlap between training, validation, and test data and records the method used, even when perfect separation is difficult at web scale.
Licensing is not one yes-or-no label. A data agreement can limit commercial use, redistribution, geography, retention, model training, or downstream outputs. Publicly accessible material can raise separate copyright, privacy, terms-of-service, or attribution questions. NIST notes that training-data provenance supports transparency and accountability, while also recognizing that data may be proprietary and subject to intellectual-property rights. Buyers should ask what the provider can document for the model and product they are actually using.
Human feedback is not an invisible finishing touch. People may write ideal answers, rank alternatives, label unsafe requests, correct mistakes, create tool demonstrations, or test adversarial prompts. The quality of that feedback depends on instructions, expertise, pay, language coverage, disagreement handling, and the examples selected for review. Post-training can make a model more helpful in common situations while also creating new refusal, style, or cultural failure modes.
Synthetic data sits between useful expansion and dangerous self-reinforcement. It can create rare examples, labels, translations, or controlled variations that are expensive to collect from people. It can also repeat the generating model's assumptions, make errors look authoritative, and reduce the diversity that helps a system handle unfamiliar inputs. The right question is not whether synthetic data is real. It is whether the data has a verified purpose, an independent quality check, and a measured effect on the target task.
Retrieval is a different intervention from retraining. A team can add an approved document collection at answer time, preserve citations, and update the collection without changing the foundation model. This is often safer for policies, prices, product documentation, and internal knowledge that changes frequently. It still requires access controls, deletion rules, freshness checks, chunking, and evaluation. A model's training data and a company's retrieval data should be documented separately.
Ask “which data, at which stage, for which purpose?” before drawing a conclusion about a model.
| Type | Role | Question to ask |
|---|---|---|
| Publicly available data | Web pages, books, code, forums, images, or other material accessible under a provider's collection and policy decisions. | Public access does not automatically resolve copyright, privacy, terms, provenance, or quality questions. |
| Licensed or partnered data | Material obtained through an agreement with a rights holder, archive, organization, or data provider. | The license scope, geography, duration, permitted uses, and downstream obligations matter. |
| Human demonstrations | Examples written, labelled, ranked, corrected, or reviewed by people to teach a desired task or preference. | Reviewers bring expertise and judgment, but their instructions, incentives, and population affect the result. |
| Synthetic data | Examples generated by a model, simulator, rules engine, or other process rather than directly observed from a person. | It can expand edge cases but may inherit errors, collapse diversity, or create self-reinforcing model habits. |
| Evaluation data | Held-out tasks, benchmarks, red-team cases, and production-like examples used to measure a model. | Evaluation data should be protected from leakage and should represent the actual deployment context. |
OpenAI publicly describes its training sources as including selected publicly available information, partnerships, and human feedback, while also describing separate privacy practices for business and API data. That is an example of why product data controls should not be inferred from a broad statement about foundation-model training. Read the terms for the exact product and account.
For current or high-stakes information, use retrieval, citations, source review, or a specialist workflow. For a broader explanation of retrieval, read how RAG works. For output testing, use AI evaluation. For business data boundaries, see AI governance.
NIST's AI risk-management guidance emphasizes provenance, transparency, accountability, and context-sensitive controls. You do not need a perfect record of every token to ask useful questions. You do need enough documentation to understand what a system was intended to do, who may be affected, what data shaped it, and how you will detect a material failure.
AI training data is the text, code, images, audio, video, labels, demonstrations, preferences, and other examples used to adjust a model's parameters or behavior. Different stages use different data: pretraining teaches broad patterns, post-training shapes instruction following and safety, and evaluation data measures performance rather than necessarily training the model.
OpenAI says its foundation models are trained using selected publicly available information, data from partnerships or licenses, and information provided or generated by human trainers and researchers, with different controls and terms for products. A provider's statement about data sources should not be generalized to every model or product.
A trained model is not normally a searchable document database. Training adjusts parameters so the model can predict and generate patterns. Models can still memorize or reproduce some content, especially under certain conditions, which is why privacy, copyright, provenance, and memorization research matter.
Data reflects the people, languages, institutions, decisions, and omissions represented in it. Filtering and labelling can add another layer of judgment. If a population, dialect, domain, or edge case is underrepresented or stereotyped, the model may provide lower-quality or harmful outputs for that context.
Synthetic data can expand coverage, protect some sensitive information, and create labelled examples, but it can also reproduce errors, amplify bias, reduce diversity, or drift from real-world distributions. It should be tested for utility, privacy, fidelity, and failure modes rather than treated as automatically safe.