Designing an AI Use-Case Intake Process: Why Tiering Matters More Than Approval

Designing an AI Use-Case Intake Process: Why Tiering Matters More Than Approval

Every boardroom has a story about governance gone well-and one about governance that turned into a roadblock. For a $1.2B insurance group I worked with, the roadblock looked like a monthly committee meeting. Every AI request-no matter how small-landed on the same agenda. The committee could only meet once a month. Backlog grew. Teams waited six months for a green light. Predictably, business units started tinkering outside the process with shadow tools and vendor trials. The result was the opposite of what governance was supposed to do: slower adoption, more risk, and less visibility.

They fixed it not by hiring more reviewers, but by rethinking the question they were asking. Instead of "approve or deny," they asked, "what level of review does this actually need?" The answer was a simple four-tier model: trivial (auto-approved), low (lightweight review), elevated (committee review with risk treatment), and prohibited. Within six months, 80% of requests cleared within a week, the committee focused on the handful of genuinely high-risk cases, and total risk visibility rose-because the new process captured structured data about every request.

If your organization is trying to scale AI without turning governance into a bottleneck, this is the practical playbook.

Governance as an enabler, not a gatekeeper

Good governance should speed safe adoption. That happens when rules are proportional to risk and when the process produces information you can act on. Rigid, one-size-fits-all approval rituals create two predictable failures:

- Slow adoption: business teams are blocked waiting for decisions, so they either stall projects or use shadow solutions.
- Poor visibility: committees see only what arrives on their calendar, not the activities in the wild.

Tiering fixes both. It routes routine, low-risk work quickly, concentrates expert attention where it matters, and accumulates structured intelligence about what the organization is building.

The four-tier model that scaled the insurer

The insurance group replaced the single committee gate with four tiers:

- Trivial - Auto-approved. Low-sensitivity data, no automated decision, internal use only, human-in-loop, minimal customer exposure. Common examples: automated meeting notes summarization, template generation for internal briefs using redacted inputs.
- Low - Lightweight review. Internal decisions, limited sensitive data, human oversight required, few customers affected. These undergo a short checklist review by a governance analyst or tech owner.
- Elevated - Committee review + risk treatment. High-sensitivity data, high decision impact (including pricing and claim outcomes), customer-facing systems, significant autonomy (e.g., automated decisions), cross-border data transfers, or use of third-party foundation models. The committee assesses and prescribes risk treatments or controls.
- Prohibited. Uses that contravene regulation or policy (e.g., unconsented biometric inference for claims decisions, unlawful profiling), or where risk cannot be mitigated to an acceptable level.

This is simple, but clarity is the point. The insurer applied mapping rules to each new request and automated routing to the right review path.

What governs the mapping? Four practical criteria

When you need to route a use case, ask four straightforward questions. These are the axes that matter for business and regulators (NIST AI RMF, EU AI Act, and corporate auditors all look at these factors):

1. Data sensitivity - Does the project use personal data, health records, claims history, or special category data that requires elevated protection?
2. Decision impact - Will the model make or materially influence decisions that affect customers economically or legally (pricing, claims denials, policy underwriting)?
3. Autonomy - Is the output automated or human-in-loop? Fully automated actions that affect customers require far stricter controls.
4. Customer exposure - Is the system customer-facing or does it influence customer experience and trust? External-facing models require extra scrutiny for fairness, explainability and regulatory compliance.

These axes map cleanly to tiers. For instance, low data sensitivity + advisory outputs + human-in-loop + internal-only = trivial. High data sensitivity + automated decisions + customer-facing = elevated or prohibited.

The intake form that makes routing reliable

Routing works only if the intake asks the right questions. Keep the form short, precise, and machine-routable. The insurer found that a single-page intake with structured fields did more to reduce friction than long narrative descriptions. Key fields that drive routing:

- Project name and owner (business sponsor)
- Business objective and expected benefit (KPIs)
- Proposed model type / vendor / foundation model use
- Data sources and classification (PII, health, financial, third-party)
- Decision type (informational, recommendation, automated action)
- Autonomy level (human-in-loop, human-on-the-loop, fully automated)
- Customer exposure (internal only / small pilot / wide customer roll-out)
- Estimated number of users and scale
- Geographic data flows and residency requirements
- Compliance flags (e.g., AML, anti-discrimination, sectoral regulations)
- Proposed controls (logging, human review, appeal process)
- Timeline and budget (to triage urgency)
- Attachments: risk assessment, data flow diagram, model card (if available)

Make required fields enforceable. If a proposer tries to skip data-sensitivity classification, the form won't submit. That discipline increases the quality of information the committee sees and powers automated routing.

SLAs that build trust (and stop the gaming)

Trust the process with predictable timelines. The insurer established simple SLAs that respect operational tempo:

- Trivial - auto-approved within 24 hours (most auto-approval is instant)
- Low - decision within 3-5 business days (lightweight review)
- Elevated - initial determination within 10 business days; full committee review within 2-4 weeks depending on complexity
- Prohibited - immediate rejection with remediation guidance

Two governance rules make these SLAs work:

- Transparency: Every requester can see status, reviewer notes, and next steps in the portal.
- Escalation: For genuine emergencies, there is a documented fast-track with stricter preconditions (pre-agreed controls, additional logging, and immediate post-deployment review).

Predictable SLAs reduce shadow IT. When business teams can plan around a reliable timeline, they're less likely to build unauthorized workarounds.

Handling exceptions without breaking the model

No system survives unanticipated real-world needs without an exceptions process. Exceptions are not failure-they're a sign your model needs refinement. But they must be controlled.

The insurer designed three exception pathways:

- Fast-track approvals for emergencies: Only for business-critical projects with an executive sponsor. These require a written business case, pre-built risk controls, and a sunset date (30-90 days) for a full elevated review.
- Temporary approvals: Allow pilots to proceed for a fixed time with intense monitoring (daily logs, performance thresholds, and mandatory rollback triggers).
- Appeals and reconsideration: If a team disagrees with a tiering decision, an appeal goes to a cross-functional adjudication panel that responds within five business days.

Crucially, every exception creates data. The governance team used exceptions as input for continuous improvement: revising rubric thresholds, clarifying definitions, or expanding automation to cover new case types.

Why tiering increased visibility (not reduced it)

A common fear is that auto-approvals hide activity. The opposite happened. The insurer's structured intake and automated routing produced a live dataset of every AI proposal-its classification, controls, and business impact. That dataset made three things possible:

- Risk heatmaps: Which business areas submit the most elevated cases? Which vendors are common? Where is sensitive data concentrated?
- Portfolio management: The committee stopped being a day-to-day reviewer and became a strategic board for high-risk projects and investment prioritization.
- Regulatory readiness: When auditors or regulators asked for an inventory of AI systems, the insurer could produce a searchable register with tiering, controls, and SLAs-rather than frantic after-the-fact discovery.

This was how governance became an enabler: by turning decisions into structured information that accelerates safe scale.

Practical implementation steps (90-day playbook)

If you want to emulate this at your organization, here's a pragmatic 90-day roadmap:

1. Week 1-2: Gather stakeholders (legal, security, product, compliance, business owners). Agree on the four-tier framework and the four routing axes.
2. Week 3-4: Draft a one-page intake form and mapping rules. Keep the form short-10-12 required fields.
3. Week 5-6: Build the intake portal or configure an existing tool (ServiceNow, Jira, or a lightweight form with automation). Implement automatic routing logic.
4. Week 7-8: Pilot with 10 active projects across business units-mix trivial, low, and elevated examples.
5. Week 9-12: Review metrics (time-to-decision, exceptions, shadow activity). Adjust mapping rules, SLAs, and intake fields. Publish the revised policy and roll out organization-wide.

Measure success by time-to-decision, percentage of requests auto-routed, and number of exceptions. Aim for 70-80% of requests qualifying for trivial or low tiers within the first two quarters.

Where frameworks fit in

Use frameworks like NIST AI RMF and ISO/IEC 42001 as a backbone-not a control checklist that kills velocity. NIST helps you map risk and monitoring requirements to tiers. The EU AI Act's risk categories are useful if you operate in the EU or serve EU customers; map your elevated tier to "high-risk" constructs where appropriate. The key is to align your tier definitions with regulatory expectations without duplicating work.

Pitfalls to avoid

- Overcomplicating the form. Long intake processes kill compliance.
- Making the committee the default path. If the committee sees everything, it never clears backlog.
- No feedback loop. If teams don't get clear reasons for decisions, they'll bypass the process.
- Treating governance as purely policing. Position it as a product that helps the business move faster and safer.

Conclusion - the readiness move you can make this week

Tiering converts governance from a single gate into a risk-proportionate routing engine. The insurance group's experience is simple: routing most work through lightweight checks and treating a small minority as genuinely elevated saved months, reduced shadow adoption, and increased risk visibility.

Concrete readiness move: this week, convene a short cross-functional workshop and draft a one-page intake form mapped to the four routing axes (data sensitivity, decision impact, autonomy, customer exposure). Pilot that form with five live projects over the next 30 days and measure time-to-decision. Progress requires two things: a clear, enforceable mapping and SLAs teams can trust. Do those, and governance becomes the lever that accelerates safe AI adoption-not the barrier that stalls it.