Fashion brands chasing AI-powered forecasting, personalisation, and product development are running into the same wall: their data is trapped inside systems that were never designed to talk to each other, let alone to a large language model. The question is not whether to adopt AI — that debate is settled. The question is whether you bolt it onto what you have, or build on a foundation that can actually carry the load.
Key takeaways
- Layering AI onto legacy PLM or ERP creates hidden maintenance costs that compound over time, a pattern well-documented in machine learning engineering research.
- Brands that built unified data platforms before adding AI report structural advantages their competitors cannot replicate quickly.
- Most enterprise AI adoption remains narrow: the majority of firms using AI integrate it in three or fewer business functions, limiting the returns.
- The 'AI-sprinkle' approach — adding a generative AI module to an existing SaaS stack — is a different strategic bet from rebuilding on an AI-native architecture, and the costs of each path are rarely compared honestly.
- PLM vendors are adding AI features, but the underlying data model matters as much as the feature list.
What does 'AI-native' actually mean in a fashion context?
The phrase 'AI-native, not AI-sprinkle' has been circulating in venture capital commentary, and it captures a real distinction. An AI-native architecture is one where the data model, the API surface, and the workflow logic were designed from the start to be consumed by machine learning pipelines and generative models. An AI-sprinkle approach takes an existing product — a PLM, an ERP, a merchandising suite — and adds a generative AI module on top, often via a third-party API call inserted between existing screens.
For a fashion brand, the difference shows up in three places: data freshness, data shape, and feedback loops.
Data freshness. Legacy systems were built for batch processing. Nightly syncs, weekly exports, quarterly data warehouse refreshes. AI models — especially those driving demand forecasting or dynamic pricing — need signals that are hours or minutes old, not days. Bridging that gap requires custom ETL pipelines that become their own maintenance burden.
Data shape. A PLM built in the early 2000s stores product attributes in ways that made sense for a spreadsheet-era workflow: flat tables, coded fields, free-text notes. Feeding that into a modern embedding model or a retrieval-augmented generation system requires transformation layers that are fragile and expensive to maintain.
Feedback loops. When an AI recommendation turns out to be wrong — a trend call that missed, a size curve that did not fit the actual customer — a native architecture can route that signal back into the model. A bolted-on module usually cannot: the feedback has nowhere to go except a human's inbox.
What does the technical debt actually look like?
The concept of technical debt in machine learning systems is not new. Research published as part of the Advances in Neural Information Processing Systems proceedings identified a specific set of ML system anti-patterns — boundary erosion, entanglement, hidden feedback loops, undeclared consumers, and data dependencies — that create 'massive ongoing maintenance costs in real-world ML systems.' Every one of those anti-patterns is easier to accumulate when you are grafting AI onto a legacy stack than when you are building with AI as a first-class concern.
For a fashion brand, this translates into concrete line items:
- Integration engineering. Someone has to build and maintain the connectors between your PLM, your ERP, your e-commerce platform, and your AI layer. That team does not ship product features; it keeps the pipes from leaking.
- Data governance overhead. Legacy systems often have inconsistent master data — the same supplier coded three different ways, size labels that changed across seasons. Cleaning that before it reaches an AI model is a project, not a task.
- Model drift management. When the upstream system changes — a new field, a renamed category, a supplier onboarding — the AI layer breaks in ways that are hard to detect until a forecast is already wrong.
- Shadow IT proliferation. When the official system cannot support an AI use case, teams build their own workarounds: spreadsheets fed into ChatGPT, unofficial Python scripts, departmental data exports. These are invisible to IT and impossible to govern.
Where are fashion brands actually integrating AI today?
The honest answer is: narrowly. A US Census Bureau working paper on AI diffusion across firms found that among companies that have adopted AI, 57% use it in three or fewer business functions, with sales and marketing, strategy, and IT leading the list. Writing, document analysis, and information search are the dominant generative AI tasks. The research also found a robust positive correlation between the breadth of AI integration and commercial performance — meaning the brands getting the most from AI are the ones that have spread it widest, not just deepest in one function.
In fashion specifically, the functions where AI integration is most mature are demand forecasting, trend signal aggregation, and copywriting. The functions where it is most nascent — and where the architecture gap bites hardest — are product development, supplier collaboration, and end-to-end traceability.
What does a modern data platform foundation look like?
The alternative to the integration treadmill is a unified data and AI platform that sits beneath your applications rather than beside them. Databricks is the clearest example of this category: a lakehouse architecture that combines data storage, transformation, and AI model serving in a single governed environment. Instead of moving data between systems, you bring your applications to the data. Forecasting models, PLM workflows, and supplier portals all read from and write to the same source of truth.
This is not a simple migration. Moving from a legacy stack to a lakehouse-first architecture typically takes years and requires retraining teams, renegotiating vendor contracts, and accepting a period of running parallel systems. But the brands that completed that transition earlier are now compounding the advantage.
Zalando is the most-cited example in European fashion. In its full-year 2025 results published in March 2026, the company described its data and infrastructure platform — built over 17 years — as a 'massive advantage,' citing billions of customer interactions and what it called the continent's leading fashion-specific data asset. The point is not that Zalando is uniquely talented; it is that they started building the foundation before the AI moment arrived, and that head start is now structural.
What about PLM vendors — are they closing the gap?
The two PLM platforms most widely deployed at mid-to-large fashion brands are Centric PLM — now part of Dassault Systèmes and expanding its suite through acquisitions including a product experience management platform — and PTC FlexPLM, which has been adding AI-powered capabilities including tech pack creation features announced at the National Retail Federation's annual show in early 2026.
Both are adding AI features, and both are doing so on top of data models that predate the current AI wave. That is not a criticism — it is a constraint that applies to every enterprise software vendor with a large installed base. The question a CIO should ask is not 'does this PLM have an AI feature?' but 'where does the AI model actually read from, and can I audit that data pipeline?'
Centric PLM's direction — building an end-to-end suite that spans PLM, planning, pricing, and product experience management — is one answer to the fragmentation problem: fewer systems means fewer integration seams. PTC FlexPLM's answer is deeper AI tooling within the existing PLM workflow. Neither is wrong; the right choice depends on how much of your stack you are willing to consolidate versus how much you need to preserve.
What both approaches share is a dependency on the quality of the data already in the system. If your PLM contains five years of inconsistently entered tech packs, adding an AI layer on top does not fix the underlying data quality problem — it amplifies it.
The replatforming decision: a framework for CIOs
There is no universal answer to 'should we replatform?' but there are questions that sharpen the decision:
-
How old is your data model? If your PLM or ERP was implemented more than ten years ago, the data model almost certainly predates the assumptions that modern AI systems need. Assess what it would take to expose clean, real-time data from that system — not just a nightly export.
-
How many integration points do you maintain? Count the custom connectors, the ETL jobs, the middleware layers. Each one is a maintenance liability and a potential point of failure for any AI layer you add above it.
-
Where is your AI producing value today? If the answer is only in marketing copy and image generation, your architecture gap has not yet become visible. If you are trying to use AI for demand forecasting, product development, or supplier risk, the gap will surface quickly.
-
What is your tolerance for parallel running? Any serious replatforming requires running old and new systems simultaneously for a period. That is expensive and disruptive. Factor it into the true cost of modernisation, not just the licensing cost of the new platform.
-
Do you own your data? This sounds obvious, but many brands discover during a migration that their most valuable historical data is locked inside a vendor's proprietary format, accessible only through that vendor's API on that vendor's terms.
The honest cost comparison
The 'AI-sprinkle' path has a lower upfront cost and a faster time to a demo. It also has a higher ongoing cost in integration engineering, data cleaning, and model maintenance — costs that are diffuse, hard to attribute, and therefore easy to undercount.
The AI-native or replatforming path has a higher upfront cost and a longer time to value. It also has a lower ongoing maintenance burden and a compounding advantage as the data asset grows.
Neither path is free. The architecture gap is not a technology problem with a technology solution — it is a strategic choice about where you want your cost curve to be in three to five years. The brands making that choice explicitly, with full visibility into both sides of the ledger, are the ones most likely to be satisfied with the outcome.
FAQ
What is the difference between AI-native and AI-sprinkle in fashion software? AI-native means the data model and workflow were designed from the start for machine learning. AI-sprinkle means a generative AI module has been added to an existing system. The practical difference is in data freshness, data shape, and whether AI outputs can feed back into the system automatically.
How much does it cost to add AI to a legacy PLM? The licensing cost of an AI module is only part of the picture. Integration engineering, data cleaning, and ongoing model maintenance add significant ongoing costs that are hard to attribute to a single budget line. Firms that have measured total cost of ownership typically find the integration work exceeds the software cost.
Are Centric PLM and PTC FlexPLM AI-native? Both are established PLM platforms that are adding AI-powered features to existing architectures. Centric PLM, part of Dassault Systèmes, is expanding toward an end-to-end suite. PTC FlexPLM has announced AI-powered tech pack capabilities. Neither was built from scratch as an AI-native system, which is a constraint shared by every enterprise PLM with a large installed base.
What is a data lakehouse and why does it matter for fashion AI? A lakehouse combines the storage scale of a data lake with the governance and query capabilities of a data warehouse, and adds a model-serving layer. For fashion, it means forecasting models, PLM data, and customer signals can all live in one governed environment rather than being copied between systems — reducing the integration debt that makes AI brittle.
How long does an AI replatforming project take for a mid-size fashion brand? Brands that have gone through full data platform migrations typically report two to four years from initial architecture decision to decommissioning the last legacy system. Running parallel systems during that period is expensive but necessary to avoid operational disruption.
Further reading
- Hidden Technical Debt in Machine Learning Systems
- AI-Native, Not AI-Sprinkle: Why AI Is A Business Change, Not A Technology Change
- The Microstructure of AI Diffusion: Evidence from Firms, Business Functions, and Worker Tasks