Doing AI to Say We Have AI

A growing share of enterprise AI initiatives do not start with a problem. They start with a need to be seen using AI. The result is theater: cost, risk, and complexity in search of a use case, with the chatbot, the copilot, and the “intelligent” search box all playing the same role – a visible signal of momentum, light on architecture, accountable to no one in particular.

A company does not always adopt AI because it has found an opportunity. Sometimes it adopts AI because the market is watching, competitors are announcing things, the board is asking about generative models, vendors are pushing demos, and someone needs a screenshot that proves progress. So the chatbot appears. Or the internal assistant. Or the improvised copilot. Or the “intelligent” search box. Or a workflow with AI pasted on top of it. Not necessarily because it is needed. Because it is visible.

The problem is not using AI. The problem is using AI as a status signal. AI placed deliberately, scoped properly, and connected to a real workflow can create significant value. AI deployed so the organization can say it has AI is an expensive way to confuse motion with progress, and the bill is broader than it looks at launch.

This article is about that gap.

The pressure to look AI-native

Several pressures converge at the same time. Competitors announce AI. Investors ask about AI. Boards ask whether the company has an AI strategy. Vendors arrive with polished demos. Conferences and social media amplify the visible end of the bell curve. Internally, leaders feel the need to show momentum, and individual contributors feel the need to be seen working on something modern.

Under that pressure, the question that gets asked first is rarely the right one. The organization starts asking, “Where can we put AI?” before it has asked, “What problem actually deserves AI?” The first question is a sourcing exercise. The second is a strategy.

The wrong starting question

“How do we add AI?” is the question that produces theater. The shape of the answer is predetermined: a feature, a surface, a demo. The shape of the problem is whatever is left over when the demo is built.

The better question, the one that produces strategy, is the inverse. What problem is important enough, frequent enough, expensive enough, or complex enough to justify AI? Where does a decision get made badly today? Where does a workflow burn time, attention, or accuracy? Where is a user stuck waiting for someone else to do something a model could do well, with controls, under supervision?

AI is not the starting point. The problem is. AI is one option for solving the problem, evaluated against rules, traditional software, automation, search, forms, process improvement, and the boring possibility that the problem might already be solved by cleaner data or clearer ownership.

AI theater looks like progress

Theatrical AI initiatives are difficult to kill because they look like leadership. They are easy to present in a slide. They produce convincing demos. They generate momentum. They satisfy the board. They are difficult to criticize without sounding anti-innovation. They let the organization say it is doing something.

That is exactly what makes them dangerous. The signal of progress is decoupled from the substance of progress. By the time the gap becomes visible – in the bill, in a screenshot, in a tribunal decision, in a security review that should have happened earlier – the political cost of pulling the system back is higher than the cost of leaving it running. The organization is now in the business of defending a thing it never decided to build.

The chatbot is the most visible symptom

Chatbots are not the whole problem. They are the easiest symptom to screenshot. A polished public assistant on a corporate homepage is the canonical photo of the pattern: an AI surface that arrived before its architecture did.

The well-known cases follow the same shape. A dealership chatbot agreed, on camera, to sell a vehicle for one dollar. A delivery company’s public assistant produced inappropriate output and criticized its own employer in the company’s voice. An airline’s chatbot gave a customer misleading information, and a tribunal held the airline accountable for the answer. None of those are stories about adversarial AI research. They are stories about the symbol of innovation arriving before the architecture, and the public discovering the gap before the company did.

The chatbot is convenient because it is visible. The same gap shows up wherever AI is deployed for the screenshot rather than for the problem: an internal copilot that nobody owns, an “intelligent” search box bolted onto an unsorted document corpus, a workflow with AI pasted on top of a process that was already broken, a vendor plug-in installed without anyone agreeing on what it should refuse to do. Different surfaces, same gap.

Hype skips the boring questions

When an AI initiative starts from FOMO, a recognizable set of questions gets skipped. They are the questions where architecture lives. Naturally, they are also the first ones cut when everyone wants the shiny thing.

What problem does this solve? Why AI, and not traditional software? What should the system refuse to do? Who owns it? What does each interaction cost? What happens when it is wrong? What happens when users abuse it? What data can it use? What decisions is it not allowed to make? How do we measure success in operating terms, not in vague engagement metrics? When would we turn it off?

None of those questions are exotic. They are the same questions any serious public capability has to answer. The fact that AI surfaces routinely skip them does not mean AI has earned the exemption. It means the exemption was granted informally, and it will be revoked publicly.

The API bill arrives later

The literal API bill is the smallest part of the bill. It is the easiest to measure, which is why it gets the headline, but it is rarely where the largest costs land.

The full bill includes inference cost, yes – long prompts, long completions, retrieval calls, tool calls, verbose logs, and the denial-of-wallet pattern in which a public surface running on a paid model becomes a free proxy for that model and online communities settle in for the afternoon. It also includes the support burden created by users who treat the bot as an authoritative interface, the operational debt of monitoring a system nobody designed to be monitored, the brand cost when generated output becomes a screenshot, the legal exposure when a customer-facing channel commits the company to something it did not intend to commit to, the security cost of a public production surface that nobody scoped for adversarial input, the vendor lock-in that follows when a model provider’s policy changes alter the product’s behavior, the content-maintenance cost of keeping the bot’s sources fresh, the engineering attention diverted from work that would have moved the actual business, and the false expectations seeded in users and leadership when an AI demo is presented as a finished system.

The bill for hype is paid in money, reputation, operations, trust, governance, and engineering attention. The model invoice is the line item people remember; the rest is the line items they do not.

Real AI strategy is less photogenic

Valuable enterprise AI tends to start in places that do not screenshot well. Ticket classification. Case summarization. Internal search over approved sources. Analyst assistance and document review. Data extraction from messy inputs. Anomaly detection in places where humans stop scaling. Controlled draft generation behind a human reviewer. Decision support that makes the human better, not absent.

The shape is consistent. A narrow job definition with explicit non-goals. A workflow whose pain, cost, delay, or error rate is documented before the model is chosen. An accountable owner with a name on it. Approved data sources with a refresh cadence. Refusal behavior that is intentional and tested, not an emergent property of a system prompt. Cost and rate controls wired in from day one. Observable behavior, with logging and red-team prompts as part of the test suite. A documented lifecycle, including the conditions under which the system is turned off.

None of that screenshots well. That is the point. The screenshot was the goal of theater. The system has to live afterward.

Sometimes the best AI decision is not using AI yet

Not every problem deserves a model. Some problems need architecture, cleaner data, clearer ownership, better process, or operational discipline. Those interventions are tragically unglamorous, and they are often correct.

Improve the knowledge base before adding a chatbot, because a chatbot pointed at a stale or contradictory corpus inherits the contradictions and pays per query to repeat them. Clean the data before automating analysis, because a model trained on dirty inputs makes dirty inferences faster, not better. Standardize the process before building copilots, because a copilot bolted onto an inconsistent process amplifies the inconsistency. Create internal APIs before deploying agents, because agents without a contracted surface end up screen-scraping the enterprise. Instrument metrics before predictive optimization, because models cannot optimize what is not measured. Improve traditional search before adding generation, because generation over a poor index is generation of poor answers. Fix ownership before adding automation, because automation amplifies whoever is accountable, including no one.

Some problems deserve a rule, not a model. Some deserve a form. Some deserve a conversation between two people whose calendars are simply not aligned. The discipline is to choose deliberately, not to default to AI because everyone else does.

The architecture test

A practical test separates strategy from theater. None of these questions require a model to answer. Each is a yes-or-no. The fewer yes answers, the more the initiative is theater dressed as strategy.

• If we removed the word “AI,” would the problem still matter?
• Did users need this before the hype cycle?
• Do we have evidence of pain, cost, delay, risk, or error?
• Is AI the best solution, or just the most marketable one?
• Do we know what failure looks like?
• Do we know what the system must never do?
• Can we measure value within ninety days?
• Is there an operational owner with a name on it?
• Are there cost and usage limits, set before launch?
• Is there a safe way to shut it down?

The test is deliberately ungenerous. Theater is hard to kill once it is launched; it is much easier to refuse to launch.

What leaders should demand

The leadership move is not asking for more AI. It is asking for the discipline that turns AI into value.

Mature AI leadership demands use cases tied to real value. Clear problem statements written before the model is chosen. Architecture boundaries that name what the system must never do. Measurable impact within a defined window. Explicit limits on cost, usage, scope, and authority. Accountable ownership with a name on the page. A risk analysis that includes brand, legal, security, and operational exposure. Total cost of operation, not just the model invoice. Shutdown criteria, agreed before launch. Evidence that AI is the right answer, weighed against simpler alternatives that the organization sometimes does not want to revisit because the AI conversation is more interesting.

Surface count is a vanity metric. Operating discipline is the actual capability. The number of places the company has put AI is a much weaker signal than how deliberately AI has been placed where it can create value safely.

After the screenshot

The shallow question is whether the company has AI. The better questions are whether we need it here, what problem it solves, what value it should create, what it is forbidden to do, what it costs when people misuse it, who owns the outcome, and what happens after the screenshot.

AI does not only fail when it hallucinates, gets manipulated, or costs too much. It also fails when it never should have been deployed in the first place. The mature organization does not start with “where can we put AI?” It starts with “what problem deserves AI, what value do we expect, what limits does it need, and who is accountable for the outcome?”

AI theater wants the screenshot. Good architecture asks whether the system should exist after the screenshot.

Source notes

Sources are listed in the order the article uses them. The first two anchor the strategic argument: independent research on why AI initiatives fail, and the industry hype-cycle reading that the same initiatives are mid-fall from inflated expectations into the trough of disillusionment. The next three are public incidents repositioned here as symptoms of the symbol-of-innovation arriving before the architecture that should support it. The last two are the architectural concerns the article treats as line items on the bill for hype rather than as the thesis.

• RAND, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed” (2024). Anchors the leadership-driven failure thesis. Based on 65 semi-structured interviews with experienced data scientists and ML engineers, the report finds that 84 percent of failures are leadership-driven, with the most common root causes being misunderstanding or miscommunicating which problem the system is supposed to solve, applying AI to problems that simpler tools could solve, and pressure on managers to “do something—anything—with AI to demonstrate to their superiors that they are keeping up.” Used as the primary citation for the FOMO/hype-driven adoption pattern that this article calls AI theater. Source: Ryseff, De Bruhl, Newberry, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI,” RAND RR-A2680-1 (Aug 2024).
• Gartner, “Hype Cycle for Generative AI” (2025). Industry-side reading of the same pattern. Gartner places generative AI past the Peak of Inflated Expectations and into the Trough of Disillusionment, noting that “innovations with lofty promises are struggling to deliver on inflated expectations and move from proof of concept to production.” Used as supporting evidence that AI theater is widely recognized as a pattern, not as an isolated complaint. Source: Chandrasekaran, “The 2025 Hype Cycle for GenAI Highlights Critical Innovations,” Gartner (Jul 2025).
• Chevrolet dealership chatbot incident. Used to illustrate a public AI surface launched without scope, refusal design, or defined authority, including the widely circulated “agree to sell a Tahoe for $1” exchange. Cited as evidence of a symbol of innovation that went live before the architecture that should have supported it – not as a claim that chatbot output creates binding contracts. Source: Gizmodo, “I’d Buy That for a Dollar: Chevy Dealership’s AI Chatbot Goes Rogue” (Dec 2023).
• DPD chatbot incident. Used to illustrate brand exposure when a public assistant produces inappropriate or self-critical output. The lesson is operational, not technical: the symbol of innovation went live without the operating model that public surfaces require. Source: The Guardian, “DPD AI chatbot swears, calls itself ‘useless’ and criticises delivery firm” (Jan 2024).
• Air Canada chatbot tribunal decision. Used to illustrate that companies remain accountable for the answers their official channels give out, including chatbot answers. Treated as a warning about ownership and accountability, not as a generalized legal claim. Sources: Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal of British Columbia); BBC, “Airline held liable for its chatbot giving passenger bad advice” (Feb 2024).
• OWASP Top 10 for LLM Applications — LLM01: Prompt Injection. Cited because prompt injection is one of the mechanisms by which the absence of architecture becomes visible on a public AI surface. Theatrical deployments tend to discover, in production, that a system prompt is not a security boundary. Source: OWASP GenAI Security Project — LLM01: Prompt Injection.
• OWASP Top 10 for LLM Applications — LLM10: Unbounded Consumption. Cited because cost is one of the line items the bill for theater is paid in. A public surface running on a paid model without limits is a meter strangers can spin. Source: OWASP GenAI Security Project — LLM10: Unbounded Consumption.