The Language Problem
Every enterprise seems to believe it has a data problem. Too much data, too little data, dirty data, siloed data. But what if the deeper issue is linguistic? Different parts of the organization use the same words to mean different things.
To Sales, "Revenue" means a booked contract. To Finance, it means recognized earnings. To Operations, it might mean cash received. When an AI system tries to reason across these domains, it encounters what is effectively a Tower of Babel — the same terms carrying different meanings depending on who defined them.
This probably isn't just semantics. It might be one of the most underappreciated barriers to AI adoption.
The Intelligent Archipelago
Most enterprise data landscapes look less like a unified continent and more like an archipelago — a chain of islands, each with its own language, its own definitions, its own way of organizing reality.
CRM data lives on one island. ERP data on another. Marketing analytics on a third. Each island is internally consistent but uses different vocabularies, different granularity, different assumptions about what entities and relationships matter.
When AI is deployed across these islands without addressing the language gap, the results tend to disappoint. The model doesn't know that "Customer" in the CRM means something subtly different from "Account" in the ERP, which maps to yet another concept in the billing system. It treats them as the same, or as unrelated, and either way the reasoning can break down.
What Happens When You Feed Silos to AI
Without a map of how these semantic islands relate, AI seems to produce three categories of failure:
Wrong numbers — Aggregating "Revenue" across systems that define it differently produces figures that are confidently precise and potentially wrong.
Missed connections — Failing to recognize that the same customer appears under different identifiers in different systems.
Hallucinated relationships — Inventing connections between entities that share a name but not a meaning.
The natural instinct is to fix this by forcing a universal language — one master data model that all systems must conform to. But decades of enterprise architecture suggest this approach rarely works. The organization resists because each domain's language evolved to serve real, local needs. Stripping that away loses nuance that matters.
Don't Drain the Ocean. Build Bridges.
The alternative might be to stop trying to force a single language and instead build bridges between the islands. This could mean creating a semantic layer — a knowledge graph or ontology — that maps the relationships between different domains' vocabularies without requiring any of them to change.
Sales keeps calling it "Revenue." Finance keeps calling it "Recognized Earnings." But the bridge knows these are related concepts with a specific transformation rule between them. When AI reasons across domains, it traverses the bridge rather than guessing at translations.
This is the knowledge garden approach: instead of draining the ocean to create one landmass, you cultivate the connections between islands until AI can navigate the archipelago.
The question for any enterprise deploying AI might not be "have we unified our data?" but rather "have we mapped our languages?"