Tiered AI intake is the operational discipline of routing each AI request to a depth of review proportional to its risk - typically across four tiers from Self-Service through Restricted. It replaces the one-track review process that breaks at the point where governance volume meets adoption velocity, and it is the load-bearing component of any AI governance program operating at enterprise scale.

Key Takeaways

The Proportionality Principle. Every major AI regulatory framework - the EU AI Act, ISO/IEC 42001, and the NIST AI RMF - converges on the same operational requirement: scrutiny applied to an AI system must be proportional to the risk it presents. Tiered intake is how that requirement gets operationalized at enterprise scale.

The Four-Tier Model. Self-Service / Light Review / Full Review / Restricted. Each tier has a defined risk profile, review process, and approver. The structure maps cleanly to the EU AI Act's four-level risk categorization and to ISO 42001's risk-based controls.

Intake as Continuous Discipline. Intake is never "done" for any system above Tier 1. Substantial-modification triggers, vendor model updates, and use-case scope changes all force re-assessment. Programs that treat intake as one-time fail at scale.

Intake: the load-bearing component of any governance program

Every component of an AI governance program - the AI inventory, the assessment library, the monitoring cadence, the regulatory documentation, the audit trail - depends on intake. Without it, the program governs only what it knows about, and what it knows about diverges from what is in production within a quarter. The pattern is consistent across enterprises that have crossed the first wave of AI adoption: the failure mode is rarely loud. Governance becomes slow enough to bypass.

The slow-bypass pattern manifests in two distinct shapes. The first, the bottleneck failure mode, emerges when a single review track is applied to every AI request and creates queues. A consumer-products marketing team submitting a request for an AI copywriting tool waits behind a candidate-ranking system that legitimately requires a multi-week conformity assessment. By the third or fourth time business owners experience this latency, they begin routing around the process: personal accounts get used, free public AI services absorb the work, embedded SaaS features get switched on without disclosure. The shadow AI surface grows in inverse proportion to intake throughput, and the inventory increasingly reflects what was approved rather than what is in production.

The shadow AI surface grows in inverse proportion to intake throughput.

The second is the gap failure mode. A single review track operating at the depth a high-risk system genuinely requires becomes punitive overhead for low-risk tools. The choices then narrow to two equally bad outcomes: the depth gets diluted into something that does not satisfy the regulatory regime, or the program loses internal credibility because it asks marketing to fill out the same 200-question assessment used for credit scoring models. Either way, the program is less effective than it appears on paper.

Tiered intake addresses both. The principle is endorsed by every major AI regulatory regime: Article 6 of the EU AI Act,[4] Clause 6.1.4 of ISO 42001 read alongside Clauses 6.1.2 and 8.2 of the same standard,[2] and the Govern function of the NIST AI RMF.[3] It is also operationally achievable at enterprise scale.

The four-tier model: matching scrutiny to risk

Figure 1: The four-tier AI governance intake model. Scrutiny scales with risk, with the prevalence of each tier in a mature program approximately 60-70% Tier 1, 20-25% Tier 2, 5-15% Tier 3, and a small but non-zero Tier 4.

Worked through against a concrete request, the model resolves cleanly. Take an HR team requesting an AI-powered candidate ranking system from a third-party vendor. The use case falls under EU AI Act Annex III[6] (employment), which is the floor for Tier 3. The system makes consequential decisions about individuals (employment), reinforcing Tier 3. The data is sensitive (CVs include personal data, sometimes special-category data), reinforcing again. Each dimension converges; the request routes to Tier 3 with full assessment, multi-stakeholder review, technical documentation per Annex IV,[7] and defined re-assessment triggers tied to vendor model updates.

Compare to an internal grammar tool used only on published marketing copy. No personal data, no consequential decisions, no external impact. The dimensions converge on Tier 1. The intake is a registration form completed in two minutes; the system appears in the inventory by lunchtime; no human reviewer touches the request unless an exception is flagged.

The presence of Tier 4 is what makes the rest of the structure credible.

Without an explicit refusal path, intake implicitly accepts every request as eventually governable, and the prohibited-use provisions of the applicable regimes become invisible to the program. A Tier 4 entry should appear in the audit trail with a documented refusal - that record itself becomes evidence of governance maturity to a regulator.

Edge cases worth naming. Some systems straddle tiers. A Tier 2 system whose use case expands materially (say, a customer support chatbot whose remit grows to include refund decisions) should be re-assessed and may move to Tier 3. Conversely, a Tier 3 system that has been operating with substantial human oversight for two years and whose risk profile has been demonstrably stable may be a candidate for promotion to Tier 2 with continued monitoring. Tier movement should be a documented decision, not a default. The question to ask: would a regulator accept the new classification given the evidence available?

Agentic systems are the inflection point this model has to handle

The four-tier model is not new. What is new is the rate at which Tier 3 systems are arriving - driven primarily by agentic AI, the class of systems given permission to take autonomous action rather than only produce outputs reviewed by a human. The intake for agentic systems is structurally different in three ways the four-tier model has to absorb.

First, the autonomy dimension forces a Tier 3 default regardless of underlying use case. An agentic AI that handles internal expense queries reads as Tier 2 by use-case sensitivity, but the moment it is given permission to actually file expenses or schedule reimbursements, it crosses into Tier 3. The risk profile is not "what kind of decision" but "what kind of action."

Second, intake for agentic systems must capture authority boundaries explicitly. A Tier 3 agentic intake should establish what tools the agent can call, what actions it can take without human confirmation, what escalation conditions trigger handoff, and what monitoring covers behavior between confirmations. None of this maps onto the questionnaire structure that worked for static AI systems; agentic intake forms typically need 30–40% more dimensions, focused on action-space rather than data-handling.

Third, substantial modification reads differently. For a static AI system, model updates are the dominant re-assessment trigger. For an agentic system, expanding the action whitelist (allowing the agent to call a new API, write to a new system of record, or move money in a new category) is a substantial-modification event that may exceed the original assessment's scope entirely - and that may not be visible in the model itself. The intake process for agentic Tier 3 systems should require explicit registration of the action whitelist at deployment and re-engagement of intake on any whitelist change.

For agentic systems, the question is not "what kind of decision" but "what kind of action."

Classifying systems consistently: the seven dimensions

Tier assignment must produce the same answer for the same risk profile regardless of which reviewer happens to handle the request. A poorly-designed classification process produces drift; a well-designed one applies a consistent set of dimensions to every request and routes deterministically. A well-designed intake form asks five to eight questions across the dimensions below and uses the answers to deterministically route. Manual override exists for genuine edge cases; manual classification as default produces drift.

For regulated financial services firms specifically, the model risk management dimension is more than a tier-floor input; it triggers a parallel lifecycle (model validation, ongoing monitoring, periodic recertification) that intake should hand off to the existing MRM function rather than re-execute. The intake record for an MRM-in-scope AI system should reference the corresponding MRM ID, not duplicate the MRM workflow.

When dimensions conflict. The dimensions usually point in the same direction; occasionally they do not. A predictive maintenance system in a manufacturing plant might process minimal personal data, make no consequential decisions about individuals, and be entirely reversible, yet form part of an Annex I product (machinery) whose AI integration is high-risk under EU AI Act Article 6(1).[4] The use case category alone forces Tier 3, regardless of what the other dimensions suggest. The rule: take the highest tier indicated by any single dimension, and document the reasoning.

The Article 6(3) exception. The EU AI Act allows a provider to self-determine that an Annex III system is not high-risk if the system performs a purely procedural or preparatory task, or improves the result of a previously completed human activity without influencing the final decision. The exception is narrow.[13] An AI tool that reformats CVs into a standardized layout for a human reviewer may qualify. An AI tool that ranks the same CVs by predicted fit does not, even if a human makes the final hiring decision; the ranking influences the decision in a manner the regulator considers material. Misuse of the 6(3) exception is itself a regulatory exposure. The classification process should treat 6(3) determinations as documented findings requiring justification, not as routing conveniences.

Article 50 transparency, and why it deserves its own dimension. EU AI Act Article 50[15] imposes disclosure obligations on AI systems that interact with humans, generate synthetic content, or produce deepfakes - regardless of underlying use case or sector. A Tier 2 customer support chatbot crosses into Article 50 the moment a customer is unable to distinguish it from a human agent without explicit disclosure. The intake form should test for Article 50 triggers directly; reaching this dimension late, in an Annex III conformity assessment that did not contemplate it, produces evidence gaps that surface in audit. From 2 August 2026 forward, this is a hard obligation for providers and deployers of in-scope systems and should be visible in the intake decision record.

A bank's procurement of a third-party customer support chatbot illustrates how the dimensions interact. The vendor markets the system as "limited risk" because outputs are conversational and human agents handle escalations. The bank's intake process applies the dimensions: use case category (customer-facing, no Annex III floor); data sensitivity (transcripts may contain account information - raises the tier); decision impact (informational only - no impact raise); reversibility (responses can be retracted - no raise); autonomy level (responds without human review of each message - raises tier in agentic-adjacent direction); transparency triggers (Article 50 applies - chatbot disclosure required); sector triggers (financial services context - raises further); MRM triggers (no underlying model directly governed under SR 11-7 / SS1/23 for a vendor chatbot - informational); source (third-party procurement - fresh intake required regardless). The system lands in Tier 2 at the higher end, possibly Tier 3 depending on data sensitivity assessment.

The vendor's "limited risk" framing is irrelevant; the deploying organization's own classification governs.

For the broader vendor-risk discipline that surrounds this kind of intake, see our third-party AI vendor risk assessment guide.

The five-step workflow, scaled per tier

The intake process follows a recognizable five-step shape regardless of tier. The tier determines how much process happens at each step.

Diagram showing the five-step AI governance intake workflow: Step 1 Identify use case, Step 2 Check inventory, Step 3 Risk assessment, Step 4 Review, Step 5 Decision. The shape holds at every tier; the depth at each step scales with the tier classification.

The five-step shape holds across tiers; what scales with the tier is the depth of process at each step. A Tier 1 request might complete all five in twenty minutes; a Tier 3 request typically takes four to six weeks for the assessment alone, then another two for the review and approval cycle. Roles should be assigned per tier: at Tier 1, the requester serves as the named owner and the system enters the inventory automatically; at Tier 2, the named approver in legal or risk owns the decision and the requester remains accountable for ongoing operation; at Tier 3, the multi-stakeholder review board carries decision rights, an assigned independent reviewer owns the technical documentation review, and the business owner remains accountable for substantive use.

Substantial modification is the trigger that brings Step 3 back. Article 3(23) of the EU AI Act defines substantial modification as a change to an AI system after it has been placed on the market that affects its compliance or intended purpose.[14] Parallels exist in ISO 42001 (which treats substantial change as a trigger for re-assessment within the AI management system) and in the NIST AI RMF (which treats material change as a trigger for re-mapping risk). Practical examples: a vendor pushes a foundation-model version update that changes a tool's behavior; an agentic system's action whitelist gets expanded to include a new API; a customer support chatbot's remit gets extended to include refund decisions; the training data for a fine-tuned model gets refreshed with new sources. Each is a substantial-modification candidate, and intake should re-engage at the appropriate tier depth, not as a bureaucratic exercise but because the previous risk assessment may no longer hold.

Take a healthcare provider that deployed an AI diagnostic aid in 2025 under Tier 3 review, with the original assessment based on a specific model version trained on a specific dataset. In April 2026, the vendor announces a model version update incorporating new training data and a refined inference pipeline. Under substantial-modification rules, the provider's intake process should re-engage; the assessment from a year ago may not cover the new behaviors of the updated model. The re-assessment may conclude no change is warranted, but it must be a documented determination, not silence.

From manual to automated: the inflection point that forces the platform decision

From four hours per use case to under one. Same team. Same regulatory bar. Six months.

That is the operational reality at one consumer goods company that replaced its manual intake process - built on email forms and Google Forms - with an automated, tiered workflow. The processing-time change is the visible metric; the structural change is the more important one. Before the transition, the risk team was the bottleneck for every AI request, regardless of risk profile. After the transition, low-risk requests no longer competed for attention with high-risk ones, the multi-stakeholder review boards spent their time on the systems that genuinely required it, and the audit trail became regulator-ready by default rather than as a forensic exercise.

A tiered intake process can be operated manually. Most programs begin this way: email forms, shared spreadsheets, standing review meetings. The model holds for the first dozen or two AI requests.

The transition to automation is forced rather than optional past a certain volume. The symptoms are predictable. Manual classification drifts between reviewers - the same system gets different tier assignments depending on who is on duty. Email-thread audit trails fragment across team members, project channels, and shared drives, with no single source of truth a regulator could request. Re-assessment triggers get missed because nobody is tracking them at scale. Tier 1 requests, which should be automated, end up sitting in the same queue as Tier 3 because the routing logic exists only in someone's head, and that someone is on holiday.

The capabilities that become essential are not exotic: a centralized inventory that multiple teams can edit safely; deterministic tier classification driven by the intake form's answers; routing of requests to the right reviewers; document generation against regulatory requirements; an audit trail that survives organizational change.

The choice between manual and automated intake is a choice about how much governance overhead the organization absorbs as it scales AI adoption. A tiered process delays the inflection point but does not eliminate it. Organizations that move to automation early treat the platform investment as a structural condition for scaling AI adoption, ahead of the inflection point; those that wait until scaling has already broken find that the platform decision is forced under conditions of compromise.

Where intake fits in the broader GRC stack

Intake works when it is the front door for the existing GRC processes the organization already runs - vendor risk, procurement, security review, privacy assessment - not a competing parallel track. A new intake process that operates alongside existing review functions produces duplicated effort and competing records of truth, both of which the program will lose.

The output of intake should be a single record that procurement, legal, security, and privacy can each reference for their respective obligations:

• Vendor risk references the intake record to inform contractual provisions on AI use - change-notification windows, audit rights, model-card disclosure obligations

• Procurement references it to ensure the contract structure matches the system's risk classification and intended use. The procurement handoff is the hardest one in practice: existing TPRM platforms (OneTrust, ServiceNow Vendor Risk Management, ProcessUnity) own contract template inheritance, and AI-specific clause libraries need to be grafted onto that workflow rather than maintained in parallel.

• Security references it for the access-control implications of the system, the data flows it requires, and the threat model that applies

• Privacy references it for the DPIA or LIA the system requires, the data subject rights implications, and the cross-border data flow considerations

The cost of operating two governance systems is structural, not incremental.

The intake record is the upstream input for each. In practice this means intake is built or selected with explicit integration points to the GRC stack already in place. The cost compounds as both systems' records of truth diverge over time.

Take a bank's intake process for a third-party AI vendor as the operational shape this looks like. The intake automatically triggers downstream actions: vendor risk receives the intake record and applies its standard third-party assessment with AI-specific extensions; legal reviews the contract for the change-notification window and audit-rights provisions; security receives the data-flow specification and runs its threat model; privacy completes the DPIA based on the data classifications captured at intake. None of these teams re-asks for the same information; each pulls from the intake record. The vendor sees one coherent set of requirements rather than four parallel processes asking overlapping questions.

How tiered intake fails (and how to fix it)

Tiered intake fails in seven recognizable patterns. The first five surface in the first eighteen months; the last two surface in years two and three and quietly kill programs that survived the early failures. Each has a diagnostic signal that appears in routine governance reviews and a structural fix that addresses the underlying cause.

Diagnostic detail on the most common early-stage failure. Treating intake as one-time is the failure mode most enterprises fall into first, and the one with the largest cumulative cost. The signal: a quarterly inventory review surfaces three or four systems that have materially changed since their last assessment - a vendor pushed a model update, a use case expanded, a new data source was integrated - without re-engaging the intake process. By month twelve, the inventory's risk classifications are fiction; by month eighteen, the audit trail no longer accurately represents what the deployed systems are doing. The fix is structural: every system above Tier 1 has a defined re-assessment cadence (typically annual for Tier 2, semi-annual for Tier 3) and a list of trigger events that force earlier re-assessment regardless of cadence. Both should be captured as part of the original intake decision, not added later.

Why the two year-two failures matter more than the early ones. Loss of executive sponsorship and rubber-stamp review boards are the failure modes that kill mature programs. Both are invisible in normal operating reviews; both surface only when a material incident forces the program to demonstrate that its governance posture was defensible at the moment a system was approved. The structural fixes - quantified board-level exposure metrics, rotated independent reviewers, documented contrary opinions - are operational, not cultural; they have to be built into the program before they are needed, because retrofitting them after a failure is what regulators read as evidence of governance theater.

For the broader inventory discipline that supports the failure-mode signals above, see our guide to building an AI system inventory.

What good looks like: year-1 benchmarks

The metrics below set out the working profile for a tiered intake program inside the first 12-18 months and the maturity profile most reach by year three. The headline target ranges represent observed trajectories across Enzai's customer-program base.[16] Individual programs vary by starting maturity, sector, and intake-automation level - these benchmarks describe a working-program profile rather than a guaranteed outcome. Programs running materially below the year-1 numbers at month twelve are usually missing one of the structural fixes above.

A program with no Tier 4 requests is probably failing to catch the cases it should be catching; a program where every request lands in Tier 3 has stopped classifying and is performing defensive over-tiering at the cost of operational velocity. Both states signal that the classification logic needs review.

The proportionality principle, in practice

Tiered intake is the operational expression of the proportionality principle that every major AI regulatory regime now embeds: the four-tier model gives it structure, the eight classification dimensions provide the routing logic, the five-step workflow is the shape scaled per tier, and the benchmarks supply the diagnostic.

Tiered intake produces the visibility that paper governance cannot. With a working tiered process in place, the AI footprint can grow without the program losing sight of the parts that matter most: the cases that should be caught get caught at intake, the cases that should move quickly do so without unnecessary friction, and the audit trail produced as a by-product is the kind a regulator can review without preparation.

The tension to resist is the one regulators see most often: substituting documentation for discipline. A program with detailed assessments and an empty Tier 4 is not a governance program; it is a paperwork program. The proportionality principle works only when proportionate refusal is part of the operating discipline alongside proportionate review.

For the broader agentic-controls question that sits adjacent to tiered intake at the higher tiers, see the Definitive Guide to Agentic AI Governance.

Frequently asked questions

What is tiered intake for AI governance?

Tiered intake is the operational discipline of routing each AI request to a depth of review proportional to its risk. Most enterprise programs settle on four tiers - Self-Service, Light Review, Full Review, and Restricted - with each tier carrying its own classification process, approver, documentation depth, and re-assessment cadence. The model replaces the one-track review approach that breaks at the point where governance volume meets the velocity of AI adoption.

How many tiers should an enterprise AI governance program have?

Four is the practical maximum for most enterprises. Programs governing fewer than a few hundred AI systems can often run on three (collapsing Light Review and Full Review with deeper questionnaires inside the latter). Five or six tiers is a sign of over-engineering; each additional tier creates routing ambiguity at the boundary between adjacent tiers and adds review-body coordination cost without commensurate risk-coverage benefit.

Which AI systems should automatically land in Tier 3?

Any system falling under EU AI Act Annex III, any system making consequential decisions about individuals (employment, credit, insurance, housing, healthcare, justice, essential services), any sector-specific high-risk regime trigger, and any agentic system with autonomous action capability regardless of underlying use case. The rule: take the highest tier indicated by any single classification dimension and document the reasoning.

How does tiered intake handle agentic AI?

Agentic systems default to Tier 3 because operational autonomy raises the risk profile regardless of use case. Intake for agentic systems should capture the action whitelist explicitly, the escalation conditions that trigger human handoff, and the monitoring covering behavior between handoffs. Whitelist expansion is a substantial-modification trigger that brings intake back on its own.

What triggers re-assessment of an approved AI system?

Substantial modification - defined by EU AI Act Article 3(23) as a change to an AI system after market placement that affects its compliance or intended purpose. Practical triggers include vendor model updates, agentic action-whitelist expansions, use-case scope changes, training-data refreshes for fine-tuned models, and material increases in user population or geographic deployment. Tier 2 systems typically re-assess annually plus on triggers; Tier 3 systems typically re-assess semi-annually plus on triggers.

How long does it take to build a tiered intake process from scratch?

Three to six months to operating in a manual mode for the first cohort of requests; nine to fifteen months to operating against the year-1 benchmark targets; eighteen to twenty-four months to reach the year-3 maturity profile. The transition from manual to automated is forced rather than optional past a certain volume - typically somewhere between 50 and 200 AI systems under governance, depending on the rate of new request arrival.

Does tiered intake replace existing GRC processes like vendor risk and procurement?

No. It sits upstream of them. The intake record is the single source of truth that vendor risk, procurement, security, and privacy each reference for their respective obligations; none of these teams re-asks the same questions. The most common failure mode is operating intake as a parallel track to existing GRC; the correct model is intake as the front door producing a single record consumed downstream.

Where does Enzai fit relative to platforms like ServiceNow or OneTrust?

Enzai operates as the AI-specific governance layer that sits upstream of and integrates with enterprise GRC stacks like ServiceNow, OneTrust, and ProcessUnity. The intake record produced in Enzai feeds the downstream workflows those platforms already run; the AI-specific assessment depth and regulatory framework coverage live in Enzai. Most customers operate Enzai alongside existing GRC infrastructure rather than replacing it.

Where Enzai fits

This guide describes the operating discipline. Enzai operates the platform that delivers it - the four-tier model, the dimension-driven classification, the five-step workflow, and the integrated audit trail, all running as infrastructure rather than process. If you are at the inflection point and want to work through where your program sits against the benchmarks in this guide, get in touch - we will run one of your live use cases through the model.

Read the full guide: The Essential Guide to AI Governance - From Policy to Practice covers tiered intake alongside policy development, compliance frameworks, inventory management, assessment design, and ongoing monitoring. Download the guide.

Enzai is the leading enterprise AI governance platform, purpose-built to help organizations transition from abstract policy to operational oversight. Our AI risk management platform provides the specialized infrastructure required to manage agentic AI governance, maintain a comprehensive AI inventory, and ensure EU AI Act compliance. By automating complex workflows, Enzai empowers enterprises to scale AI adoption with confidence while maintaining alignment with global standards like ISO 42001 and NIST.

References

1. Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, July 2024. eur-lex.europa.eu/eli/reg/2024/1689/oj

2. ISO/IEC 42001:2023, Information technology - Artificial intelligence - Management system. International Organization for Standardization, December 2023. iso.org/standard/81230.html

3. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. National Institute of Standards and Technology, January 2023. nist.gov/itl/ai-risk-management-framework

4. Regulation (EU) 2024/1689, Article 6 - Classification rules for high-risk AI systems.

5. Regulation (EU) 2024/1689, Article 5 - Prohibited AI practices.

6. Regulation (EU) 2024/1689, Annex III - High-risk AI systems referred to in Article 6(2).

7. Regulation (EU) 2024/1689, Annex IV - Technical documentation referred to in Article 11(1).

8. Colorado SB 24-205, Concerning Consumer Protections for Artificial Intelligence, signed May 2024. leg.colorado.gov/bills/sb24-205

9. Bank of England Prudential Regulation Authority, Supervisory Statement SS1/23, "Model risk management principles for banks", May 2023. bankofengland.co.uk

10. Board of Governors of the Federal Reserve System, SR Letter 11-7, "Supervisory Guidance on Model Risk Management", April 2011. federalreserve.gov

11. New York City Local Law 144 of 2021, Automated Employment Decision Tools. nyc.gov/site/dca/about/automated-employment-decision-tools.page

12. California Privacy Protection Agency, Proposed Regulations on Automated Decisionmaking Technology (ADMT). cppa.ca.gov/regulations/

13. Regulation (EU) 2024/1689, Article 6(3) - Exception for Annex III systems posing no significant risk.

14. Regulation (EU) 2024/1689, Article 3(23) - Definition of substantial modification.

15. Regulation (EU) 2024/1689, Article 50 - Transparency obligations for providers and deployers of certain AI systems.

16. Year-1 capture rate, tier-distribution, and time-to-decision targets in this section reflect Enzai's composite observations across enterprise AI governance programs that have completed at least 12 months of operational tiered intake. Individual program trajectories vary by starting maturity, sector, and intake-automation level; the figures cited represent a working-program profile rather than a guaranteed outcome.