A successful demo shows that a technology works. For a management decision, that is not enough. Three questions remain open: what will it cost to run, what does it deliver, and what happens when the system gets an answer wrong? This is where many AI projects stall.

Why is a demo not enough?

AI has arrived in European companies, but unevenly. According to Eurostat, around 20 percent of EU enterprises with at least ten employees used AI in 2025, up from 13.5 percent the year before. The detailed breakdown shows the gap: 55 percent among large enterprises, 17 percent among small ones.

Use is not the same as impact. In the Bitkom survey of September 2026, not a single company says it fully exploits the potential of AI, and only 3 percent describe their use as fairly extensive. McKinsey's State of AI report for 2025 paints a similar picture, according to published summaries: the large majority of organisations use AI in at least one function, but only around a third scale beyond the pilot phase. Gartner predicts that over 40 percent of agentic AI projects will be cancelled by the end of 2027 because of costs, unclear value or inadequate risk controls. That is a forecast, not a measurement. It does show where projects get stuck.

A prototype that only shows that AI can do something answers the wrong question. It has to show that this use case works in this company. Five criteria help with that test.

Does the prototype work with real data?

A prototype built on sample data proves little. Real documents are often incomplete, contradictory, stored in old formats and partly out of date. That is exactly where systems fail in production. So work with a real, representative extract in the prototype, prepared in line with data protection rules. If personal data is involved, pseudonymisation or anonymisation belongs in the prototype, not just in production.

Is the use case measurable?

"Staff should become more productive" is not a use case. "Handling time for standard requests goes down" is one. Before you build, decide what you will measure, how you measure it today and which value counts as success. Measure quality as well as time: how often does a person have to correct the result? Without a baseline, all you have later are impressions, and any management team is right to argue about impressions.

Have risk and compliance been checked?

Before anyone decides, the project needs a short, honest risk review. Four questions belong in it:

  • Data protection: which data does the system process, on what legal basis and where?
  • AI Act: what role does the company have, and does the use case trigger transparency obligations, for example because customers talk to a chatbot?
  • Impact of errors: what happens when the system gives a wrong answer, and who notices?
  • Dependency: what happens if the vendor changes or retires its model?

The Bitkom survey shows how much weight these questions carry. Among companies without AI, 66 percent cite legal hurdles and uncertainty as a reason. Among users, data protection tops the list of obstacles at 66 percent. A prototype that leaves these questions open gets postponed.

Is there an operating model?

A prototype often runs on a developer's laptop. A product needs an operating model, and management has to know which one is meant. Three variants are common:

  • The company uses a model through a vendor's API.
  • The company runs a model with a large cloud provider in an EU region.
  • The company runs an open-weight model with a European hosting provider or in its own data centre.

Each variant distributes cost, control and effort differently. The operating model also answers who runs the system, who monitors it, who applies updates and who responds when it goes down. According to Bitkom, costs that are hard to estimate are an obstacle for 63 percent of companies without AI and 54 percent of users. An operating model with named cost items takes the ground out from under that concern.

How can the value be calculated?

The value calculation answers whether running the system pays off. At prototype stage, what matters is the method, not a number for the slide deck. A simple form looks like this:

Monthly benefit = cases per month × time saved per case in hours × internal hourly rate

Against this stand the running costs: usage fees or infrastructure, maintenance, support and training. Then there is the time spent on human review. The prototype makes it visible, and many calculations leave it out. The values for the formula come from the prototype itself: from the measured time with and without AI, and from the share of results that had to be corrected. That turns a hope into a traceable calculation that every member of the management team can check.

What belongs in the decision paper?

The end result is a one-page decision paper. It contains the problem, the results with real data, the open risks, the proposed operating model, the value calculation with its assumptions and a clear recommendation. The recommendation can also be to stop the project. A prototype that honestly shows a use case does not pay off has served its purpose.

The project development page describes how such a prototype is set up.