Centralized or embedded? How banks organize their AI teams

Author: acceleraid Editorial Team

HSBC announces a Global AI Centre of Excellence in Singapore with more than 100 AI specialists for the second half of 2026. The center is intended to work with the Chief AI Officer as well as the Wealth Management and Global Payments Solutions divisions; the focus is on customer conversations, treasury solutions, and digital payments, among other things. The step shows: The decisive question is no longer whether a bank tests AI, but how it organizes responsibility, platforms, and expertise so that robust products emerge from individual projects. HSBC

How this organizational question manifests in Customer Lifecycle Management is shown in our article on the Operating Model for CLM in Banks. Why this capability should be thought of as continuous modernization rather than a one-time transformation program is explained in the simultaneously published article on the AI-native Bank.

The Operating Model is a System for Decisions

“Centralized or embedded?” is the wrong shorthand for the debate. An operating model defines who prioritizes a use case, who is responsible for data and models, who defines controls, who grants approval, and who measures the business impact. Only these decisions make AI repeatable.

A centralized approach bundles scarce expertise, technical standards, and control mechanisms. An embedded approach brings data expertise and product ownership closer to customer situations, processes, and business decisions. A bank needs both. However, it should not build both for the same tasks at the same time. Duplicate platforms, parallel model reviews, and divergent supplier decisions create costs and complicate traceability.

The sensible dividing line, therefore, does not run along an organizational chart, but along the reusability and risk of a decision. What many units require identically or what has a major impact belongs in a common core. What only works with current domain knowledge and fast feedback loops belongs in the business units.

What Practice Shows About Centralized and Federated Models

The data does not support a permanently rigid model. In a McKinsey survey of 16 financial institutions, four archetypes were almost equally distributed: highly centralized and highly decentralized were around one-fifth each, with the two mixed forms around three-tenths each. At the same time, about 70% of institutions with a highly centralized approach had GenAI use cases in production, compared to around 30% for a fully decentralized approach. McKinsey therefore expects a movement from initial centralization to federated structures; risk management, architecture, partner decisions, and standard-setting will primarily remain permanently centralized. McKinsey

ING stands for the benefit of a centrally managed start: according to Computer Weekly, 90% of their AI pilots go live, compared to an cited industry average of 30%. The bank combines centralization with a shared platform, central guardrails, and real-time monitoring, but maintains the connection to the business units. This is not evidence that every bank should copy an identical model. It is an indication that a shared delivery and control environment can close the gap between pilot and operations. Computer Weekly

DBS explicitly chooses a federated model: a CoE forms the core, cross-functional squads work from there into the business units, and data scientists are embedded in the squads. The bank reports that the time to deployment was reduced from about 18 months to four to five months. The key factor here is not the number of committees, but the combination of centrally provided specialists, shared enablement, and clear accountability in the squad. DBS

A Resilient Division of Labor: Core, Domain, Joint Handovers

A simple rule helps with concrete design: Centralize when the object is reusable, regulatory-relevant, or can only be operated economically once. Embed when the quality of the decision depends on the process context, local customer feedback, or a specific business outcome.

The central core is not an ordering service for models. It provides capabilities as a product: a certified development environment, reusable interfaces, rules for data access, documentation, and monitoring. To do this, it needs a transparent service promise to the business units: Which building blocks are available, what criteria are used for prioritization, and when can a team transition from an experiment to regular operations?

The business units, on the other hand, must not simply deliver requirements. They designate a responsible person for the business impact, define the permissible scope of action, and organize feedback from the process. Especially with customer-facing AI applications, the business unit must be clear about when a result is automatically implemented, when it is reviewed, and when it is discarded. This keeps business responsibility where the consequences of a decision become visible.

Governance is Not a Central Repository

With the current timeline of the EU AI Act, this division of labor is not optional. Since August 2, 2026, the remaining part of the regulation applies, with the exception to Article 6 Paragraph 1 mentioned in the timeline. Annex III fundamentally classifies AI for assessing the creditworthiness of natural persons or for determining a credit score as high-risk; AI for detecting financial fraud is exempted there. This classification does not replace legal advice, but it makes clear why model ownership must not disappear between the data team and the business unit. EU AI Act Implementation Timeline EU AI Act, Annex III

For each productive solution, four roles should therefore be designated by name: business outcome ownership, technical system ownership, an independent challenge function, and an instance with approval or escalation rights. Centralization can standardize these roles; however, it must not anonymize them. The business side remains responsible for the purpose, impact, and process in which the system is used.

The ECB banking supervision points to typical gaps precisely here: clear accountability for AI decisions, oversight by senior management, and robust challenge mechanisms by risk, compliance, and internal audit. It also refers to explainability, governance over the model lifecycle, data quality, bias, as well as concentration and lock-in risks. A good operating model treats these points as design requirements for every use case – not as a review shortly before go-live. ECB Banking Supervision

A Starting Point for the Next Decisions

Instead of announcing a reorganization all at once, banks can test their target model on a prioritized portfolio. First, a central minimum standard for the platform, risk, and model inventory is established. Then, a few business-owned use cases are assigned clearly defined product teams. Subsequently, the handovers are measured: How quickly is data access resolved, how often is an approval reworked, which insights are reused as standards? Only then is it worth expanding responsibilities or capacities.

Three questions are particularly useful for the portfolio decision. First: Does the value come from a reusable capability or from unique process knowledge? Second: Which decision would affect the most customers or control functions in the event of an error? Third: Who can actually assess the quality in ongoing operations? The answers often result in a hybrid model – and prevent "federated" from becoming just another word for uncoordinated individual projects.

A platform approach can reduce the repetitive specialized work per use case if data access, governance, and decision logic are available as shared building blocks. According to its own statement, Acceleraid combines CDP and data governance functions, a prediction engine, as well as orchestration for Customer Lifecycle Management; the platform is designed to be model-agnostic. For banks, this is primarily relevant if they want to enable business teams without resolving platform and control questions anew for every use case. Acceleraid Platform

The measure of success is therefore not the size of a CoE nor the number of embedded data scientists. Success occurs when a shared core enables secure reuse and the business units remain responsible for real business decisions. This is the organizational prerequisite for AI to go into production faster without responsibility being lost as pace scales up.

Illustration: AI-generated. AI-supported content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, editorial direction, and final approval remain with our team.