Approved Model Tiers: Controlling LLM Usage and Spend Through Enforced Policy

Model tiering is an access-control problem first

An approved model tier is a named set of models, matched to the data classes, users and use cases that may reach them. A low tier might cover public or non-sensitive content. A higher-assurance tier might cover regulated data and consequential decisions, with stricter controls on who can call it and what happens to the request.

Without tiers, teams tend to fall into one of two patterns. They default to the most capable model for every request, which inflates spend. Or they adopt unapproved models to save money, which creates compliance exposure. Both patterns come from the same gap: the rules are not applied where the call is made.

The distinction that matters is between policy documented in a standard and policy enforced at runtime. The NIST AI RMF Govern category describes policies and procedures as in place, transparent and implemented effectively. A tier table in a wiki or a model-onboarding review shows intent. It does not stop a coding assistant, an agent or a script from sending sensitive data to a model outside the permitted tier, and it produces no record of what happened.

Criteria that assign models and use cases to tiers

Tier assignment should rest on a small set of documented criteria, each traceable to a framework your organization already answers to.

Legal and regulatory scope. AI RMF Govern 1.1 expects legal and regulatory requirements involving AI to be understood, managed and documented. Record which requirements drive each tier, including the sector rules that apply to your data, and cite them in the tier definition.

Risk tolerance. Govern 1.3 calls for risk management activity proportionate to the organization's risk tolerance. Give each tier an explicit tolerance, which then determines how strict its controls are.

Task definition. Map 2.1 asks you to define the specific tasks an AI system supports and the methods it uses. Summarization of internal notes and a decision that affects a customer belong in different tiers, so build the inventory of use cases before assigning anything.

Model capability and systemic-risk characteristics. The EU AI Act treats a general-purpose model as presenting systemic risk when it has high-impact capabilities or significant impact through its reach. Providers must keep technical documentation, including evaluation results, available to authorities on request. Capability disclosures such as input and output modalities, autonomy and tool access can inform tier placement. They are provider documentation, not a runtime control, so keep them in each model's tier file.

Add data sensitivity as the fourth working criterion. It is usually the one that decides most calls in practice.

Failure modes and how execution-path enforcement addresses them

Shadow model usage occurs when teams call models that were never placed in a tier. A default-deny rule for unlisted destinations, applied in the execution path, turns an unknown model into a blocked request rather than an unreviewed one.

Tier drift occurs when models, providers or regulations change while tier assignments stay fixed. The EU AI Act text has been amended since its adoption, and a consolidated version dated 27 July 2026 exists, so scheduled re-evaluation and versioned tier policy are needed. Versioning lets you show which rules applied on a given date.

Unapproved fallback routing occurs when a failover or substitution sends a request to a model the caller was never permitted to use. Check the substituted model against the same tier rules as the original.

Inconsistent enforcement occurs when one application applies tier rules and a coding assistant or agent does not. A single policy applied across all of them removes the gap.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. With 100+ models under one policy plane, a new model can be assigned a tier before its first use rather than discovered after it.

Audit-ready evidence, and spend as a consequence

An auditor will ask which models were permitted for which data classes, users and use cases, and what actually happened. Retain a decision record for each call that shows the policy version applied, the decision taken, the model requested versus the model permitted, and any redaction or escalation outcome. Keep the tier definitions, owners, exceptions and change history alongside it. Evidence that is a by-product of enforcement is more reliable than evidence reconstructed from application logs afterward.

Retention periods and data residency should be configurable per regulatory regime, since requirements differ. Trussed produces continuous audit-ready evidence from enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST, and supports self-managed deployment in the customer cloud with configurable retention and data residency.

Spend follows from the same boundaries. When a request is limited to its permitted tier, a high-capability model is not used by default for routine tasks, and rate limits cap the volume sent to expensive tiers. Predictable spend is a result of controlled access. Designing tiers around cost alone tends to weaken the compliance rationale that makes them defensible.