It Worked in the Prompt: AI’s New Vaporware

dehakuran.com · October 2026 · 5 min read

Three speech bubbles ask about chat, sharing and maintenance above a dissolving application. The code survives. The capability evaporates.

“I built this in a couple of prompts.”
“It’s just a skill. We only need to add it.”
“Why can’t I share it with the team?”
“It works perfectly in my chat.”
“Who maintains it? I thought IT would.”

Sounds familiar?

Perhaps AI is giving “vaporware” a new meaning: software that gets built, impresses in a demo, then slowly evaporates.

The code exists.
The interface looks convincing.
Someone has even started using it.

Then the application meets the organisation

  • It needs access to restricted data.
  • Security needs to understand what it can do.
  • Someone has to decide who can use it and who is accountable when it fails.

Later, a connected system changes.

  • A data source becomes unreliable.
  • The original builder moves to another project.
  • Nobody has the time, budget or authority to keep it useful.

The application stays online. People quietly stop depending on it.

The code survives. The capability evaporates.

Enterprise AI capability means being able to build, validate, integrate, govern and maintain what we create. Generating the code is only part of that commitment.

The gap continues after launch

In The POC-to-Production Gap, I explored why faster prototyping doesn’t automatically mean faster production.

IT access, privacy, security, compliance and infrastructure all shape the journey. A fast prototype can conceal how much organisational work remains.

The same question continues after launch: can the organisation sustain what it has built?

Someone must notice when source information becomes outdated. Someone must evaluate changes to the model, prompts and surrounding software. Someone must investigate failures and decide whether the application still delivers enough value to justify the effort.

In Who Owns Your AI After It Goes Live?, I explored who needs the responsibility, funding and authority to do that work.

Without those answers, software can gradually lose its usefulness. Its exceptions accumulate. Its information becomes less reliable. Its users find other ways to get things done.

A successful deployment begins an ongoing commitment.

Build the capability around the application

That is why enterprises need to build internal AI capabilities, partner for them, or combine both.

Those capabilities span engineering, evaluation, integration, security, governance and ongoing operations. They require business understanding, funding beyond the prototype and clear accountability for outcomes.

Those capabilities cover five responsibilities:

Build. Understand the business problem, the users and the outcome worth achieving.

Validate. Evaluate representative inputs, exceptions and failures. Establish what acceptable performance means.

Integrate. Connect the application to real data, permissions, systems and workflows. Plan for those dependencies to change.

Govern. Define access, human review and accountability. Give someone the authority to intervene.

Maintain. Keep the application working and check whether its outputs remain useful as models, information and requirements evolve.

These responsibilities need people, time and funding.

AI can help perform the work. The organisation still has to ensure it happens.

Partner with ownership in mind

A partner can bring specialist expertise, engineering capacity and experience navigating difficult integrations.

The enterprise needs enough internal capability to define the outcome, evaluate delivery and own the decisions that follow.

Before committing, make the operating arrangement explicit. Who investigates failures? Who approves changes? Who maintains the data and integrations? What knowledge must remain inside the organisation? What happens when the original delivery team leaves?

Those answers belong in the business case.

For an experiment, the arrangements can be lightweight. A temporary tool may have a deliberately short life. The commitment should grow with the consequences of people depending on it.

The problem begins when an experiment acquires users and responsibilities without acquiring the support to match.

From a promising PoC to sustainable value

Before celebrating the next AI-built application, ask:

  • Who is accountable for its business outcome?
  • What evidence shows it works beyond the demonstration?
  • Who can diagnose a failure when the original builder is unavailable?
  • What happens when its data, model or connected systems change?
  • Where is the time and budget to keep it useful?

Every new application creates a future obligation for someone.

AI makes it easier to create that obligation. Enterprise capability makes it possible to fulfil it.

At Philips, we’ve built—and continue to improve—such enterprise AI capabilities to turn promising PoCs into lasting value, combining business ownership with the engineering, integration and operational capabilities to keep them useful after launch.

Frequently Asked Questions

What does enterprise AI capability include?

It includes building, validating, integrating, governing and maintaining AI applications, supported by business ownership and ongoing funding.

Should enterprises build AI capabilities internally or use partners?

They can use either approach or combine them. Partners can provide expertise and delivery capacity; enterprises still need the ability to evaluate the work, own decisions and remain accountable for outcomes.

Why can an AI application lose value after launch?

Its data, connected systems and business requirements can change. Without ongoing evaluation and maintenance, an application can remain online while becoming unreliable or less useful.

AI StrategyEnterpriseSoftware EngineeringAI Governance

Deha Kuran

AI Executive, Engineer, and Evangelist. Head of AI Business Operations at Philips.

Follow the thinking on LinkedIn →