AI theater: when usage hides the absence of value

An AI demo is almost always appealing. It shows a natural-language request, a clean answer, an interface that appears to understand, and a dramatic before-and-after. The room reacts well because the demonstration makes visible a future where painful work disappears. But a demo is a protected environment. It does not include missing data, contradictory policies, impatient customers, exceptions, legal responsibility, or budget tradeoffs. Theater begins when that demo becomes sufficient proof.

Theater is dangerous because it occupies the political space of transformation. A company that announces a lot of AI can look like it is moving, so it receives less pressure to prove. Teams that ask questions become blockers, pilots stay open, budgets spread, leaders collect examples instead of deciding on use cases. Everyone sees activity. Nobody knows which pain disappeared.

The language of theater avoids constraints. It talks about enablement, acceleration, the future of work, agents, autonomy, moonshots, transformation. These words can be useful, but they become suspicious when they replace workflow names, volumes, errors, costs, and decisions. A solid initiative can say: we want to reduce supplier qualification time by 20 percent while keeping errors under 2 percent. A theatrical initiative says: we want to unlock AI potential in procurement.

The second signal is the absence of bad results. A real AI program produces disappointments because it tests hypotheses. It closes paths, reduces scopes, admits some uses are not worth their cost. Theater closes nothing. It keeps everything alive to protect the story. If every pilot is described as promising, if no stop decision is documented, if the only numbers are usage and satisfaction, the organization is not learning. It is staging its optimism.

A third signal is the missing loser. In a healthy portfolio, some use cases lose budget because others have better proof. In theater, every initiative remains "strategic" because nobody wants to create a public loser. That sounds kind, but it prevents concentration. The company spreads attention across weak signals and starves the few workflows that could actually change performance. Asking which use case lost resources this month is often the fastest way to know whether governance is real.

An internal demo that fails mostly costs time. A public chatbot that fails can cost money, trust, and legal accountability. The Air Canada case made this clear: an automated answer about a commercial policy does not float outside the company. It is received as the company’s answer. The New York City chatbot showed the same logic in the public sector: when an official interface gives wrong regulatory guidance, the risk is much larger than user satisfaction.

Theater loves conversational interfaces because they create instant maturity. Yet the more confidently an interface speaks, the more it needs boundaries: sources, freshness, tone, forbidden topics, escalation, trace, responsibility. Without these limits, the organization creates a machine that looks like it knows. That is the dangerous form of spectacle: the user cannot see uncertainty, and the company cannot see every answer leaving.

Internal theater creates fewer visible scandals, but it is expensive. It looks like an AI committee that meets often without closing decisions, a use-case catalog that grows without prioritization, a center of excellence that produces guides but owns no result, or a dashboard that shows adoption without full cost. These devices can be necessary, but they become theatrical when they document intent more than they change work.

The remedy is to connect every artifact to a decision. A committee must stop, scale, or correct use cases. A catalog must prioritize by cost, value, and risk. A guide must reduce observed errors. A dashboard must trigger budget tradeoffs. If an artifact changes no decision, it may be elegant and useless. Theater fades when governance stops being a stage and becomes a decision machine.

The most useful committee question is deliberately uncomfortable: what did we decide here that we would not have decided without this forum? If the answer is only "we aligned," "we raised awareness," or "we shared progress," the forum can still be useful as communication, but it should not be confused with governance. Real governance leaves hard traces: budget moved, use case stopped, vendor consolidated, risk accepted, owner named, metric replaced. Internal theater fades when meetings produce fewer narratives and more consequences.

In many companies, AI has become a marker of competence. Saying a use case does not work can sound like admitting backwardness. Teams therefore polish results, keep limitations private, turn errors into training needs, and extend pilots. The dynamic is human. Nobody wants to break momentum. But a culture that cannot declare failure cannot learn fast enough to get ROI.

Stopping must become honorable. A pilot stopped with evidence should be celebrated as savings and learning. A test that reveals risk before production protected the company. A trial showing review cost is too high avoids funding an illusion. AI maturity is not visible in the number of projects launched. It is visible in the number of clear decisions the organization can take without losing face.

Leaders can make this concrete by changing the meeting ritual. Instead of asking teams to show what worked, ask them to bring one assumption that weakened, one metric that disappointed, and one decision they recommend. The tone matters: if disappointment is punished, theater returns immediately. If disciplined bad news is rewarded, teams start surfacing reality earlier, when the cost of correction is still low.

To separate value from spectacle, ask for a trace. Not a video. An operational trace: ticket handled, delay reduced, error avoided, sale accelerated, invoice reconciled, decision documented, customer request resolved, old tool closed. The trace must be verifiable by someone who did not participate in the demo. It must survive team enthusiasm and compare against a baseline period.

The trace can be simple. A table with ten before-and-after cases is sometimes enough. An exception log can be more useful than a sophisticated dashboard. A sample reviewed by an expert can reveal more than an adoption score. Theater wants to climb into abstraction; proof descends into cases. The bigger the AI narrative becomes, the more concrete the evidence must be.

The trace should also show what happened after the first output. Did the customer accept the answer, did the invoice reconcile without later correction, did the manager approve faster, did the risk team reduce review scope, did the old workflow actually close? Theater stops at the generated artifact. Proof follows the artifact until it creates or fails to create a result.

Some teams fear that a proof requirement will kill energy. The opposite is true. Proof frees ambition from fashion. When a use case demonstrates real value, it becomes easier to give it budget, data, IT support, and a place in the system. When a use case fails, it releases resources for a better problem. Method turns AI into a portfolio of options instead of a story to defend.

The right posture is sober: every initiative has a hypothesis, owner, full cost, boundary, measure, and decision on a fixed date. It can start small, even manually, as long as proof is clear. A company operating this way may be quieter than competitors for a few months. Then it will have something rarer than an announcement: a short list of use cases that survive contact with the field.

This method also protects the people doing the work. Without it, operators become responsible for making a vague promise true after leadership has already celebrated it. With it, they can say exactly what is known, what is uncertain, what support is needed, and what should stop. The conversation becomes less performative and more humane because it stops asking teams to defend a fantasy.