Enterprise AI architecture: Why most projects fail at the start

Jul 2, 2026 • 9 min

According to RAND Corporation, 80.3% of AI projects fail to deliver intended business value. Most of those failures trace back to the same place: architecture.

A poor infrastructure decision with conventional software creates technical debt (i.e., taking a shortcut in the present that only creates more work later). A poor infrastructure decision with AI creates technical debt that grows while the organization carries it, because the system is learning from the wrong foundation every day.

Good AI architecture is a foundation that’s already learned the domain, so every capability you add compounds on proven ground. Bad architecture makes you rebuild that ground first — and learn its gaps the hard way.

The top reasons enterprise AI stalls

The same patterns appear across industries and revenue bands when AI investments underdeliver. They are worth naming precisely, because they are all addressable, but only before an organization has committed to an approach that locks them in.

An illustration of four puzzle pieces positioned around a red circle with an X in the middle.] — **Fig 1**: The four patterns that reliably turn AI spend into architectural debt are opacity, generic models, siloed data, and fragmented investment.

A lack of transparency and accountability

When AI tools forego transparency, they create a governance problem: When an autonomous decision goes wrong, someone should own the outcome.

If a system recommends cutting safety stock on a high-velocity SKU ahead of peak season but doesn’t explain why, planners will override it. And they should. But if the logic is locked away in an AI black box, adequate oversight is impossible to demonstrate. When AI logic is opaque, planners can’t trust it, regulators can’t audit it, and the organization loses the ability to scale autonomous decision-making with confidence.

This is becoming a compliance problem as the EU AI Act raises the bar on explainability for automated decisions. Organizations should not act on AI recommendations at scale unless they can see the reasoning, intervene when something looks wrong, and reverse a decision after the fact.

Generic AI applied to domain-specific problems

A generic AI model only learns from one organization, so it can’t tell normal from abnormal. That judgment only comes from data across many operations.

The forecasting logic, replenishment constraints, and promotional dynamics that define supply chain planning take years to model correctly and require data from hundreds of comparable deployments to stay accurate.

But a general-purpose AI model works from whatever data the individual organization can provide — one company’s transaction history, one set of supplier relationships, one market’s seasonal patterns. It has no frame of reference for whether a promotional lift or replenishment constraint is standard or unusual.

Take a food retailer selling their own private label lines. In a store carrying many brands, a shopper faced with a stockout just picks a competitor’s version. But the private label retailer doesn’t have an equivalent on the shelf, so they lose the sale and may also lose the customer’s loyalty.

In a situation like this, every replenishment decision carries more weight. A generic AI model using transaction history from a retailer that carries many brands of each product won’t have any frame of reference for whether a given stockout risk is unusual or routine. But purpose-built planning logic, trained on hundreds of comparable operations, can flag the situation appropriately.

The data isn’t operationally ready

Most large organizations have data spread across ERP, WMS, POS, supplier portals, and pricing engines that were never designed to work together. Product hierarchies don’t match across systems, supplier records exist in multiple formats, and location data means something different in the replenishment system than in the space planning tool.

These issues rarely surface at the start of a project. They instead appear six to nine months into a deployment, once the model is in contact with real production data. At this point, the organization faces a data engineering project that wasn’t in the original scope.

Investments don’t stack

Most AI initiatives are scoped, funded, and built as independent projects on different timelines with different data pipelines. The forecasting model doesn’t know what the pricing model is doing. The replenishment logic isn’t informed by the promotional calendar.

It’s the opposite of Integrated Business Planning (IBP). Each new initiative starts from scratch, solving the same infrastructure problems before it can address the actual business problem. As the portfolio grows, so does the cost of maintaining it.

Governance is retrofitted, not designed proactively

Governance gets scoped out of AI projects because it feels like overhead. By the time governance gets added, the architecture has already been built around assumptions that make governance difficult to add.

The result can fail in two ways:

Automation runs without adequate oversight and generates errors that damage confidence in the entire AI program (so adoption stalls and fails to scale).
The organization installs so many manual checkpoints that the efficiency gains disappear.

As mentioned above, the EU AI Act and NIST’s AI Risk Management Framework are raising the bar on explainability and human oversight. Organizations that designed governance from the start are already aligned. Those that didn’t face a costly rebuild.

Focus on the foundation, not “build vs. Buy”

The “build-vs.-buy” debate produces no answer that actually works. Internal builds underestimate scope: The operational data model, domain logic, and integration layer across ERP, WMS, POS, and supplier systems must be built before the model can work reliably. Closed vendor relationships carry the opposite problem: Planning capability advances at the vendor’s pace, against a roadmap built for the majority of their customer base. Business-specific requirements go into a feature request queue. Some get built, many don’t, and most take longer than the business needs.

AI tools compress the time to write code, not the time to acquire domain knowledge or validate logic against production outcomes at scale. A team that stands up a demand forecasting model in weeks has reached the starting line faster, not crossed the finish line.

The better question is: What foundation does the organization need to deliver ROI, and how much of it already exists?

An illustration of a scale with a gear on one platform and a shopping cart on the other. — **Fig 2**: To solve the vendor challenge, it’s important to first assess what the foundation can support and what it needs.

The RELEX 3-stage maturity model for AI architecture

The organizations pulling ahead have stopped treating the AI platform decision as binary. The RELEX platform is built around a three-stage maturity model.

1. Deploy

Deploy starts on a foundation that captures the learning of everyone who came before, whereas an internal build only learns from one organization.

A purpose-built planning platform brings structured and connected operational data models on day one, including products, locations, hierarchies, supplier constraints, lead times, pricing zones, and promotional overlays. The time that would have been spent building the foundation, instead gets spent on configuration and adoption.

Domain logic across forecasting, replenishment, merchandising, and promotions has been validated across hundreds of deployments and is continuously refined against real production outcomes. And it keeps improving, with every refinement and corrected edge case flowing back to the whole customer base.

An illustration of a UI window and a toggle below. — **Fig 3**: Real-time planning intelligence only creates value if every agent in the architecture can actually reach it.

2. Connect

Connect makes planning intelligence available to every agent in the architecture in real time. When data is locked inside a system that can’t share it, agents make decisions with an incomplete picture. But through MCP and standard API connectors, every agent can reach the planning data needed to make good decisions, including demand signals, inventory positions, and replenishment recommendations.

A procurement agent can query current replenishment recommendations before placing an order. A pricing agent can check the promotional calendar before adjusting a price. Gartner projects that 40% of enterprise applications will include task-specific agents by end of 2026, up from under 5% a year ago.

An illustration of a cloud with the letters, API, in the middle. Below is a toggle — **Fig 4**: Open protocols turn planning data from a silo into shared infrastructure every agent can act on.

3. Extend

Extend lets engineers build capabilities specific to unique business needs on a foundation that’s already proven.

Every organization has problems specific to their business — routing logic tied to a particular distribution network, supplier risk scoring that reflects a specific category’s dynamics. No packaged solution covers all of them, and building from scratch means spending the first year on infrastructure before the actual problem can be addressed.

But when engineers build on a proven platform, they inherit the operational data model, security controls, audit trail, and access governance from day one. They work on the actual differentiating problem: the supplier risk monitor that automatically adjusts safety stock based on disruption signals, the dock scheduling logic that optimizes truck arrivals against warehouse capacity. Those capabilities compound and are genuinely hard for competitors to replicate.

**Fig 5**: Unlike conventional software, AI systems learn from what they’re built on. The foundation choice determines the trajectory.

The real choice: build on the right foundation or keep rebuilding the wrong one

Over the next few years, the competitive advantage won’t go to the companies that adopted AI and the companies that didn’t. It will go to those that built on the right foundation and those still rebuilding the wrong one.

**Fig 6:** The capability gap between organizations that got the foundation right and those that didn’t widens every day.

And the window to choose is narrow. Boards expect measurable AI ROI within 12 to 18 months. The decision that remains is whether the investment is on infrastructure that will compound or infrastructure that will constrain.

Explore how leading retailers, manufacturers, and wholesalers are making AI infrastructure decisions to build advantages that grow over time in our webinar:

Buy what’s proven. Build what’s yours.

Enterprise AI architecture FAQ

What is RELEX Open?

RELEX Open allows organizations to connect external systems and agents to RELEX and build proprietary capabilities on top of the platform. Deploy gives organizations a foundation built from hundreds of deployments. Connect enables agents and systems outside RELEX to access planning data and actions through open protocols and MCP. Extend allows organizations to build new tools and workflows on RELEX infrastructure. All three operate on the same data model, security controls, and audit framework as the core platform.

Why do enterprise AI pilots fail to scale?

Four structural reasons: generic AI tools lack the signal depth supply chain planning requires; fragmented data creates problems that only surface months into deployment; standalone projects don’t compound value; and governance frameworks retrofitted after deployment make it impossible to establish the organizational trust that autonomous AI decisions require.

What's the best maturity model for AI platform decisions?

A maturity model that creates a foundation on validated infrastructure, uses open protocols, and builds proprietary capabilities to fulfill the unique needs of the users. At RELEX, we call this: Deploy, Connect, Extend. Deploy means leveraging proven, pre-validated planning infrastructure rather than starting from scratch. Connect means integrating systems and agents through open protocols, ending the need for workflows across systems, so every system works from the same data. Extend means building proprietary capabilities on that foundation so engineers work on the actual differentiating problem rather than rebuilding infrastructure that already exists.

Should you buy or build an AI platform?

Building gives organizations control and flexibility but requires constructing the foundational data model, domain logic, and integration layer before the actual business problem can be addressed. Buying accelerates time to value but can create a ceiling where business-specific requirements either wait for vendor release cycles or get built as brittle workarounds. But ultimately, the more durable question is not build or buy, but what foundation the organization needs and how much of it already exists.

How does RELEX connect to multi-agent AI environments?

Through open protocols and MCP, allowing external agents access to planning data and workflows in real time. Rebot coordinates on the RELEX side, ensuring every system operates from the same version of the truth. RELEX is designed to function as the operational core of a multi-agent environment rather than a constraint within it.

Written by

Laurence Brenig-Jones

VP Product Strategy & Marketing

Laurence Brenig-Jones is VP Product Strategy & Marketing at RELEX Solutions, based in Helsinki, Finland. He has over six years of experience at RELEX and specializes in product strategy and new innovations. His prior experience is in retail supply chain and strategy consulting.

Connect via LinkedIn