Can Your AI Strategy Keep Up? 

You cannot predict the future of AI. You can make decisions now that will allow your strategy to survive it. 

At Big Data LDN this September, I opened my session with one question. If a better model became available tomorrow, could your organisation use it? 

Or would changing that model mean reopening the workflows, integrations, controls and governance built around it, and possibly the business case as well? 

That question sits in the background of almost every AI conversation I have with enterprise leaders. Nobody can keep up with every announcement, so the real focus should be on finding ways to benefit from what comes next without starting again every time the market moves. The future of AI is unpredictable. Your AI strategy cannot afford to be fragile. 

Four years in, the question has moved from amazement to accountability

It is nearly four years since ChatGPT arrived in November 2022 and changed the public imagination. I joined Microsoft in January 2023, right at that inflection point, and suddenly every conversation was about generative AI. What can it do? Where can we use it? Which use cases will move the needle? 

Then came copilots. Then use-case lists. Then pressure to prove ROI. And now agents. 

I think 2026 marks another shift. The question is no longer "what can generative AI do?" It is "what can we put into production repeatedly, safely and measurably?" The first wave proved the technology is powerful. It did not prove that enterprises know how to scale it. 

My perspective on this comes from more than twenty years of working through these waves. My foundation is process and measurement at Motorola, where I earned my Green Belt in Digital Six Sigma. From there I moved into workflow transformation and early enterprise AI at IBM, and then at AWS, I watched cloud and AI move from theory into real production environments. At Microsoft, I led Data and AI for the UK public sector, where governance, regulation, trust and public accountability were part of the conversation from the start. And now, at Jeen, I work with customers on their enterprise AI strategy, agents, workflows and the ownership layer around them. Throughout, the question that mattered was never which tool to use. It was how work changes, and whether you can measure the value. 

The interface gets the attention. The architecture decides whether it scales.

While enterprises were working out how to scale, the market itself exploded. Hugging Face alone now hosts more than two million public models. New entrants keep arriving, and and investment keeps following them. 

The individual numbers matter less than what grew around the model: inference, retrieval, agent orchestration, coding, voice, video, evaluation and security. Even the protocols connecting these systems are still being written. So when an organisation tells me it will standardise its AI strategy around one model, I see that as quite a risky bet. The model is only one part of the stack. Build for a changing ecosystem, not for one winning model. 

There is a pattern here, and I have seen it in every wave. With the web, we got excited about websites. With mobile, apps. Cloud had the console. Generative AI gave us the chatbot. Now we have agents. 

But the interface is never what makes a technology wave scale. What scaled the web was not the website. It was everything underneath it: protocols, infrastructure, networks and standards. The same is true now. The agent is the visible part. Behind it sit data, context, permissions, workflow, governance, cost, integrations and accountability. That is the foundation that decides whether anything built on top of it will scale. 

We do not need another four years of use-case lists

Here is what the first four years taught us. Model capabilities advanced much faster than the enterprise operating model could absorb them. 

• Model access does not automatically change a workflow. 

• Deploying a copilot does not automatically prove ROI. 

• Creating an agent does not automatically create governed autonomy. 

• A list of a hundred use cases does not make a repeatable enterprise capability. 

We have spent years identifying things AI could do. Now we need to get much better at deciding what work actually changes. If an employee writes a report in twenty minutes instead of two hours, that is useful. If the report then waits five days for the same approval process, the economics of the whole workflow barely change. 

It also helps to stop treating all AI adoption as one thing. I find it useful to split enterprise AI into four ways organisations use it: 

1. Work with AI. Individual productivity: drafting, summarising, research, meetings, coding. This is where most companies began. 
2. Know with AI. Organisational knowledge: finding a policy, analysing documents, accessing enterprise data, supporting decisions. 
3. Run with AI. AI inside operational workflows: underwriting, claims, credit, procurement, compliance. 
4. Serve with AI. The experience layer: voice, chat, customer journeys, employee experiences. 

These are not maturity levels. One company may be doing all four at once. But they create value in very different ways. Giving someone a writing assistant is fundamentally different from giving an autonomous system authority inside a regulated workflow. So instead of asking "are we using AI?", ask where you are using it, what value you expect, and what system surrounds it. 

Nobody designed their AI islands. They accumulated them.

Whichever of those four areas you work in, you are building on constantly shifting ground. Models are changing. Agent frameworks are changing. Infrastructure choices, regulation, security and economics are all changing at the same time. That makes brittle architecture more than a technical inconvenience. It is a business risk. If changing a model means reopening a six-month transformation programme, then your model choice is largely theoretical. 

And the reality inside most enterprises is not one clean AI strategy. It is Copilot here and ChatGPT there. An internal RAG project. A specialist vendor. An agent platform. Developers calling model APIs directly. Claude or Gemini in another team. 

None of those decisions is necessarily wrong, and that is what makes the problem hard. Each local decision makes sense. Together, they fragment control. 

The same logic applies to agents, where I think the industry has developed a bit of an obsession with standalone agents. To be clear, I am not anti-agent. Agents matter. But an agent without an operating system is chaos waiting to happen. Every agent depends on human authority, context, governance, workflows, cost controls and permissions. Some of those elements connect. But changes often do not propagate across them, and the right people are not notified. An agent bolted onto a broken process simply becomes a faster broken process. 

So the answer is not fewer agents. It is an operating layer underneath them. Picture the same agent with the same dependencies, but now integrations run through one foundation instead of point-to-point wiring. Policy applies at the moment the agent acts. Every step is recorded: who did what, why, and under which policy. The estate stops being a tangle of separate relationships and becomes one governed system. 

That is the shift I want leaders to hold on to. Not "how many agents do we have?" but "what system are those agents operating inside?" 

The more autonomy you create, the more control you need

This leads to what I call the AI scaling paradox. As adoption grows, control and visibility can actually shrink. More tools, more pilots, more agents, more autonomy. Meanwhile, finance has less visibility into cost, security has less visibility into data movement, and business leaders know less about which decisions are being delegated. 

Adoption and control are usually treated as a trade-off. They should not be. Three capabilities separate experimentation from AI at enterprise scale: 

1. Control. Govern users, agents, policies, data, cost and performance in one operating model. 
2. Optionality. Change models, vendors, tools or deployment environments without rebuilding the business layer. 
3. Owned intelligence. Your business logic, workflows, context, evaluations and learning loops are organisational assets. They should not disappear inside a prompt or become trapped inside one vendor's API. 

Future-proofing, then, is not about predicting which model wins, it is about designing for change. 

That principle has to show up in real technology choices: model orchestration that routes by quality, cost, latency and risk; deployment portability across cloud, private cloud, on-premise and fully air-gapped environments; governed enterprise context; runtime policy; AI FinOps; and workflow integration. Each is a point where you either retain flexibility or quietly lock yourself in. 

I would also challenge the idea that multi-model support, on its own, means flexibility. The real test is this: if I change the model, what can I keep? The workflow? The policy? The permissions? The evidence? The context? That is a far more meaningful definition of architectural freedom. 

Governance is a good example of why this matters. Historically, it has lived in policies and documentation. But when an agent acts in real time, governance has to become runtime behaviour. In practice that means four steps: 

1. Separate policy from agent logic. Do not hard-code the same rule into fifty different workflows. 
2. Evaluate at runtime, at the moment the prompt, tool call or action happens.
3. Act on the violation. Allow it, block it, mask it, flag it, route it, or require approval. 
4. Trace and own the outcome. What happened, why, under which policy, and who is accountable for what happens next.  

That last step matters more than it looks. The person who built the agent is not necessarily the person accountable for the business outcome. The next step in governance is not policy on paper. It is policy as an operating layer, part of execution rather than an audit exercise after it. 

The value was never the agent. It was the process it changed.

Let me make this concrete. We work with a financial services customer that receives thousands of complex international credit directives every month from Visa, Amex and Mastercard. An expert committee used to spend roughly a full week every month manually reviewing those documents. 

We did not give them a chatbot. We redesigned the workflow. A multi-stage agent now ingests the directives and supporting documents, identifies the required tasks and routes them to the right owners. It achieves around 95 per cent document-processing accuracy and saves a full week of expert manual work every month. 

The committee still exists. The humans are still accountable. What changed is what reaches them and how the work moves. That is the difference between AI as a tool and AI as part of the operating fabric. 

The same foundation carries very different paths to production. In aerospace and defence, we have a fully on-premises, air-gapped deployment where employees have built more than 1,000 agents themselves, without each new agent requiring IT involvement. In healthcare, we deployed a single workflow that was then expanded into an organisation-wide platform across several functions. In insurance, a proof of concept became a production knowledge assistant, with customer journey, recruitment and voice initiatives now being built on the same layer. 

None of this has to start as a huge transformation programme. Depending on scope and deployment requirements, a governed knowledge assistant grounded in approved organisational documents can be live across a business unit in as little as two weeks. The point is to establish something useful quickly, on a foundation that can carry whatever comes next. 

An explicit trade-off is a strategy. An invisible dependency is a future surprise.

If you take one thing from this piece, make it these seven questions. Ask them before your next platform, model or agent decision: 

1. Can we switch models without rebuilding workflows? 
2. Can we govern agents across teams, tools and vendors? 
3. Can we see AI cost by user, model, team and workflow? 
4. Can we deploy differently depending on risk? 
5. Does our organisational knowledge stay under our control? 
6. Can the next use case reuse the context, integrations and controls we have already built? 
7. Can we explain what the AI did, why, and under which policy? 

You do not need a perfect answer to every question tomorrow. But you should know where you stand on each.  

As for where to start: pick a workflow where the friction is measurable, whether that is cycle time, cost, error rate, compliance burden or expert capacity. Then build the reusable foundation underneath it: context, permissions, governance, integrations, FinOps and evaluation. Once it works, scale through controlled democratisation, so business teams can create within enterprise guardrails without every new idea going back to central engineering. Start small in scope, not small in thinking. 

Build a strategy that can change with the market

So I will close where I started. Do not try to predict the future of AI. You cannot. Neither can I. The models will change. The vendors will change. The frameworks and the economics will change. 

What you can do is build a strategy capable of changing with them. For me, that is what “AI on your terms” means: the freedom to adopt what comes next without losing control, rebuilding the stack, or giving away your organisational intelligence. 

The question I left the room with is the one I will leave you with too. Where is scaling AI getting stuck in your organisation? 

Build anywhere. Govern through Jeen. This is AI On Your Terms.