A demo can work with selected examples yet remain unusable in the daily business. Moving to production tests whether the system can handle real data, exceptions, integrations and responsibility for its outputs.
It is worth understanding why this happens, because the reason is rarely the one assumed.
Evaluate the model and the system around it
The usual intuition is that technology was missing: a better model, more power, a different vendor. Sometimes it is: model capability, latency and cost need evaluation. But a good demo does not resolve the integration and operational work.
What fails sits underneath. A demo is built on a prepared case: clean data picked by hand, a couple of examples that turn out well, a technician alongside who knows the shortcuts. Production is the opposite — the real data, messy and scattered; access to the systems the company actually uses; and no one alongside to improvise when something does not fit. The pilot does not cross that bridge because the bridge was never built.
What really stops a pilot
Alongside the model, three obstacles deserve attention:
- The data is not where the AI can use it. In Spain, among companies already using AI, one of the most frequently cited barriers is the availability of data — alongside the lack of staff and cost (Source: Banco de España, EBAE, Economic Bulletin 2025/Q2). If the data lives spread across spreadsheets, emails and the heads of three people, the AI cannot read it reliably, however good the model.
- Access is not documented. For the AI to operate —not to answer, but to act— it needs to connect to the real systems: the order system, the billing system, the server where the information sits. That requires having it written down, in a structured way, which systems exist, what each one does and who can touch what. The demo skipped that work; in production it is unavoidable.
- There is no way to know what it did, or why. As soon as the system acts on the business, someone has to be able to review what it decided, with what data and under what criterion. Without that trace, no one dares let it run loose — and the pilot stays a pilot, precisely out of prudence.
The three walls have something in common: they are not solved with more technology, but by ordering what lies underneath. We call that foundation a business being operable by AI: documented in such a way that an AI system can read it and act on it without a technician translating at every step.
What a system that does reach production has
Strahlkraft40+ shows how a wellbeing product connects its assistant with controlled context, memory rules, output filters and behaviour tests. Its case distinguishes implemented mechanisms, prepared procedures and remaining validation work. This is a concrete engineering example, not proof that every risk is resolved.
It is neither chance nor the merit of a particular model. It requires product, engineering and operational work alongside model selection.
And, on top of that, it spares you double the work
There is an added reason to do that work from the start. The same foundation that takes a pilot to production is the one European law will require of you if your system is sensitive: the AI Act demands, for high-risk systems, formal procedures for data management and traceability (Source: Regulation (EU) 2024/1689, art. 17, EUR-Lex, 2024). In other words: ordering the data and the access so the AI can operate is, at the same time, what will let you demonstrate that you control it. One investment, two outcomes — and the underlying reason is that without data governance there is no AI that scales.
What to do with this
If you have a stalled pilot, before changing model or vendor it is worth looking underneath: is the data where the AI can use it? is access documented? is there a trace of what it does? In our method that is the first task, and it is not a huge project: it starts with one department and with putting in writing what today lives scattered.
The pilot that impressed did not fail for lack of artificial intelligence. It lacked the ground to stand on.