From pilot project into operations.
Most AI pilots don't fail on the technology. They fail on what comes after: data that isn't mature enough, no fit into daily work, and no clear ownership once the pilot wraps up. Closing those three gaps deliberately before the pilot ends is what reliably turns it into stable, monitored operations rather than an unused demo.
Why go live is only the beginning
In most AI projects, all of the planning is aimed at a single date: the go live. There are milestones for data preparation, model selection, interfaces and acceptance. For the period after that, the project plan often contains just one sentence: hand over to IT.
This is exactly where the problem lies. A conventional software system remains largely stable after launch, as long as nobody changes the code. An AI system behaves differently. Its quality depends on data that changes constantly, on models that vendors keep developing, and on users who work with the system in ways nobody anticipated during the project.
Going live is therefore not the end of an AI project. It is the beginning of the phase nobody talked about beforehand. This phase needs clear responsibility, a budget and processes that do not depend on individual people.
What is typically missing after a few months
The project team moves on, and IT is supposed to take over. After a few months, symptoms appear that look similar in almost every company:
None of these problems is technically spectacular. Together, they cause users to lose trust and return to their old ways of working. After twelve months without clear operational responsibility, the value of an AI system is often used up, even though the investment has been made.
The cause rarely lies with individual people. It lies in the structure of the project. A project budget ends with acceptance; an operations budget was never planned. The project team knows the system in detail, while IT knows the infrastructure but not the models. A gap opens up between the two that will not close on its own unless it is explicitly assigned to someone.
Five tasks that must be contractually assigned to someone
| Task | What it includes in practice | How you can tell |
|---|---|---|
| Monitoring | Continuously measure quality, cost and availability; define thresholds and alerts | Regular reports that the business unit can understand as well |
| Retraining | Adapt models when data or requirements change | A planned process with measurements before and after |
| Updates | Update models and software, test them in a test environment first | Documented approvals and a way back to the previous version |
| Access rights and evidence | Maintain roles, access, logs and audit readiness | Complete logs, traceable approvals |
| Decision on continued operation | A named person decides when a system is adjusted or shut down | Name and role are stated in the contract |
For us, managed AI operations means that precisely these tasks are not left open but are assigned to a role in writing. The following overview shows what each task includes and how you can tell that it is actually being carried out.
The last point is the one most often overlooked. A system that nobody is allowed to shut down keeps running even when it has long been doing more harm than good. A named responsibility creates clarity here.
Availability is not the same as quality
For operations, we set 99.9% availability as the target. This figure matters, but it only describes whether a system is reachable. An AI system can be reachable and still deliver wrong or outdated answers. Conventional IT service level agreements therefore fall short.
A service level for AI also covers quality, measured against a baseline that was set before launch. It covers cost limits and alerts for unusual consumption. It covers when retraining is triggered and who decides on it. We define response times by severity level together with you, in line with the importance of each use case. You can find details under Service level.
More important than any single figure is the question behind it: who notices first when something is wrong, your team or your customers? Good operations detect deviations before they reach users.
Your own team, managed service or hybrid model
Not every company needs a full managed service. Three models have proven themselves:
Whichever model you choose, the division of tasks should be set down in writing. A managed service only works if it is also clear what your company contributes, such as access to data, a contact person in the business unit and feedback from users.
A simple check helps you choose the model: How many AI systems should be running in production in two years, and who in your company can retrain a model when quality drops? If the second question remains open, a managed service or a hybrid model is usually the safer route. Switching later remains possible, provided documentation and exit are settled from the start.
How to recognize a good operations partner
According to Gartner, over 40% of agentic AI projects will be canceled by the end of 2027. The reasons include unclear costs, missing business value and insufficient control over risks. Sound operations address exactly these points. When selecting a partner, check these questions:
An AI system is not a project you complete. It is an operation that someone has to run.
Frequently asked questions
Sources
- NexPatch AI: guide "KI Dienstleister auswählen" (Choosing an AI service provider), on loss of value after twelve months without operational responsibility
- Gartner: forecast that over 40% of agentic AI projects will be canceled by the end of 2027