Your AI Adoption Is Waiting on Approval, Not Better Prompts

The author developed this approval model while incorporating AI into real work. AI recomposed the verified Japanese primary for DEV readers and generated the diagram under the standing delegation for English-market publication. #ABotWroteThis

AI can shorten drafting while leaving the organization waiting on approval.

When that happens, teams often reach for the familiar fixes: improve the prompt, buy a stronger model, or train people to use the tool better. Those fixes improve generation. They do not answer the question an approver actually receives:

What exactly am I accepting, what could go wrong, and who can stop it?

If those answers arrive only after the artifact is finished, every request forces the approver to reconstruct the operating boundary from scratch. The work moves quickly until it reaches the approval queue, then slows down in clarification, reassignment, and re-review.

The useful unit is not another AI policy document. It is a small approval interface attached to each AI-assisted request.

My minimum interface has five fields:

1. information class;
2. delegated task;
3. human checkpoint;
4. explanation duty;
5. stop authority.

Define those fields before asking for approval, then route low- and high-risk uses differently. That shifts approval from a vague judgment about “AI” to a concrete decision about one bounded use.

TL;DR

• Faster generation can move elapsed time into approval rather than remove it.
• An approver needs the input boundary, delegated task, human check, explanation duty, and stop authority.
• Put those five fields on the work request before the artifact reaches review.
• Use information sensitivity and decision depth to choose a light or high-assurance route.
• Do not add a new committee by default. Make the existing decision legible and test whether the route catches the failures it claims to protect against.

The queue is asking for a missing interface

Consider a team that uses AI to prepare three items:

• a summary of public documentation for internal use;
• a draft customer proposal based on confidential notes;
• a recommendation that changes a production configuration.

All three may be called “AI-assisted work,” but they do not ask the organization to accept the same exposure.

The first item uses public information and produces a reversible internal aid. The second introduces confidential information and external communication. The third delegates part of an operational decision and can affect a live system.

If every item reaches the same review queue with only a title and generated artifact, the approver must discover the differences manually. A cautious approver asks more questions. An overloaded approver may apply one heavy process to all three. An impatient team may work around the process.

None of those outcomes is primarily a prompting problem. The request omitted the fields needed to route the decision.

The five-field approval interface

The interface should be short enough to travel with the work, but precise enough that “approved” has a stable meaning.

1. Information: what entered the system?

Classify the input before debating the output.

A useful starting set is:

• public;
• internal;
• confidential or customer-related;
• regulated or otherwise restricted.

This field should also name the relevant handling boundary. “Internal” alone is weak if the reviewer still has to ask whether the chosen service may receive it, retain it, or use it for training.

The goal is not to publish secret infrastructure details on every ticket. The goal is to make the admissible information class observable at the decision point.

2. Task: what judgment was delegated?

“Used AI” does not describe the delegation.

These are materially different tasks:

• formatting or summarizing supplied material;
• generating a draft;
• comparing options;
• recommending a decision;
• executing a change.

Approval becomes harder as the system moves from transforming provided material toward making or executing a consequential choice. State the deepest delegated action, not the safest-sounding label.

3. Human check: who verifies what before use?

Naming a reviewer is not enough. Define the pass condition.

For a technical change, the human check might require:

• the proposed diff matches the request;
• tests cover the changed behavior;
• secrets and private identifiers are absent;
• the exact deployment target is pinned;
• rollback remains available.

For customer-facing prose, the check might focus on factual support, scope, confidentiality, and authority to make commitments.

The checkpoint should answer “what evidence lets this move forward?” rather than “who is eventually blamed?”

4. Explanation: what must remain reconstructable?

Not every AI-assisted output needs a model-level explanation. Every consequential use needs enough evidence to explain the decision after the fact.

That may include:

• the sources used;
• the material assumptions;
• the reviewer and acceptance evidence;
• the difference between observed facts and generated suggestions;
• the destination and public or customer-facing claim.

The required depth should match the consequence. A public-document summary does not need the same record as a production migration. But “we cannot tell what was reviewed” is not an acceptable default for either.

5. Stop authority: who can halt or reverse the use?

A rule without an operator is decorative.

The request should name:

• the signal that triggers a stop;
• the person or role allowed to stop it;
• the action that prevents further impact;
• the safe state after the stop.

For a draft, stopping may mean discarding the artifact. For an automated production action, it may mean disabling a job, revoking a capability, or restoring a verified previous state.

This field is often missing because teams discuss approval as permission to start. Reliable approval also defines permission to stop.

Route by two dimensions, not by the word “AI”

Once the five fields exist, route the request using two dimensions:

1. information sensitivity — how damaging misuse or disclosure could be;
2. decision depth — how far the system moves from assistance toward consequential judgment or execution.

That gives a practical matrix:

Information	Delegated task	Route
Public	Summarize or format	Light
Internal	Draft with a named human check	Light or standard
Confidential	Compare or recommend	High assurance
Restricted	Execute or communicate externally	High assurance, or prohibited by policy

The table is an example, not a universal legal classification. Each organization still has to bind it to its contracts, regulations, and systems.

The important design choice is asymmetry. A harmless internal summary should not wait behind the same evidence package as a customer commitment. A production-changing recommendation should not inherit the light route merely because the generated prose looks polished.

What the two routes should change

A light route may allow one named reviewer, a compact evidence record, and a reversible destination. It optimizes for low coordination cost.

A high-assurance route may require separate content and execution authority, stronger source evidence, an exact target binding, rollback proof, and live read-back after the change. It optimizes for preventing silent expansion of consequence.

The route should change the evidence and authority required—not the truthfulness standard. Low risk is not permission to invent facts, leak information, or claim success without verification.

Likewise, a high-assurance route should not become a ritual that repeats checks without knowing what failure each one protects against. Every additional gate should have a named risk, acceptance condition, and removal or redesign condition.

A request schema you can implement

The interface can live in a ticket template, pull request form, document header, or workflow payload.

ai_use:
  information:
    class: internal
    handling_boundary: approved_service_only
  task:
    delegated_action: draft_and_compare
    prohibited_action: final_customer_commitment
  human_check:
    owner: account_lead
    pass_condition:
      - claims_match_source
      - scope_has_no_new_commitment
  explanation:
    retain:
      - source_refs
      - reviewer_receipt
  stop_authority:
    owner: account_lead
    trigger: unsupported_claim_or_scope_change
    safe_state: keep_as_internal_draft

This is not a complete governance standard. It is the smallest useful contract between the person asking for work and the person accepting its consequences.

Test the approval system itself

Approval design can fail even when every request has the five fields.

Measure outcomes that reveal where the process is moving time and risk:

• requests returned because a field was missing;
• time spent waiting for an owner-only decision;
• low-risk requests sent through the heavy route;
• high-risk requests that escaped the heavy route;
• approval decisions reopened because the artifact or target changed;
• successful stops and restorations when a trigger fired.

Avoid one misleading metric: raw approval speed. A process can approve quickly because it stopped looking. The target is the shortest verified path to an accepted or safely rejected outcome, with no ambiguous authority and no unverified success claim.

Start with one repeated queue

Do not begin by writing a company-wide AI constitution.

Choose one queue where AI-assisted work repeatedly waits: customer drafts, internal analysis, code changes, or publication. Add the five fields to the request. Define one light route and one high-assurance route. Run real items through them and record where approvers still need to reconstruct context.

When the same missing question appears repeatedly, turn it into a field or deterministic preflight. When a field never changes a decision, remove or redesign it. When a low-risk request repeatedly enters the heavy route, repair the classifier rather than telling people to be less cautious.

Better prompts may improve the artifact. Better approval interfaces improve whether the organization can use it.

The distinction matters because generation speed is local. Approval latency is shared across the team. If you optimize only the first, the saved time does not disappear—it reappears in someone else's queue.