Bringing AI products to life

Outlining a practical AI development lifecycle

Over the last few years I have watched the same pattern repeat in organisations, classrooms and boardrooms. Everyone wants "AI powered products," but very few have a disciplined development lifecycle that can actually bring those products to life. Instead of a coherent path from idea to governed asset, we see scattered pilots, a few hero use cases and a lot of frustration about why value is not showing up and delivering the benefits people expected.

In earlier posts I have argued that AI needs a clear proof of concept to production pipeline rather than disconnected experiments. In “Why AI needs a proof‑of‑concept to production pipeline” I set out the stages from PoC through pilot into production and handover, and in “AI innovation: why leadership matters more than technology” I emphasised that executives need a reliable pathway, not just impressive demos. This time we are zooming in on the development side of that story and outlining a practical six stage lifecycle for AI that sits inside that broader pipeline.

The goal here is simple: treat AI products as governed assets with a clear lifecycle, not as perpetual science projects. The six stages described below fit comfortably into agile delivery and modern data platforms, but they also give boards and executives the guardrails they keep asking for.

Stage 1: Problem framing and requirements

The starting point is always the business problem and the plain language business requirements. Agile does not remove this step; it just changes how we iterate against it. This is consistent with the "clarify the why up front" principle I described in the PoC‑to‑prod pipeline, where every PoC (proof-of-concept) starts with a well articulated problem, target outcomes and measurable success metrics.

• We begin by defining the problem in plain language: who the user is, what pain point is being addressed and how we will know if we have succeeded. That includes agreeing on a small set of success metrics, such as reducing handling time, improving accuracy or reducing risk in a decision process.
• We then classify the AI use case for impact and risk. High impact systems that touch rights, access to services or financial decisions need a different level of scrutiny to low impact internal automation. Emerging regulatory frameworks make this risk thinking explicit, but even without regulation it is good practice.
• From there we capture functional requirements: what the system must do, which workflows or decisions it will affect and how people will interact with it in the real world. We also capture non-functional requirements - latency, reliability, privacy, security, explainability, jurisdictional constraints and auditability.

In my innovation pipeline post I argued that even when teams say they are working in agile, they still need clear functional and non functional business requirements as key inputs into the agile process. This lifecycle makes that concrete.

Stage 2: Data readiness and architecture

Once we know what we are trying to achieve, we turn to the data. Many AI projects struggle not because the idea is wrong, but because the data is not ready or the architecture is improvised. In "Data governance needs a rebrand" I talked about the importance of curated, trusted data products with clear metadata and lineage; this stage is where that work pays off for AI.

• We start by mapping data sources, ownership and quality: which systems hold relevant data, who is responsible for them, what the current state of quality is and how often they change. We decide what data is in scope and, just as importantly, what is explicitly out of scope because of risk, consent or relevance.
• We then check the data against our governance framework. Do we have appropriate consent? Is the provenance clear? Are there known biases that need to be mitigated? What are the retention and minimisation obligations? This avoids the "we trained on whatever we could find" trap that creates nasty surprises later.
• On the architecture side we choose patterns that align with our broader data strategy - warehouse or lakehouse, batch or streaming, retrieval augmented generation or fine tuning. We also make sovereignty and compliance explicit by deciding where data will physically reside, how it will move and which jurisdictions apply.

AI projects should build on our core data platform rather than invent a parallel universe that nobody has the skills or budget to maintain.

Stage 3: Model selection and design

Only now do we turn to models. Model selection is a governed decision, not a purely technical adventure. This connects directly to my broader work on AI governance and the "tokenpocalypse" theme, where I have argued that sensible governance and management practices must apply just as much to models and tokens as to any other asset.

• We first choose the right approach for the problem. Some problems are better served by classical machine learning or straightforward automation. Others genuinely require orchestration around a large language model, often paired with retrieval from private data or tools.
• We evaluate candidate models against accuracy, robustness, latency, context window, and fit to the non functional requirements defined earlier. If we need fast responses, strict privacy controls or a particular jurisdiction, that will narrow the field very quickly. We decide whether to use a fully managed provider model, an enterprise platform model or a self hosted model, including licensing and intellectual property considerations.
• We then design the model use and document it. That means writing down intended use, limitations, input constraints and risk classification in a model card or factsheet. For generative applications we decide whether prompts plus retrieval are sufficient, or whether fine tuning or continued pre training is justified by the value case.

This is where we avoid the trap of "hero experiments" with no path into production that I described as pilot purgatory in the pipeline post.

Stage 4: Build, integration and controls

With problem, data and model choices in place, we move into build and integration. This is where MLOps, engineering and governance come together, echoing my earlier emphasis on "invest in the boring plumbing" such as reusable pipelines, CI/CD and observability.

• We implement the end to end stack: ingestion and transformation, storage or lakehouse, feature store or embeddings, serving infrastructure, guardrails and application layer. We keep infrastructure, prompts, routing and configuration as code so that the system is reproducible and controllable.
• We build evaluation pipelines that tie back to the success metrics from stage one - offline tests, performance regression suites, robustness checks and fairness or bias tests. For higher risk systems we also run red teaming and scenario based testing to probe misuse and failure modes. All of this is logged and versioned.
• We integrate security, privacy, logging and lineage from the start rather than as bolt ons. Access controls, encryption, audit logs and model lineage are part of the architecture, not optional extras.
• Finally, we embed AI governance checkpoints - design reviews, data ethics review where appropriate, and pre-deployment sign off by the accountable owner for high impact systems.

This is how we "tie into AI governance, not around it," as discussed in the PoC‑to‑prod post to stress that governance should be embedded in the delivery pipeline instead of bolted on at the end.

Stage 5: Deployment and change management

Deployment is not a developer switch; it is a controlled organisational decision. This stage corresponds to the production step in the pipeline and the handover patterns I have previously dicsussed for CI/CD and operations.

• We use progressive delivery patterns such as canary releases, blue green deployments and feature flags. We include explicit kill switches for AI components so that they can be turned off or rolled back without taking the entire product down.
• We run user acceptance testing that focuses on business value, usability and risk scenarios, not just technical correctness. We test what happens when the model is wrong, when the user behaves unexpectedly, and when upstream systems fail.
• Before go live for high impact systems we obtain formal authorisation from the accountable owner or review board. This is the final handshake that ties legal and organisational accountability to the deployment decision.
• We communicate clearly with affected users and stakeholders. People need to understand what is automated, what is assisted and what remains human led. We explain how issues will be handled and how feedback will be used.

One cannot simply deploy AI and hope for the best. Deployment is where we choose, as an organisation, to take responsibility for an AI product in the real world.

Stage 6: Operations, monitoring and FinOps

The final stage is operations. This is where MLOps, AI governance and FinOps come together, and where the "handover to operations" step in the PoC‑to‑prod pipeline becomes day to day practice.

• On the operational side we track quality, latency, error rates and model drift using defined objectives and alerts. We monitor for bias drift and fairness issues as data distributions and behaviour change over time. We maintain traceability from individual outputs or decisions back to the specific model version, data and approvals.
• On the FinOps side we establish visibility and bake in cost controls and model API spend ("tokens") at workload and feature level. We look at cost per conversation, cost per decision or cost per task and we tag workloads so that business owners can see their spend.
• We apply cost optimisation practices such as right sizing, autoscaling, scheduling and limits on expensive workloads. We use showback or chargeback to make cost a visible part of product ownership. And we retire or archive models and services that no longer justify their cost or risk, using a defined lifecycle process.

Taken together with my PoC‑to‑production pipeline and data governance articles, this simple AI lifecycle gives teams and executives a shared language for scoping, building and operating AI systems with intention. It allows us to connect leadership, innovation and governance in practice, so that AI capabilities move from isolated experiments to trusted, well managed assets in the organisation.