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

Designing an AI use-case intake that scales: why tiering matters more than "approval"

When a $1.2B insurance group put every AI request through a single committee that met monthly, the result was predictable: a six-month backlog, teams frustrated into shadow tools, and a compliance process that looked like a dam holding back adoption rather than a safety valve. They fixed it not by creating a bigger committee, but by redesigning intake around four risk tiers - and the results were striking: 80% of requests now clear within a week, the committee focuses on the few cases that matter, and visibility into risk actually increased.

This is the practical playbook that got them there - decisions, form fields, SLAs, exception handling, and the governance mindset that turns risk controls into adoption enablers.

The problem: bottlenecks are the enemy of safe adoption

Committees that must approve every project are often born of good intent: centralize expertise, prevent errors, and ensure regulatory alignment. In practice they create three bad incentives:

- Long queues push teams to bypass controls with shadow tools that are invisible to risk functions.
- The committee becomes a gate rather than a guide, wasting subject matter time on low-impact cases.
- Risk teams lose fidelity because they see fewer, not more, projects - and those they do see are the complicated ones after months of undocumented work.

The insurance group's committee was the textbook example: monthly meetings, one checklist, one decision pathway. The backlog fueled shadow experimentation in chatbots and model tuning, increasing operational and regulatory exposure - exactly what the committee aimed to prevent.

The fix: tier, don't just approve

Instead of asking "yes/no" on every project, they asked: "what kind of review does this need?" The intake process was rebuilt around four tiers:

- Trivial (auto-approved). Low sensitivity, low impact, human in the loop, internal use only - these fly through with automated notifications.
- Low (lightweight review). Minor customer exposure or internal efficiency gains; short, focused review by a working group (not the full committee).
- Elevated (committee review + risk treatment). High customer impact, sensitive data, autonomous decisions, or regulatory exposure - these go to the committee with a mandatory risk treatment plan.
- Prohibited. Uses that violate policy, law, or unacceptable risk (e.g., profiling protected classes for pricing) - rejected with remediation steps.

This is not risk aversion; it's risk proportionality. Controls match potential harm.

The four criteria that determine a tier

The intake form and routing logic were built around four practical, binary-leaning criteria that executives and operating leaders can actually assess without becoming ML experts:

- Data sensitivity. Does the project use PII/PHI, financial data, or other regulated datasets? More sensitive data immediately raises the tier.
- Decision impact. Does the model make or materially influence a decision that affects customer outcomes (pricing, denial, coverage limits)? Direct decisioning increases tier severity.
- Autonomy. Will the system act without a human in the loop, or only recommend? Higher autonomy → higher tier.
- Customer exposure. Is the output customer-facing or affecting customer perception/rights? External-facing systems are riskier.

Each criterion is scored, and the highest applicable criterion determines the initial tier. That's deliberate - a model using non-sensitive data but making autonomous denial decisions for claims is elevated even if the dataset is benign.

Intake form fields that drive correct routing

The intake form matters because the answers must be precise enough to route correctly, but simple enough for product teams to complete quickly. The insurance group kept the form focused with mandatory, structured fields that map directly to the tier logic:

- Project title and summary (one-sentence outcome)
- Business owner, technical owner, and legal/compliance contact
- Desired timeline and go-live date
- Primary use case (underwriting, claims triage, customer service, marketing)
- Data sources (specific datasets, PII/PHI flags)
- Model type (rules-based, statistical, ML, generative AI, third-party API)
- Decision role (inform, recommend, decide)
- Customer exposure (internal, agent-only, direct customer)
- Vendor involvement (vendor name, host location, SOC/attestations)
- Regulatory touchpoints (state insurance regulator, EU market, HIPAA, etc.)
- Controls proposed (human review points, explainability, rollback plan)
- KPIs and post-deployment monitoring plan

Those fields enable automated routing and populate the committee packet when needed - a critical time saver. The form is integrated into the project management system so approvals and artifacts live with the project.

SLAs that earn trust and break incentives to shadow

Speed is governance's best friend. If governance is slow, teams circumvent it. The insurance group established clear SLAs for each tier and backed them with transparent dashboards:

- Trivial: Auto-approved; notification to risk and IT within 24 hours.
- Low: Decision or feedback within 3 business days.
- Elevated: Full committee review or decision memo within 7 business days; if committee meeting timing pushes beyond 7 days, a fast-track panel of 2 senior reviewers can provide provisional approval with mandatory follow-up.
- Prohibited: Immediate denial and remediation guidance within 48 hours.

They also set a 30-day turnaround for post-deployment checklists and a 90-day operational validation for elevated systems.

Why these SLAs? Two reasons:

1. They remove the incentive to go shadow - if a low-risk AI project returns a decision in 3 days, there's no need to launch an unsanctioned pilot.
2. They force the committee to reserve its attention for elevated cases where its expertise matters.

After implementation, 80% of requests cleared within a week; the committee's monthly agenda shrank by 70%, and the number of unregistered AI initiatives fell.

Handling exceptions without breaking the model

No intake model survives first contact unchanged. The insurance group built explicit exception pathways so the system would be durable:

- Expedited requests. For regulatory deadlines, serious competitive threats, or remediation needs. These require a documented justification and are triaged within 24-48 hours by a defined escalation path (CRO, GC, Head of Data).
- Reclassification during lifecycle. Projects can move up tiers as scope changes (e.g., internal model goes public). Change control is mandatory - a simple form triggers rerouting.
- Appeals and gray cases. Product teams can request a secondary review if they believe a tier was misapplied. An appeals panel meets weekly.
- Sunset and reassessment. Elevated systems get mandatory reassessment at 3, 6, and 12 months or when model performance or data changes exceed thresholds.
- Incidents and rollbacks. If a deployed model causes unexpected harm or regulatory notice, the rollback authority is pre-delegated to the business owner with immediate notification to the committee and regulators as required.

These exception rules are as important as the tiers themselves. They keep governance adaptive rather than brittle.

Metrics that matter - what to measure

Good governance is measurable. The insurance group tracked a compact set of KPIs to ensure the intake process improved both speed and safety:

- Time to decision by tier (median and 95th percentile)
- Percentage of auto-approved and low-review cases
- Number of committee reviews per month
- Number and severity of incidents attributable to AI projects
- Rate of unregistered AI projects discovered by audit
- Post-deployment performance deltas (drift, error rates)
- Regulatory issues escalated

After the redesign, their backlog time dropped from 180 days to under 7 for most requests, committee reviews became focused on complex elevated cases, and the audit found fewer unregistered initiatives.

Aligning with external frameworks (without becoming a lawyer)

You don't need to copy a regulator's checklist to get this right, but alignment with common frameworks makes the intake defensible and scalable:

- Use the NIST AI Risk Management Framework principles (govern, map, measure, manage) to structure decisioning and controls.
- Treat "elevated" use cases as analogous to the EU AI Act's high-risk concept - document model risk treatments, testing, and human oversight.
- Consider ISO/IEC 42001 if you plan an enterprise AI management system - tiering and intake are the operational entry points.

These references help when external audits, boards, or regulators ask why you classify something a certain way.

Practical rollout: 90-day playbook

How to get started without a year of committee meetings:

1. Define tiers and criteria (weeks 1-2). Keep them simple and testable.
2. Build a lean intake form (weeks 2-4). Integrate with existing project tools.
3. Automate routing and notifications (weeks 4-8). Use rules to map fields to tiers.
4. Set SLAs and staffing (weeks 6-10). Identify who will handle low, elevated, and expedited reviews.
5. Pilot with two business units (weeks 10-14). Iterate on form fields and thresholds.
6. Publish results and train teams (weeks 14-16). Share dashboards and show the speed gains.
7. Scale and monitor (ongoing). Use KPIs and audits to refine tier thresholds.

The insurance group completed a pilot in 12 weeks and rolled it enterprise-wide in 6 months.

Conclusion - governance that speeds adoption

Tiering transforms intake from a binary blockade into a scalable funnel: most projects get the light-touch control they need quickly, and the committee concentrates on the truly risky ones. The $1.2B insurer moved from a six-month queue and shadow AI to 80% cleared within a week, fewer undocumented projects, and stronger post-deployment oversight.

If you take one readiness move this quarter, do this: build a four-tier intake, automate routing from a compact intake form, and publish SLAs that trade central control for timely local action. Governance then becomes what it should be - an enabler of safe, auditable, and faster AI adoption, not the reason people build in the dark.

Practical next step: run a 12-week pilot with two product teams using the four tiers above. Measure time-to-decision, percent auto-approved, and unregistered initiatives discovered. You'll either prove the model, or learn what to tune - both outcomes are progress toward AI economy readiness.