Most companies that have moved past the AI experimentation phase are discovering a quiet, uncomfortable reality: the tool works perfectly, and nothing has fundamentally changed. The AI runs fast, but the organization runs at the exact same speed it always did. Not because people resist the technology, but because the decision-making chain sitting on top of it absorbs the speed gains before they reach anyone who actually acts on the output.

A previous article on this site called this phenomenon AI theatre, the visible activity that creates the illusion of progress while the operating model stays untouched. But what actually drives it? AI theatre isn't caused by bad technology. It is powered by an accountability vacuum. The human approval chain that fills that vacuum is what keeps the theatre running.

The approval queue that AI never escapes

Most AI deployments are evaluated on whether the tool produces accurate, useful output. Almost none are evaluated on what happens to that output after it leaves the model. In most organizations, it enters a review chain designed for a slower world. The AI output moves fast, but that doesn't matter. It lands in the same approval queue that existed before the tool arrived, and the queue moves at the speed it always has.

The people who run those approval layers usually have a defensible reason for keeping them in place. It's almost never about the AI's accuracy. It's about who carries the cost if the AI is wrong. A manager who approves an AI-generated recommendation that later turns out to be flawed is in a fundamentally different position than a manager whose team spent three weeks producing the same flawed recommendation manually. The second one followed the process. The first one trusted a machine. In most organizations, the political consequences of those two failures are not the same, even when the business outcome is identical.

That asymmetry is what keeps the bottleneck alive. It's not that people don't believe the tool works. It's that nobody wants to be the person who trusted it and was wrong.

The compliance AI nobody uses

Take vendor onboarding. One team built an AI summarizer to handle the thick compliance packets that come in during risk assessments: SOC 2 reports, security questionnaires, certification documents, sometimes hundreds of pages per vendor. The model could ingest the entire submission and produce a structured risk summary with flagged controls in minutes.

The Director of Procurement Operations killed it in the steering committee. He told the room the model "wasn't deterministic enough" regarding compliance gaps and instituted a strict "trust but verify" mandate. He didn't ban the tool outright, but he made it a rule that while the AI could generate the summary, a human analyst still had to read the source documents in full to validate every finding before he would accept the ticket. The product team didn't have the political capital to override Procurement, so the mandate stuck.

Today, the system is technically still live. The AI generates a beautifully formatted summary, but the analysts completely ignore it. They spend days reading the PDFs just like they used to, and then quietly copy-paste the AI's formatting into their final report so it looks like they used the new workflow.

The tool works. The approval chain above it doesn't care.

The pattern isn't limited to compliance.

The QA tool that doubled the workload

A QA team introduced an AI tool that could generate test cases from requirements and user stories. Not execution, not prioritization, but the upfront analytical work of reading a spec and producing the scenarios that need to be tested. The tool caught edge cases that humans routinely missed on first pass, and it generated structured, assignable test cases in minutes instead of the days it normally took a senior QAE to work through a complex feature spec.

The test manager didn't reject the tool. She mandated a comparison step. Before any AI-generated test cases could be assigned to the team for script development, a senior QAE had to independently write their own test cases from the same spec, then review the AI's output against theirs, and document any gaps or disagreements before the final set was approved for assignment.

The rationale was reasonable on the surface. Experienced eyes should validate coverage before anything goes downstream. But the effect was that the senior QAEs were now doing their original job in full and then doing a comparison exercise on top of it. They read the spec, think through the scenarios, write their cases, and only then open the AI output to see what it produced. The comparison step added time to a process that was supposed to get faster. A few of them raised this in retrospectives. The response was that the review step was temporary, "until we build confidence in the model's coverage." That was over a year ago. The step is still there.

Over time, the senior QAEs settled into a survival pattern. They write their own test cases first, as they always have. Then they open the AI output, cherry-pick one or two additions so the adoption metrics stay healthy, and send their version downstream. The tool generates cases for every sprint, but the bottleneck didn't move. It just acquired a second input that nobody was allowed to trust.

Locally rational, organizationally useless

Both decisions were locally rational. The procurement director protected himself from breach liability. The test manager protected her team from coverage gaps. But "locally rational" doesn't mean "organizationally useful." When every person in the approval chain makes the safe choice for themselves, the cumulative effect is a workflow that looks modernized on the surface and runs on the same human bottlenecks underneath. The AI becomes decoration. It produces output. The output enters a queue that moves at human speed, reviewed by people who don't trust it enough to let it change what they do.

This happens because organizations deploy AI tools without answering the question that actually matters: who is authorized to trust this output, and under what conditions?

In most companies, nobody has explicitly answered that. There's no document that says "the AI risk summary is the default, and a human reviews only the cases flagged as high-uncertainty." There's no policy that says "the AI-generated test cases go to the team unless a senior QAE flags a coverage concern, and flags require a written rationale." Instead, the default is universal human review. Every output gets checked, every recommendation gets second-guessed, and the people doing the checking have every incentive to keep checking because that's what protects them.

The real problem: an accountability vacuum

The bottleneck isn't a workflow problem. It's an accountability vacuum.

Nobody has decided who is responsible when an AI-informed decision goes wrong, so everyone in the chain protects themselves by adding review layers that restore the old accountability structure. The approval chain doesn't compete with the AI. It simply absorbs it, and the chain always wins.

The organizations that are getting past this aren't doing anything exotic. They're making the accountability question explicit before the tool goes live, not after the bottleneck forms.

What actually fixing it looks like

In practice, that means defining decision authority at the output level. Not "who reviews this" but "who is allowed to act on this without further review, and what are the boundaries." For low-risk vendor assessments, the AI summary is the accepted input and a human reviews only the flagged exceptions. For routine feature specs, the AI-generated test cases go directly to the team for script development, and the senior QAE reviews only the high-complexity or high-risk scenarios. The human role shifts from universal reviewer to exception handler, which is a better use of experienced people anyway.

It also means writing down the accountability structure before deployment. If the AI flags a vendor as low-risk and that vendor gets breached, who owns that outcome? If the answer is "nobody, because the AI can't be trusted to make that call," then what exists isn't an AI workflow. It's an AI demo with a human workflow bolted on top. But if the answer is "the risk team owns it, same as they would if a human analyst made the same call, and here's the escalation path," then people have permission to actually use the tool. The review chain collapses because the need to self-protect through process disappears.

None of this is about trusting AI blindly. It's about being specific about where human judgment is actually needed versus where it's just present because nobody decided it could go. Universal review isn't diligent. It's the absence of a decision about what level of diligence is appropriate.

Run a decision-authority audit before the next deployment

Most companies that have moved past the AI experimentation phase are discovering a quiet, uncomfortable reality: the tool works perfectly, and nothing has fundamentally changed. The AI runs fast, but the organization runs at the exact same speed it always did. Not because people resist the technology, but because the decision-making chain sitting on top of it absorbs the speed gains before they reach anyone who actually acts on the output.

A previous article on this site called this phenomenon AI theatre, the visible activity that creates the illusion of progress while the operating model stays untouched. But what actually drives it? AI theatre isn't caused by bad technology. It is powered by an accountability vacuum. The human approval chain that fills that vacuum is what keeps the theatre running.

The approval queue that AI never escapes

Most AI deployments are evaluated on whether the tool produces accurate, useful output. Almost none are evaluated on what happens to that output after it leaves the model. In most organizations, it enters a review chain designed for a slower world. The AI output moves fast, but that doesn't matter. It lands in the same approval queue that existed before the tool arrived, and the queue moves at the speed it always has.

The people who run those approval layers usually have a defensible reason for keeping them in place. It's almost never about the AI's accuracy. It's about who carries the cost if the AI is wrong. A manager who approves an AI-generated recommendation that later turns out to be flawed is in a fundamentally different position than a manager whose team spent three weeks producing the same flawed recommendation manually. The second one followed the process. The first one trusted a machine. In most organizations, the political consequences of those two failures are not the same, even when the business outcome is identical.

That asymmetry is what keeps the bottleneck alive. It's not that people don't believe the tool works. It's that nobody wants to be the person who trusted it and was wrong.

The compliance AI nobody uses

Take vendor onboarding. One team built an AI summarizer to handle the thick compliance packets that come in during risk assessments: SOC 2 reports, security questionnaires, certification documents, sometimes hundreds of pages per vendor. The model could ingest the entire submission and produce a structured risk summary with flagged controls in minutes.

The Director of Procurement Operations killed it in the steering committee. He told the room the model "wasn't deterministic enough" regarding compliance gaps and instituted a strict "trust but verify" mandate. He didn't ban the tool outright, but he made it a rule that while the AI could generate the summary, a human analyst still had to read the source documents in full to validate every finding before he would accept the ticket. The product team didn't have the political capital to override Procurement, so the mandate stuck.

Today, the system is technically still live. The AI generates a beautifully formatted summary, but the analysts completely ignore it. They spend days reading the PDFs just like they used to, and then quietly copy-paste the AI's formatting into their final report so it looks like they used the new workflow.

The tool works. The approval chain above it doesn't care.

The pattern isn't limited to compliance.

The QA tool that doubled the workload

A QA team introduced an AI tool that could generate test cases from requirements and user stories. Not execution, not prioritization, but the upfront analytical work of reading a spec and producing the scenarios that need to be tested. The tool caught edge cases that humans routinely missed on first pass, and it generated structured, assignable test cases in minutes instead of the days it normally took a senior QAE to work through a complex feature spec.

The test manager didn't reject the tool. She mandated a comparison step. Before any AI-generated test cases could be assigned to the team for script development, a senior QAE had to independently write their own test cases from the same spec, then review the AI's output against theirs, and document any gaps or disagreements before the final set was approved for assignment.

The rationale was reasonable on the surface. Experienced eyes should validate coverage before anything goes downstream. But the effect was that the senior QAEs were now doing their original job in full and then doing a comparison exercise on top of it. They read the spec, think through the scenarios, write their cases, and only then open the AI output to see what it produced. The comparison step added time to a process that was supposed to get faster. A few of them raised this in retrospectives. The response was that the review step was temporary, "until we build confidence in the model's coverage." That was over a year ago. The step is still there.

Over time, the senior QAEs settled into a survival pattern. They write their own test cases first, as they always have. Then they open the AI output, cherry-pick one or two additions so the adoption metrics stay healthy, and send their version downstream. The tool generates cases for every sprint, but the bottleneck didn't move. It just acquired a second input that nobody was allowed to trust.

Locally rational, organizationally useless

Both decisions were locally rational. The procurement director protected himself from breach liability. The test manager protected her team from coverage gaps. But "locally rational" doesn't mean "organizationally useful." When every person in the approval chain makes the safe choice for themselves, the cumulative effect is a workflow that looks modernized on the surface and runs on the same human bottlenecks underneath. The AI becomes decoration. It produces output. The output enters a queue that moves at human speed, reviewed by people who don't trust it enough to let it change what they do.

This happens because organizations deploy AI tools without answering the question that actually matters: who is authorized to trust this output, and under what conditions?

In most companies, nobody has explicitly answered that. There's no document that says "the AI risk summary is the default, and a human reviews only the cases flagged as high-uncertainty." There's no policy that says "the AI-generated test cases go to the team unless a senior QAE flags a coverage concern, and flags require a written rationale." Instead, the default is universal human review. Every output gets checked, every recommendation gets second-guessed, and the people doing the checking have every incentive to keep checking because that's what protects them.

The real problem: an accountability vacuum

The bottleneck isn't a workflow problem. It's an accountability vacuum.

Nobody has decided who is responsible when an AI-informed decision goes wrong, so everyone in the chain protects themselves by adding review layers that restore the old accountability structure. The approval chain doesn't compete with the AI. It simply absorbs it, and the chain always wins.

The organizations that are getting past this aren't doing anything exotic. They're making the accountability question explicit before the tool goes live, not after the bottleneck forms.

What actually fixing it looks like

In practice, that means defining decision authority at the output level. Not "who reviews this" but "who is allowed to act on this without further review, and what are the boundaries." For low-risk vendor assessments, the AI summary is the accepted input and a human reviews only the flagged exceptions. For routine feature specs, the AI-generated test cases go directly to the team for script development, and the senior QAE reviews only the high-complexity or high-risk scenarios. The human role shifts from universal reviewer to exception handler, which is a better use of experienced people anyway.

It also means writing down the accountability structure before deployment. If the AI flags a vendor as low-risk and that vendor gets breached, who owns that outcome? If the answer is "nobody, because the AI can't be trusted to make that call," then what exists isn't an AI workflow. It's an AI demo with a human workflow bolted on top. But if the answer is "the risk team owns it, same as they would if a human analyst made the same call, and here's the escalation path," then people have permission to actually use the tool. The review chain collapses because the need to self-protect through process disappears.

None of this is about trusting AI blindly. It's about being specific about where human judgment is actually needed versus where it's just present because nobody decided it could go. Universal review isn't diligent. It's the absence of a decision about what level of diligence is appropriate.

Run a decision-authority audit before the next deployment

Before deploying the next AI tool, skip the technical readiness checklist for a day and run a decision-authority audit instead. For every output the tool produces, the question is simple: who currently has to approve it, why do they have to approve it, and what would need to be true for that approval step to not exist. If that third column stays empty, if nobody can articulate what conditions would allow the AI output to flow through without a human re-doing the work, the tool will work and nothing will change. There will be a faster system feeding into the same slow chain, and six months later someone will be copy-pasting its formatting into a report they wrote by hand.

Final thoughts 

AI theatre doesn't end when better tools arrive. It ends when someone in the room finally asks the question that should have been asked before the tool was deployed: who is actually allowed to act on this?