Tier every system, and say no to some, Governance

Two requests reach your intake at once. The IT team wants an assistant that answers staff questions from the internal wiki. The lending team wants a model that scores every loan application.

One process for both fails one of them. Hold the wiki assistant to the credit model’s bar, with a committee sign-off, full independent validation and a challenger model, and the IT team learns to go around you. Hold the credit model to the wiki assistant’s bar, a peer review and a monthly look at its metrics, and it ships without independent validation.

So one of them waits. Which one, and what does it wait for? Write your answer down.

The move

Before any score, ask whether this should be AI at all. The framework’s use case assessment opens with eight questions from its when to say no standard. Would the model generate a fee or a balance instead of taking it from a system of record? Would an agent take a write action nobody can undo, with no human confirming it? Would plain search or a rules engine do the job? A yes means stop or redesign. Saying no at intake, the standard notes, “costs a conversation”.

The first of those questions is the Step 0 screen. Check the use against the prohibited practices in Article 5 of the EU AI Act, such as social scoring, and against your own list from Step 2. A match is rejected. It gets no tier and no exception. A redesign starts again at intake.

Everything that passes gets a tier, by one rule:

Score five dimensions from the GenAI or the traditional ML matrix, each as Critical, High, Medium or Low.
The highest dimension sets the tier. Any Critical gives T1. Otherwise any High gives T2, any Medium gives T3, and all Low gives T4.
Check every override. Nine facts about a system set a floor of T1 or T2. Overrides can raise the tier, never lower it.
The approver may raise it with a recorded rationale. Nobody can lower it below what the scoring and overrides give.

The guide’s call: govern by tier, not by project, and decide the no-list before the first request. Every system at a tier meets the same approver, the same evidence bar for its kind of system and the same reviews, so no team negotiates its own process. A no written in advance is a rule. A no improvised in the room is a fight.

Break it in one direction only: an approver can hold a system to a stricter tier’s bar, never a looser one.

These defaults are strict on purpose. Every AI agent is at least T2, and personal data in a prompt scores Critical. The framework was written for regulated industries, and its floors carry that risk appetite. NIST leaves risk tolerance to each organisation (MAP 1.5). If yours differs, change the matrix in the open, for every system, and record who approved the change. Never bend it for one system.

How it works

Tiering: a prohibited-use screen, five scored dimensions, the highest wins, overrides only raise, the approver may raise but never lower.

A GenAI system, agents included, is scored on hallucination severity, data exposure, prompt injection susceptibility, output controllability and third-party model dependency. A traditional model is scored on decision autonomy, data sensitivity, regulatory exposure, reversibility and scale of impact. A system with both kinds of model is scored on both, and the higher tier applies.

The highest score wins because one severe exposure is enough to hurt someone. A sum would let four quiet dimensions outvote a loud one.

Overrides are yes-or-no questions. Does it directly influence a credit decision? Does it send content to customers with no human review of each output? Is it an agent, even a read-only one? Each yes sets a floor.

The framework's six worked examples: its recorded scores, run through its rule
System	Scored	Overrides	Tier	Why
Internal knowledge searchGenAI	T3	none	T3	Highest dimension: Hallucination severity, Medium, gives T3.
Regulatory document summarisationGenAI	T2	none	T2	Highest dimension: Hallucination severity, High, gives T2.
Customer service chatbotGenAI	T1	2, 8	T1	Highest dimension: Data exposure risk, Critical, gives T1. Override 2 applies but does not change T1. Override 8 applies but does not change T1.
Credit scoring modelTraditional ML	T1	1	T1	Highest dimension: Decision autonomy, Critical, gives T1. Override 1 applies but does not change T1.
Fraud detectionTraditional ML	T1	none	T1	Highest dimension: Scale of impact, Critical, gives T1.
Agentic research assistantGenAI	T2	6	T1	Highest dimension: Hallucination severity, High, gives T2. Override 6 applies but does not change T2. The approver raised it to T1, with a recorded rationale.The AI Risk Committee raised the pilot to T1: it sends confidential research data to an external vendor API, plans and runs multi-step tool use within a session, and its drafts feed research distributed under MiFID II.

Both of your requests have a twin in the table. The knowledge search records Medium at most and no override, so it is T3, and a team lead approves it. That Medium on model dependency has to be earned. The search runs on a vendor API, and the matrix’s level text allows Medium only because the business owner recorded that an outage is tolerable and manual search will do. Without that record it scores High, and the system is T2. The credit model scores Critical on four dimensions, so the AI Risk Committee approves it. The credit model waits for its T1 evidence. The wiki assistant never waits for that committee. At T3 its approvals stay with the team lead and the business owner, who co-signs the deployment. Two things still come from outside the build team: a red-teamer, and AI Risk’s simplified vendor assessment, because the search calls a vendor API.

The agentic research assistant shows the last arrow. Its highest dimensions are High, which gives T2. Override 6 puts every agent at T2 or above, so it changes nothing. The AI Risk Committee then raised the pilot to T1, and recorded why. It sends confidential research data to an external vendor API, plans and runs multi-step tool use, and feeds research distributed under MiFID II.

Here is what the tier changes.

What the tier changes (ai-governance-framework@v2.2.0)
	T1 · Critical	T2 · High	T3 · Medium	T4 · Low
Approves the risk assessment	AI Risk Committee	AI Risk (second line)	Team lead	Team lead (self-assessment acknowledged)
Independent validation	MRM (full scope)	MRM or another second-line reviewer outside the development team (reduced scope)	Peer review	Self-test
Red-team depth (GenAI systems)	200+, including manual testing (external testers recommended)	100+	Automated adversarial scan + 50 manual cases	Automated scan, 20+ cases (recommended)
Metrics review	Daily dashboard check by AI Operations, plus a monthly system-owner review	Weekly	Monthly	Quarterly
Formal governance review	Quarterly	Semi-annual	Annual	Annual self-assessment
Revalidation	Annual, and on material change	Every 24 months, and on material change	On material change (peer re-review)	On material change (peer re-review)

One field in your register now decides who approves a system, who validates it and when it is reviewed again.

The support assistant An illustrative system, carried through every step

Score the assistant from Step 3 on the GenAI matrix.

Hallucination severity: Medium. A trained support agent checks every draft against the customer’s case and corrects it before it goes. A wrong draft costs time, and it is caught.
Data exposure risk: Critical. Customer emails carry personal data, and they go into the prompt.
Prompt injection susceptibility: High. A customer can write anything in an email. The assistant only drafts.
Output controllability: Medium. That check is a qualified person reviewing each output before use. A skim would score High.
Third-party model dependency: High. It runs on a vendor API, customers receive the replies, and the only fallback is agents writing by hand.

The highest score is Critical, so the assistant is T1.

Now the overrides. Assume the vendor keeps no data, the endpoint is in the right region, a DPA is signed and personal data is cut down before each call. With those four safeguards, override item 8 sets a minimum of T2, which changes nothing here. Miss one, and item 3 would make the assistant T1 by itself.

The AI Risk Committee approves the risk assessment, and Model Risk Management validates the system. The entry from Step 3 gains its tier:

risk_tier: "T1"
tier_basis: "Data exposure risk: Critical"
data:
  classes: ["personal-data"]
human_oversight: "human-in-the-loop"

The same assessment fills in the entry’s EU AI Act fields.

That is a heavy bar for a drafting tool. It follows from one strict default: personal data in a prompt scores Critical.

Now the team wants the assistant to send replies itself. Output controllability becomes Critical, and override item 2 applies, because customers get content no person reviewed. The tier is still T1. The change is material, so the assessment runs again and goes back to the committee with new evidence.

How it scales

Size decides who prepares the assessment and who signs it.

Small team

Have your team lead score each system. The framework lets a team lead hold the product owner’s role, which prepares the assessment.

Your T3 and T4 systems take the framework’s fast lane: the same stages, less evidence, no committee, and the team lead’s sign-off. At T3 the business owner co-signs the deployment, and the red team comes from outside the build team. Any override puts a system at T2 or above, outside the fast lane.

A small team can’t govern a T1 or T2 system on its own. Approval and validation come from outside it: AI Risk and a second-line validator at T2, the AI Risk Committee and Model Risk Management at T1. The framework assumes a second line, and another first-line team doesn’t meet its T1 and T2 validation rule. If your company has none, the guide’s call is to name a risk or compliance owner outside the building team to play that part before your first T2 system arrives, and book them at intake.

Enterprise

The product owner prepares the assessment. The tier picks the approver: the AI Risk Committee for T1, AI Risk in the second line for T2, a team lead for T3, and for T4 a team lead who acknowledges the self-assessment. Model Risk Management validates every T1 tier independently, as the framework’s decision process requires. Re-run the tiering check at every formal review and on any material change; the deep dive lists the triggers.

Starter kit

From the open AI governance framework, pinned at v2.2.0.

Risk matrix Markdown · framework/risk-classification/risk-matrix.md
GenAI risk matrix Markdown · framework/risk-classification/genai-risk-matrix.md
When to say no Markdown · framework/governance-operations/when-to-say-no.md
GenAI use case assessment Markdown · templates/genai-use-case-assessment.md

Deep dive

The override list

The full list applies in every matrix: GenAI, traditional ML, multimodal and agentic.

Item 1 · automatic T1. Makes or directly influences a regulated decision (credit, insurance underwriting or pricing, AML or sanctions, employment).
Item 2 · automatic T1. Generates customer-facing content with no per-output human review.
Item 3 · automatic T1. Processes customer personal data through an external LLM API without all four safeguards.
Item 4 · automatic T1. Agent with write access to production systems or data stores, or authority to move money, contact customers or change access.
Item 5 · automatic T1. Biometrics, deepfake-capable synthetic media, voice cloning or medical imagery.
Item 6 · minimum T2. Any agentic system, including read-only tool use, or any multi-agent system.
Item 7 · minimum T2. Other synthetic media generation.
Item 8 · minimum T2. Processes customer personal data through an external LLM API with all four safeguards.
Item 9 · minimum T2. Personal data in visual content.

The four safeguards in items 3 and 8 are zero data retention by the vendor, a regional endpoint that meets data residency requirements, a signed DPA, and PII redaction or minimisation before the call. Miss one and the system is automatic T1. The when-to-say-no standard goes further: fix the safeguard before the design review passes. T1 governance can’t repair a data flow you can’t prove is safe.

Why every agent is at least T2

An agent with read-only tools still acts on content it can’t trust. A retrieved document can carry instructions, and an early error in a multi-step plan carries through every later step. So item 6 sets T2 for any agent, and for any multi-agent system.

Write access to production systems or data stores, or authority to move money, contact customers or change access, makes it T1 under item 4. The agentic risk standard adds one more route: an agent that processes PII, MNPI or regulated data scores Critical on data exposure, so it is T1 even with read-only tools.

Re-tiering

The framework re-runs the check at every formal governance review and on any material change to scope, data, autonomy or regulation. A model change, a provider update or a prompt change counts too. The common ways out of the fast lane: the system starts serving customers, gains a tool, sends customer personal data to an external model API, or starts to influence a regulated decision.

A change that raises the tier goes back through assessment and needs the new tier’s evidence before it goes live. If the change has already happened, each missing control needs an approved, time-limited exception until the evidence exists. Non-waivable controls get none.

When to say no

Two of the standard’s eight positions are the Step 0 screen and the simpler-method test. The other six are design rules. Take figures with legal effect from a system of record. Keep a human on adverse regulated decisions. Allow no autonomous write that can’t be undone or capped. Send no customer or regulated data to an external API without proof of residency and zero retention. Launch nothing whose evaluation can’t show its threshold is met. Run no business-critical process on a model you can’t replace.

A team that thinks a position shouldn’t apply takes its case to the tier approver, who decides and records it. Two can’t be set aside at all: the prohibited-use screen, and the kill switch in the no-undo position.

Your no-list also grows with the law. From 2 December 2026, the Digital Omnibus on AI adds two practices to Article 5: AI systems that generate intimate imagery of an identifiable person without their consent, and systems that generate child sexual abuse material. Check the safeguards of every image and video tool you run.

Tier, legal class and residual risk

Three things get confused, and the register entry keeps them apart.

The tier is yours. T1 to T4 says which reviews, approvals and controls your organisation requires.

The legal class comes from the law and your role under it. The EU AI Act asks whether you are a provider or a deployer, and whether the use falls under an Annex III point. The entry records both beside the tier. The two are set by different rules, so check each one. The support assistant is T1 here. Whether the Act treats it as high-risk is a separate question, answered on its entry.

Residual risk is what is left once the controls run. The business owner accepts it by name. The tier sets the controls. It does not say how much risk remains after them.

The aggregate score

Record the sum of the five scores, from 5 to 20, for context only. It never sets the tier. The knowledge search sums to 8. One Critical dimension and four Low ones also sum to 8, and that system is T1.

The tier says what each system must pass. It can’t make anyone pass it. Good engineers skip process for reasons that make sense to them. Part II starts there. Step 5 finds where your engineers will route around you, and why.

Tier every system, and say no to some