By: Ahmed Rashad, Sr. AI Specialist, Middle East & Africa at Nutanix
Have you seen this film before? A new technology arrives, powerful and effortlessly accessible. Departments spin up projects with minimal oversight from IT or finance. The first efforts reproduce old ways of working, and then somebody rethinks the workflow entirely and the pace picks up. Then the invoice arrives, and the organisation discovers it must bring things under control without cutting off access, because access is now how the work gets done.
That was the cloud, twenty years ago. It is gen AI today, on fast forward. What took cloud most of a decade is taking enterprises about eighteen months.
We watch this from two seats. We run our own AI workloads on our own GPUs, so we have made these mistakes with our own money. We also sit alongside a great many organisations making them at the same time, in different industries and under different regulatory regimes. The striking thing is how little the story varies.
Everyone’s first question is the wrong one:
It is almost always “which model?”, and it is the question that matters least, because the answer changes every quarter.
The question that survives contact with production is what a unit of work costs. Not cost per token, but cost per resolved support ticket, per merged pull request, per document retrieved. The unit price keeps falling while total spend keeps climbing, because cheaper inference simply means more inference. Jevons would have recognised it immediately.
The same discipline applies to the benefit side. Where organisations measure carefully, the gains tend to land in a recognisable range: on the order of 10 to 15 percent for support teams, and 20 to 25 percent in feature delivery velocity for engineering teams. Those numbers are only worth quoting when they have been instrumented beforehand, against a baseline captured before deployment. Worth knowing: a randomised trial by METR found that experienced developers completed real tasks 19 percent slower with AI tools, while believing they had been 20 percent faster. If you cannot say how you measured, you have a feeling rather than a result.
Agents are not chatbots, and they do not fail like chatbots:
This is the shift most organisations are unprepared for. A person using an assistant makes a request and receives an answer, and both the cost and the blast radius are bounded by their attention. An agent decides for itself how many steps to take, which systems to touch, and what to do with whatever it finds. The same instruction on a different day produces a different number of tool calls, a different bill and a different set of side effects.
Which means the controls that work are the ones you would apply to a new joiner with production access, not the ones you would apply to software licences. An identity for every agent, distinct from the human who launched it. Permissions scoped to each tool and each system, because MCP support is table stakes now, but speaking MCP and letting you grant an agent read access there and write access nowhere are very different things. Budget ceilings that are enforced rather than alerted on. Traces detailed enough to reconstruct why an agent took eleven steps rather than three. And a human gate on anything irreversible.
The organisations getting this right have arrived at the same architectural conclusion independently. Those decisions cannot live inside each application. They belong at a single point that every agent’s requests pass through, so that policy, spend and audit are answered once for the whole estate rather than reimplemented project by project.
Running inference in production is a different discipline from running a pilot:
A demo needs one model to work once. Production needs many models to work continuously, at predictable cost, while the field moves underneath you. Every organisation we work with has replaced a model in production faster than it expected to, whether because of a cheaper open weight release, a regulatory constraint, or a change in vendor pricing. The ones who suffered were those who had welded a specific model to a specific location and a specific set of applications.
Flexibility here is not a luxury, it is the whole game: serving different models for different tasks, sizing endpoints to demand, and sharing GPUs across workloads through partitioning and scheduling rather than dedicating them. And, unfashionably, batch. Document classification, index rebuilds and evaluation runs do not care whether they complete at 14:00 or at 04:00. Defer them, and interactive workloads get the daytime capacity they need. Banks ran on this logic throughout the mainframe era. It was never wrong. It merely stopped being necessary when compute was cheap.
Location is becoming a variable, not a decision:
Public cloud wins on speed and on access to the newest hardware. Other forces push the opposite way. Data residency and sovereignty requirements are no longer a compliance checkbox to be satisfied at the end of a project. For a growing number of organisations they determine which workloads can exist at all, and where. Add data gravity, latency to customers, and the economics of sustained utilisation, and owned or colocated infrastructure starts to look like the sensible home for a meaningful share of inference.
Meanwhile a new class of specialised GPU providers has appeared, and some of the organisations we work with are becoming those providers themselves, turning regional advantage and spare capacity into a business of their own.
Nobody gets this allocation right at the first attempt. What matters is that getting it wrong stays cheap to correct: that a workload can move between owned, rented and regional infrastructure without being rewritten, and that governance follows it when it moves.
Do not build a walled garden:
The temptation is to stand AI up as a separate estate, with its own tooling, its own rules and its own team, deliberately quarantined from everything else. There are two problems with that.
The first is that agents produce nothing of value until they can reach the systems and the data where your business actually runs. A wall built for safety very often becomes the reason a promising pilot never becomes production. The capability works. It simply is not allowed near anything that matters.
The second is the arithmetic of running everything twice. Two sets of policies, two audit trails, two places to look during an incident, and two opportunities for them to contradict each other, while the people who understand your controls best sit on the far side of the wall from the workloads that need them most.
The organisations moving fastest treat AI as a workload like any other, subject to the same access model, the same operational discipline and the same teams, with the controls that are specific to AI layered on top rather than rebuilt alongside.
Where that leaves us:
There is no magic bullet for a technology moving this fast, and anyone selling one is selling something else. But the discipline transfers even when the tools do not. Measure cost per unit of work. Instrument your claims before you repeat them. Give agents identities, budgets and boundaries, enforced in one place. Keep models and workloads free to move. And govern all of it with your estate rather than beside it.
The film is on fast forward, and none of us gets to slow it down. But you can learn the genre well enough to see the twists coming, and avoid being the character who loses the plot.
