Using model outputs for training and distillation

This guide helps you record the origin and permitted use of training material. It is not legal advice, a training recipe or a permission finding for a real account.

Useful examples produced during an AI evaluation may look like a ready-made training dataset. Using them to train another model is a separate proposed activity—not simply keeping a copy of an output.

Before taking that step, trace what entered the generating service, what came out, what people added and how the trained model will be used.

The question is not only “Do we own the output?” It is:

Can we use every contribution in this training and delivery plan, under the terms that actually apply?

Output ownership alone does not settle confidential inputs, third-party material, training-use restrictions, annotations, model-component terms or redistribution.

The practical output of this guide is one input-to-delivery record for a proposed dataset and trained-model use.

Name the activity before checking permission

These activities are related, but they are not interchangeable:

Activity	What it means here
Ordinary output reuse	Using a generated result in a document or workflow, subject to the relevant checks—not using it to train another model.
Synthetic examples	Generated records resembling the examples a workflow might encounter. “Synthetic” does not establish that confidential or third-party material was absent from their creation.
Fine-tuning	Adjusting a model using an additional dataset.
Knowledge distillation	Transferring some behaviour from a larger model or ensemble to a smaller model using teaching signals.

Hinton, Vinyals and Dean’s Distilling the Knowledge in a Neural Network describes the technical idea of distillation. The paper’s primary landing page was checked 5 October 2026. It does not grant permission to use a service’s outputs or a downstream checkpoint.

Describe what you intend to do rather than relying on the label “distillation”. For example: generate examples, have staff annotate them, then use the dataset to train a smaller internal classifier.

That plan needs both a technical description and a permission trail. Evidence that a model can learn from a dataset is not evidence that the firm may create and deliver it.

Draw the input-to-delivery chain

Start with:

Input → generating service/model → output → curated dataset → trained model → delivery

If the trained model is a distillation student, identify it as such. If it starts from a pretrained base checkpoint, identify that checkpoint too. Do not assume every classifier has a pretrained base.

For each stage, record the following.

Stage	What to identify
Input	Prompt material, retrieved documents, examples and instructions. Separate sources where their origins or conditions differ.
Generating service/model	Exact service, account arrangement, model/version where available, relevant settings and applicable terms at the time.
Output	Batch identity, generation date, review status and proposed uses. Do not assume originality or exclusive rights.
Curated dataset	Dataset revision, selection, filtering, edits, annotations, removals, exclusions and contributors.
Trained model	Model identity; training or adaptation proposed; base checkpoint where used; relevant component-rights record.
Delivery	Staff-only application, client access or distribution of files. Record the actual plan and its exclusions.

If you are still planning the work, record proposed identities and unresolved choices honestly. Do not fill future batch IDs, review results or approvals as though the work has happened.

Copy the evidence record

Use one record for the proposed dataset and use. Within it, repeat these fields for each relevant stage and transfer.

Field	What to enter
Exact identity	[Source set, service/model, output batch, dataset revision, trained model or delivery method]
Origin, version and dates	[Source; URL or internal reference; revision; creation/generation and retrieval dates as relevant]
Contributors	[Who supplied, authored, generated, selected, edited or annotated the material]
Proposed action	[Submit, generate, retain, annotate, train, fine-tune, evaluate, deploy internally, provide client access or redistribute]
Applicable terms and obligations	[Agreement, policy, licence or confidentiality obligation; scope; version/effective date; incorporated terms]
Permission evidence	[Relevant passage or evidence reference; what action it supports; unresolved interpretation]
Information sensitivity	[Synthetic, internal, client-confidential, personal or third-party; classification owner; access limits]
Retained evidence	[Permitted copies or references; manifest; transformation history; approvals; evidence location and access owner]
Status and next check	[Supported / unknown / conflict / not applicable—with reason; affected action; named owner; next check and due date]

Retain evidence in an appropriately restricted location. A provenance record should not become an unnecessary second copy of confidential prompts or client material.

Check the transfers, not just the items

A complete inventory does not establish permission for every movement through the chain.

• Input → service: may this material be submitted to this service under the proposed account and configuration?
• Service → output: what terms govern generation, retention and the proposed output use?
• Output → dataset: may the outputs and any added material be selected, edited, annotated and retained for this purpose?
• Dataset → trained model: is the proposed training use supported, including relevant contributor and model-component conditions?
• Trained model → delivery: does the evidence cover this delivery method and audience?

Permission to submit an input does not automatically permit retaining the output for training. Permission for internal training does not automatically permit client access or distribution of model files.

Where a pretrained checkpoint or other model component is involved, link to its exact-artefact rights record, using the exact-weight licence worksheet to record permissions and unresolved rights questions. This guide records the additional training-material trail; it does not replace that component review.

Why output ownership is not the whole answer

The public OpenAI Services Agreement distinguishes output ownership, responsibility for input rights, restrictions concerning development of competing models and defined exceptions.

The checked page states updated 1 December 2025; effective 1 January 2026. Its coverage is limited to the business and developer services it identifies. That public page does not establish which agreement governs a firm’s actual account, whether an exception applies or how its proposed model would be treated.

The Google Gemini API Additional Terms, page-stated effective 23 March 2026, separately address generated-content ownership and restrictions concerning developing competing models. They also incorporate other API terms and policies.

That is a second example of separate questions—not a finding about an Australian account, a Vertex AI arrangement, an older agreement or a derived dataset.

Neither example establishes a blanket rule that generated material may—or may not—be used for training.

Retain the exact applicable agreement and service-specific terms relevant to the generation and intended use. Where material language remains unclear, seek qualified review and hold the affected action pending resolution. Do not infer eligibility for an exception from a product description or the fact that the intended model is small or internal.

A fictional permission gap

Entirely fictional and untested. No real vendor account, client data, model, agreement or classifier has been inspected.

A consultancy proposes to generate short synthetic descriptions of routine practice documents, have staff label them and train a smaller internal classifier.

Its first record exposes these gaps:

Transfer	Fictional entry	Status and next check
Input → service	Prompts would use an internal category list. Its contributor and confidentiality status have not been checked. The service and applicable account terms are unidentified.	Hold submission. The workflow owner identifies the list’s source and information class, then records the proposed service and terms.
Service → output	Generated descriptions are proposed as examples. Model/version, generation date and output batch do not yet exist as completed records.	Unknown. The review must establish support for the intended generation and training use before execution.
Output → dataset	Staff would remove near-duplicates and add labels. Contributors, dataset revision and exclusion criteria are not yet established.	Hold dataset preparation using generated material. Assign contributors and document the review and exclusion process.
Dataset → trained model	A smaller classifier is proposed. Its implementation, any pretrained base and training permissions remain unresolved.	Hold training. Identify the model and relevant components; link the applicable exact-artefact rights record, using the exact-weight licence worksheet where needed.
Trained model → delivery	Staff-only use is proposed. Client access, file distribution and production reliance are excluded.	Not approved. Record the boundary and reassess if delivery changes.

Even if the chosen generating service assigns output rights to the consultancy, that would not settle the category list’s provenance, training-use restrictions, staff contributions or any base-checkpoint terms.

The owner does not resolve those gaps by relabelling the examples “synthetic”.

The immediate decision is to hold generation for this training plan until the input boundary and applicable service terms have been established. The owner can meanwhile design a blank dataset manifest and review process. That private planning is not permission to generate or train.

If a restriction remains unclear, the next action is a bounded question for a qualified reviewer, supported by the exact agreement, intended training activity and delivery plan.

Copy the decision record

The evidence fields show what was checked. This closing record shows what may happen next.

Field	Decision
Record ID	[Dataset/use identifier; linked evidence records]
Decision owner and date	[Accountable person; decision date; relevant reviewer input]
Affected activity	[Generation, retention, dataset preparation, training, evaluation or delivery]
Outcome	[Ready for a defined scope / seek qualified review / hold affected activity]
Supported scope	[Inputs; service/account; dataset; model; users; delivery method; dates]
Exclusions	[Actions, information classes, audiences or delivery methods not covered]
Evidence and obligations	[Supporting references; required controls; owners]
Unresolved issues	[Gap; affected action; named owner; next check and due date]
Separate checks	[Information handling, operating responsibility, technical feasibility and task fit; status and owner]
Review triggers	[Changes to sources, account, service, model, terms, dataset, components or delivery]

Mark the training-material permission review ready for the defined scope only when material permissions and obligations are evidenced, contributors and components are identified, and unresolved issues do not affect that scope.

That outcome is not a legal or regulatory clearance, proof of model performance, or blanket production approval. Separate information-handling, operating and task-fit checks still apply.

Seek qualified review for an unclear material restriction, incorporated term, third-party right, confidentiality obligation or proposed exception. Give the reviewer the exact text, intended action and affected transfer.

Hold the affected action when essential identity or terms are missing, evidence conflicts or a necessary permission cannot be established.

Next action: draw the six-stage chain for one proposed dataset, then assign an owner and next check to every unresolved transfer before generating training material.

Sources and boundaries

Primary passages checked 5 October 2026: the distillation paper, OpenAI Services Agreement sections 3.3(e), 4.1 and 4.3, and Gemini API Additional Terms, Use Restrictions and Use of Generated Content. These are scoped public sources; they do not establish the agreement governing your account, an exception’s applicability or a real training plan’s permissions. The fictional example is untested. Model performance and deployment suitability remain unverified.