Why AI Pilots Fail in Enterprise: Technical Debt Explained

Your company can have AI pilots, automated workflows, dashboards, and piles of data, yet still see weak business results. That gap frustrates leaders because the tools are there, but the outcomes never seem to scale.

On TechTalk with Bill, host Bill Martin and former IBM and ServiceNow technologist Gary Goh make a simple case: AI fails when the foundation underneath it is unstable. The problem starts long before the model runs.

[embed]

Why companies with AI still struggle to get results

Many enterprise teams believe they are already prepared because they have bought the right tools. They have copilots, workflow automation, reporting layers, and data platforms. On paper, the boxes are checked.

Bill Martin argues that this view misses the real issue. Years of legacy customization, fragmented workflows, and inconsistent data create a weak base. AI lands on top of that base and inherits every crack.

Gary Goh adds an important point from experience. Technical debt is often unavoidable because businesses move fast, priorities change, and teams are told to deliver now. In that rush, shortcuts pile up. A quick fix becomes a custom workflow. A temporary integration stays in production. A duplicated table becomes part of the operating model.

That is why so many AI efforts stall even when the technology itself looks strong. Common signs include:

• data models that don’t match across teams
• local customizations that solve one problem and create five more
• weak governance around workflows, integrations, and change

When leaders say, “We already have AI,” they may be describing a toolset, not a system that can support reliable AI at scale.

How technical debt builds, even in well-run organizations

Goh’s background helps explain how this happens. At IBM, he learned a culture built around process and governance. That approach created discipline and auditability, but it could also slow down change because many systems were rigid and purpose-built.

ServiceNow and similar platforms shifted that model. A platform with a central data model can support faster delivery and local optimization. Used well, that is a major advantage. Used poorly, it opens the door to endless customization.

The risk grows when teams start thinking, “We can build anything here.” Skilled developers often can. Yet speed without standards creates brittle systems. Reuse drops. Patterns disappear. Governance falls behind.

According to Goh, the slide often begins with small decisions that seem harmless at the time. A business unit asks for its own workflow. A team creates a custom table for a concept that already exists elsewhere. A temporary integration is pushed live because the deadline is close. None of these choices looks fatal on its own. Together, they create long-term drag.

That is why governance becomes an architectural duty, not a side task. Flexible platforms increase capability, but they also increase the need for control.

Legacy debt and modern platform debt are different, but both hurt AI

Older enterprise debt and newer platform debt do not look the same. The older form was often centralized and easier to locate. The newer form is spread across teams, apps, and services, which makes it harder to trace.

This side-by-side view shows the difference:

Debt typeOlder enterprise systemsModern platform environmentsWhere it sitsCentralized data centers and core systemsDistributed teams, apps, services, and workflowsWhat creates itHeavy custom code in large systemsFast local customization and duplicated logicMain problemChange is slow and expensiveTraceability is weak and reuse breaks downAI impactHard to modernizeHard to trust, govern, and scale

The key takeaway is simple: modern debt hides better.

In the older model, teams often knew where the heavy custom code lived. Today, with distributed development and tools such as Kubernetes, many groups move at their own pace. That speed helps delivery, but it also spreads responsibility across the organization. As a result, root causes become harder to find.

How to spot an architecture that will fight every AI initiative

Some environments give off warning signs early. Goh points to siloed development as one of the clearest signals. Each department runs its own projects, shapes its own workflows, and creates its own fixes.

A quick smell test can help:

1. Multiple departments use custom workflows that do nearly the same job.
2. Teams create new tables instead of reusing shared models and integrations.
3. Manual workarounds still sit behind “automated” processes.
4. No one can clearly explain data lineage, ownership, or change impact.

When HR, finance, sales, retail, or manufacturing all build parallel versions of the same process, the organization starts paying for the same logic many times over. Then AI arrives and has to read across inconsistent schemas, conflicting rules, and messy context.

That is where reliability falls apart. Models struggle to interpret the data. Governance gets harder. Hallucinations and weak output become more likely because the system cannot provide a clean, consistent picture of the business.

“Build your foundation before you go AI.”

Why “it still works” is one of the most dangerous phrases in IT

Executives often push back on cleanup because the system still runs. Reports still load. Chatbots still answer questions. From a budget view, that makes refactoring look optional.

Goh uses a strong analogy. A bridge built for bicycles may work perfectly for years. Once cars start using it, the old design becomes a liability. Support pillars and patch jobs can keep it standing for a while, but the base was never built for the new load.

Enterprise AI creates that same pressure. A system that worked for manual workflows and basic reporting may break under the demands of agents, large-scale automation, and continuous model use.

This issue also has a human side. Most architects inherit old environments. Raising technical debt can sound like blaming the previous team. Goh’s answer is practical: frame the work as evolution, not criticism. Focus on what the organization needs next and how to stop the same debt from coming back.

That approach also helps with business stakeholders. Leaders care about speed, compliance, revenue, and customer experience. Technical debt matters when it slows change, raises audit risk, or damages service quality.

AI readiness requires clean context, not only access to AI tools

Many companies now “have AI” because licensing is easy. Employees can use mobile AI tools. Enterprises can roll out copilots. Access is no longer the hard part.

Readiness is harder. AI-ready organizations have structured data, clear workflows, and reliable architecture that supports accuracy and scale. Without that, the tool exists, but the business cannot depend on it.

Goh argues that most stalled generative AI pilots do not fail because the models are weak. They fail because systems are disconnected, data quality is poor, and standard processes are missing. In those conditions, AI cannot resolve conflicting logic or produce dependable output.

That also explains why plug-and-play AI promises fall flat in heavily customized environments. Bad input still leads to bad output. When fields conflict, data is incomplete, or workflows vary by team, the model inherits confusion.

Where to start if your enterprise is stuck

The first step is to take stock of the environment you already have. That means understanding the workflows, integrations, data quality, and customizations that support critical business processes today.

After that, Goh’s triage is clear. Identify the most important AI use cases first. Then prioritize standardization and clean up the data those use cases depend on. Validation matters because every change introduces risk when the foundation is inconsistent.

Bill Martin connects that view to his “Validate Now” idea. The logic is simple: stabilize and standardize before trying to scale AI. Stop the bleeding before you attempt bigger ambitions.

This also helps when the business wants the next shiny feature. Refactoring and consolidation are harder to sell than a new AI capability, but they protect KPIs and reduce future cost. They also improve the odds that the next AI investment will deliver something real.

In an AI-native business, the architect’s role expands. The architect is no longer only a system designer. The job starts to look more like a product owner for enterprise foundations, setting standards, guiding change, and protecting the conditions AI needs to work.

AI struggles in places where the foundation has been neglected for years. Tools alone won’t fix duplicated workflows, poor data, and weak governance.

The strongest message from Bill Martin and Gary Goh is also the simplest: clean, standardize, and modernize first. Once that base is solid, AI has a real chance to do the work leaders expect from it.