Which LLM Use Cases Require Formal Governance and Which Do Not: A Risk-Tiering Approach for Regulated Enterprises

Why uniform governance fails in both directions

Regulated enterprises are under pressure to govern every LLM deployment. Applying the same approval workflow and evidence burden to a meeting-notes summarizer and to a tool that supports credit decisions slows adoption without reducing risk. Under-governing the second case creates regulatory and audit exposure. Both are failure modes, and a defensible program treats them as equal.

In this guide, formal governance means four things working together: a documented policy for the use case, an approval decision by an accountable owner, runtime enforcement of that policy, and retained evidence of what the system was allowed to do and what it did. Not every use case needs all four at full depth. The purpose of tiering is to decide, with criteria you can show an auditor, how much of each a given use case gets.

The tiering unit should be the use case, not the model. Under the EU AI Act, classification follows intended purpose and the area of use, not the underlying technology. The same LLM can sit in a baseline tier for internal drafting and a formal tier when it supports an eligibility decision.

Six criteria that move a use case up a tier

The EU recitals classify stand-alone systems as high-risk based on intended purpose, the severity and probability of harm, and use in specifically pre-defined areas. NIST AI RMF leaves risk tolerance to the organization. A practical program therefore needs its own explicit criteria. These six are a working set, and they are a recommended internal method rather than a regulatory list.

Data sensitivity: does the use case process regulated, personal or confidential data, or only non-sensitive content? Decision impact: does output influence a decision about an individual, such as credit, insurance risk, employment or access to a service? NIST also expects a comparison against a human baseline where AI augments or replaces human decision-making, so document that impact.

Autonomy: does a person review each output, or does the system act on its own? Tool and system access: can it read only, or can it write, send, approve or change records? External exposure: do customers or the public interact with it directly? NIST notes that prioritization may differ for systems that interact directly with humans. Regulatory scope: does the use case fall in a pre-defined high-risk area such as credit scoring, insurance risk assessment, employment or biometrics?

Score each criterion, and let the highest-impact factor set the floor. One strong trigger, such as a decision about an individual, should outweigh several low scores elsewhere.

A three-tier model and what each tier requires

Three tiers are usually enough to separate real differences in control expectations without creating a classification program that is itself a burden. The depth of each control scales with the tier. Document the organization's risk tolerance and the process used to assign tiers, consistent with the NIST GOVERN 1.3 expectation that the level of risk management activity follows risk tolerance.

• Tier 1: Baseline: Internal use, non-sensitive content, no tool write access, no effect on individuals. Controls: acceptable use policy, named owner, inventory entry, standard data handling rules, basic usage monitoring.
• Tier 2: Managed: Sensitive or regulated data, tool access, or external exposure, without consequential decisions about individuals. Controls: documented policy, runtime enforcement on data and tool calls, periodic review, retained evidence of policy actions.
• Tier 3: Formal: Pre-defined high-risk areas, material influence on decisions about individuals, or autonomous actions with consequential effect. Controls: documented policy and approval, lifecycle risk management, human approval for high-impact actions, runtime enforcement, retained evidence, scheduled review.

What the frameworks support, and where the line sits

The EU AI Act follows a risk-based approach: the higher the risk of harm, the stricter the rules. The Commission states that the Act introduces no rules for AI deemed minimal or no risk. Uses that can pose serious risks to health, safety or fundamental rights are high-risk, with credit scoring that denies a loan as a named example and insurance risk assessment, employment and biometrics among the pre-defined areas. As of October 2026, the Commission gives 2 December 2027 as the date from which high-risk obligations apply.

For high-risk systems, the requirements cover risk management, data set quality, technical documentation and record-keeping, transparency to deployers, human oversight, and robustness, accuracy and cybersecurity. The risk management system must be established, documented and maintained as a continuous process across the lifecycle, with regular review. Separately, generative output must be visibly labelled in certain cases, such as deepfakes and text intended to inform the public on matters of public interest. That duty applies independent of high-risk status, so check it even for lower tiers when output is published.

NIST AI RMF does not prescribe a risk tolerance, and it allows a low-risk finding in a specific context to suggest lower prioritization. That is the basis for running baseline controls on low-risk uses. Neither framework tells you how to treat tool access or MCP connections, so those factors are your own judgment, applied consistently and recorded.

Example use cases on both sides of the line

Baseline candidates: drafting internal emails, summarizing non-sensitive documents, brainstorming, and rewriting public-facing copy that a person reviews before release. These carry no sensitive data, no tool write access and no effect on individuals. A policy, an owner and standard data handling rules are proportionate. Requiring a full approval workflow here consumes review capacity that higher-risk uses need.

Managed candidates: an internal assistant that searches policy documents containing personal data, a support assistant that can read customer records, or a coding assistant connected to internal repositories. The data or tool access creates exposure, but no consequential decision about an individual is being made. These need documented policy and enforcement at the point of data and tool use.

Formal candidates: an LLM that summarizes applicant files to support credit or underwriting decisions, one that screens or ranks job candidates, or an agent that can change customer records or issue payments. These sit in or near pre-defined high-risk areas or take consequential actions. They warrant documented risk management, human approval for high-impact actions, and retained evidence. A human reviewer in the loop does not automatically lower the tier if the output materially shapes the decision.

How runtime enforcement supports the higher tiers

A policy that exists only as a document depends on every team following it. For Tier 2 and Tier 3, the policy should be enforced where the interaction happens. 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, it can allow, redact, block, rate limit, or escalate for human approval. Enforced at runtime, not reviewed after the fact, the policy applies to the request that actually occurs.

This enforcement also generates audit-ready evidence: a record of what the policy permitted, what it redacted or blocked, and which actions were escalated to a person. That evidence maps to HIPAA, NAIC, NYDFS, EU AI Act and NIST expectations. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Runtime enforcement is one layer, not the whole program. The high-risk requirements above also cover lifecycle risk management, data quality and technical documentation. Those remain governance work that enforcement does not replace. Runtime enforcement addresses the interaction and tool-call level, which is where human approval and record-keeping expectations become operational.