Main Takeaways

• Taxonomy building is harder than it looks — anticipating synonyms, avoiding bias, and writing machine-readable definitions for every concept is far more work than designing a simple hierarchy.
• Use LLMs for branches, not the whole tree — AI handles synonym generation, term comparison, and gap-filling well; full taxonomy generation still produces messy, classification-style output.
• Prompting is a skill most taxonomists don’t have — purpose-built tools remove the barrier of crafting expert prompts every time you need a usable result.
• Being inside the workflow is the real advantage — reviewing and accepting suggestions without leaving the tool beats copying and pasting from ChatGPT every time.

Taxonomies and ontologies are both fundamental semantic components of knowledge graphs, semantic layers, and the semantic backbone for enterprise data, information, and knowledge access. Taxonomy modeling, especially compared with ontology modeling, is relatively simple, since it is based on just hierarchies. Taxonomy building is not so easy. The apparent ease of taxonomy modeling, however, may result in not devoting enough resources to actual taxonomy building.

Taxonomy building involves various challenges, including:

• Understanding the detailed concepts of a subject domain
• Anticipating all the variant (alternative) names or labels for a concept that may occur in sources or searches
• Knowing how best to construct unbiased, logical hierarchies that are machine-readable and can support various applications, instead of an individual’s navigation design
• Supporting the various context-supporting requirements of AI systems, such as GraphRAG, including writing definitions for all concepts
• Having sufficient time and resources to create a full taxonomy, especially when it’s part of a larger project that requires competing resources.

How AI addresses the challenges of building of taxonomies

Generative AI and LLMs can help with all of these challenges. In general, taxonomies connect varied users to varied content so anticipating possible text strings in searches and in target text is an important part of creating concepts and their labels. It is best to get viewpoints from multiple participants or stakeholders when creating a taxonomy. LLMs are good at anticipating text strings, so LLMs are well-suited for generating taxonomies. Furthermore, LLMs can serve as “additional viewpoints” for creating a taxonomy, and can provide even more suggestions when a generation request is repeated.

Understanding the subject domain

LLMs are trained on huge data sets in all subject domains, so they can define, relate, and compare concepts to create taxonomies instantly. In comparison, human taxonomists have limited subject matter expertise and require a lot of time to research concepts without AI.

Generating sufficient variant/alternative labels for concepts

LLMs similarly identify all possible synonyms or alternative labels for concepts, whereas an individual human may think up far fewer and needs to spend time researching multiple sources to come up with more alternative labels.

Knowing how best to construct hierarchies:

Those who are not taxonomy experts tend to create taxonomy hierarchies modeled on navigation hierarchies or classification schemes that make sense to them alone, but are not valid taxonomies for general use. LLMs correctly interpret prompts for taxonomies, and do a reasonably good and consistent job at it.

Creating definitions for concepts

This is a tedious task for taxonomists or subject matter experts, who don’t usually spend their time writing definitions. LLMs extract from multiple sources to generate original and correct definitions, especially for the newer requirements of newer AI applications and GraphRAG systems.

Having the time and resources to create a full taxonomy

Taxonomies are increasingly built as part of a larger system, such as a semantic layer, a knowledge graph, or a GraphRAG system. There greater resources are spent on other technical components, leaving limited time and resources for taxonomy development.. LLMs and generative AI are a great time saver.

Why full taxonomy generation falls short

Taxonomists and subject matter experts have been experimenting with generative AI in taxonomy creation and its related tasks since as soon as these tools became available. Early attempts at generating full taxonomies were not acceptable. The LLMs either extracted from multiple sources and pieced them together in an inappropriate and inconsistent manner (resulting in, for example, the same concept appearing in different levels of the hierarchy or with different preferred labels), or the LLMs took original copyrighted taxonomies.

Although taxonomy generation results have improved over the intervening years, generating a full taxonomy from the top is never perfectly suited for a specific use case. No matter how detailed your prompt is, it cannot sufficiently explain everything. It’s best to manually design the highest structure of the taxonomy, the concept schemes, to take into consideration your users, your data and content, and your implementation.

Where LLMs excel: taxonomy sub-tasks

LLMs have proven more successful in other tasks than building full taxonomies. Taxonomy owners usually use LLMs to assist with creating smaller parts of taxonomies, such as specific hierarchy branches. Taxonomists also use LLMs for various related tasks.

These tasks have included, among other uses:

• Generating a list of narrower concepts for a specific concept or category, especially in generic (non-proprietary) subject domains, such as science, technology or medicine.
• Generating a list of synonyms/alternative labels for a concept
• Comparing two technical (unfamiliar) terms to determine if they are synonyms, one is broader than the other, or if they are overlapping and/or related
• Structuring a flat list of terms, such as extracted by text analytic, search logs, or user brainstorming, into a 2–3 level hierarchy
• Generating SPARQL queries with instructions in order to generate reports or batch edit taxonomies in SKOS, which is based on the RDF data model
• Developing stakeholder interview questions for the taxonomy design phase

AI generation for sub-tasks to the entire taxonomy generation allows more opportunity for human review. There is also a greater likelihood to get sources generated by the LLM for limited-scope tasks. In contrast, there is little transparency to the sources when generating an entire taxonomy, compared to more limited tasks.

What is also interesting is that both novice and experienced taxonomists, along with subject matter experts who are not taxonomists, use LLMs and Generative AI to assist with taxonomy creation and development. Thus, all can benefit from the integration of LLMs into taxonomy management systems, such as Graphwise Graph Modeling (PoolParty).

What Graph Modeling’s Taxonomy Builder feature can do

Graphwise began developing ways to integrate LLMs into the taxonomy creation workflow of PoolParty as soon as LLMs became publicly available. The initial focus was on using LLMs to suggest (or advise) specific sub-tasks of taxonomy generation: narrower concepts, alternative labels, and definitions for a concept, in a feature called Taxonomy Advisor, introduced in PoolParty 2024.

The ability to generate with AI a full hierarchical taxonomy, whether as a branch from any starting node or even from the start of an empty taxonomy project, was introduced earlier this year as the Taxonomy Builder feature with PoolParty 10.1. What was previously called Taxonomy Advisor has become the “Extend Your Taxonomy” function of Taxonomy Builder in PoolParty 10.2.

Taxonomy Builder builds or extends taxonomies that are customized for your domain by taking into account the context of the taxonomy you have created so far and the additional optional settings and instructions you provide. Alternative labels and definitions can be generated at the same time as the concept hierarchy generation or can be generated from an individual selected concept as part of its details. All generated concepts, alternative labels, and definitions are first presented as suggestions for the user to accept, edit, or deselect before committing to the taxonomy.

Taxonomy builder advantages over publicly accessible LLMs

It’s true that Taxonomy Builder does not do everything that LLMs possibly can do with respect to taxonomy development (although more features for it are planned). But using Taxonomy Builder as a part of Graph Modeling has distinct advantages and benefits over simply going to a public generative AI web tool (ChatGPT, Claude.ai, Google Gemini, etc.)

Incorporation into the taxonomy building workflow

It’s far easier and quicker to select from among generated suggestions right within the Graph Modeling system. With a few clicks the user can add AI-generated concepts, alternative labels or definitions to the appropriate taxonomy node. This is more efficient than switching to another application and then copying and pasting results or reformatting generated answers into an importable spreadsheet. As a consequence, you are more likely to use LLMs for taxonomy creation when using Taxonomy Builder than if you had to go out to a web URL of a generative AI platform. This means you are more likely to build out a fuller taxonomy.

Use of the optimal combination of LLMs

On your own, you would need to select which generative AI tool to use, and you might not be sure which is best for the task. Taxonomy Builder utilizes an appropriate combination of LLMs, because different LLMs are better at different tasks pertaining to taxonomy development.

No need for writing complex, detailed prompts

A major obstacle to getting suitable generative AI results is the challenge of writing sufficiently clear and detailed prompts. Prompting for various taxonomy development tasks is not something that most taxonomists do often enough to get good at.

Taxonomy Builder facilitates the task by taking information from multiple sources (project name and description, concept scheme name and description, taxonomy context, selections from among the setting, in addition to a user’s instructions) along with its own prescription prompt templates to create the optimal set of instructions.

Taking existing taxonomy context into consideration

Taxonomy Builder instructs the LLMs to build out a taxonomy that follows the example of existing taxonomy concepts that are broader, narrower, or sibling concepts of the selected concept from which to generate taxonomy. Context informs the label format style, the specificity of concepts. For example, a hierarchy of food concepts will not be the same if they are of different contexts of agriculture production, grocery store offerings, recipes, or for nutritional recommendations.

Quickly generating usable starter taxonomies

The “Build Your Taxonomy” feature in Taxonomy Builder very quickly generates a multi-level taxonomy with suitable concepts and added features of alternative labels and definitions, to which you may add more depth or more sibling concepts. By contrast, Generative AI web tools, in their free versions, either take too long, may time out and give up, or take too many follow-up instructions (using up the daily free allowance) before generating results in a usable form.

More suitable AI results with Taxonomy Builder

Comparison tests of full taxonomy generation with identical prompts in ChatGPT, Claude, Google Gemini, and Graphwise’s Taxonomy Builder for the same subject resulted in taxonomies with more suitable concepts for tagging in Taxonomy Builder. In comparison, the other generative AI applications had results that were more like classification schemes with comprehensive categories at each level.In the case of Claude, the hierarchical levels were even named (Domain, Category, and Tag).

It seems as if Taxonomy Builder has a better understanding of “taxonomy” for information retrieval. The other generative AI services also sometimes suggest incomplete or adjectively (and thus ambiguous) labels, such as Enterprise, Creative, and Infrastructure, to refer to types of software.

In comparing results for generated alternative labels in the public generative AI tools (with the prompt for “synonyms or alternative labels”) and Taxonomy Builder, the public generative AI tools provide many more, not so suitable results, often with broader meanings. For example, for Productivity Software, synonyms generated included Information Worker Software, Professional Tools, Collaboration & Productivity Tools, Workforce Software, and Enterprise Software. By contrast, the alternative label suggestions from Taxonomy Builder are more tight and focused: Business software, Business tools, Office applications, Office programs, Office software, Productivity tools, Task management software

Furthermore, the long, detailed answers that generative AI services now tend to provide can take time to read through. Taxonomy Builder provides more concise responses that can quickly be selected from.

To wrap it up

Taxonomy Builder provides appropriate results, of a suitable number, that can efficiently be reviewed and selectively included within the taxonomy creation and editing workflow. It assists subject matter experts, novice taxonomists, and experienced taxonomists. The result is a fuller taxonomy, built in less time, with better coverage — and an AI system that can actually use it.

Originally published at https://graphwise.ai on July 3, 2026.

Main Takeaways

• Graphwise is launching Graphwise Platform Pulse, a quarterly initiative and webinar series dedicated to help companies maximize ROI during their AI journey — starting live on July 2, 2026
• The Graphwise Platform delivers the Semantic Backbone for enterprise AI to merge all our components into a single, end-to-end secure framework. Each one builds on the output of the one before it, turning fragmented data into governed, AI-ready knowledge your organization can actually trust.
• Organizations that build on the Semantic Backbone get 100% deterministic, explainable AI responses grounded in verified enterprise facts, with multi-hop reasoning across every data source and zero tolerance for hallucination.

GenAI is smart. But it has no idea what your business knows, how your data is connected, or which answers it should trust. This results in uncertainty in AI due to the constant hallucinations it responds with. And yet, enterprise investment in AI has never been higher. McKinsey reports that over 88% of organizations have deployed AI in at least one business function — but only 11% have managed to scale it successfully.

The core issue is that most single AI tools have no corporate memory. They don’t know your business data, your processes, or your priorities. When they hit a gap in their knowledge, they confidently hallucinate, making up facts that sound authoritative but have no grounding in reality. If you add to that their inability to connect information across data silos, you have an AI that is simultaneously overconfident and underinformed. For most enterprises, that combination plummets ROI before a project ever reaches production.

What Actually Fixes AI Hallucinations?

Graphwise’s Platform is the solution to AI hallucinations. Think of it as giving GenAI a “business brain” that completely understands your business POV. Instead of letting an AI guess based on general information, Graphwise builds a solid semantic layer that connects your siloed data, documents, and unique business logic into one.

By grounding the AI in this verified source of truth, we eliminate those unpredictable hallucinations and replace uncertainty with reliable facts. It guarantees 100% deterministic, explainable AI responses with multi-hop reasoning (the ability to connect pieces of information across entirely different systems) while automatically generating the data pipelines via AI-assisted modeling.

This blog post introduces the Graphwise Platform and explores how it provides a trustworthy, scalable foundation for enterprise AI.

If you’d rather see it in action, you can join our Platform Pulse webinar on July 2 for a live end-to-end demonstration.

How the Graphwise Platform works as one framework

Most enterprises stitch together their AI infrastructure from separate tools using a database here, a modeling layer there. Graphwise platform provides the complete end-to-end framework that maps, transforms, stores, and connects your enterprise data to AI, without the integration overhead of managing multiple vendors.

Instead of a company having to buy, stitch together, and maintain different software vendors to build a secure AI data pipeline, Graphwise does it all in a unified environment, dividing the journey into two distinct, manageable business phases.

Phase 1: Establishing the structural foundation

Step one starts with a simple question: what kind of enterprise knowledge are you trying to make AI understand?

For some organizations, the most valuable knowledge is hidden in unstructured content — PDFs, policy documents, manuals, emails, research papers, contracts, reports, and internal knowledge bases. For others, it lives in structured systems — SQL databases, MongoDB, CRM platforms, IoT systems, digital twins, or operational applications. Most enterprises, of course, have both.

What you need to know before you start?

Graphwise starts by helping you map the logic behind your knowledge.

• If your data is unstructured, the platform helps you build and manage taxonomies. This gives your organization a controlled vocabulary, so different documents, teams, and systems stop using different words for the same thing. It reduces ambiguity and helps AI understand the language of your business more consistently.
• If your data is structured, Graphwise uses ontologies to map out the real-world relationships behind it. This is where the platform defines how products connect to suppliers, how assets connect to locations, or how employees connect to processes. In other words, it does not just describe your data. It describes how your business works contextually.

Step 1: Modeling business logic

This step is powered by Graph Modeling. Instead of asking teams to manually build complex models from scratch, Graph Modeling uses LLMs to suggest concepts, synonyms, relationships, and business rules. But the human expert stays in control. Users can accept, edit, or reject every recommendation, so the final model reflects real business knowledge rather than a generic AI guess.

Step 2: Linking enterprise data

Once the rules are defined, Graph Automation turns them into something operational.

This is where the platform starts connecting your actual enterprise data. Graph Automation coordinates repeatable data and transformation pipelines across systems like SharePoint, SQL databases, content repositories, etc. Instead of leaving your data scattered across separate tools, it brings those sources into one governed flow.

Inside that, Semantic Analytics enriches the content. It identifies entities, extracts concepts, applies metadata, and automatically tags information so that previously hidden knowledge becomes visible to the system. Each piece of information thus becomes part of a larger network of meaning and context.

That enriched knowledge is then stored in GraphDB, Graphwise’s enterprise-grade semantic graph database. GraphDB holds your data as an interconnected web of facts, where relationships are explicit, governed, and queryable. It also supports native reasoning, which means the platform can infer new insights from the relationships already present in the graph.

This is the moment where disconnected data becomes a single source of truth. Not because everything has been copied into one giant repository, but because everything has been connected through shared meaning.

Phase 2: Deploying the semantic layer and powering intelligence

Once the knowledge graph is built and securely stored, the platform is ready to power AI applications with GraphRAG.

Traditional retrieval approaches often rely on finding text that looks similar to a user’s question. In enterprise environments, that is rarely enough. Important answers are usually spread across multiple systems, documents, and business relationships.

Step 3: GraphRAG implementation

GraphRAG uses the knowledge graph to assemble verified business context before generation happens. Instead of relying on disconnected fragments, the AI works from governed enterprise facts, enabling traceable responses and multi-hop reasoning across different data sources.

That is what makes the Graphwise Platform different from a collection of AI tools. The value is not only in each component, but in how they work together:

• Graph Modeling defines the business meaning
• Graph Automation activates it across enterprise systems
• Semantic Analytics enriches unstructured content
• GraphDB stores it as a governed web of facts
• GraphRAG retrieves from that trusted foundation.

Step 4: Agentic horizon

Once that foundation exists, it becomes reusable across search and recommendation, analytics, AI assistants (like Graphwise for M365), and future agentic workflows instead of requiring a new pipeline for every use case.

It also prepares organizations for what comes next: autonomous AI agents. Because the platform creates a unified model of the business, future agents can operate with the context, memory, and governance needed to support complex enterprise workflows safely and reliably.

Originally published at https://graphwise.ai on June 24, 2026.

Main Takeaways

• A knowledge graph isn’t just a fancier database — the crucial step is adding semantics and inference, so the system can reason about relationships (e.g. “indigo is a shade of blue”), not just look things up.
• Vector RAG’s core flaw is fragmentation — chunking severs the natural links between related content, and similarity search can’t reconstruct those connections, leading to incomplete or misleading answers.
• GraphRAG makes retrieval explainable and auditable — because answers follow a traceable path through explicit relationships, you can cite the exact concept, clause, and source — not just “the LLM said so.”
• Two real deployments, same verdict — whether starting from structured DITA XML or 600 unorganized PDFs, GraphRAG delivered measurably more accurate, complete, and consistent answers than vector-only baselines.

Retrieval Augmented Generation (RAG) has quickly become the default architecture for grounding large language model (LLM) responses in factual, domain-specific information. However, as enterprise adoption matures, awareness of its limitations has also grown — fragmented retrieval, semantic ambiguity, poor explainability, and brittleness that scales poorly with data complexity.

The question is no longer whether RAG is useful, but whether the vector-only implementation that most teams initially choose is actually fit for purpose. In this post, we argue that it often is not. We also explain exactly what GraphRAG offers instead, supported by two anonymized enterprise deployments from our work at Graphwise.

From graphs to knowledge graphs

It is important to begin with a distinction that is crucial for downstream AI applications: the difference between a plain property graph and a knowledge graph. A raw property graph is useful for traversal and pattern matching, but it cannot generalize beyond what is explicitly encoded. There is no mechanism for the graph to recognize that “sneakers” and “running shoes” belong to the same category or that “indigo” is a shade of blue. It can answer literal queries but cannot reason.

First, semantics are layered in — domain ontologies and taxonomies are imported and mapped onto the existing data, giving concepts shared meaning and arranging them into coherent hierarchies. Colors become organized into warm and cool palettes. Product types nest under common categories. This alone materially improves data quality, search precision, and governance.

The second step is inference: an inference engine runs over the enriched graph and generates new relationships automatically — relationships no human has explicitly typed in, but which follow logically from the rules and ontology in place. The result is a graph that can reason, not just retrieve.

This distinction matters at enterprise scale because knowledge graphs are not just a storage mechanism. They are a semantic layer that sits between raw data and every downstream consumer.

On one side, unstructured content such as documents, emails, and SharePoint sites is processed by generative AI components that extract entities and index them into a content hub. On the other, structured source systems are connected via a semantic data fabric that preserves lineage and governance. The knowledge graph unifies both sides into a single queryable layer that feeds generative AI applications, BI dashboards, operational systems, and analytics pipelines alike.

What RAG does and where it falls short

Standard RAG is conceptually straightforward. Documents are split into chunks, embedded into vector representations, and stored in a vector database. At query time, the user’s question is embedded and matched against stored chunks using a similarity metric such as cosine similarity. The closest matches are ranked and subsequently retrieved and provided to an LLM as context. This approach works well for simple question-answering over relatively homogeneous document sets. Problems arise at scale and in knowledge-intensive domains.

The first issue is knowledge fragmentation. Chunking is a destructive operation; it severs the links between sections of a document that were intended to be read together, thus creating disjoint pieces of knowledge. For example, a healthcare policy document may spread a single coverage rule across multiple chunks. If we retrieve any one of these in isolation, the answer is incomplete.

The second issue is contextual mismatch.Vector similarity fundamentally struggles with the nuances of human language, especially when handling complex, technical, or domain-specific concepts. It maps both questions and potential answers into a vector space, but often fails to capture underlying relationships, logical connections, and factual context between pieces of information. As a result, the system frequently retrieves content that is semantically similar — using similar vocabulary or covering the same general topic — but is contextually or factually irrelevant to the user’s specific query.

The third problem is semantic ambiguity. This type of ambiguity occurs when a word or phrase has multiple possible meanings, and without further context or explicit relationships (like those a graph provides), a system (like a RAG system) struggles to determine the intended meaning. For example, the term “benefit” has two different healthcare-related meanings (insurance coverage vs. wellness services), which a simple text search might fail to distinguish, leading to irrelevant or mixed retrieval.

Beyond these retrieval-quality issues, there are systemic challenges related to cost and maintainability. Updating a vector index when source data changes requires re-encoding, which is computationally expensive at scale. Because the system operates as a black box — similarity scores are not explanations — provenance is poor. Prompt engineering can nudge an LLM toward citing sources, but it cannot make the retrieval process genuinely explainable. Hallucination risk remains high because there is no structured semantic guardrail on what is retrieved or how it is assembled into a response.

What GraphRAG adds

GraphRAG is best understood as an architectural extension of RAG rather than a replacement. It retains the LLM as the generative component but replaces or augments the vector retrieval layer with a knowledge graph that preserves the structure, context, and relationships of the underlying data. As a result, the content passed to the LLM is not just a collection of similar-looking text chunks; it is semantically structured, relationally aware, and traceable to explicit sources.

The practical benefits are clear. Knowledge graphs enable multi-hop reasoning: instead of retrieving only the most similar chunk, the system can traverse a graph to follow a chain of relationships — linking, for example, a physiotherapy treatment to an insurance coverage rule to a specific policy clause — before assembling a response. This greatly reduces the noise problem, as the graph acts as a guardrail, constraining retrieval to semantically relevant paths rather than relying solely on embedding similarity.

Entity disambiguation also improves substantially. For example, a knowledge graph can encode that HER2 and ERBB2 refer to the same gene, or that “benefit” in a healthcare context maps to distinct concept nodes depending on the surrounding entities or context.This is the type of expert domain knowledge that vector embeddings simply average out.

Explainability is another meaningful gain. Because the retrieval path through a knowledge graph is a sequence of explicit relationships, it is auditable. The system can cite not just a source document but the specific concept node, relationship, and document section that informed the answer. This matters in regulated industries and enterprise contexts where “the LLM said so” is not an acceptable justification for a decision.

Case study 1: Technical documentation for a construction company

The first deployment we want to share involved a construction company with a large collection of technical product documentation structured according to the DITA standard. The problem was familiar: a technician on a construction site needing precise, actionable information about a hydraulic system would get generic answers from a public LLM and imprecise results from keyword search. The knowledge was in the documentation; the challenge was retrieval quality and specificity.

The project had five distinct phases.

The first phase was data transformation. DITA-structured XML was converted to RDF, with careful attention to mapping the DITA content model to RDF triples. This preserved the document structure and the relationships between topics, components, and procedures.Documents that did not conform to DITA were structured using IRI-based schemas, then linked to the DITA-derived graph nodes to provide a unified semantic layer across the entire content corpus.

The second phase involved initializing the project using the knowledge graph. This required identifying which documents corresponded to specific parts of the product taxonomy and making those relationships explicit and queryable.

The third phase involved building the search interface. It provided semantically aware answers that included not only text but also images, URLs to web documentation, and troubleshooting videos stored in separate systems. The goal was to consolidate all relevant content into a single, coherent retrieval surface, regardless of its original storage location.

The fourth phase focused on improving query understanding. User intent, not just keyword matching, could now be captured. The system returned results specific to the product and fault context rather than generically plausible ones.

The fifth and final phase was the deployment of the GraphRAG prototype. The working application used structured technical content and the knowledge graph to deliver contextually aware and precise answers. It significantly outperformed both baseline LLM responses and vector-only RAG in correctness and specificity, a result validated by early stakeholder feedback confirming improved relevance in real-world queries.

Case study 2: Unstructured internal documents for a research organization

The second deployment addressed a different starting point: a large German research organization with approximately 600 internal PDFs and documents in German and English, without an existing structured data model or manual annotation. The question we set out to answer was whether GraphRAG could deliver meaningful gains over vector-only RAG without requiring an expensive upfront knowledge engineering effort.

Our approach focused on taxonomy-driven semantic enrichment. We first applied standard chunking and multilingual embedding, resulting in a vector layer comparable to a conventional RAG baseline. The differentiating step was overlaying our Graph Modeling taxonomy and ontology on top of every chunk, automatically annotating each one with concept tags drawn from a custom knowledge model.

These tags gave each chunk a semantic fingerprint, anchoring it to a position in the domain concept hierarchy instead of leaving it as a free-floating embedding. SPARQL-based enrichment rules were then applied to merge raw tags with broader and related concepts. This captured the full domain hierarchy and made cross-concept relationships explicit. The knowledge model was built using our corpus analysis tools to extract candidate concepts directly from the document set. In this way, the semantic layer emerged from the content rather than being imposed externally.

The resulting index combined full-text search with faceted filtering over the taxonomy. This allowed retrieval to be constrained by concept, category, or relationship type, in addition to embedding similarity.

The following example illustrates the performance gap. When a user asked for the full duties and responsibilities of the Chief Information Officer (CIO), the vector RAG system returned brief, generic sentences that omitted key responsibilities and did not highlight the relationship between the CIO and the IT Management Director. As a result, the user had to open multiple PDFs and verify answers manually.

Our GraphRAG system returned a multi-sentence answer listing all six CIO responsibilities with the relevant policy clause. Across the full evaluation set, GraphRAG achieved 95% correctness, on average, and significantly fewer hallucinations than the vector baseline. It also showed a smaller standard deviation, indicating more consistent performance across query types.

Building a semantic layer for AI

Both projects highlight the same underlying requirements for a production-grade GraphRAG system. Data preparation is essential — the garbage-in, garbage-out principle applies regardless of how sophisticated the retrieval architecture may be.

For structured data, this requires upfront investment in transformation to RDF, careful ontology mapping, and relationship modeling. The initial effort is greater than for unstructured data, but the result is a graph that is highly customizable, easy to extend as new data arrives, and reusable across projects beyond GraphRAG.

For unstructured data, the investment is lower — automated tagging and taxonomy-driven enrichment can deliver significant gains without manual annotation — but some knowledge modeling is still required to maximize the value of the semantic layer. LLM integration and prompt design remain important but are increasingly secondary concerns. Fine-tuning is largely impractical for most enterprise organizations due to data and compute requirements. The more practical approach is effective prompting combined with a rich, well-structured retrieval layer that reduces the work the LLM must do in synthesizing an answer. Retrieval and reasoning quality depends directly on the quality of the knowledge graph — which is why the data preparation phase cannot be shortcut.

Evaluation should be integrated from the beginning, not added at the end. In both projects, we used a combination of quantitative scoring against test case sets and qualitative stakeholder feedback to identify where retrieval was falling short and which parts of the semantic layer needed refinement. This iterative evaluation loop enables a GraphRAG system to improve over time rather than stagnate at its initial accuracy level.

To wrap it up

The case for GraphRAG over vector-only RAG is not primarily theoretical — it is demonstrated in production. Our deployments show that, whether the starting point is well-structured technical documentation or a heterogeneous corpus of internal PDFs, grounding retrieval in a knowledge graph delivers measurably better answers. More accurate, more complete, more explainable, and more consistent.

For data engineers and architects evaluating RAG architectures for knowledge-intensive enterprise applications, the evidence is clear. Vector embeddings are a powerful tool, but they are not truly semantic. In domains where context, relationships, and domain-specific meaning are essential to the user, the graph-based semantic layer is not optional. It is the foundation that enables the rest of the system to function.

Originally published at https://graphwise.ai on June 10, 2026.

Main Takeaways

• Traditional RAG breaks down at scale — what gets AI to production fast eventually creates fragmented pipelines, rising token costs, and maintenance overhead that’s hard to control.
• GraphRAG replaces pipelines with a shared knowledge layer — instead of duplicating indexes per use case, one reusable graph serves multiple AI applications, cutting sprawl and engineering effort.
• Structured retrieval directly lowers LLM costs — by surfacing only relevant context rather than broad chunks, GraphRAG can reduce token usage by up to 80%.

Once AI moves into production, cost predictability and operational control quickly become critical concerns. AI systems rely on multiple components, including graphical processing units (GPUs), data pipelines, retrieval layers, and external APIs. This makes it difficult to forecast, spend, or control long-term operational costs. As a result, 85% of organizations miss AI cost forecasts by more than 10%, largely due to limited visibility and infrastructure complexity.

To address this, many teams adopted retrieval-augmented generation (RAG). RAG simplified early AI deployments by grounding models in external data and reducing retraining, helping teams ship AI features faster.

However, as RAG systems scale, new challenges emerge. Fragmented retrieval layers, repeated indexing, and growing operational overhead make systems harder to maintain and control. The challenge isn’t just building AI, but building RAG-based systems that scale sustainably.

Graphwise’s GraphRAG addresses these limitations with a graph-based approach that reuses existing data structures, reduces redundant retrieval and retraining, and lowers operational overhead. This leads to faster deployment, lower maintenance, and more predictable delivery while maintaining performance.

This article explores why traditional RAG becomes costly at scale and how GraphRAG offers a more sustainable path forward.

How traditional RAG simplified early AI deployments

Enterprise AI development has long been constrained by high costs and architectural complexity. AI systems required significant compute resources, extensive data preparation, and deep integration with existing enterprise systems, all of which slowed deployment and inflated budgets. Traditional RAG helped reduce these barriers and made AI more accessible.

Here’s how traditional RAG simplified the complexities of early AI development.

Infrastructure and compute costs

Many early AI systems ran across fragmented environments. Today, 61% of enterprises operate AI workloads in hybrid setups, which makes cost management more difficult. At the same time, compute requirements kept increasing. Since 2016, compute costs for large AI models have grown roughly 2.4x per year.

Traditional RAG helped control this by reducing the need to retrain models every time enterprise data changed. Instead, systems could retrieve relevant information at query time, lowering compute usage and making early deployments more affordable.

Data preparation complexity

Data preparation has historically taken up most of an AI project’s timeline. Teams spend a large part of their effort cleaning, labeling, and integrating data before systems can deliver any real value. This process often consumes a significant share of both time and cost.

Traditional RAG simplified this process by allowing teams to work directly with existing documents and knowledge repositories. This reduced upfront data transformation and accelerated the path from experimentation to usable AI applications.

Integration with legacy systems

Integrating AI with legacy applications, databases, and workflows has been another major hurdle. 67% of organizations report significant challenges integrating AI with legacy systems — with integration efforts increasing project costs by an average of 82%.

Traditional RAG lowered integration friction by layering retrieval over existing systems rather than replacing them. This lets AI augment current workflows with minimal disruption.

The limitations of traditional RAG architectures

Traditional RAG helped organizations get AI into production faster. But as use cases expanded and systems grew, RAG’s limitations became harder to ignore. What worked well for early deployments often struggled under real-world scale and complexity.

Some of the limitations include:

• Frequent re-indexing and embedding rebuilds — Text-only or vector-based RAG systems rely on embeddings that must be rebuilt whenever data changes. As datasets grow or update frequently, this creates ongoing maintenance work and slows iteration.
• Inefficient retrieval and rising LLM costs — Traditional RAG typically retrieves large chunks of loosely related content. This broad retrieval increases prompt size, drives up token usage, and slows response times — making costs harder to predict at scale.
• Growing architectural sprawl — Each new AI use case often comes with its own pipelines and vector indexes. Over time, teams end up maintaining multiple parallel systems. This increases maintenance effort and makes the overall setup harder to manage.
• Limited understanding of context and relationships — Vector similarity alone struggles to capture how pieces of information relate to one another. In complex domains, this leads to shallow context, inconsistent answers, and more manual validation.

Graphwise GraphRAG: A reusable, grounded RAG architecture

As AI systems scale, teams need retrieval approaches that reduce time spent searching, reworking data, and managing fragile pipelines. Research shows that unstructured retrieval approaches demonstrate significantly lower efficiency and accuracy compared to graph-based retrieval in complex QA tasks. Graphwise’s GraphRAG is designed around this principle.

GraphRAG combines knowledge graphs with large language models to clearly separate knowledge modeling from language generation. Instead of relying only on document chunks or vector similarity, GraphRAG represents enterprise knowledge as connected entities and relationships. These relationships guide retrieval, allowing the system to surface precise, context-aware information rather than broad sets of loosely related text.

This structured approach changes how users interact with information. Queries can move directly through connected concepts, making it easier to surface summarized facts and grounded answers — even in complex enterprise environments.

GraphRAG introduces several architectural advantages over traditional RAG approaches:

• Reusable knowledge foundation — Knowledge is captured in a shared graph and reused across multiple AI applications and assistants.
• Simpler updates and evolution — Changes happen at the graph level, without retraining models or rebuilding embeddings when data evolves.
• Reduced system sprawl — A shared knowledge layer replaces duplicated pipelines, indexes, and retrieval logic.
• More controlled retrieval — Structured relationships help limit context to what’s actually relevant, improving efficiency and grounding.

GraphRAG vs. traditional RAG

Traditional RAG and GraphRAG handle complexity and scale differently in the following ways:

How GraphRAG reduces AI development and operational costs

GraphRAG streamlines AI development and operations by leveraging a reusable, graph-based architecture. It helps teams deliver AI faster, maintain less, and scale more effectively.

• Teams can build new AI applications on previously modeled knowledge, which reduces repeated engineering effort and accelerates development.
• Changes to data or business rules happen directly in the graph, avoiding full pipeline rebuilds or costly retraining cycles.
• Only the most relevant context is retrieved, which lowers token usage, reduces inference costs, and improves response efficiency.
• Grounded retrieval minimizes hallucinations and cuts down on redundant validation, ensuring outputs are trustworthy.
• Relationships and insights captured once in the graph can be applied to multiple AI applications. This capability helps reduce duplication and simplify scaling AI use cases.

With these capabilities, GraphRAG reduces development and operational overhead. It also provides a foundation for more predictable and cost-effective AI adoption.

GraphRAG ROI: Faster development and lower maintenance

Graphwise GraphRAG delivers measurable improvements in AI development speed, operational efficiency, and cost predictability.

• Faster build time — Teams can move nearly 2.7x faster, with searches running 40% quicker and over 30 minutes saved per query. This significantly accelerates development cycles.
• Lower maintenance hours — Manual tagging is cut by 60%, while duplicate and redundant work drops by 50%, so teams can focus on higher-value tasks.
• Predictable delivery — Targeted retrieval reduces LLM token usage by up to 80%, helping organizations keep project timelines and budgets under control.

Conclusion

AI development becomes expensive when systems grow fragmented and difficult to maintain. While traditional architectures helped teams get started, they often introduce long-term complexity — rising operational costs and unpredictable delivery timelines.

Graphwise GraphRAG offers a more sustainable path forward. It simplifies development, reduces maintenance effort, and lowers ongoing LLM usage by grounding AI systems in reusable knowledge graphs. Teams can build once, reuse knowledge across use cases, and scale AI without constant rework.

The result is smarter AI delivered faster, with costs easier to control and outcomes easier to trust.

Originally published at https://graphwise.ai on May 28, 2026.

Graphwise is proud to introduce Marta, a cutting-edge digital assistant designed to revolutionize how our users, clients, partners, and employees interact with and learn about the Graphwise ecosystem. Marta provides an efficient, personalized, and comprehensive learning experience, detailing our products and illustrating how they generate substantial business value across a multitude of industries.

Marta isn’t just another chatbot. She represents a fundamental shift in how we interact with complex data, built on a principle we at Graphwise hold dear: Drinking our own champagne.

The knowledge graph advantage

Marta’s capabilities are rooted in the core technologies of Graphwise:

• The Graphwise Platform: Providing Marta with the necessary processing power, data integration capabilities, and advanced graph algorithms to analyze complex product information and business outcomes.
• The Graphwise Knowledge Hub: A centralized repository of product documentation, case studies, value propositions, and industry-specific data, all interconnected via a knowledge graph, serving as Marta’s brain.

The difference between standard chatbots and Marta?

Contextual Intelligence. If you ask a standard AI about a complex business solution, it scans for keywords. If you ask Marta, she consults the Graphwise Knowledge Hub and sees the relationships between our products, industry-specific ROI, and real-world case studies.

A living demonstration of our technology

Marta is more than an assistant or informational tool. She is a living demonstration of the scalability and intelligence of the Graphwise Platform:

• No data silos: She integrates product documentation and business value propositions into a single, fluid conversation.
• Accuracy: Because she sits on top of a Knowledge Graph, her responses are grounded in the specific architecture of our ecosystem.
• Multi-agentic system: Marta is the first step toward a multi-agentic system, where she will eventually work together with other specialized agents to tackle diverse and complex informational queries, setting a new standard for intelligent digital assistance

Marta draws on a set of integrated tools to answer queries: it can query GraphDB using SPARQL, generate Mermaid diagrams, search the web, and more. She selects the appropriate tool — or combination of tools — depending on the nature of the query. A human-in-the-loop mechanism allows her to ask for clarification when uncertain. What this means for you

Marta provides a shortcut to expertise, whether you are:

• A client looking for a specific ROI calculation or deeper insights into strategic use cases
• A partner gaining comprehensive knowledge for effective solution selling
• A Graphwise user aiming to master Graphwise features and functionalities

You no longer have to dig through PDFs, technical manuals, or infinite landing pages. You simply ask, and Marta navigates the graph to find the exact intersection of information you need.

Originally published at https://graphwise.ai.

Main Takeaways

• ISO 42001 certification gives Graphwise a verifiable framework for EU AI Act compliance
• GraphRAG grounds every AI output in verified data, eliminating the “black box” problem
• Enterprises inherit Graphwise’s compliance infrastructure, reducing their own regulatory burden
• Annual third-party audits provide ongoing independent verification without extra customer effort

At a time when the EU AI Act or other similar frameworks such as the NIST AI Risk Management Framework have gone from being a proposal to becoming a binding legal reality, enterprises face a critical challenge: how to harness the power of large language models (LLMs) without compromising on safety, transparency, and legal accountability.

At Graphwise, we have anticipated this shift. By achieving the ISO/IEC 42001:2023 certification — the world’s first international standard for AI Management Systems (AIMS) — we haven’t just checked a compliance box; we have codified a rigorous development framework for our next-generation GraphRAG software.

ISO 42001: Our blueprint for EU AI Act readiness

Responsible AI frameworks demand that AI systems be safe, transparent, and explainable. While these frameworks provide the “What,” ISO 42001 provides the “How.” Graphwise utilizes this international standard to guide the entire lifecycle of our Graph RAG development:

• Systematic risk management: We apply the ISO-mandated risk-based approach to identify and mitigate biases and “hallucinations” at the architectural level.
• Data governance and integrity: Our certification ensures that the data fueling our knowledge graphs is handled with the highest standards of quality and lineage — a core requirement of the EU AI Act’s data governance mandates.
• Transparency by design: ISO 42001 requires clear documentation and explainability, which we manifest through our “Explainable Conclusion” engine in GraphRAG.

Why GraphRAG is the “Trust Layer” for your AI

Traditional RAG (Retrieval-Augmented Generation) often falls short of regulatory standards because it relies on “flat” vector searches that lack context. Graphwise GraphRAG goes further by combining LLMs with a semantic knowledge graph.

Its key compliance features are:

• Multi-hop reasoning: Unlike keyword searches, GraphRAG understands complex relationships, providing more accurate and contextually aware answers.
• Deterministic grounding: Every output is anchored to your proprietary, verified data, virtually eliminating the risk of misinformation.
• Audit-ready provenance: Every response includes clear citations and a “reasoning path,” allowing your compliance teams to see exactly why the AI reached its conclusion.

The customer advantage: accelerate your own compliance

When you choose us as a partner certified in ISO 42001, you aren’t just buying software — you are inheriting a compliant infrastructure that simplifies your own regulatory journey.

• Reduced due diligence: Graphwise’s third-party verified AI controls significantly lower the burden on your procurement and legal teams.
• Future-proofing: As regulations evolve, our ISO-aligned management system ensures that Graphwise software adapts proactively, not reactively.
• Accelerated “high-risk” approval: Graphwise operates under an ISO 42001 Artificial Intelligence Management System (AIMS), we provide “live evidence” — such as pre-packaged AI Impact Assessments and System Lifecycle documentation.
• Elimination of the “black box” liability: ISO 42001 requires maintaining rigorous Explainability and Interpretability controls. By using our GraphRAG, you inherit a “Traceability Chain” where every AI-generated answer is linked to a specific data source in your knowledge graph.
• Third-party vendor oversight: Our certification includes mandatory annual surveillance audits. This means an independent, third-party registrar is doing the “monitoring” for you. Instead of conducting a resource-intensive manual audit of Graphwise each year, you can fulfill your regulatory requirement to monitor and verify our compliance by simply maintaining a record of our current third-party certification.
• Ethical brand protection: ISO 42001 embeds Ethical Guardrails into the development process. By choosing a certified partner, you ensure that “Fairness” and “Bias Mitigation” are not just marketing buzzwords but are audited technical requirements, protecting your brand from the fallout of “rogue AI” incidents.

The EU AI Act is not a hurdle; it is a catalyst for better AI. By aligning our GraphRAG technology with the ISO 42001 standard, Graphwise provides the technical and legal “Trust Layer” your enterprise needs to innovate with confidence.

Originally published at https://graphwise.ai on May 5, 2026.

In the evolving landscape of the energy sector, the ability to efficiently interact with complex data models is becoming a necessity. This blog post explores the Talk2PowerSystem project, a collaboration between Statnett and Graphwise, that creates AI-based tools and methods to automate the analysis of complex power system models and deliver actionable insights for engineers.

Through the synergy of large language models (LLMs), Semantic Web technologies, and geospatial standards, Talk2PowerSystem aims to revolutionize the analysis of grid data. Today, power system engineers rely on the Common Information Model (CIM) — a robust but incredibly complex framework of standards (IEC 61970, 61968, 62325). While CIM is the gold standard for data, its sheer size makes crafting graph queries a daunting task for even the most seasoned engineers. Our vision is to let experts query these models using natural language instead.

Delivering on that vision of natural language querying is not straightforward: industry-standard ontologies are enormous, and while LLMs open up new ways to interact with knowledge graphs, their context windows are limited — feeding them verbose schemas can lead to confusion or lost instructions. In the rest of this post, we present three important aspects of our approach in Talk2PowerSystem:

• simplifying ontologies so LLMs can digest them efficiently,
• applying semantic reasoning to collapse deep CIM hierarchies into query-friendly shortcuts, and
• grounding the model in physical space with GeoSPARQL to unlock spatial querying and visualization.

Simplifying ontologies for LLMs: Lessons from the field

To enable a chatbot to reliably query complex ontologies, we needed to make them “LLM-friendly”. CIM for the electrical grid consists of over 20 parts (profiles) with a lot of duplication and complexity. Their union has over 900 classes and 5500 properties, but an actual grid data would use less than half of all ontology terms.

It is not only in CIM. Other standard ontologies, such as the ERA Vocabulary, are also designed for completeness. They often contain:

• Long descriptions of regulations
• Administrative metadata (creation dates, XML mappings)
• Translations in multiple languages
• Many unused classes and properties

When an LLM processes this raw data, it consumes many tokens and can lose focus on the relevant structure. We used a pipeline to clean and simplify the ontology before presenting it to the AI and employed the following key optimization strategies:

1. Pruning textual descriptions: An effective way to save tokens is shortening rdfs:comment fields by cutting descriptions at approximately 400 characters using SPARQL regex updates. This removes excessive legal citations or historical notes that do not help the LLM understand the current data structure, ensuring that the model focuses on the core definitions of entities.
2. Removing “bookkeeping” metadata: Ontologies are often cluttered with administrative data such as dct:modified dates, creator names, and contributor lists. While vital for governance, this information is “noise” for an LLM trying to generate a query. Deleting these properties significantly compacts the schema.
3. Enhancing presentation and formatting: The way Turtle (RDF) is serialized matters. Standard serializations often produce “ugly” output — scattered definitions, unordered terms, and confusing blank nodes for OWL restrictions. We recommend using tools like turtle-formatter to group classes, properties, and individuals logically and alphabetically. “Prettier” schemas lead to higher accuracy in query generation.
4. Ontology subsetting: Large-scale ontologies like CIM contain thousands of classes. However, specific datasets often use only a fraction of them. By subsetting the ontology — including only the classes and properties which are actually instantiated in the knowledge graph- developers can drastically reduce the token load.

By removing noise and reducing the size of the schema to 285 classes and 445 properties, we improved the LLM’s ability to generate correct SPARQL queries. A cleaner schema also saves tokens and helps the model focus on the relevant data structure. Further details of our approach can be found in this detailed technical blog: Simplifying Ontologies for LLMs: Lessons from the Field.

Beyond simplifying the schema, the project also had to address the logical complexity of how data is interconnected.

Using semantic reasoning to simplify LLM SPARQL generation for electrical CIM

We apply custom semantic reasoning to CIM in order to simplify deep graph hierarchies into manageable “shortcut” relations, making the data model more manageable for querying by LLMs.

The challenge: Deep nesting and long traversals

As already discussed, CIM is a robust standard for representing the entire electrical enterprise. However, its granularity makes querying difficult. A simple request like “List all substations connected via an AC-line to substation X” requires navigating a deep hierarchy of objects:

• Substations contain VoltageLevels, which contain Bays, which contain Equipments
• Equipments connect via Terminals to ConnectivityNodes, which connect to other Terminals of other Equipments

In order to answer the request, a raw SPARQL query needs to traverse from a Substation “down” to its parts, to Terminals and ConnectivityNodes, then “up” to parts of Lines (called ACLineSegment), “down” the other side of the Line, and “up” to the other Substation. This involves multiple unions, transitive closures, and property paths.

While execution is fast (approximately 0.1s), the query structure is too complex for LLMs to generate reliably. LLMs often produce syntactically correct but inefficient or semantically incorrect queries when faced with such deep nesting.

The solution: Semantic reasoning and inference

To address this, we implemented standard OWL2 RL rules to introduce “shortcut” relations that simplify the graph structure for the LLM without altering the underlying data model.

We defined a new namespace cimr: (CIM Rules) and added the following inferred relations:

1. Super-properties (union properties): cimr:hasPart aggregates various containment relations (for example, EquipmentContainer.Equipments, Substation.VoltageLevels).
2. Transitive closure: cimr:hasPartTransitive allows querying parts at any depth.
3. Property paths: cimr:connectedTo shortcuts the Terminal-ConnectivityNode-Terminal path.
4. Composite paths: cimr:connectedThroughPart links containers directly if their internal components are connected.

Outcomes

Simplified queries

The complex SPARQL query was reduced to a few readable lines. The LLM can now simply ask for cimr:connectedThroughPart rather than constructing a multi-line property path.

Before (simplified snippet):

After:

Performance and efficiency

We created a custom cim.pie ruleset with custom optimizations like transitiveOver and fixed-arity property chains to keep reasoning efficient. The inferred triples increased the knowledge graph size by approximately 1.95x, a manageable expansion that enables significantly easier querying with negligible impact on query speed.

In summary, through semantic reasoning, we can bridge the gap between complex domain ontologies and LLM capabilities. Documenting these inferred properties allows the LLM to discover and use them, thus transforming a prone-to-error SPARQL generation task into a reliable one. If you are interested in getting further into the details of this process, please check out our post Using Semantic Reasoning to Help LLM with SPARQL Generation in Electrical CIM.

Finally, to make Talk2PowerSystem insights actionable for field operations and planning, we had to ground the logical model in physical space.

Mapping electrical resources with GeoSPARQL

Power systems are inherently spatial: power lines traverse landscapes and substations occupy specific locations. By bridging CIM with geospatial standards, we unlock powerful visualization and analysis capabilities — from simple mapping to complex spatial querying and reasoning.

The Standard: GeoSPARQL

To represent geospatial objects in RDF, we use the GeoSPARQL Ontology. This allows us to map CIM structures directly to standard geospatial types:

• Features:cim:PowerSystemResource becomes also geo:Feature
• Geometries:cim:Location maps to geo:Geometry, storing coordinates as Well-Known Text (WKT) literals (for example, POINT, LINESTRING, POLYGON).

This standardization ensures compatibility with the broader ecosystem of geospatial tools and triple stores like Graphwise GraphDB.

Visualization and context

While raw data is useful, visualization provides immediate insight. Since GeoSPARQL is a commonly implemented OGC standard, we can use third-party tools like YasGUI to render query results directly on a map.

Beyond simple plotting, SPARQL queries can dynamically style elements (for example, coloring power lines red or green based on their nominal voltage) and generate rich tooltips for better context.

Spatial querying and integration

The true power of GeoSPARQL lies in querying data based on spatial relationships, not just topological connections.

• Geometric filters: We can query for objects that intersect specific bounding boxes or polygons (for example, “Find all assets within the Sandefjord industrial area”)
• Distance analysis: We can order or filter objects by their distance from a specific point
• Federated queries: We can combine our private grid data with public datasets like OpenStreetMap (via SPARQL federation). This allows us to ask complex questions like “Which power lines cross this specific administrative boundary?” without storing that boundary data ourselves.

In brief, integrating GeoSPARQL with CIM smooths the transition between electrical engineering and GIS. It enables us to enrich power system analytics with geospatial context, leveraging existing standards to visualize, query, and reason about the grid in relation to the real world. If you would like to dig deeper, please check this detailed technical blog: Mapping Electrical Resources with GeoSPARQL.

Conclusion

The Talk2PowerSystem project proves that the future of power systems isn’t just about more data — it’s about more accessible data. By simplifying the vocabulary, creating logical shortcuts through reasoning, and grounding everything in geospatial context, we are empowering the engineers to talk directly to the systems they manage and gather actionable insights.

Originally published at https://graphwise.ai on April 27, 2026.

The World Economic Forum Global Risks Report ranks misinformation and disinformation among the five most impactful technological risks for the next 10 years. While the rise of GenAI technologies has made the work of malicious actors more convincing and prolific, the “good guys” have also harnessed their AI faculties to fight back.

Graphwise has had its share in addressing this growing societal challenge through leveraging its semantic technology and AI research expertise in EC-funded initiatives. In the last three years, our Innovation team has led the development of AI-based tooling to empower:

• Fact-checkers and disinformation researchers (in vera.ai, BROD, FactCRICIS)
• Police authorities (in VIGILANT)

Thanks to identifying concepts, events, and similar narratives and interlinking them in a knowledge graph, this tooling helps unlock new analytical capabilities across multiple languages. We have integrated all these capabilities in the Database of Known Fakes (DBKF) and have made them accessible through a user-friendly interface. It makes it easy to double-check whether a claim has already been debunked by trusted fact-checkers.

Now, let’s put ourselves in the shoes of the user and take a closer look at our tooling. We’ll follow the investigative journey of an analyst interested in some misleading stories around renewable energy.

Linking and discovering concepts across languages

Our analyst conducts his study in a multilingual setting and on a large dataset. So, he needs to be sure that the results he gets from this database will contain the same concept, “renewable energy”, across all languages of the dataset. To address such a need, we have designed a multilingual entity linking model. It detects, disambiguates, and links named entities and other general concepts mentioned in text to a common knowledge base (Wikidata) across different languages. The connections between the instances of concepts in the different languages are stored in the knowledge graph so our DBKF can respond to the “renewable energy” query in the blink of an eye.

This interlinking of the information in the knowledge graph allows for deriving additional insights. For example, which concepts are mentioned together with the queried one. Or in what context the queried concept occurs or how its mentions are distributed over time.

DBKF provides a visual way of exploring all these aspects, including concept “quotes” (excerpts from the text with the immediate context) as shown in the screenshots below.

Based on the currently available data in the DBKF repository, our analyst can unravel some interesting and very different stories. For example, in the German context, the misleading statements revolve around how renewable energy installations are not capable of a black start after a blackout. It also talks about the allegedly non-recyclable rotor blades of wind turbines or speculates about carbon tax. The Polish context, on the other hand, offers misinformation about the Polish government’s achievements in increasing the share of renewable energy in the country’s energy mix.

This brings us to the next useful enrichment of the data: detecting not only objects or subjects, but related actions.

Spotlighting real-life events

For the needs of our target end users in the VIGILANT project (police authorities analyzing disinformation that has the potential to instigate criminal activity), we developed a state-of-the-art event extraction algorithm. It helps them uncover who did what, when, where, and why.

We built upon the Text2Event transformer model, which is pre-trained to detect 33 event types. In order to address some of the most common narratives found in disinformation content, we fine-tuned the model to extract 3 additional event types. These included pinpointing claims of miracle cures, severe weather phenomena, and regulatory or legislative changes that affect a broader subset of society, such as the Paris accords or the introduction of vaccine passports.

So now our fictional analyst may want to find out if events such as “attack”, “die”, and “injure” get frequently associated with his research. Claims like “falling blades from failing wind farms could be launched your way at any moment” could mislead people into believing that if they live near wind turbines, they are at risk of injury or death. Similarly, information that solar panels cause fire outbreaks raises questions about their safety.

In DBKF, we provide excerpts with event “quotes”, highlighting the word that denotes the event trigger. You can see some examples in the following screenshots.

Although they are not highlighted, we also store the event arguments (actors, targets, places and so on), which can be used to further filter the identified events. This information is interlinked with the raw text in the claims (the short misleading statements), the claim reviews (the whole debunking articles), and the extracted concepts in the knowledge graph. This is illustrated in the following diagram.

This offers great flexibility in terms of designing complex faceted searches. Analysis of results from such searches can offer additional insights about narratives within and across documents that were previously hidden. This opens up a new level of content analysis, in which we can group similar stories.

Identifying clusters of similar content

While the disinformation covered by debunks globally varies greatly, there is also a significant overlap in the key concepts addressed by debunks. This is because disinformation actors tend to reuse content and adapt it to specific contexts but leave the underlying message the same. These patterns are very useful to detect when tracing the spatio-temporal dynamics of disinformation campaigns and narratives. Such an analysis can be relevant in other domains, which require identifying and grouping similar pieces of textual content across different languages, geographical regions, and time periods.

Our Innovation team has devised a sophisticated clustering algorithm, intended to produce clusters of closely tied claims. It was specifically chosen for its ability to handle large datasets and multilingual data.

The cluster building process follows four main steps:

1. Document chunking and embedding calculation to capture the semantic information of the text
2. Cluster creation with a GPU-enabled version of the HDBSCAN algorithm
3. Cluster naming using a local Small Language Model
4. Cluster metadata calculation based on the knowledge graph. This metadata includes key concepts, authors, languages, and the start and end dates of cluster activity. Such information enriches the clusters, providing valuable context and insights for further analysis.

The DBKF user interface enables our analyst to explore the relevant clusters and the associated metadata. It also helps track the evolution of the narrative through an intuitive timeline visualization like the one shown in the screenshot below.

Going one level up (before this cluster view deep-dive) the user can see listed all the recurring narratives. They revolve around misconceptions about renewable energy sustainability, common causes of blackouts in renewable energy systems, inconsistencies in renewable energy targets and achievements.

At this point of his investigative journey, our analyst may want to explore this tooling in other ways such as aggregations or breakdowns by language. Or he may be interested in other metadata and enrichments. This is where our trusted AI assistant: the DBKF chatbot comes in.

Querying data with the help of an AI assistant

We have built a customized AI agent based on GraphDB’s Talk to Your Graph functionality. This agentic chatbot has access to all the search functionalities available through the DBKF user interface, as well as direct database access. It is designed to help users perform complex, multi-tool interrogations of the data, providing a more interactive and guided experience.

The DBKF chatbot is prompted to answer requests only related to the contents of the database and to base its reasoning on the information available in the underlying knowledge graph. Grounding the AI agent through the knowledge graph ensures factuality and explainability of answers.

Our analyst can feel at ease talking to the AI assistant in whatever natural language he prefers. In this way, he will gain deeper insights on the topic of his research.

The conversation with the chatbot can serve as his entry point into the rich capabilities of DBKF as well as an incremental introduction to its advanced features. Retrieving the ten biggest claim clusters discussing renewable energy can be the start of a more in-depth exchange, spanning all the possible connections in the database (see the screenshot below).

Conclusion

Through our work in the counter-disinformation projects, we have developed practical solutions for users, who need to perform analysis on a huge amount of data in multilingual settings.

By identifying and using the connections between concepts, events, and similar stories, we can facilitate the exploration of data in other domains in addition to media content. Providing structure and grounding for the AI agent through the knowledge graph, we ensure accurate and trustworthy answers.

Originally published at https://graphwise.ai.

The release of PoolParty 10.2 is a strategic step in our transition toward the future Graphwise Platform. While we are busy building a more integrated ecosystem, this release addresses two critical needs for the modern global enterprise: the ability to process knowledge in any language and the precision to find specific data points in an ocean of information.

A unified identity under the Graphwise brand

Following the merger of Ontotext and Semantic Web Company, we are officially bringing the Graphwise identity to our core products. It is more than just a fresh coat of paint; it is about providing a professional, integrated experience as you move between tools.

In this first phase of the rollout, you will notice a refreshed look for the log-in page, the Linked Data (LD) frontend, and the core Graph Modeling component (formerly known simply as the PoolParty suite). While the “PoolParty” name remains for this version, these visual updates prepare the groundwork for our evolution into the unified Graphwise Platform.

Your knowledge graph, now fluent in over forty languages

For years, many enterprise systems were “English-first,” requiring custom, high-maintenance workarounds for scripts like Japanese or Chinese. That ends with PoolParty 10.2. We have re-implemented our concept tagging engine using a native Lucene-based architecture.

• Native multilingual support: Graphwise now supports over 40 languages natively, including Japanese, Chinese, Russian, and most European languages. No need for external “word form” files.
• Zero-touch indexing: Previously, users had to manually “Refresh the Extraction Model” whenever a taxonomy changed. Now, the extraction model is automatically rebuilt on the first request. It simply works in the background.
• Reduced complexity: By leveraging Finite State Transducers (FSTs), we have removed the dependency on external services for lookup logic. This means high-speed tagging with significantly less infrastructure overhead.

Whether you are managing technical manuals in German or news snippets in Japanese, your taxonomy is now a global asset that detects and links concepts with native-level fluency.

Precision when it matters: find the needle in the haystack

In research-heavy sectors like Pharmaceuticals, a search for a project code like “TAK-123” shouldn’t return every document containing the number “123.” Standard search engines often return broad, noisy results for queries.

The new Exact Phrase Matching in GraphSearch makes the life of data analysts a lot easier:

• Pinpoint accuracy: You can now toggle exact matching via the API, ensuring that multi-word queries are treated as a contiguous phrase rather than a collection of individual words.
• Flexible ranking: Choose between a “Mandatory” filter (only show exact matches) or a “Ranking Boost” that pushes exact matches to the top while still showing related content.
• Alphanumeric intelligence: We’ve optimized the system to handle complex identifiers and technical terms that involve hyphens or special characters, ensuring they aren’t fragmented during analysis.

Simpler workflows for developers and admins

We’ve also cleaned up the “plumbing” to make life easier for the teams running PoolParty:

• Unified Tagger API: We have consolidated several legacy endpoints into a single, high-performance /api/tag endpoint.
• Efficient multi-document handling: Whether you are uploading a ZIP file for aggregate analysis or sending multiple files for individual results, the process is now streamlined and more predictable.

What this means for you

PoolParty 10.2 is about making your semantic operations more robust and easier to use on a global scale. It removes the friction of manual indexing, eliminates the “noise” in your search results, and provides a clear, unified interface that reflects our shared future as Graphwise.

Originally published at https://graphwise.ai.

Data privacy has shifted from a checkbox exercise to a board-level risk.

Global regulations such as the EU General Data Protection Regulation (GDPR) require organizations to maintain detailed Records of Processing Activities (RoPA) (Article 30) and to perform Data Protection Impact Assessments (DPIAs) for high-risk processing (Article 35).

In parallel, frameworks such as the NIST Privacy Framework 1.1 help organizations treat privacy risk at the same level as cybersecurity and enterprise risk.

Yet most privacy teams still live in spreadsheets, manual questionnaires, and disconnected tools. That makes it hard to answer basic questions quickly and confidently:

• Where is our most sensitive data actually flowing?
• Which third parties are the riskiest — and why?
• If a new law or contract clause changes, what’s impacted?

This is exactly where Knowledge Graphs, LLMs, NLP, GenAI, and ML fit together into a modern Data Privacy Intelligence stack.

In this post, we’ll walk through the role of each technology, how they interlock, and how Zenia Graph, together with Graphwise, helps organizations operationalize data privacy, manage legal and regulatory risk, and gain a competitive edge.

Knowledge Graphs: The Privacy Control Plane

A knowledge graph is a connected map of everything that matters to privacy and AI governance: people, systems, data, vendors, regulations, risk, compliance and controls. Instead of scattered spreadsheets and rigid forms, you have a living, queryable model — a privacy control plane.

What a privacy knowledge graph models

Typical entities and relationships include:

• Systems & applications — CRM, HR, marketing, data warehouses, SaaS tools
• Data assets — tables, fields, documents, logs, events
• Data subjects & categories — customers, employees, minors, special categories
• Processing activities — purposes, lawful bases, retention, jurisdictions
• Vendors & third parties — roles, locations, data flows, contracts, sub-processors
• Controls & obligations — DPIAs, RoPAs, DPAs, SCCs, DSAR workflows, retention rules
• Risk Factors — Threats (Ransomware, Phishing), Vulnerabilities (CVEs), Likelihood vs. Severity scores
• Legal Frameworks — Regulations (GDPR, AI Act), Specific Articles, Lawful Bases, Consent versions
• Mitigations — Encryption levels, Pseudo-anonymization, Access controls, Residual risk status
• Incidents — Breach events, Notification deadlines, Root cause paths, Remediation steps

With this in place, you can ask questions like:

• “Show me all processing involving biometric data in the EU with no DPIA.”
• “Which vendors receive EU personal data and lack updated SCCs?”
• “For this new feature, which datasets, systems, vendors, and risks are connected?”
• “If we patch the SQL vulnerability in ‘Legacy Payments’, how much does our global Risk Score drop?”
• “Which data transfers to non-EU countries rely on SCCs but are missing a Transfer Impact Assessment (TIA)?”
• “Show me all ‘High Severity’ risks affecting ‘Special Category Data’ that remain unmitigated for > 30 days.”

Why graphs beat rigid lists and forms

Most legacy platforms sit on relational or proprietary databases with fixed schemas. That works when:

• Data flows are simple
• Schemas rarely change
• Only one region or regulation matters

It breaks down when:

• The same attribute (e.g., “email address”) flows through dozens of systems and vendors
• New regulations (like the EU AI Act) or AI use cases appear faster than the schema can be updated
• You must understand not just what data exists, but how it moves and why it is allowed

Graphs are:

• Flexible — adding new node types (e.g., “AI model,” “training dataset,” “data residency zone”, “new risk”) and relationships doesn’t require redesigning every form.
• Relationship-first — flows, dependencies, and cross-border paths are modeled naturally.
• Contextual — ideal as the context layer on top of existing scanners, catalogs, and logs.

Scanners and relational lists tell you what you have. The graph explains how it fits together and what it means for risk and compliance.

Data sovereignty and localization

For global companies, data sovereignty and localization are now core requirements. Because regions, legal entities, and data stores are first-class graph nodes, you can:

• Visualize cross-border data flows between cloud regions, vendors, and subsidiaries
• Answer: “Which EU data flows to US-based systems?” or “Where do we process data for Brazilian customers?”
• Support localization policies, such as keeping HR data for specific countries within certain regions

List-based tools show you columns filtered by “country.” A graph shows the network of flows — something executives, auditors, and regulators understand immediately.

LLMs and Graph RAG: Conversational Access to Compliance

Once your privacy landscape is modeled as a knowledge graph, LLMs turn it into an interactive assistant.

Instead of learning SPARQL or hunting through dashboards, privacy, legal, or business stakeholders can ask:

• “Which vendors are high-risk in Europe and why?”
• “What personal data do we store about candidates in Germany, and where does it go?”

Graph-aware LLMs (Graph RAG)

Standard RAG pulls text chunks from documents. Graph RAG retrieves structured facts and relationships from the graph and passes them to the LLM as context.

Example prompts:

• “Summarize all high-risk processing involving biometric data in France and list missing DPIAs.”
• “Explain why Vendor X is marked high-risk and recommend remediation steps.”
• “If we add a new AI model trained on dataset Y, what privacy and transfer risks arise?”

Because answers are grounded in the graph, they are:

• Traceable — linked back to concrete systems, vendors, and documents
• Consistent — aligned with a single source of truth
• Explainable — supported by explicit graph paths and attributes

LLMs become a privacy copilot that:

• Lets users “Talk to Your Graph” in natural language (via Graphwise)
• Provides just-in-time guidance inside workflows (e.g., suggesting lawful bases or flagging high-risk use cases)
• Generates short, audience-specific summaries of RoPAs, DPIAs, and audit findings

NLP: From Documents and Policies to Structured Signal

Most privacy-relevant information starts as unstructured text:

• Data Processing Agreements and terms of service
• Vendor security questionnaires
• Privacy notices and internal policies
• Incident and logging reports
• DSAR/complaint tickets

NLP turns this unstructured content into structured graph entries.

Core capabilities include:

• PII & data category detection — spotting personal and sensitive data in schemas, samples, or documentation
• Contract & policy understanding — extracting roles (controller/processor), purposes, retention, locations, and safeguards
• Entity & relationship extraction — mapping systems, vendors, datasets, and obligations into the graph
• Classification & tagging — labeling documents as DPIAs, DPAs, policies, retention schedules, etc., and linking them to processing activities

Scanner tools like BigID or Securiti do a great job finding sensitive data. Zenia Graph ingests those outputs and adds business context: who owns the system, which purpose the data serves, what contracts apply, and which legal regimes matter.

This continuous ingestion keeps the graph — and therefore your privacy posture — up to date, instead of relying on annual surveys and stale forms.

Generative AI: Drafts, Explanations, and “What-If” Analysis

Generative AI sits on top of the graph and NLP layer to remove manual drafting work.

Typical workflows:

• Drafting DPIAs & risk assessments — using graph data about systems, data categories, risks, and controls to pre-fill DPIA assessments, streamlining the mandatory Human-in-the-Loop (HITL) review process.
• RoPA generation and updates — automatically creating and updating RoPA entries as systems, vendors, and purposes change
• DSAR support — assembling first-draft responses by pulling together where an individual’s data lives, why it is processed, and how long it is kept
• “What-if” scenarios — answering questions like: “If we move this workload from the US to the EU, or swap Vendor A for Vendor B, how does that impact risk, transfers, and required controls?”

Generative AI doesn’t replace the privacy officer or in-house counsel. It removes repetitive copy-and-paste tasks so experts can focus on decisions, negotiation, and strategy.

ML and GNNs: Real-Time Risk Scoring

Machine learning (ML) and graph neural networks (GNNs) turn your graph into a real-time risk engine.

ML for context-aware risk

With graph features available, ML can:

• Score vendor and data-sharing risk using attributes like data sensitivity, jurisdiction, certifications, incident history, and control coverage
• Detect anomalies in access patterns (for example, a sudden spike of HR data moving into an unusual SaaS tool)
• Predict missing controls — highlighting where lack of encryption, retention limits, or DPAs is likely to cause problems

Instead of flat checklists, you get risk scores that understand context.

GNNs with PyG: learning risk from relationships

In privacy, risk is rarely about a single node; it’s about how nodes are connected. That’s where GNNs and PyTorch Geometric (PyG) come in:

Steps:

1. Build a learning graph

• Nodes: vendors, systems, datasets, jurisdictions, products
• Edges: data flows, contracts, processing relations, regulatory links
• Features: sensitivity, locations, certifications, incidents, missing controls

1. Train a GNN to predict risk

• Use historical incidents, audit findings, and red flags as training labels
• Let the model learn patterns like “vendors with this neighborhood and these gaps tend to be high risk”

1. Score nodes and relationships

• Every vendor, system, or flow receives a graph-aware risk score
• Scores can be refreshed when reality changes (new vendor, new flow, expired certification, new AI model)

1. Drive real-time heat maps

• Privacy, legal, and security teams see live risk dashboards instead of static annual reports
• They can justify priorities to the board and regulators with clear evidence and reasoning

AI Governance and the EU AI Act

The EU AI Act and similar initiatives mean organizations must govern not just data, but AI models:

• Which models exist and who owns them
• Which datasets (and personal data categories) trained them
• What decisions they influence
• What risks and controls apply

A knowledge graph is a natural backbone for AI governance:

• Models become first-class nodes linked to training data, business owners, and risk assessments
• Data lineage captures which personal data feeds which models, under what lawful basis
• Policies, monitoring controls, and impact assessments attach directly to AI models, just like to systems and vendors

Vendors like Securiti are pivoting hard to “AI governance.” Zenia’s advantage is that the same graph-based infrastructure that powers data privacy compliance can govern data + models + obligations in one consistent view.

A Unified Data Privacy Intelligence Stack

Put together, the stack looks like this:

1. Ingest & Discover — Connectors + NLP

• Bring in schemas, logs, scanner outputs, contracts, policies, and regulations
• Extract entities, relationships, and privacy semantics

1. Model & Govern — Knowledge graph

• Maintain a shared model for RoPAs, DPIAs, vendors, AI models, and cross-border flows

1. Analyze & Quantify — Analytics + ML + GNNs

• Compute and update risk scores, detect anomalies, cluster similar activities and vendors

1. Interact & Assist — LLMs + Generative AI

• “Talk to Your Privacy Graph” via Graphwise
• Draft DPIAs, RoPAs, DSAR responses, AI model registers, and remediation plans

1. Orchestrate & Execute — Agentic Automation

• Move beyond conversation: empower AI agents to interact with API hooks, autonomously suspending vendor access or triggering security protocols when risk thresholds are breached

1. Act & Learn — Workflows + feedback

• Trigger tasks, capture decisions, and feed results back into the graph for continuous improvement

The result: continuous, graph-driven intelligence, not static compliance snapshots.

How Zenia Graph and Graphwise Compete — and Win

Zenia Graph specializes in data privacy, AI governance, and third-party risk using knowledge graphs and AI. Graphwise delivers the conversational interface that lets users talk to that graph and RDF graph database.

What Zenia Graph provides

• Privacy & AI Governance Graph — a domain-specific model for processing activities, data, systems, vendors, contracts, AI models, and controls
• Connectors for multi-cloud and hybrid — ingesting from AWS, Azure, GCP, Snowflake, Databricks, on-prem, and existing compliance and discovery tools
• Graph-native risk analytics — ML and GNN-based scoring, risk heat maps by line of business, region, product, and vendor
• “Talk to Your Privacy Graph” assistant (via Graphwise) — natural-language Q&A with traceable, graph-backed answers
• Generative content workflows — DPIAs, RoPAs, DSAR responses, AI model registers, and internal briefings, all grounded in the graph

Positioning vs. incumbents

• Vs. OneTrust / TrustArc (rigid form-based platforms)
• They focus on static forms and checklists.
• Zenia delivers a dynamic, graph-based model that evolves as systems, vendors, AI models, and laws change.
• Vs. BigID / Securiti (scanner-first tools)
• They are excellent at discovering PII and sensitive data.
• Zenia is the context layer: understanding why that data is there, who owns it, what contract governs it, and which obligations apply.
• Vs. Microsoft Purview (ecosystem-centric)
• Purview shines in Microsoft-heavy stacks.
• Zenia is intentionally ecosystem-agnostic, unifying multi-cloud and hybrid environments where most real enterprises live.

Conclusion: From Static Compliance to Living Intelligence

Organizations that can see, explain, and prove how they use personal data — and how they govern their AI models — will win the trust of regulators, customers, and boards.

By combining:

• Knowledge graphs as the privacy and AI governance control plane
• Our Graph Schema aligns with international standards like W3C DPV, ensuring interoperability.
• LLMs as an intelligent, conversational interface
• NLP to bring unstructured evidence into the graph
• Generative AI to draft and explain privacy and AI artifacts
• Agentic workflows to autonomously orchestrate remediation, enforce controls, and execute response protocols
• Machine learning and GNNs to quantify and detect risk in real time

…you can transform privacy from a fragmented, manual burden into a connected, intelligent competitive advantage.

Zenia Graph, together with Graphwise, helps organizations make that shift — turning rigid, form-based compliance into a living Data Privacy Intelligence Platform that keeps pace with regulation, technology, and business change.

Originally published at https://graphwise.ai.