Enterprise AI deployment is not a magic trick; it is a disciplined operating approach. The organisations that win are building on open foundations, tuning models to their business, and wiring governance into the workflow rather than bolting it on later.
Executives are past the first wave of spectacle. Demos have given way to deadlines, pilots to production targets. The new question is not whether large language models can draft emails or summarise reports; it is how to embed intelligence across workflows without breaking cost controls, security models, or service levels. That requires an operating model for AI, not a showcase.
Robbie Jerrom, Senior Principal Technologist for AI, speaks in practical terms about this shift from fascination to foundation. The framing is not about a single platform or a prescriptive stack; it is about how enterprises operationalise intelligence on top of the infrastructure they already trust. The core building blocks, ranging from Linux to containers and Kubernetes, provide the substrate. Still, the competitive edge comes from how teams connect models to real processes, real data, and real accountability.
“People still ask for a list of AI use cases as if there is a finite catalogue,” Jerrom explains. “A better approach is to let the imagination run a little, then pull it back and anchor it to a real workflow, a real measure of value, and the systems that will run it in production. That is where the momentum builds, because the first wins are small, visible, and repeatable, and teams learn how to deploy and manage the capability alongside everything else they operate.”
The step from curiosity to competence often begins inside technology teams themselves. Service operations, security monitoring, and platform engineering contain many of the low-risk, high-value patterns that lend themselves to augmentation. Log analysis, change documentation, configuration generation, and control-plane triage are examples that typically live behind the firewall and avoid sensitive customer data. They also sit close to the tools and runbooks that keep the organisation online.
“IT professionals are discovering that generative models can reduce toil in places they already understand,” Jerrom adds. “Writing playbooks, drafting configuration, correlating audit output with policy language, these are the kinds of tasks where the value is immediate. Once the platform teams are comfortable, the conversation with the business becomes far more productive because the organisation has internal proof that AI is not a novelty, it is a lever.”
From pilot theatre to production
Enterprises stumble when they treat model choice as the destination. The strength of a programme lies in how quickly a team can evaluate options, swap components, and prove that a given model fits a given task within a defined budget and latency envelope. This is where the idea of “models as a service” earns attention: a governed catalogue of vetted models that development teams can test side by side, with cost and performance transparent from the outset.
“There are thousands of models and derivatives in circulation, each with different strengths,” Jerrom continues. “Developers need a way to evaluate them against the task at hand, and operations need a way to run them that meets the organisation’s expectations on cost, performance, and audit. A service model for models gives both sides what they need. It lets the developer focus on the application, and it lets IT standardise how those capabilities are delivered.”
The service mindset matters because it decouples application logic from any single model. An enterprise can start with a compact model for a low-risk internal task, then graduate to a larger one when the use case demands higher quality, or step back to a quantised variant when economics bite. The model is a component. The product is the workflow.
This is also where tuning comes into play. Most organisations do not need to train a foundation model from scratch. Still, they need to align their model with the language, acronyms, and decision-making patterns that define their business. That is as much about precision as it is about culture, because a model that understands what “firewall” means in a safety-engineering context saves time and reduces error before a single token is generated.
“Training a foundation model is eye-wateringly expensive, so most enterprises quickly realise they should not try,” Jerrom explains. “The smarter move is to optimise and align. Make the model smaller where possible without compromising accuracy, then fine-tune it with your vocabulary and examples so it speaks your language. Sometimes that tuning happens in the weights, sometimes it happens in the context window with retrieval-augmented generation. Either way, you end up with something that feels like it belongs inside your company.”
The discipline here is not glamorous, yet it decides whether pilots survive contact with production. Compressing a model to run where the data lives can remove a data-movement bottleneck. Aligning terminology can remove a review bottleneck. Instrumenting prompts, responses, and decisions can remove an audit bottleneck. Each improvement is slight, but together they turn a proof-of-concept into a supported capability.
Choosing models without the lock-in
Technology leaders face a choice between closed convenience and open flexibility. The attraction of a single proprietary endpoint is clear, but the long-term cost is dependence on a black box that moves faster than your risk committee can manage. Open models and open tooling do not guarantee success, but they do allow inspection, replication, and exit. In a field where regulation evolves and costs swing with demand, that freedom is not ideological; it is practical.
Transparency also accelerates learning across the industry. Patterns for prompt construction, evaluation harnesses, red-teaming methods, and agent frameworks move faster when published. That momentum matters because the boundary between “good enough” and “production-ready” is a moving target. An open ecosystem provides a CTO with more than just code. It gives a stream of worked examples, failure reports, and upgrades that inform roadmaps and reduce duplication.
There is also a cultural dimension at play here. Open communities bring non-coders into the process in a way that pure source code never did. Prompt recipes, evaluation checklists, and domain-specific test sets are assets that business teams can help build, critique, and improve. That participation changes how AI is adopted: it stops being a hand-off to a specialist team and becomes a joint craft.
“Openness reduces the black-box anxiety,” Jerrom notes. “When teams can inspect the artefacts, replicate an evaluation, and see why a model behaves the way it does, they are more willing to take responsibility for deploying it. The hybrid model lets you run where it makes sense to run, from a disconnected site to a public cloud region, while keeping governance and cost under control.”
Hybrid thinking is not simply about location. It is about the ability to assemble a chain of components that match the problem: a small, fast model for classification at the edge, a retrieval step over a governed knowledge base, a larger model for synthesis in a controlled environment, and an analytics layer for monitoring and cost attribution. When models are swappable and the interfaces are open, that chain can evolve without tearing up the floor.
Agents, autonomy and guardrails
Agentic AI is where excitement meets responsibility. Giving a system a goal and a set of tools changes the shape of automation from task lists to outcomes. In theory, it moves a business beyond rigid workflow rules to a class of software that reasons about steps and tries alternatives when something fails. In practice, it creates both new opportunities and new risks, because the system will do exactly what you ask, not always what you meant.
“I wired an agent to a database and the local file system for a demo, then asked it to list the databases,” Jerrom recalls. “Because I had not started the database server, the agent explored the file system, found every database file on the machine, opened each one, and summarised them. It delivered a technically correct answer, but it was not what I intended. If that had been a data centre rather than a laptop, someone would have told me to stop playing very quickly.”
The anecdote is memorable because it is mundane. There is no malice and no exotic bug. The agent followed the tools and the instructions to the best of its ability. That is precisely why design and governance must grow in tandem with capability. Tool scopes, rate limits, allow-lists, and observation hooks need to be part of the architecture, not an afterthought. Similarly, human education is crucial in understanding the care required to frame objectives with sufficient precision.
“We are seeing production deployments of agents, but they are heavily watched and tightly bound,” Jerrom continues. “Typical enterprise patterns combine multiple models, explicit tool-calling, and guardrails that make the agent useful without opening the door to chaos. The direction of travel is clear, because a goal-seeking system that tries different paths when the first one fails is a better fit for messy real-world processes than a brittle sequence of steps.”
The right mental model for leaders is evolution rather than revolution. Agentic capabilities will initially enhance existing orchestration by eliminating friction in exception handling, data lookups, and decision support. As APIs, identity layers, and audit patterns mature for safe tool use, agents will shoulder more of the work. The leap of faith is not that software will become sentient, it is that organisations will invest in the mundane controls that make autonomy safe.
Sovereignty, skills and the culture to scale
AI has revived old arguments about data location and control, then added new ones about model behaviour and inference privacy. European organisations are particularly focused on how to keep data inside national or regional boundaries and how to meet sector-specific rules for model use. Sovereign cloud and sovereign AI are responses to that demand, but they only make sense if the operating model can span environments without fragmenting tools and teams.
“Sovereignty comes up in most enterprise conversations now,” Jerrom observes. “Customers want to run inside a country, meet local regulatory expectations, and minimise how much private data leaves the domain. These systems are powerful, and they are very good at recombining information in ways you did not anticipate, so caution is sensible. The trick is to meet those constraints without losing the flexibility to place workloads where they make the most sense.”
In practice, culture acts as the multiplier that separates hesitant adopters from disciplined innovators, because the organisations that move fastest and safest grant people permission to explore within clear guardrails, then deliberately harvest and spread what works. That approach mirrors how high-performing engineering teams adopt new technology, and it provides non-technical leaders with a more concrete way to participate that is more effective than a training course and more practical than a policy memo.
“Permission matters,” Jerrom explains. “Hands-on access, clear guidelines, and a forum to share what people discover turn isolated curiosity into collective capability. When executives themselves start using these systems to prepare for meetings or enhance communication, the entire conversation changes. Enthusiasm at the top becomes a signal, and the programme stops relying on a handful of enthusiasts on the edges.”
Skills investment should follow the same logic. Prompt competence is a literacy, not a job title. Most knowledge workers benefit from learning how to ask better questions and structure better instructions. For technical teams, the deeper bets lie in data pipelines, evaluation science, deployment fluency, and cost governance. Those are the disciplines that make intelligence available, reliable, and affordable at scale.
There is also a responsibility to anticipate misuse. The same pattern-finding that makes models valuable can be turned to re-identification and other harms when controls are weak. That is not cause for paralysis, but it is a call to design with misuse in mind and to validate systems in the ways that matter to the business, not only in benchmarks. The audit trail for prompts, sources, and decisions is as much about accountability as it is about troubleshooting and resolving issues.
Leaders often ask for a single message to cut through the complexity. The simplest one is to start where you stand. Use the tools yourself. Put a small, governed catalogue of models in front of your teams. Select two or three workflows where the time saved or errors reduced are obvious. Instrument everything. Share the results. The flywheel starts to turn when the organisation can see and measure value in its own context.
“Do not wait for a perfect roadmap,” Jerrom adds. “Spend a few hours learning what the systems can do for you as a leader. That experience will sharpen your judgement about where to invest and where to say no. The momentum will follow, and the ripple effect is powerful when it starts at the top.”
The future will not be uniform. Some organisations will remain comfortable with centralised services and a handful of closed endpoints; others will assemble bespoke chains of open components that run in data centres they control. Many will operate both patterns. What separates momentum from noise is not the label on the model; it is the ability to evaluate, swap, govern, and learn in the open.
Open source and enterprise AI deployment belong together
Open ecosystems provide the inspection, interchange, and community learning that complex programmes need. They keep exit doors unlocked. They give internal teams ownership of the artefacts they depend on. They invite contributions from people who do not write code but understand the domain better than anyone. They compress the distance between a promising paper and a working pattern. They also keep vendors honest, which matters when budgets are finite and audit trails are non-negotiable.
The destination is an operating model where intelligence is a first-class capability of the platform, not a staging demo. That operating model combines a catalogue of governable models, cost-aware deployment options, retrieval over curated knowledge, evaluation that reflects business risk, and an agent layer that performs additional tasks as controls mature. It is not a single product. It is a way of building and running software that treats AI as a material part of the system rather than a bolt-on.
The interest in agentic systems underscores this trajectory. Autonomy is enticing because it promises outcome-level optimisation rather than task-level automation. It will reach the enterprise in stages, first as tool-calling that reduces human friction inside orchestrations, then as goal-seeking behaviour within well-bounded domains. The enterprises that thrive will be the ones that design guardrails simultaneously with their goals.
The immediate path for leaders is clear. Treat model choice as a means, not an end in itself. Build a service around models so your teams can evaluate options without drama. Invest in alignment and retrieval, because those are the levers that make a model yours. Embed evaluation and audit so you can trust what you deploy. Keep sovereignty and cost in view from day one, so you do not have to rebuild. Above all, create the culture that turns exploration into execution.
“Every week brings a new capability, from multimodal perception to better reasoning,” Jerrom concludes. “The pace is exhilarating, but the fundamentals do not change. The organisations that learn in the open, align models to their business, and build the guardrails as they scale are the organisations that will look back in five years and say they turned potential into value.”
