AI risk tiering should determine how much assurance a use case needs, while control inheritance should show which evidence can be reused from models and shared platforms. Combining them carelessly creates two failures. A simplistic tier assigns every generative model the same risk regardless of use. An optimistic inheritance claim assumes a secure platform makes every application safe. The remedy is a layered record that starts with effects on people and operations, then attributes each control to the component and owner that can actually perform it.
This method extends Edilec's AI governance operating model with an assurance architecture. Pair it with the production model-monitoring guide and human review design so classification changes evaluation, monitoring, and intervention rather than becoming inventory decoration.
Build AI risk tiers from use context and consequence
Classify the use case, not only the underlying model. Ask what decision or action follows, who is affected, whether they can contest it, what data is used, how autonomous the workflow is, how widely it operates, and whether errors are reversible. Include foreseeable misuse and dependence on generated content. The NIST AI RMF emphasizes mapping context before measuring and managing risk; tiering should preserve that logic instead of reducing risk to model size.
Use a small number of tiers with clear consequences. Tier 1 may cover low-impact assistance with no sensitive data or external action. Tier 2 adds material internal decisions or controlled sensitive data. Tier 3 covers consequential recommendations, significant rights or safety effects, or privileged tool use. Tier 4 covers uses prohibited by policy or requiring executive and legal authorization under exceptional conditions. Allow upward overrides whenever uncertainty, novelty, or aggregation increases exposure. Downward exceptions need written rationale and expiry.
| Tier | Typical context | Minimum assurance before release | Ongoing governance |
|---|---|---|---|
| 1: Limited | Drafting or search with easy verification | Owner, basic security, quality test and disclosure | Usage and complaint monitoring |
| 2: Managed | Internal workflow recommendation with sensitive data | Impact screen, representative evaluation, access control, fallback | Periodic metric and change review |
| 3: High | Consequential decision support or privileged action | Full impact assessment, independent challenge, human authority, incident exercise | Tight thresholds, sampled decisions and executive risk review |
| 4: Restricted | Prohibited use or exceptional severe-risk deployment | Do not deploy without explicit policy exception and legal basis | Continuous oversight and time-limited authorization |
Separate model, platform, application, and use-case controls
The model layer covers training provenance, model evaluation, weight protection, known limitations, and provider change information. The platform layer covers identity, network boundaries, secrets, logging, model routing, common filters, and approved retrieval or tool gateways. The application layer owns prompts, data transformation, workflow logic, user interface, application evaluations, and fail-safe behavior. The use-case layer owns lawful purpose, affected-party analysis, human competence, operating procedures, contestability, and outcome monitoring. Name all four even when one team operates several.
A control is inheritable only when its scope covers the consumer, its configuration is compatible, evidence is current, and responsibility is explicit. Platform encryption can be inherited by applications using the approved storage path; it cannot cover exports copied to a departmental drive. A model provider's toxicity evaluation may inform assurance, but it does not prove accuracy for a customer's medical terminology. The NIST GenAI Profile helps identify generative-AI concerns that must be allocated across these layers.
Create a testable control-inheritance claim
For each inherited control, record control objective, provider component, consumer systems, evidence owner, configuration assumptions, evidence reference, last verification, expiry or review date, exclusions, and consumer responsibilities. Use states such as inherited, partially inherited, locally implemented, compensating, not applicable, and gap. Partial inheritance is valuable: a platform can provide immutable event transport while the application remains responsible for recording meaningful business context.
Model this as a directed assurance graph rather than copying a spreadsheet row into hundreds of assessments. A control package version should identify the exact platform release and configuration. Consumers subscribe to that package and declare deviations. When evidence expires, a control fails, or the platform changes materially, dependent owners receive a signal and reassess. This is analogous to shared-control concepts in NIST SP 800-53, adapted carefully to AI-specific model and use-context evidence.
Calculate residual risk after inherited and local controls
Do not subtract control names from an inherent-risk score. Assess whether the combined controls reduce each scenario's likelihood, consequence, detectability, or duration, and record evidence quality. A high-tier use can remain high-tier after treatment; the tier drives assurance intensity, while residual risk drives acceptance and monitoring. State uncertainty separately. Weak evidence, a new population, or untested provider change should widen the uncertainty range and may require temporary safeguards.
| Control claim | Inheritance decision | Consumer obligation | Evidence that closes the claim |
|---|---|---|---|
| Platform blocks unapproved models | Fully inherited for routed traffic | Prevent direct provider credentials | Gateway policy plus credential inventory |
| Provider evaluates harmful content | Partially inherited | Test domain, language and user-specific cases | Provider report plus local evaluation |
| Shared retrieval enforces permissions | Inherited with configuration condition | Map authoritative groups and test document ACLs | Configuration export and access probes |
| Application requires human approval | Locally implemented | Define approver authority and usable context | Workflow test and sampled decisions |
| Use is fair to affected population | Not inheritable | Assess outcomes and recourse in context | Impact study and production outcome review |
Operate tiering through intake, change, and review
At intake, the business owner describes purpose, population, decisions, data, autonomy, scale, and dependencies. A governance service proposes a tier using decision rules; an accountable reviewer confirms it and required control package. The team then attaches inherited claims, implements local controls, records gaps, evaluates scenarios, and routes residual risk to the correct acceptance level. Release systems should check required evidence states rather than relying on a PDF approval stored elsewhere.
Re-tier after new use, affected population, tool authority, data category, model family, jurisdiction, incident, or material performance change. Review high tiers more frequently and whenever inherited evidence changes. ISO describes ISO/IEC 42001 as a management system for establishing, maintaining, and continually improving AI governance; tiering and inheritance should therefore connect to objectives, competence, internal audit, management review, and corrective action rather than operate as a one-time architecture exercise.
Avoid tier and inheritance anti-patterns
Do not let a vendor's low-risk label determine the enterprise tier, because the vendor may not know the use context. Do not classify every pilot as harmless; pilots can process real data and influence real decisions. Do not inherit policy documents without implementation evidence. Do not duplicate platform evidence into static assessments that drift apart. Do not let a high control count hide one unresolved catastrophic scenario. Finally, do not make the method so elaborate that teams route around it through unmanaged accounts.
Start with one platform and three contrasting use cases. Define tier rules, build a shared package of ten to twenty meaningful controls, and trace every inherited claim to live evidence. Run a review with platform, application, business, security, privacy, and model-risk owners. Record disputed boundaries and refine the method. Scale only after dependency notifications and evidence expiry work. The measure of success is faster, clearer assurance with fewer hidden gaps, not a larger control catalog.
Set service levels for shared assurance evidence
A platform control package should have an assurance service level: how quickly consumers are onboarded, how evidence is refreshed, how failures are communicated, and how long owners have to reassess. Define severity based on dependent use cases, not only the platform defect. If a common permission control fails, high-impact applications may need immediate suspension while low-impact drafting tools can operate with a temporary safeguard. Maintain dependency contacts and test notification delivery. Report inheritance coverage, stale claims, unacknowledged failures, local deviations, and time to reassessment. These measures reveal whether centralized assurance truly reduces work or simply creates a new queue whose delays are hidden inside application approvals.
Make disputes visible. A business owner, platform team, privacy officer, and model-risk reviewer may reasonably assess one scenario differently because each sees different evidence. Record the proposed tier, dissenting view, missing fact, interim restrictions, and final accountable decision. Time-box uncertainty rather than forcing false consensus. A short pilot can gather evidence only if it stays within restrictions appropriate to the higher plausible tier. Review overrides for patterns: repeated downward exceptions may indicate commercial pressure or flawed criteria, while automatic upward overrides may show that the base questions fail to capture an important domain consequence.
Key takeaways for AI risk tiering
- Tier the use case by consequence, affected people, autonomy, scale, reversibility, and uncertainty.
- Allocate controls across model, platform, application, and use-case layers before claiming inheritance.
- Make every inherited claim conditional, evidence-backed, owned, versioned, and expiring.
- Use the tier to set assurance intensity and residual risk to drive acceptance and monitoring.
- Re-tier on material change and notify every consumer when shared evidence degrades.
FAQ about AI risk tiers and inherited controls
Can one model have several risk tiers? Yes; a model used for low-impact drafting and consequential eligibility support creates different use-case risks. Does inherited mean the application owner has no responsibility? No. Consumers must satisfy configuration assumptions, perform stated local duties, and respond to provider changes. Should tiers equal regulatory categories? They can map to them, but an enterprise method may include contractual, reputational, operational, and policy concerns. Can a control reduce the tier? Usually the tier reflects inherent context and sets assurance; controls reduce residual risk.
Conclusion: reuse assurance without outsourcing judgment
Central AI platforms can make strong controls cheaper and more consistent, but shared infrastructure cannot understand every affected person, workflow, or consequence. A disciplined tiering and inheritance model preserves both advantages: contextual judgment determines required assurance, and reusable evidence proves what common layers actually provide. When claims are versioned, conditional, and tied to residual risk, teams can move faster without confusing platform maturity with use-case safety.