Knowledge graphs and ontologies: the foundation of AI you can trust

In every company there's a person who "knows everything": which client is tied to which project, handled by which supplier, with that issue still open since March. They don't read it in a report: they hold it in their head, made of connections. The day they go on holiday, you notice. And when you try to replace them with AI, you hit the uncomfortable truth: the AI talks beautifully but doesn't have their map. So now and then it makes the answers up.

Gartner reckons that through 2026 companies will scrap 60% of AI projects that aren't backed by AI-ready data; RAND's estimates put total failure north of 80%, with data among the top causes. The bottleneck isn't the model.

Knowledge graphs and ontologies give that map to a machine.

Your company as a network of connections

Draw your company as a network of dots joined by lines. The dots are the things that matter: a client, a product, an order, a supplier. The lines are the links: this client signed that contract, covering that product, supplied by that plant. A knowledge graph is your company as a network of connections, not twenty separate tables.

In traditional systems the connections exist but are hidden, and every new question that crosses them is manual work. In a graph you walk on the connections. Tables stay the right call for plenty of cases. The graph earns its place when the value is in the connections, and in a business it almost always is.

Ontologies: agree on the words

To sales a "client" is whoever signed; to support, whoever has an active contract; to finance, whoever paid. Three teams, three meanings, reports that never match. That's the number-one hidden cost of data, and it's not technology: it's the words. The ontology is the agreement that fixes it: a shared dictionary for what the company's words mean and which links make sense. Simple rules, written once. It's the grammar that holds the graph together. And no, you don't start from a giant schema: start from the few entities that matter and expand only where it pays.

There's one more piece a plain shared dictionary doesn't have: an ontology in the strict sense (the OWL kind) also encodes inference rules. If "an active contract implies a current client" is a rule written once, the system automatically deduces consequences nobody entered by hand. That's what actually separates an ontology from a plain schema table or a data dictionary, not just agreeing on names, and it's also why much of what gets called "ontology" today isn't one.

The Palantir approach (and why you don't need Palantir)

Palantir brought this idea to the mainstream: in its Foundry platform the ontology is the layer on top of the data that describes the business: objects, relationships, even the actions you can take (a kind of "digital twin" of the organisation). Strong design. Credit where it's due (and on why Palantir as a company is polarizing, I cover that separately).

But that's exactly the point: the principle is independent of the tool. Building a shared model of the company and letting AI reason over it works on Databricks, Snowflake or BigQuery too. Forged on Foundry or elsewhere, the method outlives the tool: it's how I work.

Why does this make AI trustworthy?

The real obstacle to AI in business isn't power: it's trust. A tool that occasionally makes things up doesn't get near your processes, and rightly so. Instead of letting the AI answer "from memory", you let it consult your data first. If that data is connected in a graph governed by an ontology, the AI follows your company's real links, even several hops away (supplier → component → product → client), which plain text similarity can't do. Answers become verifiable: you can always ask "where did you get that?", which is the minimum bar for putting an answer in front of a client.

How widely is this used today?

Gartner predicts that by 2029, 40% of enterprises will use GraphRAG techniques to improve the accuracy and reasoning of their AI. The strongest source here is Microsoft Research, which sells no graph technology and publishes its methodology: its GraphRAG consistently beats classic RAG on questions that demand joining several pieces together, not a fixed multiplier but a real gain in multi-hop reasoning. As directional confirmation, not as the main proof, add two independent-of-each-other benchmarks that happen to both come from graph-technology vendors (so neither is a third-party test): one from data.world across 43 real business questions and one from Diffbot and FalkorDB, landing on the same order of magnitude: the exact same model jumps from roughly 17-20% correct answers to over 50% once the data gets a graph structure instead of raw SQL, a 3 to 3.4x gain in both cases. Translation: connecting your data isn't decoration, it moves the numbers, and the strongest confirmation comes from the one source with nothing to sell.

And the market is backing it with its wallet: in July 2026 Snowflake launched Cortex Sense, a contextual "grounding" engine for enterprise AI agents. Another major vendor, the same underlying idea: ontology first, agent second. The principle isn't a Palantir exclusive.

When you DON'T need it (yes, that's a thing)

If you have small and tidy data and simple questions, a graph is complexity that won't pay you back, so skip it. It helps when data is scattered across systems that don't talk, the valuable questions span several things, and you need AI that explains itself. Question first, tool second. Always.

In short

Trustworthy AI doesn't come from a bigger model, but from data that finally talks to each other. The knowledge graph is how you get it talking; the ontology is the grammar. The platform (Palantir or otherwise) is chosen afterwards, once the graph and the ontology are settled. And it's the same graph that becomes common ground when it's not just one model "talking", but multiple AI agents that need to coordinate with each other. The same principle, applied to location data, sits at the center of geospatial data governance.