In an era where AI is shifting from experimental pilots to core operational infrastructure, the challenge for CIOs is moving from simple adoption to long-term control. This CIONET Trailblazer, featuring Ehran Lenaerts, AI Automation Specialist at B Robots, explores the critical necessity of architecting for AI flexibility. We investigate the risks of AI lock-in, the importance of model-agnostic foundations, and why building an internal orchestration layer is the decisive step for leaders to retain sovereignty in an increasingly complex AI landscape.

How do you assess the way most organisations are currently approaching their AI strategies?

Many organisations are still in an exploratory phase, launching pilots and testing GenAI tools to gauge value. While necessary, this is not yet a strategy. A mature AI strategy starts by identifying the business problem: What process are we improving? What decision are we supporting? What risk are we introducing? Companies with previous experience in automation and machine learning often have a more realistic view, understanding that AI is not a one-size-fits-all solution but a suite of technologies to be embedded into processes. The challenge is evolving from "demo-building" to designing reliable, human-centred, and governed AI-enabled operations where output can be trusted and the solution scaled safely.

There is growing concern about “AI lock-in”. What does that risk look like in practical terms?

We see three main layers of lock-in. First is vendor or platform lock-in; heavy reliance on one ecosystem limits your ability to pivot when better, cheaper, or more compliant models emerge. Second is workflow lock-in; as employees build daily habits around specific interfaces, changing tools creates massive retraining costs and productivity resistance. Third is data/embedding lock-in; if your knowledge base is built on a specific model’s embeddings, switching models later requires complex and costly restructuring. Consequently, AI lock-in is not just a procurement issue—it is an architectural and operational risk.

Where do organisations typically go wrong when moving from experiments to scaled deployment?

The biggest mistake is treating a proof of concept (PoC) as a production system. In a PoC, the environment is controlled, but production is exposed to messy real-world data and varying user behaviours. A prompt that works in a demo often fails under high volume. Scaling requires rigorous testing, monitoring, fallback logic, and human-in-the-loop design. Furthermore, many underestimate the "hidden" costs, token usage, infrastructure, and support, which can balloon once a solution moves beyond a handful of users.

If a company decides to change AI models later, what technical and financial challenges arise?

Changing models is rarely effortless. Validation is the first hurdle: you must prove a new model performs at least as well as the old one regarding accuracy, safety, and latency. Second is behavioural change; because models interpret prompts and context differently, the application's output style and reasoning may shift, impacting customer service or compliance workflows. Third is the technical rework of prompt templates, retrieval logic, and guardrails. The financial impact includes redeployment, retesting, and data reprocessing. This is why model flexibility must be designed as a foundation, not an afterthought.

Given the pace of change in AI, how should organisations design their technology landscape to remain adaptable?

Organisations must adopt modularity. The user experience, business workflow, and data layer should be decoupled from any specific model. Treat the AI model as a replaceable component rather than the foundation of your application. Build with APIs, abstraction layers, and reusable components that allow you to route different use cases to the most appropriate model, be it a high-end frontier model or a smaller, local one. The goal is not to chase every new release but to build a steady, pragmatic foundation that allows you to replace components when there is a clear business or compliance need.

How does the concept of “AI sovereignty” fit into these architectural decisions?

AI sovereignty is about strategic control: control over data, infrastructure, model choices, and long-term dependencies. For sensitive customer data or regulated sectors, you may need the ability to host models locally or use open-source alternatives. Sovereignty doesn’t mean you must run everything yourself; it means you avoid architectures where you are "trapped" with no realistic alternatives. It is the ability to maintain operations if a vendor changes pricing, policies, or availability.

Looking ahead, what is the one decisive action an IT leader should take now?

The most important action is to build an internal AI orchestration layer before adoption becomes too fragmented. When teams independently experiment with different tools and models, you create short-term speed but long-term technical debt and security risks. An orchestration layer allows IT leaders to centralise governance without blocking innovation. It provides a single point to manage access, security, logging, and cost control, while also enabling you to route different use cases to different providers. This transforms AI from a collection of "shadow" tools into a controlled, strategic capability. The decisive move is to stop treating AI as a series of disparate experiments and start treating it as core enterprise architecture.

 --