AI Use Case Intake and Risk Tiering in Banks: From Approval to Enforceable Runtime Policy

What intake and tiering cover, and what they do not

An AI use case intake process is the single entry point through which a business line describes what it wants to build or buy. Risk tiering is the rule set that turns that description into a tier, and the tier determines how much control the use case receives. Together they are the upstream decision layer.

They do not, on their own, change what happens in production. A tier recorded in an inventory is a documented decision. Whether the constraints attached to that tier are applied to each interaction and tool call is a separate question, and it is the one examiners find hardest to answer when business lines keep separate forms, criteria and inventories.

One point on framing. The OCC's supervisory framework for bank use of what it calls Super Intelligence, issued in Bulletin 2026-54 in November 2026, is a tool for examiners. It states that it does not establish supervisory expectations or enforceable standards, and that examiners should tailor reviews to the materiality of the use case rather than treat the technology as a separate risk category. Treat it as a useful description of how examiners may think, not as a requirement, and integrate tiering into existing model risk, governance and operational-risk practice instead of building a parallel regime.

Design a standard intake schema

The schema should be mandatory for every business line and feed one central inventory. The OCC framework describes scoring every use case against a common set of risk factors independent of business line, so comparable risk receives comparable control wherever it originates. A shared schema is the practical precondition for that. Capture the factors as structured fields with defined values, not free text, so decision rules can be applied identically.

A workable minimum set follows.

• Business line, owner and purpose: The accountable owner and a plain statement of what the use case is for.
• AI type and third-party components: Generative, agentic, or other model type, plus any third-party products or models involved.
• Action mode and tools: Whether the AI supports a human decision or takes direct action, and which tools it can call.
• Consequence and reversibility: The consequence if output or action is not fit for purpose, and whether the outcome is effectively irreversible once executed, such as a payment sent or an account closed.
• Data used and permissibility: What data is used, whether it can and should be used, and the risks arising from it.
• Reassessment trigger and jurisdiction flags: Events that force re-tiering, and a flag for uses that may fall in the EU AI Act high-risk category, such as credit scoring that denies a loan.

Define tiering criteria and decision rules

Tier definitions should rest on the factors the OCC illustrates: consequence, autonomy, direct action versus decision support, and reversibility. The OCC describes a graduated model, light-touch for low-risk, low-autonomy use and materially heavier for customer-impacting, irreversible or highly autonomous action. Direct action carries materially higher risk than decision support.

Write each factor as a scored question with defined answers, then combine scores with explicit rules, for example: any irreversible direct action places the use case in the top operating tier regardless of other scores. Add an outcome for use cases whose risks cannot be controlled. Some banks, as industry commenters describe, reject models when risks cannot be controlled, and a defined rejection outcome keeps that decision consistent.

Thresholds are the bank's to set. NIST AI RMF 1.0 can be used to prioritize risk but does not prescribe risk tolerance, so document the rationale for each threshold.

On model risk management alignment, the OCC states that the MRM principles in its Bulletin 2026-13 apply to non-generative and non-agentic models, and it applies its tiering methodology separately to models and to agentic systems. The intake record therefore needs an explicit AI type field. Existing MRM validation and inventory practice can carry traditional models, while generative and agentic use cases may need additional tier-driven constraints on autonomy, oversight and independent validation. Assess before deployment and again on material change.

Translate each tier into runtime policy

The mapping below is an illustrative bank design, not a supervisory specification. Each bank must define its own tiers and actions with model risk, cybersecurity, compliance and technology teams. The principle is that control intensity rises with the consequence of failure or misuse, and that the rules reference attributes captured at intake, such as action type and reversibility.

Runtime policy applies at the level of individual interactions and tool calls. That means rules should be written against things a runtime can see: which tool is called, what data appears in a prompt or response, how often a call is made, and whether an action is on a list requiring approval.

• Tier 1: low consequence, decision support: Allow within approved models and tools. Rate limit to contain misuse.
• Tier 2: moderate consequence, internal use with sensitive data: Allow, with redaction of defined data types before they reach a model or leave it. Rate limit.
• Tier 3: customer-impacting or direct action, reversible: Redact, block tools not on the approved list, and escalate defined actions for human approval.
• Tier 4: irreversible or highly autonomous action: Block by default. Permit only named actions, each escalated for human approval before execution.
• Not approved: Block all production traffic for the use case.

Evidence to produce for each tier

No supervisory material sets out exactly what runtime evidence must exist, so the following is practitioner design. The test is whether someone outside the project can follow one line from the inventory to production: the use case, its tier, the rationale, the controls mapped to that tier, and records showing those controls ran.

For every tier, keep the inventory entry with the completed intake record, the scored tier rationale and approver, and the version of the tier-to-control mapping in force. For higher tiers, add records of each escalation and its human decision, and of each block. For lower tiers, evidence may be lighter, proportionate to the tier, but still show that rate limits and data rules applied.

Also keep a change history. When a use case is re-tiered after a material change, the record should show when the new tier took effect in runtime policy, so there is no gap between the documented tier and the enforced one.

Be precise about scope. Intake and tiering establish risk classification and do not by themselves produce evidence of production behavior. Runtime records do not establish whether the tier was assigned correctly. Both are needed, and each answers a different examiner question.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit, or escalate for human approval to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and that enforcement generates continuous audit-ready evidence mapped to NIST and other frameworks.

In practice, a bank's tier-to-control mapping would be expressed as policy in that path, with the evidence showing what the policy allowed and what it did. Trussed does not perform intake or assign tiers, and it does not provide model lineage or dataset provenance.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, with 100+ models under one policy plane. Insurance, a regulated financial sector, is where Trussed is deepest.