Almost every client conversation about AI starts with a desire to turn data into something people can use in the moment. No SQL, no dashboards, no waiting on a data team — just relevant answers, grounded in trusted data, when decisions need to be made.
Naturally, the conversation tends to start at that front end — the model, the copilot, the interface — since that's the part people can see and imagine using. Business glossaries, ontologies, guardrails, ownership and lineage rarely come up early on. In our implementations, though, we've found reliability has very little to do with the model itself, and much more to do with foundations further upstream — foundations that are often still maturing, even in organisations that are otherwise well advanced in their data journey.
Take a simple question: "What was our revenue from customers last quarter?" For AI to answer that reliably, it needs to know what revenue, customer and last quarter mean. Is revenue gross or net? What qualifies as a customer? Which financial calendar applies?
These are business problems wearing an AI costume. We consistently find that even "customer" means something different depending on who you ask — billing sees an account, retail sees a household, network sees a subscription. Each is defensible in its own context; none are automatically compatible with the others. No model resolves that on its own.
So, we start there: identifying the key business concepts behind the priority use cases and agreeing contextualised definitions, then connecting those definitions to the underlying data, metrics and data products that give them substance.
In practice, this means pairing a business-facing catalog with a technical one — one layer where the business agrees, publishes and governs what a concept means and who owns it, and another that handles governed access, discovery and lineage closer to the data and AI assets themselves.
Within many of our Microsoft Customers we often see Microsoft Purview as the business catalog and Databricks Unity Catalog as the technical catalog. Purview sits well as the enterprise-wide layer where business meaning gets agreed and governed across a broad estate across documents and operational systems; Unity Catalog sits well close to the data and AI assets themselves, where governed access, discovery and lineage need to be enforced at the point of use. Fortunately, Purview and Unity Catalog work together – with strong integration. The same separation of concerns holds with other tools — what matters is that the two layers exist and are connected, so the chain holds together end to end:
A glossary without technical enforcement stays a document nobody checks — if nothing in the platform points back to it, people default to whatever's fastest, like the column name in front of them or last quarter's figure pulled from an old spreadsheet. A technical catalogue without agreed meaning just catalogues the same confusion more precisely — it can tell you where "customer_id" lives, but not which of three competing definitions of "customer" it represents.
This is exactly what makes natural language access hard. A user doesn't ask an assistant to query a table — they ask a business question, and the AI needs to know which definition is authoritative before it can answer well. Get it wrong and you don't get a bad answer; you get a confidently wrong one, delivered as fluently as a correct one. That's harder to catch, and more damaging to trust.
We don't recommend cataloguing everything before starting. At enterprise scale that route rarely finishes, and it delays the value the programme was meant to deliver. Instead, we work backwards from the priority use cases:
In practice that means starting narrow: pick the two or three business questions the AI genuinely needs to answer well and resolve the handful of concepts behind them properly — definitions agreed, owners assigned, data mapped and lineage traced — rather than spreading effort thinly across a hundred terms that may never get used. Testing against real business questions early matters too, because it's often the fastest way to surface a definition that looked settled on paper but breaks down the moment someone asks an edge-case question.
Letting priority use cases drive which concepts get defined first keeps the model grounded in real value rather than becoming a governance exercise for its own sake — and gives teams an early, tangible win to build on. Each additional use case then extends the model rather than starting from zero, so the coverage grows in step with genuine demand instead of running ahead of it.
The most valuable part of an AI implementation isn't usually the model or the interface users see — it's what sits underneath: shared definitions, trusted data, lineage and clear ownership. The specific tools that operationalise this will vary by environment, but the work doesn't change aligning the business around what the data means, and in whatever platforms fit the stack.
Before we ask AI to understand our business, we need to make sure the business understands its own data.
If your business needs help with their AI journey, contact the One51 team to talk through the options available.