OpenAI Usage Policies Update: What Changes Nov. 20
OpenAI announced Usage Policies changes on October 21; the revised rules take effect November 20 and add review for model-access intermediaries.
The OpenAI Usage Policies update was announced on October 21, 2026; the revised page lists November 20 as its effective date. The clearest developer-facing change is a prior-review requirement for services that provide third parties direct access to OpenAI models, including model routers and AI gateways. November 20 is a future effective date, not proof that the new text is already in force.
For teams building on the API or offering model access to customers, map what a user can do through each feature. OpenAI says partners providing its models must maintain consistent safeguards, investigate possible violations, take appropriate action, and coordinate enforcement.
OpenAI Usage Policies update: who will need prior review?
The November 20 policy revision will require prior review and approval for a platform or other service enabling third parties to directly access OpenAI models. OpenAI names model routers and AI gateways as examples. Integration alone will not trigger this requirement for an application’s own features.
The rule turns on what a service enables, not its label. One writing app calls a model behind its own summarize button; a gateway lets customer teams choose a model and send their own prompts through it. These examples help interpret the policy, not classify specific products.
A product can combine both patterns, such as a built-in assistant and a configurable endpoint for other teams. Map the paths separately: who chooses the model, who supplies prompts, and whether customers get a direct-access layer. This identifies the feature to compare with the intermediary clause; it does not predict approval.
Neither page states review criteria, timing, or approved partners; November 20 is the effective date, not a stated submission deadline.
What the training restriction covers
The November 20 revision will prohibit using OpenAI models or outputs to prepare material or signals for models intended as alternatives or substitutes for OpenAI models or services. Examples include training data, rubrics, labels or rankings, and selecting examples. It will permit research, software development, evaluation, benchmarking, and product work within policy limits.
For each workflow, note which model produced the output, which model or product is being improved, and where the output goes next. This suggested record follows the output from its origin to its eventual use. Keep that chain visible when a dataset moves between an evaluation team and a training team.
The agreement exception has a defined scope
The November 20 revision will preserve uses permitted by the applicable agreement. The separate Services Agreement defines a Permitted Exception covering models primarily intended to categorize, classify, or organize data, such as embeddings or classifiers, provided they are not distributed or made commercially available to third parties. It also covers tuning or customizing models supplied through OpenAI’s fine-tuning or other services listed on its Pricing Page. These conditions are contract context, not an additional feature announced on October 21.
For an original planning example, compare an internal classifier with a classifier intended for sale to other companies. Their distribution plans differ even if their technical architectures look similar. Record that plan alongside the model’s purpose before considering an exception. Do not translate the category name into approval of a particular training run.
The previous Usage Policies version is dated October 29, 2025. The current page links it as a separate revision, not a side-by-side redline; the prior text lacks the intermediary-approval clause.
Human review under the November 20 revision
The November 20 revision will prohibit automating high-stakes actions, decisions, transactions, or submissions that materially affect rights, safety, essential access, or other consequential interests in sensitive areas without human review. Examples include legal, medical, and financial workflows.
The product question is where the consequential step occurs. Drafting a legal summary for a professional to inspect differs from submitting a decision that affects someone’s access to a service without a person reviewing it. This is an operational example, not a legal conclusion.
Map a sensitive action from model output to its destination: shown to a user, sent to another service, or used to make or submit a decision. Identify where a person can inspect and change the result before it takes effect. This locates workflows for closer review; it is not a prescribed compliance process.
What to check before November 20
Turn the policy read into a review worksheet. For each concern, write the relevant section, the workflow in scope, the evidence examined, and one unresolved question. Separate what the team knows from what it assumes. Keep the worksheet linked to product documentation so someone outside the project can reproduce the reasoning.
Link the decision to a copy of the relevant contract and policy revision. Record which feature was reviewed, who signed off internally, and what evidence remains missing.
For access mechanics rather than policy interpretation, the site’s GPT-6 API guide covers direct API access; the model access guide separates product and API routes. They help identify which path a team uses, but do not decide whether it needs review. Read the October 21 announcement alongside the revised policy.