One thing becomes obvious when you build AI close to live operations: getting the technology to work is often the easier part. The real test begins when it meets the organisation as it actually is, with fragmented data, legacy systems and manual workarounds.

McKinsey found that 88% of organisations were using AI in at least one business function in 2025, but only 7% had fully scaled it. In Malaysia, AWS found that only 19% of adopters had a formal strategy for scaling AI across multiple functions.

That, to me, is the central point: the best AI deployments are not just technically strong. They have to be built with a deep understanding of how the operation actually works.

The harder part starts after deployment

A lot of organisations can get an AI pilot built. The harder question is what happens once it becomes part of the business.

Someone has to own it. Data and business processes will change. Controls need to be maintained, and the organisation needs people who can recognise when the system is no longer performing as intended and know what to do about it.

That is where many organisations are less prepared. They may have the capability to build or commission the technology, but not necessarily the expertise to operate, maintain and improve it over time.

Building the technology is a project. Maintaining its value is an organisational capability. And that puts more weight on choosing the right problems to solve in the first place.

The best AI use case is not always the most technically impressive one

If an AI system has to be operated and maintained over time, it needs to be solving something that matters. A sophisticated model does not create business value simply because it works.

That could mean reducing the time people spend searching across fragmented business data, helping planners analyse complex spatial information faster or giving infrastructure teams earlier visibility of operational risk.

The important question is not simply what AI can do. It is where the organisation is carrying enough friction, cost or risk for applying it to make a meaningful difference.

That is where operational and technical expertise need to meet. One identifies the problem worth solving. The other determines what is possible. The strongest results come when those two perspectives are brought together early.

Being operator-led means starting with the operation

Gamuda Technologies grew in part from problems we were already encountering inside Gamuda. We could buy platforms, work with technology partners and integrate systems, but gaps still remained between what the technology could do and what the operation actually needed.

That shaped how we build today. Within Gamuda, working directly with project and operational teams means users can help shape requirements, challenge assumptions and test whether a product reflects what the operation actually needs. That proximity gives us a direct line between users and product development.

This principle is not limited to construction. Where we have deep domain expertise, we use it. Where it sits with the customer, we build with the people who understand that environment best.

The starting point is the same: understand the operation before deciding what technology belongs in it. The real advantage comes when that becomes a repeatable way of working, rather than something done project by project.

The question for technology buyers is changing

As AI capability becomes more widely available, comparing providers purely on models, features or technical specifications will tell organisations less than it once did.

The more useful questions come after that. Can the provider understand the operating problem before proposing the technology? Can it work with the people who hold the domain knowledge? Can it turn a promising use case into something that works in the business? And have they thought about what happens after deployment, when that technology has to be operated, maintained and improved over time?

That is where G-Tech’s operator-led approach becomes particularly relevant.