Table of contents
Share This Article
- What an AI Centre of Excellence Actually Is, Explained for APAC CTOs
- Why APAC Enterprises Are Standing Up AI CoEs Now
- The Operating Model Decision That Determines Whether Your CoE Accelerates or Blocks
- AI CoE Operating Models Compared
If you are a CTO, CDO, or Head of AI in a Singapore, Hong Kong, or Southeast Asian enterprise in 2026, an AI centre of excellence enterprise Singapore conversation is already on your executive agenda. The question is no longer whether to build one. It is whether the one you build will accelerate delivery across your business units or quietly become the bottleneck that every project blames for missing its goals.
The pressure to get this right is measurable. Gartner reports that organisations running successful AI initiatives invest up to four times more, as a percentage of revenue, in foundational areas like data quality, governance, AI-ready people, and change management than their less successful peers. Sea Limited, KPMG, Oracle and others have established formal AI Centres of Excellence in Singapore in the last six months, and Singapore’s Enterprise Compute Initiative has committed up to S$150 million to help mid-market companies stand up dedicated AI teams. The model works. It also fails often. Industry research places AI initiative failure rates between 70 and 85 percent, and the most common reason a CoE fails is structural, not technical.
This guide is the playbook we would hand a CTO standing up an AI CoE in Singapore, Hong Kong, or anywhere in APAC in 2026. It covers what a CoE actually is, the operating model decision that determines whether it accelerates or blocks, the six capabilities you cannot ship without, the funding and staffing pattern that works, the governance evidence your sectoral regulator will ask for, and a 90-day to 12-month rollout that gets you to operating capability without freezing your existing AI work.
What an AI Centre of Excellence Actually Is, Explained for APAC CTOs
An AI Centre of Excellence is a cross-functional unit that owns the shared platform, the governance standards, the reusable components, and the enterprise-level measurement of AI inside your organisation. It is not an AI team that builds every model. It is not a policy committee. It is not a research lab. It is the operating layer that lets every business unit ship AI faster, more safely, and more consistently than they could alone.
The simplest test for whether what you are calling a CoE is actually a CoE: ask whether removing it would slow down the business units. If your “CoE” mainly produces strategy decks and approval forms, the business units will route around it within two quarters. If your CoE owns the model registry the business units must use, the evaluation harness their releases run through, the identity and permission layer their agents authenticate against, and the cost telemetry their finance teams plan against, the business units will defend its existence in budget reviews.
The CoE plays four distinct roles, and conflating them is the most common design error.
First, it is a platform team. It builds and runs the shared AI infrastructure ā the model gateway, the evaluation framework, the retrieval and vector storage layer, the agent runtime, the observability stack. These are the building blocks every AI initiative across the company depends on.
Second, it is an enablement function. It produces the patterns, templates, training, and reference implementations that turn the platform into something a product team can adopt in days rather than quarters. Enablement is how you scale AI capability without scaling the CoE headcount linearly.
Third, it is a governance authority. It defines the standards every AI system in the company must meet ā model approval criteria, evaluation requirements, audit log schemas, identity and permissioning rules, kill switch and rollback procedures. These standards are the contract between the platform and the spokes.
Fourth, it is an enterprise measurement layer. It produces the registry of every AI system in production, the risk profile per system, the cost telemetry, and the value realisation evidence that lets the executive team make portfolio decisions.
A CoE that does only role one is an infrastructure team. A CoE that does only role three is a governance committee. A CoE that does only role four is a data office. A CoE in 2026 has to do all four, or one of the failure modes covered later in this guide will appear within twelve months.
Why APAC Enterprises Are Standing Up AI CoEs Now
Three forces are pushing this work onto your roadmap in 2026, and they are converging faster than most executive teams have planned for.
The first is the move from pilots to production at portfolio scale. The era when a single GenAI pilot was the AI conversation is over. APAC enterprises now run dozens of AI use cases simultaneously ā fraud detection, contact centre automation, document intelligence, regulatory reporting, marketing personalisation, software engineering tooling. Without shared infrastructure and standards, each of these reinvents the wheel: a different evaluation pipeline, a different prompt registry, a different observability stack, a different model provider relationship. The cost compounds linearly. The risk compounds non-linearly. A CoE consolidates the foundations so the per-use-case marginal cost falls.
The second is regulatory consolidation. Singapore’s Model AI Governance Framework for Agentic AI launched in January 2026, the EU AI Act’s high-risk obligations were rescheduled to 2 December 2027 under the Digital Omnibus provisional agreement of May 2026, and APAC sectoral regulators ā MAS, HKMA, IMDA, SFC ā are increasingly explicit about what they expect to see when they examine your AI portfolio. The cost of meeting these obligations once at the platform layer is far lower than the cost of meeting them again per system. A CoE is now the most defensible structure for that consolidation. We covered the technical implications of one of these frameworks in our Singapore agentic AI governance guide, and they apply equally to every other use case category.
The third is the cost reality of frontier models. APAC enterprises spent the 2023 to 2025 period treating model API spend as a marginal cost. By 2026, with token consumption rising 60 to 100 percent year on year in many organisations, model spend is no longer marginal. A CoE that owns the model gateway, the routing logic, the cache layer, and the cost telemetry can reduce token spend by 40 to 60 percent without business unit disruption. Without that layer, no one has the data to act on cost growth.
Add to these three forces the fact that Singapore’s Enterprise Compute Initiative is co-funding AI CoE setup for mid-market companies and that listed APAC players like Sea Limited have announced formal AI CoE programs as recently as April 2026, and the strategic question becomes: not whether to build a CoE, but how to build one that will not produce the failure modes that have made 70 to 85 percent of enterprise AI initiatives stall before they realise value.
The Operating Model Decision That Determines Whether Your CoE Accelerates or Blocks
The single most consequential choice in standing up an AI CoE is the operating model. Three models dominate the practitioner literature, and each produces a different failure mode when mismatched to the organisation.
The centralised model concentrates every AI capability inside the CoE. The CoE writes the prompts, builds the models, runs the evaluations, owns the deployments, and operates the runtime. Business units submit requirements and receive AI features. This model maximises consistency and governance, and is the right starting position when AI maturity across your business units is low or when regulatory exposure is severe enough that decentralised delivery is unsafe. It produces the bottleneck failure mode when demand exceeds the CoE’s capacity to deliver, which it almost always does as AI ambitions grow.
The federated model distributes AI delivery to business units, with the CoE retreating to a coordination and advisory role. Each business unit builds its own models, picks its own stack, and runs its own infrastructure. This model maximises agility and domain relevance, and is appropriate for large, highly diversified groups where business unit domains are genuinely distinct and the risk of central bottleneck outweighs the risk of fragmentation. It produces the fragmentation failure mode: incompatible foundations, duplicated effort, governance gaps, and an AI portfolio that cannot be measured or managed coherently at the enterprise level.
The hub-and-spoke model has emerged as the dominant best practice for 2026. The CoE functions as the hub: it owns the shared platform, the governance standards, the reusable components, the tooling, and the enterprise-level measurement. Business units function as spokes: they own their AI use cases, build solutions on the platform and standards the hub provides, and are accountable for the business outcomes their AI initiatives produce. The hub’s capacity is not the constraint on how many AI initiatives the organisation can run, because the spokes do the development work. The hub’s job is to make every spoke faster than it could be alone.
The hub-and-spoke model only works if the boundary between the hub and the spokes is drawn correctly. The most common error is for the hub to retain approval authority over every AI deployment. That is the bottleneck failure dressed up as hub-and-spoke. The correct boundary is standards-based governance: the hub defines what every AI system in production must demonstrate (evaluation pass thresholds, observability instrumentation, identity scoping, log retention), and the spokes demonstrate compliance against those standards. The hub audits, not approves.
AI CoE Operating Models Compared
The table below maps the three operating models against the dimensions APAC CTOs should compare them on when standing up an AI CoE. Use it to position your organisation, not to pick a winner abstractly.
| Dimension | Centralised | Hub-and-Spoke | Federated |
|---|---|---|---|
| Delivery throughput | Limited by CoE headcount; queues form quickly | Scales with the number of spokes; CoE invests in enablement | High in theory; constrained in practice by BU AI maturity |
| Consistency & governance | Very high ā one team, one standard | High ā standards-based with auditable conformance | Low ā divergent stacks, hard to audit at portfolio level |
| Cost efficiency | High platform leverage; CoE headcount cost grows with scope | High platform leverage; spokes pay marginal cost of delivery | Low ā duplicated tooling, vendor relationships, evaluation pipelines |
| Time to first use case | Slow ā CoE has to build platform and use case | Moderate ā platform investment first, then BU velocity | Fast per BU; slow at portfolio level |
| Regulatory fit (MAS, HKMA, IMDA) | Easiest to evidence; one team controls everything | Strong if standards-based governance is enforced | Weakest ā evidence gathering is per-BU and inconsistent |
| Best for | Year 1 setup, regulated industries, small portfolios | Most APAC enterprises by year 2; portfolios above ten use cases | Large diversified conglomerates with mature BU AI capability |
| Dominant failure mode | Bottleneck ā CoE queue blocks delivery | Hub overreach ā gatekeeper behaviour rather than enablement | Fragmentation ā incompatible stacks, governance gaps |
| Year 1 to Year 3 evolution | Usually evolves into hub-and-spoke by month 18 | Stable model for most APAC enterprises | Often re-centralises after a governance incident |
The pragmatic answer for most APAC enterprises is a phased model. Start centralised for the first nine to twelve months while the platform stabilises and the standards are written. Evolve to hub-and-spoke as the spokes demonstrate they can meet the standards. Only consider federation if you operate at conglomerate scale with genuinely distinct BU domains.
The Six Operational Capabilities Every AI CoE Must Have
A functioning AI CoE requires six operational capabilities. Organisations that launch a CoE without all six will discover the missing ones through the specific failure modes they produce, usually inside the first year. Sequence the capability build during your stand-up; do not attempt to launch the CoE without them.
1. Platform Engineering and Reference Architecture
The platform is what every spoke builds on. At minimum it includes the model gateway (a single entry point to every model provider, with routing, caching, rate limiting, and audit logging), the retrieval and vector storage layer, the agent runtime and orchestration framework, the prompt and configuration registry, and the observability stack. Reference architectures for the most common patterns (retrieval-augmented generation, agentic workflows, classification, summarisation) sit on top of the platform and tell every product team exactly how to compose the building blocks for their use case. We covered the architecture decisions for the retrieval layer in our LLM integration enterprise guide, which maps cleanly onto the platform that a CoE owns.
2. Governance Standards and Risk Tiering
The governance capability defines what every AI system must demonstrate before it goes to production and at each material change. The artefacts are concrete: a risk tier definition with criteria, an approval workflow that scales with risk tier, model and prompt change management standards, evaluation pass thresholds per risk tier, audit log schema and retention requirements, identity and permissioning standards for agents, and a kill switch and rollback playbook. The standards are written once and enforced through automation in the platform, not through approval meetings.
3. Evaluation, Testing, and Quality Assurance
Every AI system in production needs a test set, an evaluation pipeline, and a pass/fail threshold tied to its risk tier. The CoE owns the evaluation harness, the test set library, the synthetic data generation tools, and the regression testing infrastructure. Spokes contribute domain-specific test sets and run the harness against their systems. Without this capability, governance is performative and incidents are surprises.
4. Observability, Cost, and Operational Telemetry
Production AI without observability is a liability. The CoE owns the telemetry stack that captures every model call, every retrieval, every agent action, the inputs and outputs of each, the latency and cost per call, and the user feedback signals associated with each interaction. The same telemetry feeds the cost optimisation work that compounds into 40 to 60 percent token savings over twelve months, the incident response work that turns “the bot is broken” tickets into root-cause analysis in minutes, and the value realisation work that converts AI activity into board-level ROI evidence.
5. Enablement, Templates, and Reference Implementations
This is the capability that turns the platform from infrastructure into productivity. The CoE produces reference implementations for the most common use case patterns, codebases that BU teams can fork and adapt, internal training programs that bring engineers up to working competence, and office hours that compress the learning curve from quarters to weeks. The investment in enablement is what makes the hub-and-spoke model scale. Without it, the spokes will not have the capability to use the platform, and the centralised model becomes inevitable.
6. Portfolio Management and Value Realisation
The CoE owns the registry of every AI system in production across the enterprise. Each entry includes the owner, risk tier, data sensitivity, model dependencies, deployment date, last evaluation date, observed business outcomes, and cost-to-run. The registry is the substrate for portfolio decisions: which use cases to scale, which to retire, which to consolidate, where to invest the next quarter’s CoE capacity. Without this capability, the executive team cannot make AI portfolio decisions on evidence, and the conversation reverts to vendor logos and demo videos.
These six capabilities are the floor, not the ceiling. The order to build them in is platform first (months 1 to 3), governance and evaluation alongside (months 1 to 6), observability before any production deployment (month 3 minimum), enablement starting in month 4 once there is something to enable on, and portfolio management starting at month 6 once there are systems worth managing as a portfolio.
Funding Models: Central Budget, Chargeback, or Hybrid
The funding model is what turns the operating model from a strategy slide into something that survives the annual budget cycle. There are three funding models in common use, and the choice determines who has incentive to invest in what.
Central budget funds the CoE entirely out of a corporate line, with no internal cross-charging to business units. This is the simplest model to start with and the right one for the first six to twelve months while the CoE is building the platform and the spokes are not yet consuming meaningful capacity. It works because there is nothing to allocate yet. It stops working when the platform is heavily used and BU teams begin to perceive CoE capacity as a free resource. The CoE becomes the queue, the BUs demand more, the CFO sees only cost growth.
Full chargeback allocates every CoE cost to the business units that consume capacity. Model API spend, platform engineering time, evaluation runs, observability storage. This model creates the cleanest accountability and the strongest incentive for BUs to consume responsibly. It also creates the strongest incentive for BUs to route around the CoE if they perceive its rates as uncompetitive with going direct to a model provider. Implementing chargeback before the platform is sticky enough to be worth paying for tends to kill the CoE in its first budget cycle.
Hybrid funding is the model most APAC enterprises end up with by month twelve. The platform itself ā the model gateway, the observability stack, the evaluation framework ā is funded centrally as enterprise infrastructure. The variable consumption costs ā model API tokens, vector storage, agent runtime compute ā are charged back to the consuming BUs through the gateway’s per-team tagging. Enablement, templates, and reference implementations are funded centrally as well, because the marginal user does not increase their cost. Custom platform engineering work for a specific BU use case is project-funded by that BU.
The hybrid model preserves the CoE’s incentive to invest in capabilities that benefit every BU (it is funded for that work) while creating the BU-level discipline that prevents token spend from spiralling (they see the bill). It also gives the CFO a defensible view of what AI is costing and what it is returning. As a rule of thumb, year-one CoE setup costs land in the S$300,000 to S$600,000 range for a mid-market APAC enterprise with three to five initial use cases, with five to ten times return in productivity gains and risk avoidance becoming visible by year two for organisations that actually operate the platform rather than just stand it up.
Staffing the CoE: Roles, Levels, and the Hiring Sequence
A common mistake is to staff the CoE first with senior leadership and consultants and only later with engineers who actually build the platform. By the time the engineers join, the strategy is solidified, the platform is half-architected by a vendor, and the spokes have already started building around the CoE. Reverse the sequence.
The first three hires are an AI platform tech lead (a senior engineer with experience building LLM infrastructure at scale), a senior MLOps or AI platform engineer, and an AI governance lead (someone who can write standards in language that both engineers and regulators understand). These three people, with executive sponsorship, can start the platform build and produce the first version of the governance standards inside a quarter.
By month three the team adds an evaluation and quality lead, a second platform engineer focused on observability, and an enablement lead who can write reference implementations and run training. The CoE is now seven people including the head of CoE, and it can support three to five live AI use cases without becoming the bottleneck.
By month nine the team adds a portfolio and value realisation lead, a second governance specialist focused on sectoral regulation (financial services, healthcare, or whichever your dominant exposure is), and a specialist in agent identity and permissioning if your portfolio is moving in that direction. The CoE is now ten people, and the hub-and-spoke model is becoming viable.
Beyond ten people, additions should be tied to specific operational capability gaps the CoE has identified ā not to general headcount expansion. The hub-and-spoke model is what scales delivery; the hub is not.
Geographic and regulatory specifics matter for APAC hires. A Singapore CoE serving a regional bank with MAS and HKMA exposure needs governance staff who can speak fluently to both regulators. A Hong Kong CoE serving an insurance group needs IA and SFC familiarity. A Singapore CoE serving the Southeast Asia operations of a multinational needs IMDA’s Model AI Governance Framework as native vocabulary. The hiring difficulty is real; Singapore EDB and the Enterprise Compute Initiative are explicit about co-funding training because the local talent pool is thinner than the demand.
The Compliance Evidence Pack Your Sectoral Regulator Will Ask For
When MAS conducts a technology risk examination, when HKMA reviews your operational resilience, or when IMDA references the Model AI Governance Framework in a sectoral assessment, your CoE needs to produce documentation on demand. Build the evidence pack as you build the CoE, not after a notice arrives.
Portfolio inventory. The registry of every AI system in production, with owner, risk tier, data sensitivity, tool access, evaluation status, last review date, and incident history. The CoE produces this; the spokes maintain it. If you cannot produce this inventory inside one business day, you do not have a functioning CoE.
Risk profiles. A one-page risk profile per Tier 2 and Tier 3 system: the risk score, the worst-case outcome analysis, the risk acceptance decision and the name of the person who accepted it, the controls in place, and the residual risk.
Evaluation evidence. For every Tier 2 and above system, the test set used, the evaluation pass criteria, and the scores from the most recent evaluation. Version-controlled so the historical evaluation can be reproduced for any past deployment.
Audit logs. Action logs per system, retained for a minimum of three years for financial services systems (aligned with MAS Notice on Technology Risk Management), searchable by system ID, session ID, date range, and action type within a defined SLA. The CoE provides the schema, retention policy, and search infrastructure; the spokes integrate.
Human oversight evidence. For each human checkpoint type, records showing that human review actually occurred ā approver identity, timestamp, the context the approver had, and the decision made. Volume of checkpoints is not enough; regulators will assess whether the approver could have caught a real error.
Incident records. Every incident, near-miss, or unexpected behaviour, with the immediate response, root cause, and remediation. Regulators treat incident response maturity as a proxy for governance maturity.
Standards conformance evidence. The CoE’s standards (evaluation thresholds, log schemas, identity scoping rules) and the automated checks that confirm each production system conforms. This is what hub-and-spoke governance looks like when it works: not approvals, but auditable conformance.
For the technical implementation of one specific obligation that frequently shows up in this evidence pack, our EU AI Act Article 13 transparency guide covers the system card pipeline, event logging store, and disaggregated evaluation harness that a CoE typically builds once and reuses across every high-risk system in the portfolio.
A 12-Month Implementation Roadmap
You do not need three years to stand up a working CoE. You need a phased plan with clear gates between phases. The roadmap below assumes you are starting from scratch; if you already have an MLOps team or a GenAI tiger team, the early phases compress.
Phase 1: Charter and Foundation (Months 1ā3)
Land an executive sponsor at the C-suite or CTO direct-report level. Without that sponsor, the CoE cannot enforce standards on business units that outrank its head. Publish a CoE charter that names the four roles (platform, enablement, governance, portfolio measurement) and the explicit boundary of authority. Make the boundary specific: the CoE defines standards and operates the platform; deployment decisions sit with business unit owners against those standards.
Hire the first three roles ā platform tech lead, senior platform engineer, governance lead. Pick the initial three AI use cases to support: one that is high-visibility and likely to succeed (to demonstrate value), one that is moderate-risk and regulated (to prove the governance model works), and one that is internal-facing (to absorb the inevitable platform teething pains without customer-facing fallout).
Build the minimum platform: model gateway, basic prompt registry, observability with cost and latency telemetry, and a first version of the evaluation harness. Publish the first three governance standards: risk tiering, model approval criteria, audit log schema. By the end of month 3, the first internal-facing use case should be running on the platform.
Phase 2: First Production Use Case and Standards Enforcement (Months 4ā6)
Take the first high-visibility use case to production on the platform. The platform earns its first real load test, the governance standards meet their first real production system, and the evaluation harness produces the first set of evidence the executive team can reference. Add the evaluation and quality lead, the observability platform engineer, and the enablement lead.
Begin enablement work in parallel. The first two reference implementations (retrieval-augmented generation and document summarisation are the most common starting points) should ship by the end of month 6. Run office hours for the engineering teams that will become the first spokes. Publish the first version of the AI engineer onboarding curriculum.
By the end of month 6, the platform is supporting three use cases, the governance standards have produced their first audit-ready evidence pack, and at least one business unit team has started building on the platform without direct CoE delivery support. That last signal is the most important one in the phase.
Phase 3: Hub-and-Spoke Activation (Months 7ā9)
Move from centralised delivery to standards-based hub-and-spoke. Onboard the first two or three business unit AI teams as formal spokes. They build on the platform, conform to the standards, and ship without CoE approval gates. The CoE shifts capacity from delivery to enablement and audit.
Add the portfolio and value realisation lead. Begin producing the monthly portfolio report for the executive team: every system in production, the risk tier, the cost-to-run, the realised value, the upcoming work. The portfolio report is what makes AI legible to the executive team and turns scattered initiatives into a managed portfolio.
By the end of month 9, the platform is supporting at least six use cases, two or three of which are owned end-to-end by business unit spokes, and the CoE’s monthly portfolio report is part of the executive operating cadence.
Phase 4: Scale, Optimise, and Mature (Months 10ā12)
Expand to five or more spokes. Begin the cost optimisation work the observability stack now has a year of telemetry to inform. Token spend should be measurably falling per use case even as overall consumption rises. Begin the agent-specific extensions of the governance standards if your portfolio is moving toward agentic systems. We covered the technical implications in our AI agent sprawl enterprise security guide, which becomes directly relevant when your CoE’s standards have to cover agent identity and tool access.
Publish the year-one outcomes report: number of systems in production, total token spend, average evaluation pass rate, incident count and resolution time, BU adoption metrics, headline value realised. This is the evidence pack you take into the year-two budget conversation. Treat the year-two plan as a serious strategic exercise rather than a continuation of year one; the CoE’s job changes as the portfolio grows.
Common Failure Modes and How to Avoid Them
The same errors show up across APAC enterprises starting their AI CoE work. Recognise them early.
Designing the CoE as an approval body. If every AI deployment routes through a CoE approval committee, you have built a queue. The committee will become the constraint, and the spokes will route around it. Standards-based governance is the alternative: the CoE defines the standards, the spokes demonstrate conformance, the CoE audits.
Staffing seniority-first. A CoE that hires three executives and a consultant before its first engineer will produce a strategy deck before it produces a platform. By the time the engineers arrive, the architecture is half-decided and the platform is on the wrong stack.
Skipping observability. A CoE that ships a platform without telemetry will be unable to do cost optimisation, incident response, or value realisation. The same telemetry pays for itself three different ways; building it later costs three times more.
Building the registry from voluntary reporting. A registry that depends on BU teams volunteering their AI use cases will always be incomplete. Use platform telemetry, identity provider scans, SaaS OAuth audits, and engineering attestations together to produce a registry that reflects reality.
Funding the CoE entirely centrally past month twelve. If BUs perceive CoE capacity as free, demand will exceed any plausible supply. Move to hybrid funding once the platform is sticky enough to be worth paying for.
Outsourcing the platform to a single vendor. A platform built entirely by an external vendor will produce CoE dependency on that vendor for every change. Internal platform engineering capacity is the foundation; vendors are accelerants, not replacements.
Treating governance as documentation. Standards that live only in a wiki and an approval form do not govern anything. The standards have to be encoded in the platform ā the evaluation harness enforces the thresholds, the model gateway enforces the routing rules, the identity layer enforces the permissioning. Documentation is the artefact; the platform is the control.
Sequencing enablement last. A CoE that builds the platform but does not invest in enablement will become the only team that knows how to use the platform. The bottleneck is then permanent. Enablement starts in month 4 and never stops.
How Sthambh Helps APAC Enterprises Build AI Centres of Excellence
Sthambh works with CTOs, CDOs, and Heads of AI in Singapore, Hong Kong, the UK, and Southeast Asia to design and build AI Centres of Excellence that accelerate delivery rather than block it. We have stood up the platform layer, written the governance standards, built the evaluation harnesses, and operated the observability stacks that turn scattered AI experimentation into a managed portfolio.
Our work covers the full CoE build. We architect and build the platform ā model gateway with multi-provider routing, evaluation harness, observability stack with per-team cost telemetry, prompt and configuration registry, agent runtime with identity and permissioning. We write the governance standards in a form your CoE can enforce automatically, mapped to MAS, HKMA, IMDA, and EU AI Act obligations as relevant to your portfolio. We produce the reference implementations and onboarding curricula that turn the platform into something your business unit teams can adopt in days rather than quarters. And we build the portfolio management infrastructure that makes your AI activity legible to your executive team and your regulators.
For organisations with an existing GenAI tiger team or a pilot-stage AI program, our typical engagement starts with a four-week CoE design sprint: a current-state assessment of your AI portfolio, the operating model recommendation calibrated to your organisation’s size and regulatory exposure, the prioritised capability roadmap, the staffing plan, and the funding model. From there we partner on the platform build, the governance standards rollout, or the enablement program, depending on where the CoE’s capacity gaps are largest.
If you are evaluating whether your AI CoE is structured correctly, or you are about to commit to a year-one CoE build, book a 30-minute enterprise AI strategy call with our team. We will walk through your current AI portfolio, the operating model fit, and the highest-leverage move you can make in the next 90 days. Our broader agentic AI engineering work covers the technical foundations that make CoE governance enforceable at the platform layer.
FAQs
Q. How long does it take to stand up a functioning AI Centre of Excellence?
A. Six to twelve months to operating capability for most APAC enterprises starting from scratch. Months one to three produce the charter, the executive sponsor, the first three hires, and the minimum platform. Months four to six take the first use case to production. Months seven to nine activate the hub-and-spoke model with the first business unit spokes. By month twelve the CoE supports six or more use cases and produces the monthly portfolio report. Organisations that already have an MLOps team or a GenAI tiger team compress the early phases.
Q. What does an AI CoE cost in year one for a mid-market APAC enterprise?
A. Year-one setup costs typically land in the S$300,000 to S$600,000 range for a CoE supporting three to five initial use cases. The cost covers the first three to seven hires, the platform build (model gateway, observability, evaluation harness), the first round of governance standards, and the initial enablement work. Singapore’s Enterprise Compute Initiative co-funds significant portions of this for eligible mid-market companies through Oracle, Microsoft, Google, and AWS-administered programmes. Five to ten times return in productivity gains and risk avoidance becomes visible by year two for organisations that operate the platform rather than just stand it up.
Q. Should a Singapore or Hong Kong enterprise build a centralised, hub-and-spoke, or federated AI CoE?
A. Most APAC enterprises should start centralised for the first nine to twelve months and evolve to hub-and-spoke as the platform stabilises and business unit teams demonstrate they can build to the standards. Federated models suit conglomerate-scale organisations with genuinely distinct business unit domains and mature AI capability across them; for most mid-market and large enterprises in Singapore and Hong Kong, federation produces fragmentation faster than it produces agility. The hub-and-spoke endpoint is the dominant best practice for 2026.
Q. Does MAS or HKMA require a financial services firm to have an AI Centre of Excellence?
A. Neither regulator mandates an AI CoE as a specific organisational structure. Both regulators expect financial institutions to demonstrate effective governance, risk management, evaluation, and audit trails for every AI system in production, with particular attention to systems that affect customer outcomes or financial decisions. A CoE is the most defensible structure for producing the evidence MAS and HKMA examiners will request, but the structure is your choice; the evidence requirements are not. Singapore’s Model AI Governance Framework for Agentic AI and MAS’s existing TRM Notice and FEAT Principles together set the de facto bar.
Q. What is the right reporting line for the head of the AI CoE?
A. Direct reporting to the CTO, CIO, or CDO is the most common pattern in APAC enterprises in 2026. Reporting to the COO works when the CoE is tightly tied to operational use cases. Reporting to a Chief Data Officer works when the data foundation is the dominant constraint. Avoid reporting lines below the C-suite or one level beneath; the CoE has to set standards business units must follow, and that authority erodes if the head of CoE outranks no one.
Q. How is an AI Centre of Excellence different from a Data Science Centre of Excellence?
A. A Data Science CoE owns the analytical model lifecycle: feature engineering, model training, validation, deployment for predictive use cases. An AI CoE in 2026 covers a much wider scope: generative and agentic AI systems with their distinct platform requirements (model gateway, retrieval layer, agent runtime), distinct governance requirements (prompt management, tool permissioning, kill switches), and distinct cost dynamics (token economics rather than compute hours). Many organisations evolve their existing Data Science CoE into an AI CoE by adding the GenAI and agentic capabilities; others run them in parallel for one to two years before consolidating.
Q. How does an AI CoE work with existing security, risk, and compliance teams?
A. The AI CoE owns the AI-specific controls: model approval criteria, evaluation thresholds, prompt and configuration management, agent identity scoping, audit log schemas. Security and risk teams own the enterprise controls those AI controls plug into: identity provider integration, network segmentation, data classification, incident response, third-party risk management. Compliance teams own the regulatory interpretation that turns into the CoE’s standards. A clean working model is for the CoE to publish standards quarterly, the security and risk teams to validate them against enterprise controls, and the compliance team to maintain the regulatory mapping. Joint review of new use cases happens at risk tier 2 and above.
Nikhil Khandelwal
Co-founder & CTO, Sthambh
