Everyone can show an AI pilot — almost nobody can keep it in production for five years
In 2026, any technology vendor can present an impressive AI pilot to a German utility. A model that classifies tickets, another that detects anomalies in readings, a third that summarises regulatory documentation. The demos look great, the early results are shiny, and expectations grow fast.
The problem shows up months later, when someone asks who will operate that model in production, under which governance, with what recurring costs and under which regulatory controls. That is where most pilots die. Not because AI does not work, but because the pilot was never designed to reach production.
In a German utility, that distance between pilot and production is especially large. Critical systems such as SAP IS-U, FI-CA, Powercloud and market communication processes operate under BSI, GDPR, KRITIS and continuous Bundesnetzagentur scrutiny. A pilot that ignores this reality is not a pilot: it is a demo.
“An AI pilot is not a project. It is a promise. And promises do not pass audits.”
Why most AI pilots never reach production
There are five recurring reasons why an AI pilot in a utility dies before industrialisation.
01 · No governance from day one
Without a clear definition of who answers to audit, how decisions are documented and which controls apply, the pilot does not survive first contact with compliance.
02 · Weak data foundation
Pilots built on artificial or partial datasets collapse when they meet real SAP IS-U data with master data errors, legacy contracts and accumulated integrations.
03 · No integration with the ecosystem
A model that does not integrate with FI-CA, CRM, customer portal or MaKo produces isolated value and operational drag — one more system to maintain.
04 · No MLOps layer
A production model needs retraining, drift supervision, degradation alerts and rollback plans. Most pilots do not include that layer because nobody budgeted it.
05 · No senior judgement to stop on time
Many pilots carry on for months after they have already shown they will not scale, because nobody wants to admit the use case was wrong. Stopping on time saves more than the exploration cost.
✓ What actually works
Joint discovery → short pilot with written metrics → rigorous go/no-go → industrialisation with MLOps. Disciplined closure separates a serious programme from a POC collection.
The industrialisation pattern that works
It starts with a joint technical-regulatory discovery between the partner, IT, compliance and the business areas. Here the team defines which processes are touched, which data is used, which regulatory constraints apply and which metrics define success. Without this step, the pilot is born on the wrong path.
It continues with a short pilot, four to eight weeks, with metrics agreed in writing before it starts. No automatic scale-up promises. No “let’s see if it works”. Clear metrics, closed budget, fixed decision date.
Then comes the rigorous go/no-go. If the metrics are met, the pilot moves to industrialisation. If not, the learning is documented, the case is closed and the programme moves to the next candidate. This disciplined closure is exactly what separates a serious AI programme from a collection of POCs.
Finally comes industrialisation with MLOps. The model is deployed with drift monitoring, retraining pipelines, degradation alerts, rollback plans and assigned owners. The solution is documented for audit from day one, not six months later.
Who keeps the model in production matters as much as who builds it
In German utilities, the question that few clients ask at the start of an AI project and everyone should ask is: who is going to maintain this model in three years’ time? If the answer is “a team that is no longer here”, the project is lost before it starts.
Production AI demands stable teams who know the domain, the system, the data and the regulatory context. This is exactly where low attrition and Senior Consultant continuity stop being an HR slogan and become an operational variable that determines whether the AI programme survives or dies.
Where Principal33 fits
At Principal33 we combine AMS on core systems (SAP IS-U, FI-CA, Powercloud) with an AI-agnostic Data & AI practice delivered by senior, German-speaking, nearshore DACH teams. This means the same team that keeps the core in production is the team that designs, pilots and industrialises AI around it. Model continuity and team continuity are the same thing.
On top of that, the go/no-go discipline between pilot and industrialisation is part of our delivery model. We do not sell open-ended pilots or “let’s see what happens”. We sell AI programmes that reach production — or that close with metrics and documented learning.
The shift in perspective
For a German utility evaluating its AI strategy, the useful question is no longer “does the pilot work?”. Almost any vendor can demonstrate that. The question that separates serious AI programmes from AI theatre is harder: “who is going to keep this model in production in three years, and with which teams?”. When the answer is “the same people building it now”, the probability of the programme’s success changes completely.
