The Wrong Layer of GenAI
Most GenAI conversations start at the wrong layer.
If you observe an enterprise AI steering committee, the discussion almost immediately jumps to model selection. We debate the merits of open-source versus proprietary models, we argue about the size of context windows, and we spend months refining prompting techniques and evaluation frameworks.
But the real issues sit underneath.
In enterprise environments, I keep seeing the same patterns repeat. The difficult part usually isn’t getting an LLM to work once in a controlled environment. The real friction occurs when that AI attempts to interact with the messy, operational reality of the business.
A proof-of-concept can hide a surprising amount of architectural fragility. It is remarkably easy to build a compelling demo using a static dataset or a tightly controlled sandbox. The difficult part is making the surrounding ecosystem reliable enough for the business to trust it repeatedly.
The Illusion of the Sandbox
When an AI initiative stalls after the pilot phase, it is rarely the model that failed. It is the data foundations breaking under the pressure of production reality.
In a pilot, an AI agent is typically fed clean, well-understood data—often extracted manually into a CSV or a dedicated temporary database. The model performs brilliantly because the data it is reasoning over has no ambiguity.
But when that same agent is deployed into production, it is suddenly wired into the live enterprise data estate. It encounters API endpoints that time out, legacy databases with undocumented schemas, and data pipelines that silently drop records. The AI begins to hallucinate or provide incorrect answers, not because the model degraded, but because the context it is receiving is fundamentally broken.
Unseen Fragilities
Technology tends to amplify whatever already exists organisationally. When we deploy GenAI over a fragile foundation, we rapidly expose three core architectural gaps:
1. Unclear Ownership
An LLM assumes the data it retrieves is authoritative. If a business unit has not clearly defined who owns a specific data domain (e.g., customer churn metrics), the AI will inevitably ingest and serve orphaned, outdated information. AI requires strict data contracts and clear domain ownership to function reliably.
2. Fragmented Definitions
In many enterprises, a simple term like "active customer" might have three different definitions across Sales, Finance, and Marketing. A human analyst knows how to navigate this political nuance. An AI agent does not. It will retrieve conflicting answers depending on which table it queries, eroding executive trust in the system entirely.
3. Weak Governance
Traditionally, data governance and access control were managed at the application layer—dashboards simply hid data the user wasn't allowed to see. GenAI breaks this paradigm. Because LLMs require programmatic access to underlying datasets to generate context, any missing row-level or column-level security in the database itself becomes an immediate vulnerability.
The Real Architecture Work
We are treating GenAI as a software implementation problem when it is actually a foundational architecture problem.
If an organisation is struggling to move AI out of the lab, the solution is not a better prompt. The solution is doing the unglamorous, difficult work of untangling the legacy data estate.
This is where the real architecture work begins—not in selecting the most advanced LLM, but in restructuring ownership, governance, and data quality so that the intelligence layer has something trustworthy to reason over.