I have the same conversation with technology leaders across the region often enough that the setup is now familiar. The lab is running, the board has seen the demos, and budgets have been approved and renewed. When I ask how many of those projects are in live operation, the answer is usually one or two, with a longer list described as nearly ready or pending sign-off. That nearly-ready list rarely shrinks. The transition from pilot to production is harder in APAC than most AI frameworks acknowledge: financial services firms here operate across markets with different data residency rules, different regulatory expectations around model explainability, and legacy platforms that were never built for real-time AI inference. The headline numbers are improving, making the nearly-ready gap more telling. Lenovo’s CIO Playbook 2026, with research insights by IDC, finds that 46 per cent of AI proofs of concept have reached production, with some organisations projecting returns of US$2.79 for every dollar invested. Momentum is already visible, with 60 per cent of organisations in late-stage AI adoption. The constraint sits downstream: only 27 per cent have comprehensive AI governance, while data quality, in-house expertise, integration complexity, and organisational alignment continue to limit readiness. Stalled projects are failing less on model quality and more on decisions that should be made before anything gets built. The gap is rarely where teams think it is The obvious explanation for stalled AI projects tends to be model quality: the AI was not good enough, the use case was not well defined, the data was not clean. In practice, that explanation covers fewer failures than most organisations want to acknowledge. The pilots that stall on the way to production often worked technically. What they encountered were architectural and organisational constraints that were never part of the original design brief. Regulated financial services environments make this visible quickly. In markets such as Singapore, Australia, Hong Kong, and Southeast Asia, banks and wealth managers face specific requirements around explainability and auditability. When an AI system influences a client recommendation or flags a risk, there needs to be a documented, transparent rationale that compliance teams and, in some jurisdictions, regulators can review. Organisations that treat explainability as a deployment-phase concern rather than an architectural input tend to discover mid-productionisation that significant rebuilding is required. That remediation timeline kills momentum. Many initiatives don’t recover from it. Data governance follows the same pattern. A pilot can be engineered to succeed on carefully prepared historical data. Production environments introduce quality issues, missing fields, inconsistencies between live systems, and feeds that behave differently from training data. Unless the data architecture was designed with production in mind from the start, the gap between a working pilot and a reliable production system can represent months of unplanned remediation work that was never budgeted. Also Read: Enterprise infra just became SEA’s most explosive sector, surging 503 per cent YoY From pilot to live: Wealth management churn prediction One engagement I can speak to directly illustrates what changes when production readiness becomes a design constraint from the start rather than a milestone at the end. A private banking group came to us needing to identify declining client relationships early enough for relationship managers to intervene effectively. Their focus was the ultra-high-net-worth segment, where losing a single client relationship can represent years of revenue. The challenge had been attempted internally before. The previous effort produced a model with reasonable predictive accuracy. It never reached the relationship managers it was built for. In the second engagement, the design returned to what relationship managers actually needed from a system of this kind. Forecasts were built to be explainable at the level of an individual client relationship, so a manager could understand the specific factors behind a prediction rather than receiving an opaque score. A real-time feedback mechanism was built into the architecture, allowing managers to rate prediction accuracy and flag outliers, feeding continuously back into model improvement over time. The system was integrated into the global MIS that teams already used daily, removing the adoption friction that had undermined the first attempt. Extensive international training was delivered as part of the rollout because a tool requiring meaningful changes to daily workflow is as much a change management challenge as a technical one. The result was regular production operations across multiple countries, with strong user acceptance among both relationship managers and sales managers. The decisive shift came from designing around the production environment from the start, treating explainability, feedback loops, and workflow integration as architectural requirements rather than later-stage additions. When infrastructure is the whole decision A second case shows how fundamental infrastructure decisions are to whether a project reaches production at all, not only how well it performs once deployed. A banking client needed to extract structured insight from a large volume of CRM history, specifically call logs and client engagement notes, to generate next-best actions and customer insights for marketing and product decisions. The data involved was sensitive enough to make on-premise deployment the preferred architecture. Manual review of equivalent material would have cost approximately 100 euros per hour under the client’s data handling requirements. Also Read: SEA is growing up fast, but enterprise fitness tech still has homework to do The solution was an on-premise deployment of open-source large language models, selected and tuned for the client’s specific requirements around cost, inference latency, and output quality. The stack used Hugging Face models orchestrated through LangChain and FastAPI, with MLflow managing the model lifecycle. The project was delivered in six months. The system has since processed over 50,000 documents automatically, saving approximately 20 minutes of analyst time per document and generating total automation savings exceeding one million euros against the manual baseline. The on-premise open-source architecture was a foundational design requirement that made the use case viable from the outset, established before model selection began because the data sensitivity constraints left no credible alternative. The project’s success has since opened a broader internal LLM programme within the organisation, with the first production deployment serving as the proof of technical and organisational readiness for further investment. What production-ready design actually requires Looking across both cases and the wider range of AI and data engagements our teams run across APAC and Europe, the organisations that reach production consistently treat deployment requirements as design inputs at the beginning of an initiative rather than as problems to resolve once the model is working. In practice, three things need to come before model selection begins. Explainability and auditability requirements must be defined by compliance and legal teams as architectural inputs, not reviewed once a model is complete. The infrastructure question — cloud, hybrid, or on-premise, proprietary or open-source — must be resolved by reference to data sensitivity and regulatory constraints specific to each market, not by what makes the pilot easiest to build. The question of who will own and operate the system in production, with a named team, a functioning MLOps or LLMOps workflow, and a governance mechanism for ongoing model performance, must be answered before deployment, not assigned after the project wraps. For technology leaders across this region carrying portfolios of AI initiatives, the practical question is worth asking directly about projects currently in development: does each have a credible, specific path to production within twelve months, including answers to those three questions? The organisations across APAC running more of their AI in live operation are not, for the most part, the ones running the most sophisticated experiments. They are the ones who decided earlier what production would actually require. — Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic. The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27. Join us on WhatsApp, Instagram, Facebook, X, and LinkedIn to stay connected. The post Why most enterprise AI in APAC is still stuck in the proof-of-concept room appeared first on e27.
Author: Martin Papy
Source: e27