AI Moves in Months. Does Your Organisation?

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?

Treat AI as a Continuous Capability, Not 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: from problem definition and use-case framing through model selection, deployment, monitoring, and iterative improvement. 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.

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 expose models through a stable internal API or model gateway, separate data pipelines and model training into distinct components with independent release cycles, and adopt portable artefacts and standards so migration between providers is an engineering task rather than a political crisis. That portability question is also an economics question — I set out when switching between local and API-hosted models actually pays off separately. This turns “we want to try a new model” from a strategic shock into a routine change request with a defined lead time.

This turns “we want to try a new model” from a strategic shock into a routine change request with a defined lead time.

Build the Operational Backbone

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; and monitoring for performance, drift, and failure modes, tied to automated retraining or rollback workflows. This needs to be supported by AI observability: elements on latency, error rates, quality metrics, and unit costs per request, plus logging of prompts, responses, and decisions in higher-risk contexts. The four dashboards a Chief AI Officer should actually be running cover this ground in more operational detail. Without this, each new generation of models feels like a disruptive event. With it, change becomes an input to an optimisation loop.

Without this, each new generation of models feels like a disruptive event. With it, change becomes an input to an optimisation loop.

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 but smarter, risk-based governance: fast, templated processes for low-risk internal use cases; stronger but time-boxed review for high-risk, citizen-facing, or safety-critical applications; and a focus on governing capabilities and patterns (for example, RAG, agents, summarisation services) rather than specific models. Governance should also differentiate between data governance (lineage, consent, residency), model governance (validation, bias, robustness), and use-case governance (business impact, accountability).

Manage the Technology 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, reserving fixed capex for stable and predictable workloads, and integrating AI infrastructure into formal asset lifecycle plans. Decisions about where to run AI workloads should be part of portfolio governance, not negotiated on a case-by-case basis.

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 to 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; and use small pilots deliberately as disposable probes while ensuring that anything scaled conforms to standard patterns, platforms, and governance. Portfolio reviews should be at minimum quarterly, with decisions to scale, stabilise, or retire based on observed performance, cost, and risk.

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.

The practical test is simple: how quickly and safely can your organisation swap, upgrade, or retire an AI component without disrupting services or restarting from zero? That lead time is now measured in days or weeks, not months. This is the real indicator of AI maturity.

The practical test is simple: how quickly and safely can your organisation swap, upgrade, or retire an AI component without disrupting services or restarting from zero?

Free tool

Model Performance & Health Dashboard

Track drift, latency, uptime, and rollback history, the operational backbone that turns a new model release into a routine change request instead of a disruptive event.

→

Free tool

Enterprise AI Value & Adoption Dashboard

Review TCO and adoption by business unit across your AI portfolio, the same quarterly discipline this piece argues for managing AI as a portfolio, not a project.

→