Enterprise AI Maintenance: What Happens After Launch?

Launching an AI system is not the finish line. It is the beginning of a new operating responsibility.

Enterprise buyers often focus heavily on the discovery, prototype, vendor selection, model choice, and first production deployment. Those steps matter. But the business value of AI is determined after launch: when real users ask unexpected questions, source data changes, models are updated, prompts drift, costs increase, regulations evolve, permissions shift, users develop workarounds, and incidents need to be handled quickly.

That is why AI maintenance is becoming one of the most important parts of enterprise AI strategy. A production AI system is not a static application. It is a living system made of models, prompts, data pipelines, retrieval indexes, workflow integrations, user feedback, policy rules, tools, evaluations, logs, and governance controls. If those components are not maintained, the AI system can become less accurate, less trusted, more expensive, and more risky over time.

The market context makes this urgent. McKinsey’s 2025 global AI survey found that AI use is now broad across organizations, but many companies still struggle to scale AI to enterprise-wide impact [1]. Deloitte’s 2026 enterprise AI research found that worker access to AI rose by 50% in 2025 and that companies expect more AI projects to move into production, which increases the need for operating models that can support AI after launch [2]. Gartner has also warned that more than 40% of agentic AI projects may be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls [3].

For decision-stage buyers, the lesson is direct: enterprise AI deployment should not be approved unless the organization also knows how the system will be monitored, supported, updated, secured, evaluated, and governed after launch.

This guide explains what happens after launch and how enterprise teams should design AI system support and LLM application maintenance as part of the product lifecycle.

The Core Truth: AI Systems Need Product Support, Model Support, and Risk Support

Traditional software maintenance usually focuses on uptime, bug fixes, security patches, dependencies, feature requests, and infrastructure. AI maintenance includes all of that, but adds a second layer: behavior maintenance.

A standard application either returns the right database value or it does not. A generative AI application may produce a useful answer today and a weaker answer tomorrow because the source documents changed, the retrieval index became stale, a model version changed, a prompt update affected the output, or user queries shifted. OpenAI’s evaluation guidance notes that generative AI can produce different outputs from the same input, which makes traditional software testing insufficient by itself; structured evaluations are needed to test AI systems despite variability [7].

Google Cloud describes MLOps as practices for managing the machine learning lifecycle from development through deployment and monitoring, including experiment tracking, deployment, monitoring, and retraining [4]. IBM defines LLMOps as specialized practices and workflows that support development, deployment, and management of large language models across the complete lifecycle [5]. Together, MLOps and LLMOps show why AI maintenance is not optional. It is the operating discipline that keeps AI systems reliable, safe, and useful after launch.

A mature enterprise AI support model must maintain:

- The application experience.

- The model or model portfolio.

- The prompt and instruction layer.

- The retrieval and data layer.

- The tool and agent layer.

- The evaluation suite.

- The monitoring and observability stack.

- The security controls.

- The governance evidence.

- The business KPI connection.

- The user feedback loop.

- The cost model.

The best AI systems are not simply launched. They are operated.

What Changes After Launch?

Before launch, teams test controlled scenarios. After launch, the system meets reality.

Users ask questions that were not in the test set. Documents get edited, renamed, deleted, or replaced. Business rules change. APIs break. Model providers deprecate model versions. User behavior creates new risk patterns. Legal or compliance guidance changes. Costs grow with adoption. Data quality issues become visible. Security teams discover new prompt injection attempts. Business owners ask whether the system is still delivering value.

That means AI maintenance must begin immediately after launch. Microsoft’s Azure Machine Learning model monitoring guidance recommends starting model monitoring immediately after deploying a model to production and working with data scientists who understand the model to set monitoring signals, metrics, and alert thresholds [8].

The maintenance question is not “Is the AI still online?” The better question is:

Is the AI still accurate, grounded, secure, cost-effective, compliant, useful, and aligned with the business workflow?

The Enterprise AI Maintenance Framework

Etheons recommends maintaining production AI systems across twelve operating layers:

1. Business value monitoring

2. User support and adoption

3. Model and prompt monitoring

4. RAG and data maintenance

5. AI agent and tool maintenance

6. Evaluation and regression testing

7. Security and privacy maintenance

8. Cost and performance management

9. Incident response and rollback

10. Vendor and model lifecycle management

11. Governance, audit, and compliance

12. Continuous improvement and roadmap management

Each layer answers a different post-launch risk. Together, they turn AI from a project into a reliable operating capability.

1. Business Value Monitoring: Is the AI Still Worth Running?

Every AI system should launch with a business case. After launch, that business case must be monitored.

AI maintenance should track whether the system is still improving the workflow it was built for. That means measuring real business outcomes, not only usage. A high number of prompts does not prove value. A high number of active users does not prove quality. A popular assistant may still produce unsupported answers, increase review work, or fail to change the target KPI.

Business value metrics may include:

- Cycle-time reduction.

- Cost per workflow.

- Backlog reduction.

- First-response time.

- Forecast cycle time.

- Average handle time.

- Human review acceptance rate.

- Error reduction.

- Rework reduction.

- Revenue impact.

- Customer satisfaction.

- Employee satisfaction.

- SLA improvement.

- Compliance exception reduction.

- Decision quality improvement.

McKinsey’s research shows that AI high performers are more likely to embed AI into workflows and track KPIs [1]. Maintenance is where those KPIs become operational. If the system no longer improves the workflow, the business should tune it, limit it, redesign it, or retire it.

Maintenance rule: Keep AI systems only where ongoing business value can be measured.

2. User Support and Adoption: Are People Using It Correctly?

After launch, user behavior becomes one of the largest variables in AI system performance. Users may ask vague questions. They may paste sensitive data. They may trust outputs too much. They may reject useful recommendations because they do not understand the system. They may use workarounds if the AI experience is too slow or restrictive.

AI system support should include:

- User onboarding.

- Role-specific training.

- Acceptable-use guidance.

- Prompt and workflow examples.

- Escalation channels.

- Feedback capture.

- Office hours or support clinics.

- In-product reporting for bad answers.

- Department-specific champions.

- Documentation for known limitations.

Deloitte’s 2026 research highlights that workforce access to AI expanded quickly, but scale depends on how organizations redesign work and support adoption [2]. That means AI maintenance is partly technical and partly organizational.

A good support process should answer:

- Who receives user issues?

- What is the SLA for AI support tickets?

- How are bad outputs reviewed?

- How are user suggestions prioritized?

- How are repeat user errors addressed?

- How are training materials updated?

- How does the support team communicate model or feature changes?

Maintenance rule: AI adoption must be supported like a product rollout, not treated like a one-time training event.

3. Model and Prompt Monitoring: Is the AI Behavior Still Stable?

AI behavior depends on models, prompts, instructions, system policies, retrieval context, tools, and user inputs. Any change can affect output quality.

LLM application maintenance should monitor:

- Answer accuracy.

- Groundedness.

- Hallucination rate.

- Refusal accuracy.

- Toxic or unsafe output.

- Policy compliance.

- Prompt injection susceptibility.

- Output length.

- Structured output validity.

- Tone and brand consistency.

- Human edit rate.

- Human override rate.

- User satisfaction.

Prompts should be treated as versioned production artifacts. A small prompt change can affect response format, safety behavior, tool selection, or retrieval use. Prompt versions should be linked to evaluation results and deployment records.

Model behavior can also change when vendors release new versions or when the enterprise switches models. OpenAI’s official deprecations page shows that model snapshots and APIs can be deprecated and removed, with recommended replacements and shutdown dates [17]. Microsoft’s Foundry model lifecycle documentation states that customers can programmatically check lifecycle status, deprecation status, and deprecation dates for models [18]. Model lifecycle management is therefore a maintenance requirement, not an occasional cleanup task.

Maintenance rule: Version prompts, track model versions, and run evaluations before every behavioral change.

4. RAG and Data Maintenance: Is the AI Still Grounded in the Right Knowledge?

Many enterprise AI systems use retrieval-augmented generation, or RAG. RAG systems need ongoing maintenance because enterprise knowledge changes constantly.

A RAG system can degrade when:

- Source documents are outdated.

- New policies are not indexed.

- Deleted files remain in the vector index.

- Permissions change but indexes do not update.

- Chunking creates poor retrieval.

- Metadata is missing.

- Source ranking is wrong.

- Duplicate documents compete with official sources.

- Knowledge owners stop maintaining content.

- Embeddings were created with an older model.

- User queries shift into new topics.

RAG maintenance should include:

- Source freshness checks.

- Data-owner review.

- Document lifecycle management.

- Deletion propagation.

- Permission synchronization.

- Index rebuild schedule.

- Retrieval-quality evaluation.

- Citation accuracy checks.

- Stale-source detection.

- Source authority ranking.

- Vector index security review.

- Metadata completeness checks.

For secure enterprise AI, the most important RAG maintenance task is permission integrity. The system should never retrieve data that the user cannot access in the source system. When teams, roles, customers, projects, legal matters, or regions change, retrieval rules may need to change too.

NIST’s AI Risk Management Framework is intended to improve trustworthiness across AI design, development, use, and evaluation [10]. For RAG systems, trustworthiness depends heavily on maintaining the data foundation after launch.

Maintenance rule: RAG systems require content operations, not just model operations.

5. AI Agent and Tool Maintenance: Are Actions Still Safe?

AI agents require more maintenance than assistants because they can take actions. An agent may call APIs, update records, create tickets, send messages, query databases, route approvals, or trigger workflows.

Post-launch agent maintenance should monitor:

- Tool-call success rate.

- Tool-call failure rate.

- Tool-call latency.

- Unexpected tool selection.

- Unauthorized tool attempts.

- Repeated retries.

- Escalation accuracy.

- Human approval rate.

- Human rejection rate.

- Rollback events.

- Agent loop behavior.

- Cost per completed task.

- Errors by tool or workflow.

- Action audit logs.

OWASP’s 2025 Top 10 for LLM and generative AI applications includes prompt injection, sensitive information disclosure, vector and embedding weaknesses, excessive agency, and other risks across the development, deployment, and management lifecycle [12]. Those risks become more serious when an AI system can act.

Agent maintenance should also include identity and permission reviews. Agents should use dedicated identities with least-privilege access. Tool permissions should be reviewed periodically. High-risk actions should remain approval-gated unless the business has strong evidence that limited autonomy is safe.

Maintenance rule: If the AI can act, every action must be traceable, bounded, reversible where possible, and monitored.

6. Evaluation and Regression Testing: Does the AI Still Pass the Standard?

AI evaluation is not a launch gate only. It is a maintenance process.

OpenAI’s evaluation guidance recommends designing evals with clear objectives, datasets, metrics, and iterative comparison, because AI systems require structured tests to assess reliability despite nondeterminism [7]. For enterprise AI, the evaluation suite should grow over time.

A strong maintenance evaluation program includes:

- Golden test cases.

- Historical production examples.

- Edge cases.

- Failure cases.

- Adversarial prompts.

- Role-based permission tests.

- Retrieval-quality tests.

- Tool-call tests.

- Security tests.

- Compliance tests.

- Regression tests before release.

- Online evaluation from production traces.

- Human review samples.

- Feedback-to-eval conversion.

Every important production failure should become a future test case. If a user reports a bad answer, unsupported citation, wrong tool call, or privacy issue, that scenario should be added to the evaluation dataset after remediation.

Evaluation should run:

- Before model upgrades.

- Before prompt changes.

- Before adding data sources.

- Before enabling new tools.

- Before expanding to new user groups.

- After major incidents.

- On a scheduled cadence.

Maintenance rule: The evaluation set should evolve as the system encounters real-world failures.

7. Security and Privacy Maintenance: Are Controls Still Working?

AI security is not static. New prompt injection techniques, data exfiltration attempts, model supply-chain issues, connector risks, and agent vulnerabilities will continue to emerge.

OWASP’s 2025 LLM Top 10 provides current categories for LLM application risk and mitigation across deployment and management [12]. Enterprise AI maintenance should include periodic security reviews against those categories.

Security maintenance should cover:

- Prompt injection testing.

- Jailbreak testing.

- Sensitive data leakage tests.

- Tool misuse testing.

- System prompt exposure testing.

- Vector index poisoning checks.

- Supply-chain dependency review.

- Model provider risk review.

- Secret scanning.

- API key rotation.

- Access reviews.

- Connector review.

- Data retention review.

- Log redaction review.

- Incident simulation.

Privacy maintenance should cover:

- Whether prompts and outputs are logged.

- Whether sensitive content appears in traces.

- Whether user feedback is used for improvement.

- Whether vendor data terms changed.

- Whether data residency requirements changed.

- Whether retention settings still match policy.

- Whether new user groups create new privacy risks.

CISA and partner agencies’ AI data security guidance emphasizes protecting AI data across the lifecycle and managing risks such as data poisoning, provenance, and integrity [16]. Maintenance is where that lifecycle protection continues.

Maintenance rule: Security reviews must repeat after launch because AI risk changes with usage, data, tools, and threats.

8. Cost and Performance Management: Is the AI Economically Sustainable?

An AI system can be affordable in pilot and expensive at scale. Maintenance must include cost visibility.

Track:

- Cost per request.

- Cost per active user.

- Cost per completed workflow.

- Token usage.

- Retrieval cost.

- Embedding cost.

- Tool execution cost.

- Vector or search cost.

- Logging and observability cost.

- Human review cost.

- Model routing cost.

- Retry cost.

- Failed request cost.

- Peak usage cost.

OpenAI’s production best-practices documentation includes cost management, scaling, security, and production architecture considerations for moving AI applications into production [6]. Cost management must continue after launch because usage patterns change.

Performance management should track:

- Latency.

- P95 and P99 response times.

- Throughput.

- Rate-limit events.

- Timeout rate.

- Tool-call latency.

- Retrieval latency.

- Model fallback rate.

- Error rate.

- User abandonment rate.

Cost optimization may include routing simple tasks to smaller models, reducing prompt length, caching approved answers, improving retrieval precision, batching jobs, limiting unnecessary tool calls, or using different model tiers for different workflows.

Maintenance rule: Measure cost per successful business outcome, not only cost per token.

9. Incident Response and Rollback: What Happens When AI Fails?

AI incidents can include wrong answers, unsafe outputs, data leakage, unauthorized retrieval, tool misuse, unexpected cost spikes, model downtime, retrieval failures, compliance issues, or agent actions that need reversal.

Every production AI system should have an incident response plan.

The plan should define:

- What counts as an AI incident.

- How users report incidents.

- Who triages the incident.

- How severity is classified.

- How the system can be paused.

- How model access can be revoked.

- How tools can be disabled.

- How prompts can be rolled back.

- How indexes can be removed or rebuilt.

- How affected users are notified.

- How logs are preserved.

- How root cause is investigated.

- How evals are updated after the incident.

- How governance teams are informed.

AWS’s Well-Architected Framework emphasizes operational excellence, reliability, security, performance efficiency, cost optimization, and sustainability [9]. Those categories apply directly to AI incident response: the system needs operational runbooks, reliable fallback, secure containment, and cost controls.

For high-risk systems, compliance may also require incident reporting. The AI Act Service Desk timeline states that the majority of AI Act rules and enforcement begin on August 2, 2026, including rules for high-risk systems in Annex III and transparency rules [15]. Article 72 of the AI Act requires post-market monitoring for high-risk AI systems, with documented systems for collecting and analyzing performance data across the lifetime of the system [14].

Maintenance rule: If the team cannot pause, roll back, or contain the AI system, the system is not production-ready.

10. Vendor and Model Lifecycle Management: What Happens When Providers Change?

Enterprise AI systems often depend on third-party models, embeddings, vector databases, agent frameworks, cloud services, observability tools, connectors, and APIs. Those dependencies change.

Maintenance must monitor:

- Model deprecations.

- Model version changes.

- Pricing changes.

- API changes.

- Rate-limit changes.

- Safety-policy changes.

- Data-processing term changes.

- Region availability.

- Vendor outages.

- Connector updates.

- Framework vulnerabilities.

- SDK updates.

- Licensing changes.

OpenAI’s deprecation documentation shows that models and systems can have announced removal dates and recommended replacements [17]. Microsoft’s Foundry lifecycle documentation advises customers to check model lifecycle status and deprecation dates programmatically [18]. These are practical reminders that model lifecycle management should be part of AI system support.

A strong lifecycle plan includes:

- Model registry.

- Dependency inventory.

- Version lock policy where appropriate.

- Migration testing.

- Replacement model evaluation.

- Compatibility testing.

- Business owner notification.

- Rollback plan.

- Cost comparison.

- Security review.

- Documentation update.

Maintenance rule: Never let a model deprecation become a production outage.

11. Governance, Audit, and Compliance: Can the System Prove It Is Controlled?

AI maintenance creates evidence. That evidence matters for internal audit, security review, procurement, legal, regulators, customers, and executives.

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system within organizations [11]. NIST’s AI Risk Management Framework is intended to improve trustworthiness across the design, development, use, and evaluation of AI systems [10]. Both frameworks make clear that AI governance is not a one-time approval. It is lifecycle management.

AI maintenance governance should include:

- AI system inventory.

- Risk classification.

- Owner assignment.

- Model registry.

- Data-source registry.

- Prompt and configuration registry.

- Evaluation results.

- Monitoring reports.

- Access reviews.

- Vendor reviews.

- Incident logs.

- Change approvals.

- Audit evidence.

- Retirement criteria.

- Periodic risk review.

For regulated or high-impact systems, the enterprise should also maintain technical documentation and post-launch monitoring evidence. The EU AI Act’s Article 72 post-market monitoring requirement for high-risk AI systems is an example of how AI compliance becomes an ongoing obligation, not a launch checkpoint [14].

Maintenance rule: AI governance must produce evidence that the system remains controlled over time.

12. Continuous Improvement: How Does the AI Get Better?

Maintenance is not only defensive. It is also how AI systems improve.

A strong continuous-improvement loop includes:

1. Monitor production behavior.

2. Capture user feedback.

3. Identify recurring failures.

4. Add failures to evaluation datasets.

5. Improve prompts, retrieval, data, tools, or models.

6. Test against regression suites.

7. Release with version control.

8. Measure post-release impact.

9. Update training and documentation.

10. Retire unused or risky features.

Improvements may include:

- Better source ranking.

- Cleaner prompts.

- Smaller or faster model routing.

- Better refusal rules.

- More accurate citations.

- New data sources.

- Updated embeddings.

- Improved tool schemas.

- Reduced latency.

- Lower cost.

- Better human approval flows.

- Stronger role-specific guidance.

The goal is not to change the AI constantly. The goal is to improve it deliberately with evidence.

Maintenance rule: Every AI improvement should be tied to a measured quality, risk, cost, or business outcome.

The AI Maintenance Operating Model

A production AI system needs named owners. Without ownership, maintenance becomes fragmented across engineering, data, security, and business teams.

A recommended support model includes:

Role: Business owner

Responsibility: Owns workflow value, KPI, user adoption, and business decision to continue or retire.

Role: Product owner

Responsibility: Owns roadmap, user feedback, prioritization, and release decisions.

Role: Engineering owner

Responsibility: Owns application reliability, integrations, deployment, and performance.

Role: Model owner

Responsibility: Owns model selection, evaluation, routing, and migration.

Role: Data owner

Responsibility: Owns source quality, permissions, freshness, and data lifecycle.

Role: Security owner

Responsibility: Owns threat modeling, access, vulnerabilities, and incident response.

Role: Governance owner

Responsibility: Owns risk tiering, documentation, audit evidence, and review cadence.

Role: Support owner

Responsibility: Owns user tickets, training, triage, and communications.

For critical AI systems, the support model should also include legal, compliance, privacy, and internal audit review.

Maintenance rule: Every production AI system needs a named owner for value, technology, data, risk, and support.

The First 30 Days After AI Launch

The first month after launch should be treated as a stabilization period.

Recommended activities:

- Monitor usage daily.

- Review bad-answer reports daily.

- Review cost and latency daily.

- Review security logs.

- Sample outputs manually.

- Check retrieval citations.

- Verify permission behavior.

- Track user adoption.

- Collect frontline feedback.

- Tune refusal and escalation rules.

- Identify missing documentation.

- Add early failures to evals.

- Confirm support workflow.

- Report pilot results to business owners.

Do not expand user access during the first 30 days unless the system is stable. Early expansion often hides problems until they become larger.

The First 90 Days After AI Launch

The first 90 days should prove whether the AI system deserves scale.

By day 90, the enterprise should know:

- Whether users are adopting the system.

- Whether the target KPI is improving.

- Whether outputs meet quality thresholds.

- Whether retrieval is accurate.

- Whether tool calls are safe.

- Whether costs are sustainable.

- Whether incidents are manageable.

- Whether governance evidence is complete.

- Whether support volume is acceptable.

- Whether the system should scale, be redesigned, or be retired.

A 90-day review should produce a clear decision:

Scale, improve, limit, or retire.

This is an important discipline. Not every launched AI system deserves expansion. Some should remain narrow. Some should be rebuilt. Some should be replaced by simpler automation. Some should be stopped.

LLM Application Maintenance Checklist

Use this checklist after launch:

Maintenance area: Business KPI

What to check: Is the AI still improving the target workflow?

Maintenance area: User adoption

What to check: Are the right users using it correctly?

Maintenance area: Output quality

What to check: Are answers accurate, useful, and policy-compliant?

Maintenance area: Grounding

What to check: Are citations and retrieved sources correct and current?

Maintenance area: Permissions

What to check: Is access enforced before content reaches the model?

Maintenance area: Data freshness

What to check: Are indexes and sources up to date?

Maintenance area: Prompt versions

What to check: Are prompt changes versioned and tested?

Maintenance area: Model versions

What to check: Are model changes tracked and evaluated?

Maintenance area: Tool calls

What to check: Are agent actions safe, logged, and approval-gated?

Maintenance area: Security

What to check: Are prompt injection, leakage, and misuse tested regularly?

Maintenance area: Privacy

What to check: Are logs, prompts, files, and outputs retained correctly?

Maintenance area: Cost

What to check: Is cost per successful workflow acceptable?

Maintenance area: Performance

What to check: Are latency, availability, and errors within thresholds?

Maintenance area: Incidents

What to check: Can the system be paused, rolled back, and investigated?

Maintenance area: Governance

What to check: Are reviews, documentation, and audit evidence current?

This checklist should be reviewed monthly for high-impact systems and quarterly for lower-risk systems.

Common AI Maintenance Mistakes

The first mistake is assuming the launch team can support the system forever. Production support needs an operating model, not heroics.

The second mistake is monitoring only uptime. AI systems also need quality, grounding, cost, safety, and business KPI monitoring.

The third mistake is failing to maintain the data layer. A RAG system with stale documents will eventually produce stale answers.

The fourth mistake is changing prompts without regression tests. Prompt changes can alter system behavior in unexpected ways.

The fifth mistake is ignoring model lifecycle risk. Vendors change, deprecate, and retire models; production systems need migration plans [17][18].

The sixth mistake is collecting feedback without acting on it. Feedback should become evaluation data, roadmap input, training material, or incident evidence.

The seventh mistake is letting costs grow invisibly. AI cost management must be part of maintenance, especially as adoption increases.

The eighth mistake is treating governance as paperwork. Governance should decide whether the system can expand, must be remediated, or should be retired.

Build, Buy, or Managed Support?

After launch, enterprise buyers usually face three support options.

Internal support works when the organization has AI engineering, data, security, product, and operations capacity. It gives control but requires strong ownership.

Vendor-managed support works when the AI system is mostly packaged and the vendor provides production support, security updates, model lifecycle guidance, and SLAs. It is faster but may limit customization.

Partner-supported AI maintenance works when the system is custom, cross-system, or strategically important, but the enterprise needs help with LLMOps, monitoring, evaluation, RAG updates, security reviews, model migration, and continuous improvement.

For many enterprise buyers, the best answer is hybrid: internal business ownership, vendor platform support where appropriate, and specialized AI maintenance support for custom components.

The Etheons Recommendation

Enterprise AI maintenance should be planned before launch, funded before scale, and governed throughout the system’s lifecycle.

The Etheons rule is simple:

Do not launch an AI system unless you know who will maintain its behavior, data, security, cost, and business value after launch.

A production AI system needs more than uptime support. It needs continuous evaluation, source maintenance, prompt versioning, model lifecycle management, security testing, user support, incident response, governance evidence, and ROI tracking.

The strongest AI systems after launch have:

- A business owner.

- A product owner.

- A support model.

- A monitoring dashboard.

- An evaluation suite.

- A data maintenance process.

- A model lifecycle plan.

- A security review cadence.

- An incident response playbook.

- A cost management process.

- A roadmap for improvement.

- A retirement path if value disappears.

AI maintenance is not the less glamorous part of AI. It is where trust is earned.

For enterprise buyers, the decision-stage message is clear: launching AI proves that the system can work. Maintaining AI proves that the business can depend on it.

References

[1] McKinsey, “The State of AI: Global Survey 2025.” https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
[2] Deloitte, “The State of AI in the Enterprise — 2026 AI Report.” https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
[3] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[4] Google Cloud, “What Is MLOps?” https://cloud.google.com/discover/what-is-mlops
[5] IBM, “What Are Large Language Model Operations?” https://www.ibm.com/think/topics/llmops
[6] OpenAI, “Production Best Practices.” https://developers.openai.com/api/docs/guides/production-best-practices
[7] OpenAI, “Evaluation Best Practices.” https://developers.openai.com/api/docs/guides/evaluation-best-practices
[8] Microsoft Learn, “Model Monitoring in Production — Azure Machine Learning.” https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2
[9] AWS, “Well-Architected Framework.” https://developers.openai.com/api/docs/guides/production-best-practices
[10] NIST, “AI Risk Management Framework.” https://www.nist.gov/itl/ai-risk-management-framework
[11] ISO, “ISO/IEC 42001:2023 AI Management Systems.” https://www.iso.org/standard/42001
[12] OWASP GenAI Security Project, “2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps.” https://genai.owasp.org/llm-top-10/
[13] Microsoft Learn, “Model Monitoring Capabilities and Best Practices.” https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2
[14] AI Act Service Desk, “Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems.” https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-72
[15] AI Act Service Desk, “Timeline for the Implementation of the EU AI Act.” https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
[16] CISA, “New Best Practices Guide for Securing AI Data Released.” https://services.google.com/fh/files/misc/practitioners_guide_to_mlops_whitepaper.pdf
[17] OpenAI, “Deprecations — OpenAI API.” https://developers.openai.com/api/docs/deprecations
[18] Microsoft Learn, “Foundry Models Lifecycle and Support Policy. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements