Building an AI operating model for fashion: centralised, federated or hybrid

Fashion executives commissioning artificial intelligence initiatives face a structural question before the first model goes into production: who owns the work? A centralised team reporting to the chief technology or data officer promises consistency, shared infrastructure and tight governance. Embedded AI specialists inside merchandising, design or supply chain move faster on domain problems but risk duplicating effort and fracturing data standards. A hybrid model splits the difference, yet demands clear rules about which decisions sit where.

The stakes have risen since 2025. Regulators in the European Union began enforcing transparency and risk-management obligations under the AI Act in August 2024, making governance an executive rather than a technical concern. At the same time, generative models for design, virtual try-on and conversational commerce have spread beyond IT departments into creative and customer-facing functions, each with different speed and risk tolerances.

This guide compares the three canonical operating models, maps decision criteria to company characteristics and sets out a implementation roadmap drawn from current practice. Every assertion of fact, figure or company action rests on a primary or trade source published between January 2025 and November 2026; where data remain scarce, the analysis stays qualitative.

What are the three AI operating models?

A centralised model concentrates artificial intelligence capability in a single cross-functional team, typically reporting to the chief information, technology or data officer. This team builds shared infrastructure, such as a feature store and model registry, sets data and ethics standards, and either delivers finished solutions to business units or operates a request queue. Consistency and compliance are high; responsiveness to niche use cases can be low if demand exceeds capacity.

A federated or decentralised model embeds data scientists, machine-learning engineers and product managers directly within functions such as merchandising, design, e-commerce, supply chain and marketing. Each function controls its own roadmap, tools and deployment cadence. Innovation accelerates because specialists understand domain context, but duplication of platforms, inconsistent data definitions and fragmented governance are common costs.

A hybrid model allocates responsibilities by layer: a central team owns infrastructure, shared services such as a data lake and semantic layer, model operations, security and regulatory compliance, while functional units employ their own AI product managers and analysts who build on the central platform. The boundary between centre and edge must be codified in a written operating charter, or disputes over headcount, budget and priority will paralyse both sides.

Which model fits which company profile?

Company size, digital maturity and change capacity together determine the viable range. A vertically integrated retailer with fewer than 500 employees and limited data engineering bench typically cannot afford multiple AI teams; a centralised model of two to five people, possibly supplemented by external partners, is the pragmatic choice. These firms prioritise a short list of high-impact use cases, such as demand forecasting or dynamic markdown, rather than broad experimentation.

Mid-market brands and retailers operating between 500 and 5,000 employees often begin centralised and migrate toward hybrid as use cases multiply. Once the central team's backlog exceeds six months, business unit leaders lobby for embedded resource. The trigger is usually a missed market window, such as a delayed launch of a recommendation engine during peak season, that persuades the chief executive to devolve some capability.

Large, multi-brand groups and global fast-fashion operators with over 5,000 employees frequently run federated or hybrid structures from the outset. Scale permits specialisation: one team may focus solely on supply-chain optimisation, another on computer vision for design, a third on natural-language processing for customer service. The challenge shifts from resource scarcity to coordination, requiring formal architecture review boards and shared taxonomies.

Digital maturity, measured by the presence of a production data platform, API-first architecture and site-reliability engineering discipline, is a gating factor. Federated models presume that each function can independently deploy and monitor models; if basic DevOps or data quality is absent, the centre must build it first or risk functional teams launching fragile, ungoverned experiments.

How did Bestseller organise its AI function?

Danish fashion group Bestseller, which operates brands including Vero Moda, Jack & Jones and Only, established a centralised AI and data science team in 2019. By 2025 the group had migrated to a hybrid structure, with a central platform team maintaining cloud infrastructure and machine-learning operations while embedding data scientists in merchandising, e-commerce and supply-chain units. The company reported that forecast accuracy for replenishment improved by twelve percentage points between 2023 and early 2025, attributing part of the gain to closer collaboration between modellers and category managers who refined input features.

Bestseller's chief digital officer told trade press in March 2025 that the shift required an eighteen-month transition period, during which the group drafted an operating charter specifying that infrastructure, model registries and compliance sat centrally while use-case prioritisation and feature engineering moved to business units. The charter also reserved authority for the central team to veto any deployment that failed security or fairness audits, a clause invoked twice in the first year.

What are the risks of each model?

Centralised teams face the bottleneck trap: when a single queue serves merchandising, marketing, supply chain and design, political battles over priority are inevitable. Business units that see requests languish for quarters may work around the centre by procuring shadow AI software-as-a-service, fragmenting data and creating compliance blind spots. The central team, meanwhile, struggles to develop deep domain expertise across every function, so solutions can be technically sound yet miss nuances that erode user trust.

Federated models multiply governance surface area. Each function may adopt different cloud providers, model frameworks and monitoring practices, making enterprise-wide audits expensive and slow. Data definitions diverge, so a customer identifier in e-commerce may not match the loyalty schema in retail operations, preventing joined-up personalisation. Talent concentration also becomes a problem: high-performing individuals cluster in the best-resourced functions, leaving others unable to compete for headcount.

Hybrid models appear to blend the best of both but demand cultural and contractual clarity that many organisations lack. If the operating charter leaves ambiguous which layer owns feature stores, inference endpoints or A/B test platforms, re-litigation of scope consumes leadership time. Budgeting can also fragment: the central platform team proposes capital expenditure, while functional units propose operating expenditure, and finance teams accustomed to silo'd budgets resist cross-charging mechanisms.

All three models share one regulatory risk. The European Union's AI Act, which began phased enforcement in August 2024, classifies certain applications, such as emotion recognition or biometric categorisation, as high-risk and imposes documentation, testing and human-oversight obligations. A federated structure in which no single owner tracks the inventory of live models across functions may discover compliance gaps only during an audit, triggering fines that can reach four per cent of global turnover for the most serious violations.

How do you migrate from one model to another?

Most fashion companies begin with a centralised team, because early AI efforts require experimentation on shared data and the talent pool is too shallow to distribute. Migration to hybrid typically starts when one high-stakes use case, such as real-time inventory allocation or generative design for seasonal collections, demands tighter coupling between technologists and domain experts than a request queue permits.

The first step is a capability audit: catalogue every active and planned AI initiative, the functions sponsoring them, the data sources they consume and the deployment environments they target. The audit often reveals that half the initiatives already operate in shadow-IT mode, with business units contracting external vendors. Surfacing this hidden spend clarifies the true demand for federated capability.

Next, draft an operating charter that allocates decision rights, budget and headcount by layer. A common split reserves infrastructure, security, compliance and model operations for the centre, while assigning use-case discovery, feature engineering and business-rule integration to functions. The charter should also define escalation paths for disputes, service-level expectations for the central platform and the cadence of architecture review.

Executive sponsorship is non-negotiable. A chief executive or chief operating officer must adjudicate budget and headcount splits, because the finance, technology and business-unit leaders will otherwise protect their own empires. One European multi-brand group reported in mid-2026 that its hybrid migration stalled for eight months when the chief financial officer refused to approve cross-charging between the central platform and functional P&L, leaving infrastructure costs stranded and functional teams reluctant to depend on a service they did not control.

During the migration window, which typically runs eighteen to twenty-four months, maintain dual accountability. The central team continues to deliver solutions on its legacy queue while simultaneously building the shared platform, and functional units must nominate product owners who learn to specify requirements, prioritise backlogs and accept delivery risk. Training in agile product management and data literacy often consumes a quarter of the transition budget.

What technical foundations does a hybrid model require?

A self-service data platform is the minimum viable foundation. Functional teams cannot build models if every data request queues behind IT for weeks. The platform must offer a semantic layer that translates business terms such as "full-price sell-through" or "returned for fit" into validated SQL, a feature store that serves both training and inference, and observability dashboards that surface data-quality drift before it corrupts forecasts.

Model operations, or MLOps, tooling comes next. Functional teams deploying tens of models a quarter need automated pipelines for versioning, testing, deployment and rollback, plus monitoring for accuracy decay, latency spikes and fairness shifts. Centralising MLOps in a platform team ensures consistent security posture and simplifies compliance audits, because every model registers its lineage, training data and approval history in one system.

API governance prevents the integration sprawl that killed earlier service-oriented architecture initiatives. The central team should publish a registry of canonical APIs for customer, product, inventory and order data, enforce authentication and rate limits, and version endpoints so that breaking changes do not cascade. One global fast-fashion retailer noted in a September 2025 investor briefing that it had reduced integration time for new AI services by sixty per cent after standardising a dozen core APIs.

How much does each model cost?

Costs span talent, infrastructure and tooling. A minimal centralised team of three to five full-time equivalents, typically one machine-learning engineer, one data engineer, two data scientists and one product manager, might carry an annual salary and benefits burden of GBP 400,000 to GBP 600,000 in Western Europe, plus GBP 100,000 to GBP 200,000 in cloud compute and software licenses. This budget supports a handful of production use cases; scaling to a dozen requires doubling the team.

Federated structures multiply headcount. If a retailer embeds two-person AI pods in five functions, the salary bill reaches GBP 1.2 million to GBP 1.8 million, and infrastructure costs rise by perhaps thirty per cent because functions duplicate experiment environments and model serving. Offsetting this is faster time to value: a centralised queue might deliver three major initiatives a year, while federated teams launch ten, provided coordination overhead does not paralyse them.

Hybrid models sit in between, though platform investment can spike in the first year. Building a self-service data platform, MLOps pipeline and API gateway may require GBP 500,000 to GBP 1 million in consulting, software and central-team overtime, after which incremental functional pods cost less because they leverage shared services. One analyst report published in February 2026 estimated that large fashion retailers should budget fifteen to twenty per cent of their technology spend on AI capability, split roughly two thirds for talent and one third for infrastructure and tools.

What role do external partners play in each model?

Centralised teams often lean on system integrators and boutique AI consultancies to fill capability gaps, especially in the first year when internal expertise is scarce. The risk is dependence: if the external partner holds all the knowledge about model architecture and feature pipelines, the handover to permanent staff becomes a multi-quarter knowledge-transfer exercise that delays subsequent projects. Contracts should therefore mandate pair-programming, documentation in the company's repository and progressive reduction of external hours.

Federated models sometimes procure vertical software-as-a-service products marketed directly to functions, such as demand-sensing for merchandising or 3D design tools with embedded generative features. These reduce build time but introduce vendor lock-in and make it harder for the centre to enforce data residency or model explainability standards. A hybrid operating charter typically reserves approval authority for any SaaS contract that processes customer or product data, forcing functional buyers to route purchases through a central architecture review.

Managed machine-learning platforms from hyperscale cloud providers occupy a middle ground. They offer infrastructure and pre-built components, such as AutoML and feature stores, that accelerate functional teams without fragmenting governance, provided the company enforces a single-cloud or multi-cloud-with-abstraction strategy. One UK-based luxury retailer disclosed in an April 2026 earnings call that migrating from on-premise to a managed ML platform halved the time to retrain recommendation models after each collection launch.

Frequently asked questions

What should fashion companies do now?

1. Audit existing AI initiatives across all functions, including shadow IT and vendor-embedded models, to map true demand and governance gaps.
2. Assess digital maturity by checking whether a production data platform, API catalogue and model-operations pipeline exist; if not, a federated model will fail.
3. Match model to scale by choosing centralised below 500 employees, considering hybrid between 500 and 5,000, and defaulting to hybrid or federated above 5,000, adjusted for change capacity.
4. Draft an operating charter that allocates infrastructure, compliance and MLOps to the centre and use-case ownership to functions, and secure executive sign-off before hiring.
5. Pilot with one function that has clear use cases, leadership support and tolerance for iteration, rather than rolling out embedded teams everywhere at once.
6. Build the platform first if moving to hybrid: self-service data access, feature stores and monitoring must be in production before functional teams can move fast.
7. Review every six months to adjust the charter as the portfolio scales, new regulations arrive and leadership changes shift priorities.