Risk Tiering LLM Applications by Data, Audience, and Autonomy

Why questionnaire reviews do not produce enforceable tiers

Regulated organizations typically run several kinds of LLM application at once: internal assistants, customer-facing chatbots, coding assistants, and agents that call tools. A questionnaire review can label each one, but the label usually lives in a register. Nothing in the execution path reads it. The result is predictable. Low-risk assistants wait in the same queue as high-risk agents, and high-risk applications ship with controls no stricter than anyone else's.

Risk tiering works when it is treated as a decision framework with two halves. The first half is a design-time decision about the application: what data it touches, who can reach it, and how much it can do without a person. The second half is interaction-level enforcement: what happens to each prompt, response, and tool call while the application runs. This guide keeps the two halves separate on purpose. The split is a design choice, not a regulatory requirement, but it makes it clear where a tier assignment ends and where a policy decision begins.

Define three dimensions with observable criteria

The levels below are a proposed design, not a published standard. Adapt the wording to your own data classification scheme. What matters is that each level can be determined from facts about the application rather than from opinion.

Data sensitivity is an input-side dimension. Users of externally hosted model APIs can reveal internal documents or their own customers' data in prompts, so score what can reach the model, not what the application is intended to receive. Include the provider's data-retention and data-use terms in the score, because retaining or reusing consumer data without clear notice and consent creates legal exposure.

Autonomy is best scored per action. Oversight should be commensurate with risk, autonomy, and context of use, and OWASP guidance on agents ties autonomy boundaries to action risk levels. An application's autonomy score is therefore the score of its riskiest reachable tool, not an average.

• Data sensitivity: 1 public, 2 internal, 3 confidential, 4 regulated personal or health data. Raise the score if provider terms allow retention or reuse.
• Audience exposure: 1 a single team, 2 all internal staff, 3 authenticated customers, 4 anonymous public users.
• Autonomy: 1 suggests only, 2 reads through tools, 3 acts with human approval, 4 acts independently.

Combine scores into tiers and justify the boundaries

The sources prescribe no combination method, so choose one and document it. A simple rule is that the highest of the three scores sets the tier. It is easy to audit and errs toward protection. Add explicit overrides where the rule is too permissive, for example a minimum of Tier 3 for any application that combines regulated data with tools that write to other systems.

To justify where one tier ends and the next begins, borrow the reasoning in the EU AI Act's treatment of stand-alone high-risk systems: consider the severity and probability of harm in light of intended purpose. Record a short statement for each application on what the worst credible outcome is and how likely it is. Because classification depends on intended purpose, one underlying model can sit in different tiers across different applications. Re-score whenever the purpose, data sources, audience, or tool set changes.

Example runtime control sets by tier

These control sets are illustrative starting points. Each action applies to individual interactions and tool calls, and each should be configured, not assumed.

• Tier 1 (all scores 1): Allow by default. Apply a baseline rate limit. Keep interaction metadata.
• Tier 2 (highest score 2): Allow with redaction of identifiers and secrets. Rate limit per user. Block data categories the application should never receive.
• Tier 3 (highest score 3): Redact and block by default. Escalate write actions and external sends for human approval. Record structured decision metadata.
• Tier 4 (highest score 4): Block by default and allow only listed tools. Require human approval for every consequential action. Apply strict rate limits and review the tier on a schedule.

Tool-call approval and the evidence that proves enforcement

The application tier sets a ceiling, but approval decisions belong at the tool-call level. Map every tool or action to a risk level and let only mapped low-risk tools run without review, which mirrors the OWASP example. An unmapped tool should default to the most restrictive treatment.

For evidence, OWASP recommends structured decision metadata for high-risk actions. Define its schema so that one record links the tier assignment to the action taken. A workable record contains the application and its tier, the dimension scores and the date they were assigned, the policy version in force, the action requested, the policy decision (allow, redact, block, rate limit, escalate), and for escalations the approver and outcome. Together these show what the application was permitted to do and what it did.

Evidence of assignment alone is not enough. High-risk systems under the EU AI Act are expected to perform consistently in accuracy, robustness, and cybersecurity throughout their lifecycle, so enforcement should be monitored over time. Sample decisions regularly, check for blocked or escalated patterns that indicate a wrong tier, and re-tier when they appear.

Aligning tiers with frameworks, and where tiering stops

Use the NIST AI RMF and its Generative AI Profile as organizing frameworks for the program, and map tier criteria and controls to specific sections after reviewing the documents. Add sector requirements as overrides on the data or audience dimensions where they apply to your business.

Keep EU classification separate from internal tiers. The EU AI Act defines four levels: unacceptable, high, transparency, and minimal or no risk. High-risk status depends on intended purpose and use in pre-defined areas such as employment, education, and essential services. An internal Tier 1 label does not place an application outside those areas, so use them as a screening question before scoring. As of October 2026, the European Commission lists 2 December 2027 for high-risk obligations, and the Digital Omnibus on AI, proposed in November 2025, addresses application timing. Check the current text before fixing a compliance schedule.

Application-level tiering stops at the decision about what an application may be. It cannot see a specific prompt carrying regulated data or a specific tool call with unusual parameters. Those are interaction-level questions, and they need enforcement in the path.

Enforcing tier policy at runtime with Trussed

Trussed is one way to apply tier-specific policy in the execution path. It enforces policy across models, agents, tools, MCP servers, AI sites, and coding assistants, with the actions described above: allow, redact, block, rate limit, and escalate for human approval. Enforcement is scoped to individual interactions and tool calls, so the tier your team assigns becomes policy that is enforced at runtime, not reviewed after the fact.

Enforcement generates audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Trussed does not assign tiers for you, and it does not provide transaction-level governance or end-to-end tracing of agentic workflows. The tiering method in this guide stays yours.