Your KMS has a taxonomy. Your enterprise does not.
I’ve spent 15 years building taxonomies into knowledge management systems. So every time a vendor deck or analyst piece talks about “taxonomies and ontologies for AI-readiness” like it’s a brand new discovery, I’ve had the same reaction. Insert dramatic eye roll here.
My KMS has had a taxonomy since day one. I call it a folder structure. It’s got metadata. I call it keywords. It’s got role-based access control (RBAC), so an agent only sees the knowledge relevant to them. I’m still sitting here waiting for the big reveal.
I read a piece from Enterprise Knowledge recently that made the case for taxonomies and ontologies as AI-readiness infrastructure. My first instinct was the same eye-roll. My second instinct, the one that actually stuck, was that my KMS has always had a taxonomy. What I’d missed was where its authority actually ends.
The taxonomy in your KMS solves for one container
Inside a purpose-built knowledge management system, the taxonomy question is basically solved. It has a controlled hierarchy of topics, metadata tagging, RBAC deciding who sees what. AI grounded in that single system inherits all of it for free, which is why a well-governed KMS is a genuinely good RAG source, and why most AI disappointment goes back to pointing AI at a filing cabinet instead of a knowledge base.
But that boundary, everything inside “your KMS,” is the whole problem.
A taxonomy only does its job inside the system it was built for. The moment you ask AI to reason across your KMS and your CRM and your ticketing platform and the SharePoint site nobody officially owns, you’ve left the one place where your taxonomy has any authority.
What a taxonomy and an ontology actually do
Remove the fancy sounding jargon and it’s simple.
A taxonomy is a shared vocabulary. It says, here is the official list of things we talk about (our products, our regions, our case types) organised into a hierarchy, with the synonyms and legacy terms mapped back to one canonical term.
An ontology goes a step further. It’s the rulebook for how those things relate to each other, and what that implies. Take “billing dispute”, which products it can apply to, which team owns it, what it triggers, what it can’t be confused with.
Your KMS almost certainly has a working taxonomy. It almost certainly lacks an ontology that extends past its own walls. Think a rulebook that tells your AI assistant that “billing dispute” in the KMS, “payment issue” in the CRM, and “invoice, unresolved” in the ticketing tool are the same thing.
That’s as deep as I’m going to get on ontologies here. Whether a single, well-built KMS ever needs a formal ontology or knowledge graph on its own is a fair question, worth its own answer with real examples rather than a paragraph here. For now, lets just agree that the enterprise problem needs a rulebook that reaches past a single system’s walls.
A scenario I’ve lived more than once
Picture a 400-agent contact centre for a regional insurer. Four systems, all doing their job well individually:
- The KMS: structured articles, each tagged by product line, customer segment, and regulatory status. Excellent taxonomy. RBAC by role.
- The CRM: case records tagged with its own picklist of issue types, built by a sales ops team years ago for pipeline reporting, not customer service.
- The ticketing system: free-text categories agents type in themselves under deadline pressure, because the dropdown never had the option they needed.
- A SharePoint site: process documents from three re-orgs ago, technically retired, never deleted, still fully indexed by whatever search tool’s being used.
Each of those four systems has something you could call a taxonomy. None of them agree with each other, and nobody designed them to. That includes the one detail no diagram can show you, the SharePoint doc is technically retired, superseded by the KMS article eighteen months ago, and still fully indexed anyway.
This is a translation problem nobody solved before AI showed up. It guesses because nothing ever told it these three terms mean the same thing, or that one of its four sources should have been removed a year and a half ago.
Why RBAC doesn’t save you here
I’ve written before about the gap between who can see this and should this be trusted. This is a related but genuinely different gap: does this even mean the same thing as that.
Permissions and RBAC answer an access question. They don’t answer a semantic one. A perfectly permissioned, perfectly governed piece of content in your KMS can still be functionally invisible to AI across systems, simply because nothing told it that this system’s term and that system’s term mean the same thing.
You can have flawless governance in every individual container and still have zero coordination between them. Nobody built that architecture, because nobody needed one until AI started being asked to reason across the boundary. That’s an architecture gap, not a governance failure.
Where this actually bites
The failure mode isn’t always a wrong answer. It’s often something worse, a plausible answer built from the wrong source, cited with total confidence, that a human has no fast way to trace back and catch.
In a regulated contact centre, that’s not a minor UX issue. If a customer complaint later asks what information grounded that answer, “somewhere across four systems, synthesised by a model with no concept of which term meant what” is not an answer you want to give a regulator.
The wrong fix. Dump it all into one place
Once the four-system mismatch is obvious, the instinct is to stop having four systems. Pull everything out (the KMS, the CRM notes, the ticketing history, the SharePoint remains) into one shared store. Chunk it, embed it, point the AI at a single index. Tada problem solved.
I’ve made this argument before from the governance side, when content leaves a governed system and lands in a shared index, you lose version authority, approval status, ownership, conflict resolution, and the retrieval audit trail. The index measures how relevant content sounds, not whether it’s right.
The taxonomy version of that same argument holds just as well. Chunking and embedding doesn’t carry your classification structure across either. The postcode, age band, and funding type fields that made a disability care catalogue instantly filterable don’t survive the trip into a vector database as first-class attributes. At best, they become words mentioned somewhere inside a chunk, competing for relevance with everything else in that chunk. What was clean, tagged, hierarchical knowledge becomes an undifferentiated pile of text fragments, distinguishable mostly by vector proximity.
Chunking and embedding is a retrieval mechanism, not an information architecture. It’s very good at finding text that sounds related to a query. It has no concept of canonical terms, ownership, supersession, or eligibility rules, the exact things a taxonomy, and where it’s warranted, an ontology, exist to encode. Centralising the content without carrying the structure across with it just trades four small, well-organised problems for one large, disorganised one.
What actually fixes this is a layer that maps meaning between the systems you’ve got, without requiring you to gut the structure each one already built.
Where I landed
Taxonomies and ontologies aren’t a new idea KM people needed to learn. Most of us have been building them into single systems for years. What’s actually new is the scope.
The valuable work is building the layer that sits above every individual taxonomy. The enterprise semantic layer that says “these four systems’ vocabularies map to one shared reality,” so an AI assistant reasoning across containers has some hope of getting it right.
That’s a different job to the one most KM taxonomies were built to do. It’s also, I’d argue, the actual AI-readiness work most organisations haven’t started, or even considered, because it’s easy to assume the taxonomy problem is solved when you’ve only ever looked at it one system at a time.
Have you tried to reconcile terminology across systems before pointing AI at all of them? I’d be curious whether it was a deliberate project or something you discovered the hard way. Comment and let me know.