# Management after go-live: who owns an AI application

[Skip to content](#lm-inhoud)Network/[NL](/en/beheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie)EN[Hubhub.llmnet.nlCompare models on task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organization, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie&text=Management%20after%20go-live%3A%20who%20owns%20an%20AI%20application)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie&title=Management%20after%20go-live%3A%20who%20owns%20an%20AI%20application)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie&text=Management%20after%20go-live%3A%20who%20owns%20an%20AI%20application)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Fbeheer-na-go-live-wie-is-eigenaar-van-een-ai-toepassing-in-productie&title=Management%20after%20go-live%3A%20who%20owns%20an%20AI%20application)[](#)
 
 
# Management after go-live: who owns an AI application in production

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 

 
 The champagne is finished, the dashboards are blinking green, and the first hundred end users are working with the new AI application every day. After a successful implementation, many organizations assume the project is complete. In practice, the real challenge only begins after go-live. While traditional software settles into a stable management regime with predictable error codes and fixed maintenance contracts after delivery, a Large Language Model behaves unpredictably. Outputs change due to underlying model updates, users try to creatively bypass the system, and API costs fluctuate based on usage patterns. Who within the organization is responsible when the model suddenly starts hallucinating, gives hallucinated answers to customer questions, or turns out to be twice as expensive overnight? Establishing clear ownership and setting up structural management after go-live is not an administrative afterthought, but a fundamental requirement to prevent a promising application from turning into an unmanageable risk within a few months.

 
## The pitfall of forgotten aftercare

 A persistent misconception in many organizations is that the vendor or external developer remains responsible for operational performance after delivery. Although external parties can support technical monitoring, substantive and operational ownership always rests with the organization itself. When a project team is disbanded after implementation without long-term roles and responsibilities being assigned, a vacuum immediately emerges. Departments push responsibility onto each other: IT regards the application as functional business software, while the business unit assumes IT handles technical maintenance and cost monitoring. The result is that no one intervenes when the quality of the generated output slowly declines or when license costs quietly rise. To understand how this transition from project to operations goes smoothly, you can review the insights on [why AI projects stall after the pilot phase and how to prevent it](https://consultancy.llmnet.nl/en/pilot-naar-productie), which describes the crucial steps for a stable handover.

 
## Operational ownership: business versus IT

 Within a modern organization running AI in production, ownership needs to be split into at least three domains: functional ownership, technical management, and governance. Functional ownership should sit with the business owner or process owner who uses the application to achieve daily objectives. They determine whether the output still aligns with operational practice and whether the generated value continues to meet expectations. Technical management, on the other hand, covers monitoring API connections, latency, rate limits, and infrastructural stability, which usually belongs to the IT department or an internal platform team. The third domain, governance and compliance, requires coordination between legal, information security, and management. The absence of this separation leads to blind spots, particularly around information security and model changes. Organizations that want to stay on top of this would do well to look at the conditions in [responsible AI governance for SMEs](https://consultancy.llmnet.nl/en/ai-governance-mkb), which helps you avoid bureaucracy while still setting clear lines of responsibility.

 
## Monitoring model quality and concept drift

 Traditional software applications behave deterministically: the same input always produces the same output, unless there's a bug in the code. AI applications built on language models behave probabilistically. This means output quality can fluctuate due to factors the organization has no direct control over, such as silent updates from the API provider or changing language use among users. This phenomenon, known as concept drift, calls for a continuous monitoring strategy. Who keeps an eye on whether the virtual assistant's answers still meet the applicable guidelines, tone of voice, and factual accuracy? In practice, this means teams need to periodically take samples and set up feedback loops in which end users can directly report incorrect or unwanted output. It is essential to define in advance which correctness thresholds apply, so you can intervene in time before customers or employees are structurally misled by outdated or incorrect model outputs.

 
## Cost control and financial ownership

 An underestimated risk after go-live is the unpredictability of operational costs. Where a traditional cloud application often runs on fixed monthly license fees per user, organizations with LLM integrations typically pay per processed token or per API call. An unforeseen usage spike, a poorly written prompt that generates unnecessarily long responses, or an automated process stuck in an infinite loop can result in a hefty bill at the end of the month. Financial ownership means the cost owner analyzes consumption patterns monthly and sets budget caps with the vendor. Organizations must also account for the rapid aging of underlying models; if a model is deprecated by the provider after a year, there needs to be budget and capacity to migrate to a newer version without the production environment going down. Anyone who wants to stay in control of these kinds of variable expenses and technical conditions can also consult the guidelines on [what to watch for in a contract with an AI vendor](https://consultancy.llmnet.nl/en/ai-contracten-en-sla) to cover unexpected costs and vendor dependencies both legally and operationally.

 
## Incident management and response to hallucinations

 What happens on a Tuesday afternoon at two o'clock when a customer service chatbot makes an incorrect commitment, leaks confidential internal data, or makes an offensive remark? With traditional IT systems, a user reports a bug and a developer fixes the code. With an AI application, the cause is more complex: is it the prompt, the retrieved documentation in the RAG architecture, or the underlying model itself? Handling this properly requires a predefined incident plan. This plan describes who has the authority to take the AI application offline immediately (the "kill switch"), who handles internal and external communication, and how root-cause analysis is carried out to prevent recurrence. The absence of such a protocol causes delay and panic the moment something goes wrong. It is therefore crucial to train for these kinds of scenarios in advance and to understand how to verify the reliability of the underlying components, drawing on documentation such as the guide on [reading model cards and model licenses for production](https://hub.llmnet.nl/en/modelkaarten-en-licenties-lezen) to keep the limitations of chosen models clearly in view.

 
## Documentation, lifecycle management, and model deprecation

 Models are continuously updated, modified, or phased out by their developers. An AI application that performs optimally on a specific model today may perform poorly in nine months because the vendor deprecates that particular model. Lifecycle management means the organization maintains an inventory of all active AI components, the versions used, the connected data sources, and the prompts. Without this documentation, a form of technical debt emerges where no one dares to touch the application anymore for fear of breaking the whole thing. A periodic reassessment — twice a year, for example — ensures outdated prompts are cleaned up and performance is compared against newer, possibly cheaper or more powerful alternatives on the market.

 
## Practical measurement methods for continuous quality assurance

 Quantifying the performance of an AI application in production requires a specific methodology that goes beyond traditional software testing. Because LLM output is formulated in natural language, traditional unit testing can be wholly inadequate. Organizations are therefore increasingly turning to LLM-as-a-judge frameworks, in which a secondary, independent model evaluates samples of the production model's output against predefined criteria such as relevance, tone, and factual accuracy. In addition, tracking user feedback through clear thumbs-up/thumbs-down buttons or correction forms is a crucial quantitative indicator. Aggregating this feedback produces a trend analysis showing whether end-user satisfaction is rising or falling. It's important to recognize, however, that these measurement methods are themselves also susceptible to drift, and that human sampling by subject-matter experts always remains necessary as the ultimate quality safeguard.

 
## Edge cases, exceptions, and unforeseen usage patterns

 In daily practice, organizations inevitably run into edge cases that were overlooked during the design phase and the pilot period. Think of users who try to bypass the system's safety filters using so-called prompt injection techniques, or business users who deploy the AI application for tasks the model wasn't trained for, such as processing complex legal contracts while the tool was optimized for simple FAQ answering. Ownership after go-live implies there must be a process to detect, analyze, and mitigate these edge cases. This might mean tightening the system prompt, building extra guardrails into the middleware, or temporarily restricting access for specific user groups to prevent misuse.

 
## Weaknesses and blind spots in management

 Setting up post-go-live management has clear weaknesses and limitations that organizations must openly acknowledge. One of the biggest blind spots is "management fatigue": after the intensive implementation period, attention quickly wanes, so monitoring dashboards stop being checked and incidents go unnoticed. Objectively measuring model quality is also notoriously difficult; quality assessments require subjective human judgment, which takes time and is sensitive to differences in interpretation. Dependence on external API providers also remains a risk that internal management can never fully eliminate. If a vendor decides to double its prices or discontinue its service, the organization still faces a major migration effort, no matter how tightly internal ownership is organized.

 
## Conclusion and implementation checklist

 Ownership after go-live is not a one-off task, but a structural part of running the business. By assigning functional ownership to the business, placing technical management with IT, and making clear agreements about costs and incidents, a fragile AI pilot transforms into a durable, reliable production application. The checklist below helps organizations put this in place right away:

 
 
 
- Appoint a clear business owner: Define who is ultimately responsible for the substantive quality and the value generated in practice.
 
- Set up a technical monitoring channel: Continuously monitor API costs, latency, rate limits, and usage patterns.
 
- Draw up an incident protocol: Establish who has the authority to shut down the application immediately in the event of unwanted output.
 
- Schedule periodic quality audits: Sample the output monthly or quarterly to detect concept drift in time.
 
- Document the entire stack: Keep an up-to-date register of model versions used, prompts, data sources, and vendor terms.