> ## Content Index > Fetch the complete content index at: https://thebeagle.io/llms.txt > Use this file to discover other available public pages before exploring further. # What is a business ontology, and why enterprise AI needs one - URL: https://thebeagle.io/what-is-a-business-ontology/ - Published: 2026-07-16T09:56:52.000Z - Updated: 2026-09-16T10:20:05.000Z - Description: Two AI tools, one question, two answers, and both of them right. The layer that decides which answer your business means is the one most enterprises have never written down, and you can start yours with one decision and about an hour. - Author: Yannick Meriguet - Tags: Business Ontology Ask two AI assistants the same simple question: how many active customers do we have? One answers just over two million, the other about half a million fewer, both are wired into the same systems, and both of them are right. Nobody misconfigured anything. The two tools inherited two ideas of what "active" means, and neither idea was ever written down. One counted everyone who logged in this quarter, the other everyone with a paid contract. For years your people bridged that gap in their heads, in a meeting, with a footnote nobody kept, and the machine cannot do that. It picks one meaning and runs with it, every time it is asked, all day. You have been told that AI is a data problem or a model problem: buy the platform, clean the data, pick the vendor. But the thing that just handed you two customer counts was not short of data, and it was not short of intelligence. It was short of an agreed answer to a question your business never wrote down: what do we mean by our own words? There is a name for the layer that holds those answers, a business ontology, and most enterprises do not have one. That gap is becoming the difference between AI that scales and AI that stalls, and it decides who owns your operating logic. ## What a business ontology is A business ontology is an explicit, shared model of how your business works: the things it deals with (customers, products, contracts, claims, risks), how those things relate, the rules that govern them and the decisions they drive. It is written down once, in a form both people and software can use. A database stores information, a data model describes how that information is structured, and an ontology describes what the information means in business terms, independent of any one system. It is what your enterprise has always navigated by, finally written down. In short, every enterprise already has one, and I have yet to meet one that had written it down. It **lives in the heads of the twelve people about to retire**, in a spreadsheet on someone's desktop, in the way the Milan office has always handled that one exception. ## A word that meant five things I watched this happen in a room once, years before anyone in it had said the word "AI". A European industrial manufacturer was racing to claw back a backlog of more than two years of orders. The whole mission was supply-chain optimisation: find the hold-up, kill it, ship faster. One of the biggest arguments on the programme was about a single word. The managers said maintenance was behind and dragging the line, and the consultants said it was on track. Both had the reports to prove it, and the meetings went in circles for hours. The word was the problem. "Maintenance" was not one thing but five, and each person in the room meant a different one: One word, five different jobs | "Maintenance" | Triggered by | Goal | | ----------------------- | ----------------------------------------- | -------------------------------------- | | Corrective | A failure | Restore the function | | Preventive, systematic | A fixed calendar or cycle | Avoid the failure | | Preventive, conditional | A measured parameter crossing a threshold | Intervene at the right moment | | Predictive | Data and trend analysis | Anticipate the failure | | Ameliorative | Performance analysis | Improve the equipment so it fails less | Five disciplines, five triggers, five goals, written down as one word. The managers meant the schedule; the engineers meant the repairs. Both were right, and the meetings went in circles for hours. A manager asking "are we on top of maintenance?" meant the preventive schedule, and an engineer answering "yes" meant corrective, because failures were being fixed fast. Both were telling the truth and neither was answering the other. On a programme trying to recover two years of backlog, hours were burning on a word carrying five meanings and written down as one. Then the five definitions went onto a single page, the trigger for each and the goal of each, and that afternoon the argument dissolved. Nobody conceded anything. They could simply see, at last, that they had been managing **five different jobs under one label**. That page was an ontology, though nobody in the room called it that. It was also the forgiving version, with people in the loop who could feel the confusion and slow down. Now hand the same word to an AI told to optimise that supply chain. It feels nothing and it cannot tell that "maintenance" forks five ways. So it picks one and schedules ten thousand work orders on it, fast, confident and wrong four times out of five. Which word in your business is doing that job today? ## Why enterprise AI needs one The two customer counts already showed you what an AI model does when nobody has written the meaning down: it guesses, and it guesses the same way every time. The one number I use for this comes from an interested party, so read it as a direction and not a measurement. [data.world](https://data.world/blog/genai-benchmark-ii-increased-llm-accuracy-with-ontology-based-query-checks-and-llm-repair/), which sells exactly this kind of ontology layer, had a language model answer forty-three business questions against enterprise data. On its own the model was right 17% of the time; with an ontology checking and repairing its queries, 72.6%. The model did not get smarter. [The business got legible](https://thebeagle.io/why-enterprise-ai-pilots-stall/). The step from one benchmark to your whole business is my argument, not data.world's finding. Accuracy answering real business questions Language model alone 17% Model + business ontology 72.6% More than four times better. Source: data.world GenAI Benchmark II, a vendor benchmarking its own ontology layer, so read the figure as directional, not exact. AI does not run on your data. It runs on your definitions. ## Ontology, knowledge graph, data model: what's the difference These three get used as if they were the same thing, and the difference between them is the whole point. A data model is structure: it says a customer record has a name, an identifier and an address. A knowledge graph is connection: it links your data into relationships, so this customer signed that contract, which covers this product, sold by that legal entity. A business ontology is meaning and rules. It defines what a customer is, when one becomes "active", which of your fifteen legal entities may own that relationship, and what has to happen when a rule is met. The way I keep them apart is simple: the knowledge graph is the map, and the ontology is the legend that tells you what the symbols mean. Enterprise AI needs all three, and what I have seen fail most often is the one enterprises skip. Which of the three has a budget line in your AI programme? The three layers enterprise AI runs on Data model **Structure.** A customer has a name, an ID, an address. Knowledge graph **Connection.** This customer signed that contract. Business ontology **Meaning and rules.** "Active" means a paid contract. One answer, every time. Enterprise AI needs all three. It fails most often on the one enterprises skip. ## How an ontology makes AI explainable, and who stays in control An answer you cannot explain is a liability, and in Europe it is increasingly a legal one. The EU AI Act expects a high-risk system to be transparent and open to human oversight, meaning a decision a person can follow and challenge rather than a black box. An ontology does not deliver that on its own. What it does is let you trace a decision to the definition and the rule it applied, which is the part a supervisor can follow. Take a claims-escalation decision at an insurer. If "high-severity claim" means one thing to the fraud team and another to the medical assessors, an AI that routes claims applies whichever definition it inherited. Nobody can say afterwards which rule it followed. Write that definition and the escalation rule into an ontology, and the same decision traces cleanly: **this claim met this threshold, so this rule fired**. It also decides who is in control. If the logic your AI runs on lives only inside a vendor's platform, you are renting your own operating rules. If it lives in an ontology you own, you can change AI model, vendor or country without rewriting what your business means by its own words. For a regulated firm that is more than strategy. Europe's Digital Operational Resilience Act, DORA, puts the same question to the board in supervisory terms. How concentrated is your dependence on any single third-party provider, and could you exit it if you had to? If your operating logic is locked inside one platform, you have no good answer to either question. > Sovereignty, in practice, is not where your data sits. It is who owns the logic your AI runs on. ## What building one looks like The mistake is to hear "ontology" and picture a two-year enterprise-wide mapping programme. I have stopped starting from the enterprise. I start from **one decision that keeps breaking**: what makes a customer count as active, or which of your entities owns a contract. The people who own that decision go in one room and agree on a page: the terms, the definition of each and the rules that move them. That page is the first ontology, and most of the time it is the first time the business has stated its own logic out loud. The decision is often hiding behind a word your teams argue about, and the way to find it is to ask each function to define that word in one sentence and count the answers. This is what I call the Definitions Test. The meeting that follows, what it costs and who keeps the page honest afterwards, is [the subject of the legibility post](https://thebeagle.io/why-enterprise-ai-pilots-stall/). The part that is specific to a European group is the discipline across countries. You keep one shared definition where the business genuinely is one, and an explicit local variant where Milan really does differ, both written down, so that one ontology governs many subsidiaries without flattening them into a rigid standard. Every [AI use case](https://thebeagle.io/ai-use-case-selection/) that touches that decision then inherits one definition instead of guessing at five, and the second use case is cheaper than the first. None of this starts with a platform decision. It starts with a sentence, your business saying out loud what it means by the words it runs on. Write it down and your AI inherits an author. Leave it unsaid and the model becomes the author, on rules you never chose. Before your next AI investment, then, run the test on the three business terms your teams argue about most: one sentence per function, then count how many different answers come back. It costs about an hour to set up and a day before the answers are all in. The definitions test 1. Before your next AI investment, take the three business terms your teams argue about most. 2. Ask each function to define them, in one sentence. 3. Count the different answers. That gap is exactly what your AI is about to scale, or to compound. And you: which of your own words would you least want an AI to define on your behalf? ## Common questions ### What is a business ontology, in one sentence? An explicit, shared model of how your business works (its entities, their relationships, the rules and the decisions), written so that both people and software can use the same meaning. ### How is it different from a knowledge graph? A knowledge graph connects your data into relationships. An ontology defines what those things and relationships mean and the rules that govern them. The graph is the map; the ontology is the legend. ### Do we have to model the whole enterprise? No. That is the expensive way to fail. You start with one high-value decision that keeps breaking, and expand only where it pays. ### Is this a technical project? No. The hard part is a business agreement on meaning. It is led from the business and the operating model, not from a database team.