Mapping the AI value chain

Over the last few years I have watched organisations reach for AI capability without ever stopping to ask where that capability actually sits in the business. Everyone wants "AI powered products," but very few teams can point to a shared picture of how AI creates value end to end - what supports it, what depends on it, and what compounds over time.

So I put together a value chain map for AI for one of my AI innovation courses, and it is worth walking through in detail because the structure tells you almost as much as the content.

Starting from Porter, not from the hype cycle

Michael Porter's value chain is about forty years old, and it still holds up because it forces a simple discipline: separate the activities that create value for the customer (primary activities) from the activities that make those primary activities possible (support activities).

Most AI strategy conversations skip this step entirely. They jump straight to use cases and pilots without asking what has to be true underneath those use cases for value to actually land. Applying the value chain to AI is not a branding exercise - it is a way of making the dependencies visible.

The three support activities

Every primary activity in an AI capable organisation rests on three support functions, and if any one of them is weak the whole chain is fragile.

• AI governance. This is not a compliance checkbox bolted on at the end. It is the framework, and mechanism for review, that determines whether an AI system can be trusted with a decision. I have written before about what effective AI governance actually requires, and the short version is that governance has to be embedded into delivery, not layered on top of it after the fact.
• Talent and AI fluency. AI is change management wearing a technical costume. Without people who understand what the models can and cannot do, and without a workforce that is fluent enough to challenge a bad output rather than defer to it, none of the rest of the chain functions.
• Model and data supply. This is the plumbing - vendor relationships, model selection, licensing, context windows, sovereignty and jurisdictional constraints. It is unglamorous and it is exactly the kind of "boring plumbing" that determines whether the rest of the organisation can build on solid ground or is quietly improvising.

The four primary activities

Sitting on top of those support functions are the activities that actually create value for the customer or the business:

1. sourcing and preparing the inputs an AI system needs,
2. building and integrating the models into real operational workflows,
3. delivering the resulting product or decision into the hands of users, and
4. operating and monitoring it once it is live.

This maps closely onto the AI development lifecycle I set out recently - problem framing and data readiness feed the front end of this chain, build and deployment sit in the middle, and operations and FinOps close the loop. The value chain perspective is the necessary complement to the lifecycle perspective: where the lifecycle shows the temporal progression from idea to operation, the value chain shows the structural dependencies that have to hold at every point in that progression.

The point of laying it out as a value chain rather than a lifecycle is that it makes clear these are not sequential phases you complete once. They are activities the organisation performs continuously, in parallel, for every AI product it runs.

Proprietary data as substrate, not support

Here is the one place I want to depart from a strict Porter reading. Data does not sit neatly inside "model and data supply" as just another support activity.

Proprietary data functions as substrate - it is the layer everything else in the chain grows out of, not a service that feeds into it.

Commodity models are increasingly interchangeable. What is not interchangeable is the data an organisation has accumulated that nobody else has access to - the interaction history, the domain-specific corpus, the operational telemetry. Recent industry analysis has made the same point directly: proprietary data is becoming one of the few durable competitive advantages left in AI, precisely because it cannot be purchased or replicated the way compute or off-the-shelf models can.

If you treat proprietary data as just another input to be sourced, you will underinvest in the one asset in this whole chain that actually compounds.

The innovation engine and the feedback loop

The chain does not end with delivery. Every AI product that goes into production generates signal - usage patterns, failure modes, edge cases, new proprietary data - and that signal has to flow back into the front of the chain, not disappear into a dashboard nobody reads.

This is the innovation engine: a deliberate mechanism for routing what you learn in operations back into problem framing, data readiness and model selection for the next iteration. Without that feedback loop, the value chain is just a pipeline, and pipelines depreciate. With it, every cycle through the chain makes the next one cheaper, faster or more accurate.

This is also where the governance and talent support functions earn their keep a second time - someone has to decide what signal is worth acting on, and someone has to have the fluency to act on it responsibly.

What this means for you

If you are trying to work out where your organisation's AI effort is stalling, this map is a reasonable diagnostic:

• Weak governance shows up as slow, distrusted deployments.
• Weak talent and fluency shows up as either reckless adoption or reflexive rejection, with not much sensible ground in between.
• Weak model and data supply shows up as pilots that cannot get past a demo.
• A missing feedback loop shows up as a portfolio of AI products that all feel like they were built once and then abandoned.

Before you commission another proof of concept, it is worth asking which layer of this chain is actually the constraint - because more use cases will not fix a governance gap, and better prompts will not fix a data supply problem.