Why AI Models Now Launch in Gated Tiers

AI models used to launch as one thing you could either call or not call. Increasingly they launch as two or three things with the same name, where the difference is not capability but permission: who is allowed to use the ungated version, and what they had to sign to get there. Four vendors shipped that shape in the last two weeks. It is now the default, and it changes how you evaluate a release.

The pattern, in four recent releases

Look at what actually shipped rather than at the headlines.

Same architecture inside. Different safety configuration, different application process, different answer to the same prompt. OpenAI's own deployment safety page for Astra is explicit about the mechanism: it calls Astra the first model to reach the Critical level of cybersecurity capability under its Preparedness Framework, and describes trust-based access requiring researchers to meet specific criteria before they get unrestricted capability in biology and cybersecurity.

Why vendors are doing it

The straightforward reason is that safety frameworks now produce a binary that used to be a judgement call. When an internal evaluation says a model crosses a threshold in cyber or biology, the vendor has committed publicly to doing something about it. Withholding the model entirely costs revenue and hands the category to a competitor. Shipping it ungated breaks the commitment.

Tiering is the way out. Ship the capability, put the risky slice behind a verification programme, and the commitment survives contact with the roadmap.

There is a second reason nobody puts in the announcement. A verification programme is a customer list. It tells the vendor exactly which organisations are doing security research, drug discovery, or anything else worth knowing about, along with a stated use case and a named contact. That is a genuinely valuable asset acquired as a byproduct of a safety control.

Neither reason is sinister. Both are worth understanding before you plan around a tier.

What this breaks in your evaluation process

Three specific things, all of which have bitten teams already.

Benchmarks stop being comparable. A published score is measured on one tier. If you are on the other one, the number does not describe your system. When a vendor reports a coding or security benchmark for a gated variant and you are calling the general one, you are reading a different model's homework. It is a new way for a benchmark claim to be technically accurate and still wrong for you.

Refusals become a routing problem, not a prompting problem. A model that declines your security-tooling question may not be badly prompted. It may be the tier that is supposed to decline. Teams burn days rewriting prompts against a wall that is doing its job. The distinction between a tier boundary and a genuine refusal matters, and why models refuse safe-looking questions is the other half of that picture, seen from the model's side rather than the product's.

Your access can be revoked independently of the model existing. A verification programme has terms. Falling out of them removes your capability without any deprecation notice, because nothing was deprecated. That is a different failure mode from a model being retired, and your continuity plan probably does not cover it.

How to evaluate a tiered release

A short checklist that costs ten minutes and saves a sprint.

1. Identify which tier you can actually get. Before benchmarking anything, find out whether the gated tier requires an application, a legal entity, a named use case, or a review that takes weeks. If you cannot realistically get it, evaluate the open tier and ignore the gated numbers entirely.

2. Test the boundary early with your real prompts. Run ten prompts from the hard end of your actual workload on day one. You are looking for refusals that cluster around a theme rather than scattering randomly. Clustered refusals mean you are hitting a tier boundary.

3. Ask what happens to the gated tier's pricing. Verification programmes often start free and do not stay that way. Ask before you build.

4. Read which tier the system card describes. Frequently it is the ungated one, sometimes both, occasionally neither clearly. Reading a system card is now partly an exercise in working out which model it is actually about.

5. Write down which tier you shipped against. Six months from now, when behaviour changes, this note is the difference between a two-hour investigation and a two-day one.

Does this look like preview versus GA?

It resembles it and it is not the same thing, which is a distinction worth holding onto. A preview becomes generally available on a timeline; the gap closes. A gated tier is designed not to close. Nobody plans for the Cyber variant to become the default variant.

So the instincts you have built around preview and general availability mislead here. Waiting does not help. If you need the gated capability, apply now, because the wait is a process wait, not a maturity wait.

What to expect next

The obvious extension is more than two tiers, and the early signs are already there: HUMAIN's split is regional alignment rather than capability risk, which is a third axis appearing before the first two have settled. Expect models where capability, jurisdiction, and permission are three independent dials, and where "which model are you using" becomes an insufficient question.

The practical adaptation is small but real. Record the tier alongside the model name everywhere you record the model name. Your logs, your evals, your incident notes, your vendor questionnaire responses. It costs one field and it will save you an argument. If you are keeping a running view of releases, tracking AI news without drowning in it covers the wider habit.

FAQ

Why can I not just use the gated model?

Because access requires passing the vendor's verification, which typically means a named organisation, a stated use case, and agreement to additional terms. It is a process, not a purchase.

Is the gated tier a different model or the same one?

Usually the same base model with different safety configuration and system prompting. Vendors are not always explicit about this, which is why the system card matters.

Does a gated tier mean the open tier is worse?

At general tasks, usually not. The gap tends to be narrow and concentrated in the specific risk domain the gate exists for. Benchmark your own workload rather than assuming a broad penalty.

How do I know which tier I am on?

Check the exact model identifier you are sending, not the marketing name. The identifier is the only reliable signal, and it belongs in your logs.