AI now moves on a cadence measured in months, not years.
Models, frameworks, and hardware are surpassed so quickly that many initiatives feel obsolete almost at launch. For CIOs, CDOs, COOs, and public sector leaders, the response cannot be to slow the market; it has to be to change how the organisation designs, funds, governs, and operates AI as a capability.
Three questions frame what follows:
How do we avoid our AI investments becoming obsolete within 12 to 18 months?
How do we design an AI platform that can swap models without replatforming?
How do we align governance with a monthly AI cadence without increasing risk?
Stop Treating AI as a Project
Many organisations treat AI as a one-off project with a go-live date and a fixed end state. That approach worked for traditional IT systems with longer lifecycles. It could fail in the current AI environment, where underlying models, tooling, and infrastructure can materially change within a single budget cycle.
AI needs to be managed as a continuous product lifecycle:
Problem definition and use-case framing
Data acquisition, preparation, and feature engineering
Model selection, training, and evaluation
Deployment, integration, and monitoring
Iterative improvement and, eventually, retirement
Budgets, KPIs, and accountability should follow this lifecycle. Business cases should be written around outcomes such as service levels, accuracy, time saved, and reduced risk, rather than specific model names or vendors that will inevitably change. Funding models should explicitly allow for recurring spend on data quality, monitoring, and incremental model improvements.
Architect for Modularity, Not Hero Models
The pain of instant obsolescence is largely an architecture problem. When a solution is tightly coupled to a specific model, framework, or vendor, any external change becomes a major replatforming exercise.
Robust AI organisations do three things differently:
They expose models through a stable internal API or model gateway, so downstream systems see a consistent contract even as models change.
They separate data pipelines, feature engineering, model training, inference, retrieval (for example, RAG), and monitoring into distinct components with independent release cycles.
They adopt portable artefacts and standards where possible, such as containers, model formats, and infrastructure as code, so migration between providers or runtimes is an engineering task rather than a political crisis.
A simple reference stack can help orient this: channels and applications at the top; orchestration and guardrail services; a model gateway that can route to multiple providers; a retrieval and knowledge layer; and underlying data and feature platforms. This turns “we want to try a new model” from a strategic shock into a routine change request with a defined lead time.
Build Real MLOps, Not Just Models
In many organisations, model development is sophisticated, but everything around it is ad hoc. Code is moved manually, monitoring is shallow, and there is no reliable rollback path.
In that environment, a faster external cadence simply means more incidents and more unplanned work.
What actually absorbs the shock of rapid change is disciplined MLOps:
CI/CD and continuous training pipelines that can regularly rebuild and redeploy models as data and base models evolve
Automated testing of data contracts, regression performance, safety constraints, and cost limits before release
Canary deployments and A/B testing to compare new models with existing ones under real load
Monitoring for performance, drift, and failure modes, tied to automated retraining or rollback workflows, with clear thresholds and runbooks
This needs to be supported by AI observability. This includes elements on latency, error rates, quality metrics, and unit costs per request, plus logging of prompts, responses, and decisions in higher-risk contexts. Without this, each new generation of models feels like a disruptive event. With it, change becomes an input to an optimisation loop.
Governance Must Match the Cadence
Governance is often the most significant source of effective obsolescence. If it takes months to approve an AI use case, the model, the data, and sometimes even the business context will have shifted before anything reaches production.
The answer is not weaker governance. It is smarter, risk-based governance:
Fast, templated processes for low-risk internal use cases on standard patterns
Stronger but time-boxed review for high-risk, citizen-facing, or safety-critical applications
A focus on governing capabilities and patterns (for example, RAG, agents, summarisation services) rather than specific models, so model swaps within an approved pattern are treated as minor changes
Living risk registers and periodic reviews embedded in the lifecycle, instead of one-off approvals at the start
Governance should also differentiate between data governance (lineage, consent, residency), model governance (validation, bias, robustness), and use-case governance (business impact, accountability). Audit trails for training data, prompts, and outputs are essential where decisions affect citizens, safety, or regulatory outcomes.
Treat Hardware and Infrastructure as a Portfolio
The rapid evolution of AI-specific hardware is introducing a new source of technology risk. Some organisations are discovering that their AI infrastructure ages faster than their business cases.
Leaders can manage this by:
Classifying workloads (training vs inference, batch vs real-time, experimental vs mission-critical) and matching each to appropriate infrastructure tiers
Using cloud or managed GPU capacity for volatile or experimental workloads, where demand and models change rapidly
Reserving fixed capex for stable, predictable workloads where long-term efficiency and data residency justify it
Integrating AI infrastructure into formal asset lifecycle plans, including security hardening, software support, and decommissioning
The aim is to avoid being forced into expensive refreshes by individual projects. Decisions about where to run AI workloads should be part of portfolio governance, not negotiated on a case-by-case basis.
Curate the Portfolio and Plan for Exit
No organisation can keep pace with every new foundation model, technique, or tool. Trying to do so leads to fragmentation, duplicated effort, and an estate of half-maintained pilots.
A more defensible approach is:
Maintain a portfolio of AI use cases with explicit prioritisation by value, risk, criticality, and dependency on fast-moving capabilities
Define decommissioning or consolidation criteria at the outset: when does this solution get replaced, integrated into a platform capability, or retired?
Use small pilots deliberately as disposable probes, but ensure that anything scaled conforms to standard patterns, platforms, and governance
Portfolio reviews should be regular and disciplined, at a minimum, quarterly, with decisions to scale, stabilise, or retire based on observed performance, cost, and risk, not just technical enthusiasm.
Treat AI as an Evolving Capability
AI will not slow down. The organisations that cope best will not be those with the newest models; they will be the ones that have treated AI as an evolving capability, architected for modularity, industrialised MLOps, aligned governance with reality, and managed AI as a portfolio with deliberate entry and exit strategies.