Do not send every AI request through the same approval queue

The first AI governance mistake is approving everything informally.

The second is sending every request to the same committee.

A marketing manager wants to use a writing assistant for public campaign drafts. A support leader wants to summarize private ticket history. A finance team wants a model to flag unusual invoice patterns. An engineer wants an agent that can open pull requests. Those are not the same governance problem, even if every request contains the word “AI.”

One queue makes the wrong promise. It tells low-risk teams to wait for a process they will route around, and it tells high-risk teams that approval is mainly a calendar slot. The better first design is an intake model with lanes.

The decision

Use one intake form, but do not use one approval path.

Sort each request into a lane based on four questions:

Question	Why it changes the lane
What data will the workflow see?	Public text, internal notes, customer records, employee data, regulated data, and source code carry different exposure.
What can the output affect?	A private draft, an internal recommendation, a customer message, a system change, and a business decision need different review.
Can a mistake be reversed?	Reversible drafts can tolerate local controls. Automated writes, external sends, and high-consequence decisions need stricter gates.
Who has to maintain it?	A personal habit can live with the user. A recurring workflow needs an owner, support path, logs, and a review date.

The intake form should collect enough information to sort the request. The lane should decide who reviews it, how fast it can move, what evidence is required, and when it must be reviewed again.

NIST’s AI Risk Management Framework is useful because it treats AI risk management as context-aware work across govern, map, measure, and manage functions, not as a universal yes-or-no checklist NIST AI RMF. The AI RMF Core also says its actions are not necessarily ordered steps and should be applied in ways that fit resources, capabilities, and lifecycle context AI RMF Core.

That is the point of lanes. They preserve governance without pretending every AI request has the same risk shape.

A useful first set of lanes

Start with four lanes. Rename them to match the company, but keep the distinctions clear.

Lane	Good fit	Required review
Local use	Personal or team drafting with public or approved internal information	Manager or workflow owner
Standard workflow	Recurring internal workflow with confidential data or shared outputs	Business owner plus security or privacy as needed
Controlled workflow	Customer, employee, financial, legal, security, production, or high-impact operational use	Business owner, domain reviewer, security, privacy, legal, procurement, compliance as relevant
Restricted or no-go	Prohibited use, missing owner, unclear data rights, automated high-consequence action, or insufficient review evidence	Stop or redesign before review

This is not a maturity model where every request should climb toward the strictest lane. It is routing. A low-risk draft assistant should not become a compliance project. A tool that can write records to a customer system should not be treated as a local productivity habit.

ISO describes an AI management system as policies, processes, and controls for governing how AI systems are designed, developed, deployed, and used. Its ISO/IEC 42001 explainer emphasizes responsibilities, risk assessment, data governance, monitoring, lifecycle controls, and continual improvement ISO 42001 explained. Intake lanes are a lightweight way to make those management-system ideas usable before a company has a full AI governance office.

What belongs in the intake record

The intake record should be short enough that teams actually submit it and specific enough that reviewers can route the request.

Use these fields:

Field	Example
Request	Summarize closed support tickets before quarterly account reviews
Owner	Director of Support Operations
Users	Support managers and account managers
Input data	Support ticket text, account name, account tier
Output	Internal renewal-risk summary
Output audience	Account owner only
Tool or vendor	Approved enterprise assistant, no personal accounts
Data retention	Vendor logs off for prompts and files, internal record kept 90 days
Human review	Account owner reviews before CRM entry
Reversibility	CRM note can be corrected, customer email not automated
Expected lane	Standard workflow
Review trigger	New CRM fields, external email use, model/provider change, customer-visible output

The “expected lane” is a requester’s guess, not the decision. The reviewer can move it.

The “review trigger” is often the most important field. It prevents approval from becoming stale. A workflow approved for internal drafts from support tickets is not automatically approved for customer-facing replies, account scoring, refund decisions, or automated CRM updates.

Give each lane a service level

Governance fails when every request disappears into a vague queue. Publish a response expectation for each lane.

For example:

Lane	First response	Decision target	Evidence required
Local use	2 business days	5 business days	Tool, data type, intended use, owner
Standard workflow	3 business days	10 business days	Sample inputs and outputs, review gate, retention notes, failure modes
Controlled workflow	5 business days	Scheduled review	Full workflow description, data map, vendor review, domain review, security/privacy assessment
Restricted or no-go	2 business days	Stop or redesign	Reason for restriction and redesign path

These numbers are placeholders. The important part is the promise. Low-risk teams get a fast path. High-risk teams know the evidence bar before they start. Reviewers can spend attention where the blast radius is real.

Without service levels, local teams will treat governance as delay. With service levels, the intake model becomes part of delivery planning.

Do not make the central team own every decision

The central AI team should own the intake model, lane definitions, shared standards, exception handling, and review quality. It should not own every workflow forever.

A local business owner should own the business use. Security should own security review. Privacy should own privacy review. Legal should own legal interpretation. Procurement should own vendor terms. Compliance should own regulated control requirements. The central team coordinates the system and spots patterns across requests.

OECD’s AI Recommendation frames accountability around roles, context, and the state of the art OECD Recommendation on AI. That is a practical operating principle: accountability follows the work. A finance workflow cannot be made safe only by an AI program manager who does not own finance controls. A support workflow cannot be maintained by a steering committee that never sees the ticket queue.

Use the intake lane to route accountability to the people who can actually inspect the workflow.

What goes wrong

The first failure mode is under-routing. Teams label everything “local use” because they only see the interface, not the data boundary. Fix that by asking about input data and output effect before asking about the tool.

The second failure mode is over-routing. Reviewers send harmless drafting tasks through legal, security, privacy, procurement, and an executive committee. That trains the company to hide work. Fix that with a genuinely fast local lane and clear limits.

The third failure mode is lane drift. A workflow starts as a local assistant, then gains private data, shared outputs, tool access, and operational dependence. Fix that with review triggers and a workflow inventory. If the data, output audience, tool permission, model, vendor, human review gate, or business use changes, the lane may need to change.

The fourth failure mode is vague approval. “Approved to use AI for support” is too broad. Approval should name the workflow, tool, data boundary, output audience, review gate, owner, and next trigger.

When a single queue is still appropriate

A single central queue can work for a short emergency pause, a newly regulated category, a security incident, or a company that has only a handful of AI requests.

It can also work as the front door. Every request enters through one form, one email alias, or one ticket type. The mistake is making the front door the whole operating model.

If the organization has dozens of teams experimenting with AI, a single queue becomes either too slow or too shallow. It will block low-risk requests, miss context on specialized workflows, and make reviewers the bottleneck for decisions that should belong to business owners and domain functions.

The operating rule

Write this into the AI operating model:

AI requests enter through one intake record, then route by lane according to data sensitivity, output impact, reversibility, tool permission, ownership, and review evidence.

That rule gives teams a path. It also gives reviewers a way to say yes without pretending every yes has the same meaning.

The goal is not more process. The goal is fewer hidden exceptions, faster low-risk adoption, and sharper review where AI can actually affect people, customers, systems, or company records.