--- title: "Enterprise ontology: the layer holding data, documents and agents together" url: https://zerofive.ai/en/blog/insights/enterprise-ontology-for-ai canonical: https://zerofive.ai/en/blog/insights/enterprise-ontology-for-ai language: en published: 2026-10-21 updated: 2026-10-17 author: "ZeroFive.AI" tags: ontology, data identity, knowledge graph, RAG, governance abstract: "Why retrieval picks the wrong object and agents lack scope without an entity model. How to build one from twenty entities rather than the whole company." --- # Enterprise ontology: the layer holding data, documents and agents together **In short.** An enterprise ontology defines the entities that matter, what they are called, which attributes they carry, how they connect and which identifier makes each one unique. Without that layer, a retrieval system returns the right document about the wrong entity, an agent doesn't know which actions are valid on which object, and two functions using the same word keep meaning two different things. A complete model of the company isn't needed; the twenty entities of the process you want to support are. The topic looks abstract until you watch what happens when it is missing, and what happens is always the same: plausible answers about the wrong object. ## Glossary, taxonomy, ontology | Instrument | What it holds | What it is for | |---|---|---| | Glossary | Terms with a prose definition | Aligning language between people | | Taxonomy | Hierarchical categories | Classifying documents and content | | Ontology | Entities, attributes, relationships, constraints, identifiers | Letting machines reason about real objects | The practical difference sits in the last column. A glossary explains to a person what we mean by active customer; an ontology tells a system that a customer is an entity with a VAT number as identifier, carrying a status drawn from permitted values, linked to contracts and cases, and that a case cannot exist without a contract. ## The identity problem The same company appears in the CRM under its registered name, in the ERP under an internal code, in the document repository as a folder under its trading name, in email as a domain. Until those four representations are reconciled, any system joining sources produces partial answers. A question about a customer's active contracts finds the documents filed under the trading name and misses those signed under the previous registered name, without flagging the gap. Reconciliation requires three decisions, and they are business decisions before technical ones. Which system holds the authoritative identifier for each type of entity. Which rules establish that two records are the same entity. Who resolves the doubtful cases, because some will stay doubtful whatever rules are written. This work pays beyond AI. An organisation that resolves the identity of its customers improves reporting, invoicing and service, and the spend doesn't need the project that surfaced it to justify itself. ## When the same word means different things The second obstacle is semantic. Order means one thing to sales, another to logistics, a third to finance, and the three definitions coexist peacefully until somebody tries to add them up. An ontology doesn't remove the differences, it makes them explicit. It declares that a sales order and a production order are distinct entities joined by a relationship, and that the word used alone is ambiguous. From then on a request asking how many orders are open gets a clarifying question instead of a wrong answer. The same holds for statuses. Active, suspended, closed look like universal values and in real systems carry different transition rules, and those rules belong somewhere other than in the head of whoever runs the process. ## What changes for semantic retrieval An index built without structure returns chunks of text resembling the question. With an ontology above it, every chunk carries which entity it concerns, in which version, with what validity. That enables structured filtering ahead of the semantic search, which is the step that lifts perceived quality most. A question about a specific counterparty's contract narrows the space to that counterparty's documents, and only inside that space searches by similarity. There is also an effect on the ability to say it doesn't know. If the system knows which entities exist, it can notice that the question concerns an object it holds no material about, instead of returning the nearest document belonging to another entity. ## Agents and the scope of actions An agent that performs actions needs to know which objects it may act on and which operations are permitted on each. Without that map, permitted actions live inside natural-language instructions, which is the most fragile place to keep them. With it, the agent works over a declared set of entities and transitions, and an attempt outside scope is blocked by the system rather than by the model's good behaviour. The same structure serves after-the-fact control. An action log saying which entity was touched, under which identifier and through which status transition, is readable by an audit function. A log saying the agent performed an update is not. ## How to build it without an endless project The mistake that sinks this work is starting from a complete model of the company. An ontology built to be exhaustive takes months, ages during construction and ends up used by no system. The workable route starts from the process you want to support and stops there. List the entities appearing in the flow, rarely more than twenty. For each, fix the authoritative identifier, the attributes the use case needs, the relationships with other entities in scope and the permitted values for statuses. Then verify against real cases. Take thirty requests that actually arrived and check that every entity mentioned can be represented in the model. Those that can't show where scope needs extending, and whether to extend it becomes an explicit choice rather than an omission. The last part concerns maintenance. An ontology has versions, and a change to permitted statuses or relationships affects systems already running, so it needs an owner and a process that assesses the impact of changes. ## Where the model lives Three homes are workable, and the choice depends on what already exists. | Home | When it fits | Limitation | |---|---|---| | Existing data catalogue | The company already has data governance | Often describes tables rather than business entities | | Knowledge graph | Many relationships, queries that traverse them | Needs specific skills and maintenance | | Shared connector schema | Scope is limited and operations-oriented | Distorts if scope grows a lot | The third row is the most common starting point in organisations without an established data governance programme, because the ontology begins as a contract between the systems and the assistant and grows alongside the use cases. ## The link with documentation obligations Data quality and traceability appear among the requirements for high-risk systems under the AI Act and among the controls of ISO/IEC 42001, and an ontology is the document that allows verifiable answers about the meaning and provenance of the data used. It also serves something more mundane. When somebody disputes an outcome, reconstruction requires knowing which entity was involved, which version of the data was valid at that moment and which definition was in force. Without an explicit model, that reconstruction is an exercise in collective memory. ## The errors that recur The first is building it as an academic exercise, with levels of abstraction no system will use. The validity test is simple: if no component queries it, it is documentation rather than infrastructure. The second is duplicating it inside prompts. Listing entities and rules in an assistant's instructions moves knowledge into a place that isn't versioned or queryable, and two different assistants end up with two diverging definitions. The third is not assigning ownership. A model without an owner stops being updated after the first reorganisation, and from then on describes a company that no longer exists. ## Where to start The reasoning on knowledge structures and the difference between reasoning and guessing is in [ontologies as infrastructure](/en/blog/insights/ontologies-infrastructure-ai-reasons-or-guesses). The choice between semantic retrieval and connectors, which the ontology makes possible, is in [RAG and connectors](/en/blog/insights/rag-vs-connectors-which-channel), while the separation between components that interpret and components that decide is in [probabilistic and deterministic](/en/blog/insights/probabilistic-deterministic-ai-architecture). On data quality as a prerequisite, see [data governance for AI](/en/blog/insights/data-governance-for-ai) and [data readiness](/en/blog/insights/data-readiness-ai-projects). To define the scope of a model useful for your first use case you can [book an assessment session](https://calendly.com/fabiolalli/zerofive).