I have a somewhat unpopular opinion about enterprise AI:
Most companies don't need a better AI model. They need better infrastructure around the model they already have.
There is a tendency to treat AI adoption as a model-selection problem.
Should we use GPT? Claude? An open-source model? RAG? Agents? Fine-tuning?
Those questions matter, but they are often happening too early.
If the AI system can't access current customer data, transaction information, inventory, operational events, or business rules when it needs them, the model doesn't have much room to demonstrate its intelligence.
I've become increasingly convinced that legacy architecture is one of the biggest hidden constraints on real-time AI.
And no, I don't think the answer is "replace everything with a new platform."
That's usually an expensive way of avoiding the actual architecture problem.
AI is becoming real-time while enterprise systems are still batch-oriented
Traditional enterprise software was built around a very different assumption.
Data could be processed overnight.
Reports could arrive every few hours.
Systems could exchange files.
Employees could manually move information between applications.
That model worked because business decisions didn't always need to happen within milliseconds.
AI changes the equation.
Imagine an AI fraud detection system evaluating a transaction.
The model may identify suspicious behavior almost instantly. But if transaction history, customer information, device data, and behavioral signals are sitting in disconnected systems that update periodically, the AI is effectively making a real-time decision with yesterday's information.
That's not an AI problem.
That's an architecture problem.
The same pattern appears in customer support, ecommerce recommendations, inventory forecasting, underwriting, claims processing, and operational automation.
Real-time AI requires real-time access to the context behind the decision.
The five legacy problems I would worry about first
1. Your data is everywhere
Large organizations rarely have one clean source of truth.
Customer data might live in a CRM.
Financial information might sit in an ERP.
Transaction records may live in a core banking platform.
Operational data could exist in databases, spreadsheets, SaaS applications, and internal tools.
Then someone says:
"Let's connect AI to all of it."
That's where reality starts getting complicated.
The AI isn't necessarily struggling to reason. It's struggling to assemble the context it needs.
2. Your systems were designed for batches, not events
This is probably the biggest architectural mismatch.
Legacy applications often work perfectly well when information is processed periodically.
But an AI agent responding to an event doesn't want a database that was last synchronized three hours ago.
It wants the current state.
A fraud model wants the current transaction.
A recommendation engine wants the current customer behavior.
An inventory system wants the current stock position.
An AI support agent wants the latest customer interaction.
Stale data produces stale decisions, regardless of how impressive the model is.
3. Integration becomes the hidden AI project
Companies often announce an AI initiative as if the difficult part will be building the AI.
In many enterprise environments, the difficult part is getting the AI connected to everything else.
Legacy applications may have limited APIs.
Some systems require custom middleware.
Others expose data through older integration mechanisms.
Some critical applications may have been heavily customized over decades.
Suddenly, the "AI project" becomes a data integration and modernization project.
This is why I think architecture should be discussed before model selection.
4. Tight coupling makes experimentation expensive
AI development requires iteration.
You try something.
Measure it.
Change the workflow.
Test another approach.
Introduce a new model.
Add another data source.
Change the decision logic.
That becomes difficult when every change requires modifying a tightly coupled legacy application.
The result is predictable: teams move slower, costs increase, and experimentation becomes risky.
AI-native systems need a different level of flexibility.
5. Technical debt compounds everything
Technical debt isn't just an engineering annoyance anymore.
It can directly determine how quickly an organization can adopt AI.
Every undocumented dependency, brittle integration, obsolete interface, and hard-coded business rule increases the cost of connecting new intelligence to existing workflows.
Eventually, the organization reaches a strange situation:
It has invested heavily in AI but can't operationalize it because the surrounding software can't keep up.
That's the part of the AI conversation I think gets overlooked.
I don't think enterprises should rip out their legacy systems
This is where I strongly disagree with the "modernize everything" approach.
A bank shouldn't replace its core banking system because it wants an AI fraud detection capability.
A manufacturer shouldn't throw away decades of operational software because it wants predictive maintenance.
A healthcare organization shouldn't rebuild every system before introducing AI into a workflow.
That's financially and operationally unrealistic.
Instead, I'd take a much more aggressive approach to selective modernization.
Keep the systems that still do their core jobs.
Modernize the interfaces around them.
Create reliable data access layers.
Introduce event-driven integration where real-time behavior actually matters.
Expose important business capabilities through APIs.
Move appropriate workloads toward cloud-native infrastructure.
Then put AI on top of that foundation.
The goal isn't to make everything new.
The goal is to make the existing enterprise usable by modern software.
What an AI-ready architecture should actually look like
In my view, an AI-ready enterprise needs several things working together:
Accessible data
AI systems need governed access to the information required for decisions.
Real-time integration
Important events should be available without relying entirely on scheduled batch transfers.
Decoupled services
AI capabilities shouldn't require rewriting an entire monolithic application every time the workflow changes.
APIs and event streams
These become the connective tissue between legacy applications and newer AI systems.
Observability
If an AI system makes a bad decision, teams need to understand what data, services, and processes contributed to it.
Human controls
Not every AI decision should automatically become an automated business action. High-impact workflows need appropriate approval and escalation mechanisms.
This is less exciting than talking about autonomous agents.
But it's far more important.
The companies I'd actually watch in this space
I don't think there is a single "best AI company" for enterprise modernization. Different organizations have radically different constraints.
But if I were evaluating engineering partners for this specific problem, these are some of the names I'd put on the shortlist.
1. EPAM — for engineering-heavy modernization
EPAM is interesting when the problem is deeply technical and involves complex enterprise environments.
Its 2026 partnership with Anthropic specifically focuses on applying AI to areas such as legacy operations, workflow automation, large-scale data, and enterprise transformation.
My take: EPAM makes more sense to me when the challenge is "how do we actually re-engineer this complicated enterprise environment?" rather than simply "give us an AI strategy."
2. Accenture — for massive enterprise transformation
Accenture is difficult to ignore at enterprise scale.
Its 2026 work with Microsoft around forward-deployed engineering is explicitly focused on helping organizations operationalize AI across the enterprise.
My take: If you're dealing with a huge multinational organization, multiple business units, and a transformation measured in years rather than months, Accenture's scale is a significant advantage.
But I wouldn't automatically choose the biggest consultancy for every AI modernization project.
3. Thoughtworks — for engineering-led architecture
Thoughtworks belongs on the conversation when architecture, engineering practices, and long-term maintainability matter as much as the AI implementation itself.
My take: I'd look toward Thoughtworks when the question is less "how quickly can we deploy an AI feature?" and more "how should we redesign the engineering system around AI?"
That distinction matters.
4. IBM — for complex enterprise and regulated environments
IBM remains relevant where AI modernization intersects with hybrid cloud, governance, existing enterprise infrastructure, and highly regulated industries.
My take: IBM becomes particularly interesting when modernization can't be separated from governance, security, compliance, and existing enterprise technology investments.
5. GeekyAnts — for a more engineering-focused modernization approach
GeekyAnts is another name I'd include in the broader AI engineering conversation, particularly for organizations looking at the intersection of legacy modernization, AI integration, and product engineering.
Its current positioning spans AI systems, product engineering, and enterprise modernization rather than treating AI as an isolated layer.
My take: I wouldn't put GeekyAnts in the same category as Accenture when comparing global transformation scale. That's not the point.
The more interesting comparison is whether a team can actually connect modernization, product engineering, and AI implementation without turning the engagement into an enormous transformation program.
For startups, scale-ups, and organizations looking for a more hands-on engineering engagement, that's a category worth considering.
My controversial take: stop buying AI before fixing the plumbing
Here's where I'll take the strongest position.
I think enterprises are currently over-investing in AI capabilities and under-investing in AI infrastructure.
Another model won't fix disconnected databases.
A better prompt won't fix stale customer records.
An autonomous agent won't magically create an API for a 20-year-old application.
And throwing an LLM at a broken workflow doesn't make the workflow intelligent.
It just makes the broken workflow more complicated.
The organizations that get the most value from AI won't necessarily be the ones with the most advanced models.
I think they'll be the ones that can connect data → intelligence → business action with the least friction.
Don't modernize everything. Modernize what AI touches.
This is probably the principle I'd use if I were advising an enterprise today.
Don't start with:
"How do we replace our legacy systems?"
Start with:
"Which business decisions would become dramatically better if AI had access to real-time information?"
Then work backward.
Identify the data.
Identify the systems.
Identify the integration bottlenecks.
Identify where latency matters.
Identify where humans still need to approve decisions.
Then modernize those paths first.
That's a much more realistic AI strategy than attempting to rebuild an entire enterprise because AI became popular.
The real AI readiness test
Before buying another AI platform, I'd ask five questions:
- Can our AI access the data it needs in real time?
- Can our existing applications expose the capabilities AI needs?
- Can we introduce new AI workflows without rewriting core systems?
- Can we trace what data influenced an AI decision?
- Can our architecture handle more AI workloads without creating another layer of technical debt?
If the answer to most of these is "no," I wouldn't start with another AI pilot.
I'd start with the architecture.
Because at some point, enterprise AI stops being an AI problem.
It becomes a software engineering problem.
And honestly, I think that's a good thing.
It means the path to better AI isn't necessarily another model.
Sometimes it's finally fixing the systems we've been avoiding for the last decade.
