KI-Halluzinationen abstellen: Warum die Dateninfrastruktur entscheidet

Die gefährlichste KI-Halluzination im Unternehmen ist nicht die offensichtlich falsche Antwort, sondern die plausible. Sie sieht sauber formatiert, autoritativ und einsatzbereit aus und ist trotzdem falsch. Genau daran scheitern KI-Programme in der Produktion: nicht am sprachlichen Können der Modelle, sondern an einer Dateninfrastruktur, die verifizierte Geschäftsrealität nicht von wahrscheinlicher Mustererkennung trennt.

Stellen Sie sich vor, Sie lassen einen internen KI-Assistenten das Lieferkettenrisiko bewerten, um bei einem plötzlichen Lieferengpass Ihr finanzielles Exposure zu bestimmen. Das Modell liefert eine flüssige, perfekt formatierte Zusammenfassung über Ihre Prioritätskunden. Bei genauem Hinsehen stellen Sie fest: Es hat eine ausgelaufene Vertragsbeziehung gezogen, zwei rechtlich getrennte Tochtergesellschaften als einen Account behandelt oder eine vertriebsseitige Umsatzdefinition verwendet statt der, auf die sich das Finanzwesen stützt.

Der eigentliche Schaden ist nicht die eine falsche Zeile in einer Tabelle, sondern der Vertrauensverlust danach. Sobald dieses Vertrauen bricht, stockt das KA-Programm. Fach- und Führungsebene, Analystinnen und Operations-Teams hören auf, die Anwendung zu nutzen, weil sie sich eine selbstbewusst formulierte Fehlantwort in einem kritischen Workflow nicht leisten können. Die Adoption stößt an eine Wand — nicht weil das Large Language Model nicht schreiben oder zusammenfassen kann, sondern weil es verifizierte Fakten nicht zuverlässig von plausiblem Pattern-Matching unterscheidet. Das ist einer der Gründe, warum Unternehmen selbst nach großen Investitionen in moderne Datenplattformen nicht datengetrieben werden.

In Produktivsystemen ist Halluzination meist eine Eigenschaft Ihrer Dateninfrastruktur, kein Charakterfehler des Modells. Generische KI-Systeme können nur mit dem Kontext arbeiten, den Sie ihnen bereitstellen. Fehlen geteilte Definitionen, governte Beziehungen, verifizierte Datenquellen und klare Geschäftsregeln, füllen die Modelle diese strukturellen Lücken probabilistisch.

Dieser Leitfaden erklärt, warum Enterprise-KI halluziniert, warum Fixes auf Modellebene an eine logische Decke stoßen, wo dokumentbasiertes Retrieval zu kurz greift und wie geerdete Enterprise-KI aussieht, wenn sie auf einer ontologie-gestützten Wissensschicht aufsetzt.

Was Halluzination im Unternehmenskontext bedeutet

Bevor Sie das Halluzinationsrisiko über Ihre Architektur hinweg senken können, müssen Sie die Enterprise-Variante des Problems sauber definieren. Falsche Antworten im Consumer-Maßstab — ein Chatbot, der eine historische Trivia erfindet — sind meist nur peinlich. Enterprise-Halluzinationen sind operativ gefährlich. Sie fließen in Vorstandsberichte, Verträge, regulatorische Meldungen und in autonome Agenten, die in Live-Umgebungen handeln. Für Ihre Infrastruktur ist eine Enterprise-Halluzination nicht einfach eine Falschinformation, sondern ein nicht belegter KI-Output, der glaubwürdig genug wirkt, um eine Geschäftsentscheidung zu beeinflussen oder eine falsche automatisierte Aktion auszulösen.

Wahrscheinlichkeit ist nicht Wahrheit

Large Language Models sind darauf optimiert, auf Basis struktureller Mustererkennung wahrscheinliche Antworten zu erzeugen — nicht, Geschäftsrealität zu verifizieren. Sie sind herausragend darin, kohärente, hochgradig selbstbewusste Sprache zu produzieren. Weil sie im Kern Vorhersagesysteme sind, priorisieren sie sprachliche Plausibilität vor faktischer Korrektheit.

Fehlt dem Modell verifizierter Kontext, hört seine zugrundeliegende Statistik nicht auf. Es sagt weiter das wahrscheinlichste nächste Wort auf Basis der Grenzen seiner Trainingsdaten voraus. Beim Halluzinieren ist das Modell nicht defekt — es arbeitet nur ohne ausreichend Wahrheit unter sich.

Enterprise-Halluzinationen sind relational

Besonders schwierig wird das Problem, weil die Fragen an Ihre Geschäftsdaten selten isolierte Fakten betreffen. Sie sind ihrem Wesen nach relational und schneiden quer durch mehrere organisatorische Grenzen:

• Welche Ihrer aktiven Kunden sind von einem verzögerten Zulieferteil betroffen?
• Welche Kundenverträge hängen an einer Softwareversion, die Sie abkündigen wollen?
• Welche Umsatzkennzahl soll Ihr Agent für einen lokalisierten Compliance-Report ziehen?
• Welche physischen Produktionsanlagen sind von einer geänderten regulatorischen Anforderung betroffen?

Diese Fragen korrekt zu beantworten erfordert das Navigieren präziser Beziehungen zwischen Kunden, Verträgen, Produkten, Lieferanten und Finanzregeln. Keine einzelne Datenbankzeile und kein isoliertes Textdokument trägt die ganze Antwort. Das Modell braucht Unternehmenskontext, nicht mehr unstrukturierten Text zum Lesen.

Woher Enterprise-KI-Halluzinationen typischerweise kommen

Wenn Sie die Halluzinationsrate gegen null treiben wollen, müssen Sie den Technologie-Stack nach unten durchgehen und sehen, wo Ihre Geschäftslogik verloren geht. Eine echte Lösung setzt voraus, dass Sie diagnostizieren, warum gängige, modellnahe Patches das eigentliche Infrastrukturproblem nicht lösen.

Das Modell ist nicht das ganze Problem

Ein Upgrade auf ein größeres Modell oder ein erweitertes Kontextfenster kann grundlegende Reasoning-Fehler reduzieren. Ebenso hilft domänenspezifisches Fine-Tuning, ein Modell an Ihre Terminologie, Formatvorgaben und engen Workflows anzupassen.

Doch keine dieser Anpassungen bringt einem Modell bei, welche konkrete Definition von Kunde, Umsatz oder Defekt Ihre Organisation für einen bestimmten kritischen Workflow verwendet. Fine-Tuning formt das Verhalten eines Modells; es kann keinen dynamischen operativen Kontext liefern, der in seinen Trainingsdaten schlicht nicht existiert. Ist die Ground Truth nicht im unmittelbaren Input des Modells vorhanden, muss das Modell weiter raten.

Prompt-Engineering stößt an eine logische Decke

Klare System-Instruktionen, konfigurierte Ausgabeformate und Confidence-Scoring sind notwendige Praktiken, die den Genauigkeits-Boden anheben. Sie helfen, offensichtliche Formatfehler abzufangen und Muster-Ausreißer zu markieren.

Aber Prompt-Engineering kann kein fehlendes Geschäftswissen erzeugen. Sie können Ihren Assistenten anweisen, verifizierte Datenquellen zu nutzen — ein Text-Prompt kann jedoch nicht auflösen, ob Ihr CRM oder Ihr ERP der maßgebliche Datensatz für einen strittigen Account ist. Wer weiter am Prompt-Wrapper feilt, während das darunterliegende Datenmanagement fragmentiert bleibt, dessen KI-Anwendungen plateauen lange vor dem Produktiveinsatz.

Wo dokumentbasiertes RAG zu brechen beginnt

Retrieval Augmented Generation (RAG) verbessert die Erdung, indem es zur Laufzeit externen Kontext in das Prompt-Fenster des Modells injiziert. Für das Abfragen flacher Wissensbasen, statischer technischer Dokumentation oder Richtliniendateien ist das eine ausgesprochen nützliche Architektur.

Dokumentbasiertes RAG hat jedoch strukturelle Grenzen. Es gerät ins Straucheln, sobald eine Antwort domänenübergreifende Logik oder strukturierte operative Daten durchlaufen muss. Einen isolierten Textabschnitt aus einem PDF-Vertrag zu ziehen ist nicht dasselbe, wie zu verstehen, wie dieser Vertrag einen Finanz-Asset-Datensatz in einem ERP-System verändert. Diese strukturelle Reibung ist der Grund, warum Teams RAG-Halluzinationen weiterhin in Produktivumgebungen sehen: Das System ruft relevante Dokumente ab, synthetisiert aber die falsche geschäftliche Schlussfolgerung. Genau hier wird das Anreichern von RAG mit Knowledge Graphs wichtiger als eine weitere Prompt-Schicht.

Die semantische Lücke, in der das Halluzinationsrisiko wächst

Eine der Hauptursachen für Enterprise-KI-Halluzinationen ist die semantische Lücke in Ihrer Dateninfrastruktur. Betrachten Sie, wie ein Kernbegriff wie Umsatz über Ihre Datenplattformen driftet:

• Der Vertrieb erfasst Umsatz als Brutto-nach-Rabatten, um Deal-Volumen zu bewerten.
• Das Finanzwesen rechnet Umsatz als Netto-vor-Retouren, um den Cashflow zu schützen.
• Das Controlling verfolgt Umsatz strikt über nach IFRS-15 realisierte Umsatzkennzahlen.

Jede dieser Zahlen kann in ihrer eigenen Domäne faktisch korrekt sein. Das Halluzinationsrisiko entsteht, wenn Ihre KI-Systeme diese widersprüchlichen Informationssätze als austauschbar behandeln, weil nichts in Ihrer Datenarchitektur den semantischen Unterschied maschinenlesbar gemacht hat. Eine Analystin weiß aus Erfahrung, welche Definition in welche Entscheidungsmatrix gehört; ein LLM trägt dieses institutionelle Gedächtnis nicht, sofern Ihre Infrastruktur es nicht offenlegt. Ihre Datenplattformen managen Speicher, Pipelines und Zugriffsrechte hervorragend — Bedeutung managen sie nicht automatisch. An diesem Punkt ist das Problem nicht mehr nur algorithmisch, sondern semantisch.

Welche Halluzinations-Fixes wirklich etwas bewegen

Um diese strukturelle Schwachstelle zu beheben, müssen Sie Ihren KI-Stack durch eine ehrliche Hierarchie von Kontrollen betrachten. Prompt-Fixes und infrastrukturelle Umbauten als gleichwertige Optionen zu behandeln, lässt Ihre Genauigkeitsmetriken plateauen.

Nützliche Kontrollen: Prompts, Guardrails, Evals und Human Review

Das Standard-Toolkit der KI-Entwicklung bleibt für die Enterprise-Sicherheit notwendig. Prompt-Engineering, semantische Guardrails, Output-Validierungsbibliotheken, automatisierte Eval-Suites und Human-Review-Prozesse fangen offensichtliche syntaktische Anomalien und Formatfehler zuverlässig ab.

Diese Methoden funktionieren jedoch primär als operative Notlösungen. Sie schränken ein, wie sich das Modell ausdrückt, beheben aber nicht die zugrundeliegende Datenfragmentierung, die Halluzinationen überhaupt erst verursacht. Sie helfen der KI, sich bei schwachem Kontext besser zu verhalten — sie machen schwachen Kontext nicht vertrauenswürdig.

Begrenzte Fixes: Fine-Tuning und größere Modelle

Ein Umzug Ihrer Workloads auf größere Frontier-Modelle kann grundlegende Reasoning-Fehler minimieren, während domänenspezifisches Fine-Tuning Ton und Syntax eines Systems an spezialisiertes Branchenvokabular anpasst. Für isolierte Workflows im Enterprise-Maßstab sind das wertvolle Optimierungen.

Die Grenze liegt darin, dass Enterprise-Halluzinationen selten auftreten, weil einem Modell Sprachintelligenz oder Trainingsdaten fehlen. Sie treten auf, weil die konkret benötigte Antwort weder in seinen Gewichten noch in Ihren Prompts oder Ihren abgerufenen Dokument-Shards existiert. Der Kontext steckt gefangen in getrennten operativen Systemen, widersprüchlichen Definitionen und nicht abgebildeten Abhängigkeiten. Ein Infrastrukturproblem lässt sich nicht mit einem algorithmischen Patch beheben.

Der strukturelle Fix: KI in einer Wissensschicht erden

Wenn Enterprise-KI in der Produktion sicher arbeiten soll, ist das Ziel nicht, das Modell besser raten zu lassen. Das Ziel ist, die Zahl der Momente zu reduzieren, in denen es überhaupt raten muss.

Eine geerdete Architektur leitet das Modell durch ein maschinenlesbares Modell des Geschäfts, bevor es eine Antwort erzeugt. Hier werden Knowledge Graphs zentral für Enterprise-KI. Eine Ontologie formalisiert Ihre Konzepte, Regeln und Definitionen, während ein Knowledge Graph diese Logik mit lebenden Datensystemen verknüpft. Zusammen geben sie dem Modell formale Semantik: einen Weg, verifizierte Fakten und berechnete Beziehungen abzurufen, statt sich allein auf wahrscheinliche Sprache zu verlassen.

Das Modell generiert weiterhin Sprache, muss den geschäftlichen Kontext hinter der Antwort aber nicht mehr erfinden. Es kann verifizierte Fakten abrufen, definierten Beziehungen folgen, Quellen zitieren und sich enthalten, wenn die Wissensschicht die Antwort nicht stützen kann. Das verändert die Steigung Ihrer Leistungskurve, statt nur den Startpunkt zu verschieben.

Wie geerdete Enterprise-KI in der Produktion aussieht

Der Wechsel von einem probabilistischen zu einem stärker begrenzten System verändert den Ablauf der Datenabfrage. In einer produktionsreifen, geerdeten Umgebung arbeitet die Softwarearchitektur mit einem klareren Audit-Pfad.

Von der plausiblen Antwort zur überprüfbaren Antwort

Wenn Sie eine Abfrage durch eine geerdete Infrastruktur laufen lassen, hört Ihr KI-Modell auf, ein unabhängiger Generator zu sein, und wird zur intelligenten Schnittstelle über einem strukturierten Weltmodell. Der Schritt-für-Schritt-Ablauf folgt einem nachvollziehbaren Pfad:

Die geerdete Daten-Pipeline:

• Interpretieren: Das KI-Modell parst die natürlichsprachige Nutzerabfrage.
• Zuordnen: Das System bildet die Abfrage auf explizite Geschäftskonzepte und Kennzahlen in der Ontologie-Schicht ab.
• Übersetzen: Die semantische Engine erzeugt formale Datenbankabfragen entlang vordefinierter Beziehungspfade.
• Abrufen: Die Architektur holt lebende Fakten aus maßgeblichen Systems of Record und erzwingt dabei lokalisierte Governance.
• Synthetisieren: Das LLM erzeugt eine Antwort, die strikt durch die abgerufenen Fakten begrenzt ist, und legt Herkunft und Logik neben der Antwort offen.

Der Unterschied zu einem naiven RAG-Lookup liegt nicht darin, wie selbstbewusst die Antwort klingt, sondern darin, ob die erzeugten Kennzahlen verifiziert, reproduziert und in einem Unternehmensaudit verteidigt werden können. Wie sich diese strukturelle Ausrichtung mit Ihren bestehenden Business-Intelligence-Werkzeugen verzahnt, betrachten wir gesondert am Zusammenspiel von Knowledge Graphs und Semantic Layer für BI.

Wie wir KI in der Unternehmensrealität erden

In d.AP sitzt diese Erdungsschicht über den bestehenden Unternehmenssystemen, statt sie zu ersetzen. Sie verbindet operative Daten, Dokumente und Domänenmodelle über einen ontologie-gestützten Knowledge Graph, sodass KI-Systeme geschäftliche Bedeutung abfragen können, statt aus unverbundenen Datensätzen zu raten. Das funktioniert nur, wenn die Ontologie als intentionaler Kern des Knowledge Graphs behandelt wird, nicht als lose Metadatenschicht.

Der Anspruch ist nicht, Snowflake, Databricks, SAP oder Salesforce zu ersetzen. Die Wissensschicht sitzt direkt darüber und liefert ein strukturiertes Weltmodell Ihres tatsächlichen Betriebs. Sie hält fest, was Ihre Kern-Entitäten genau bedeuten, wie sie über Abteilungen hinweg zusammenhängen und welche Sicherheitsregeln zur Abfragezeit gelten — und senkt so das Halluzinationsrisiko bei domänenübergreifenden Fragen.

Weil d.AP offene W3C-Standards wie RDF und OWL nutzt, hängen Ihre Unternehmensdefinitionen weniger von einem geschlossenen Anbietermodell ab. Ihre Fachanwenderinnen und Fachanwender können komplexe Datenbeziehungen in natürlicher Sprache befragen, ohne SQL oder SPARQL zu beherrschen — genau das Ergebnis, das ein Semantic Layer im Zusammenspiel mit Gen AI für unternehmensweite Intelligenz liefert.

Die fehlende Kontrolle: die KI "Ich weiß es nicht" sagen lassen

Der wichtigste Vorteil, Ihre KI in einer formalen Ontologie zu verankern, ist die Fähigkeit, sich zuverlässig einer Antwort zu enthalten. In einem nicht geerdeten Setup wird das Modell weiterhin zu einer Antwort gedrängt, selbst wenn sein Kontextfenster Lücken enthält — was direkt zu erfundenen Daten führt.

Ein geerdetes System verhält sich wie ein menschlicher Experte. Findet Ihre Wissensschicht keinen verifizierten Fakt, keine abgebildete Beziehung und keine explizite Unternehmensregel, die die Abfrage stützt, verweigert die Anwendung das Raten. Sie sagt gefahrlos "Ich weiß es nicht", markiert die strukturelle Lücke oder bittet die nutzende Person um Präzisierung.

Genau das bedeutet das Eliminieren von Halluzinationen in einer operativen Umgebung: nicht ein System, das jedes Mal perfekt rät, sondern eines, das es vermeidet, eine unbelegte Antwort zurückzugeben. Confidence-Scores schützen Ihre Workflows nur, wenn sie an harte Retrieval-Evidenz und semantische Vollständigkeit gekoppelt sind. Diese Grundpräzision ist der Grund, warum formale Ontologien im Zeitalter agentischer KI zur praktischen Voraussetzung für Vertrauen werden: Sie geben mehreren autonomen Systemen ein geteiltes Vokabular, um Workflows auszuführen, ohne Datenkorruption zu riskieren.

Wie Sie starten, ohne Ihren KI-Stack neu zu bauen

Eine maschinenlesbare Wissensschicht auszurollen bedeutet keinen massiven, mehrjährigen Infrastruktur-Umbau. Sie können diese Architektur einführen, indem Sie eine bewusst enge, wertvolle Grenze anvisieren.

Schritt 1: Mit einer systemübergreifenden Frage beginnen

Der schnellste Weg in die Produktion führt daran vorbei, das gesamte Unternehmen auf einmal modellieren zu wollen. Isolieren Sie stattdessen eine einzelne, reale, aktuell schmerzhafte systemübergreifende Frage, die Ihre Teams regelmäßig zwingt, Daten manuell zusammenzustückeln. Wählen Sie Ihren Ausgangspunkt anhand von Fragen, die Sie heute nicht beantworten können, aber können sollten:

• Welche strategischen Kunden-Accounts sind unmittelbar von dieser konkreten Lieferverzögerung betroffen?
• Welche aktiven Wartungsverträge hängen an einer Fertigungskomponente, die wir abkündigen wollen?
• Welche regionale Umsatzdefinition muss unser automatisierter Agent für diesen Compliance-Report ziehen?
• Welche hochwertigen Assets sind unmittelbar von einer geänderten Umweltauflage betroffen?

Die richtige erste Frage überschreitet mehr als ein System, ist operativ relevant und liefert heute inkonsistente oder langsame Antworten.

Schritt 2: Das Minimum an Bedeutung modellieren

Sobald Ihre Zielfrage steht, definieren Sie die absolut minimale tragfähige Ontologie, die sie stützt. Bewertet Ihre Frage das Lieferantenrisiko, modellieren Sie nur die dafür nötigen Kernkonzepte und Beziehungspfade: Kunde, Vertrag, Lieferant, Produkt und Region.

Bilden Sie diese logischen Entitäten hinunter auf die physischen Tabellen und operativen Anwendungen ab, in denen die Daten heute liegen. Diese gezielte Umsetzung gibt Ihrem ersten Business-Use-Case innerhalb von Wochen eine governte Bedeutungsschicht und vermeidet vollständig die Falle des Über-Scopings der Engineering-Fläche. Diese initiale Deployment-Sequenz lässt sich entlang unseres Frameworks für den Aufbau eines Knowledge Graphs für RAG mit d.AP planen.

Schritt 3: Wiederverwendbare Infrastruktur schaffen

Das Liefermodell, das wir bei d.AP nutzen, baut explizit auf dieser Land-and-Expand-Logik auf. Der erste Use-Case ist so konstruiert, dass er vollständig für sich steht und dem Geschäft schnellen Wert sowie positiven ROI liefert.

Weil Sie auf einem offenen semantischen Fundament bauen, verfällt diese Arbeit nicht. Die Kernkonzepte, Entitäten und Beziehungsverknüpfungen, die Sie für die erste Frage abbilden, werden zu dauerhafter, wiederverwendbarer Infrastruktur. Beim nächsten KI- oder Analytics-Projekt sinkt Ihre Entwicklungszeit, weil Ihre Datenarchitektinnen das bestehende Ontologiemodell schlicht erweitern, statt bei null zu beginnen. In diesem Kompoundierungseffekt werden semantische Schichten für die Datenstrategie mehr als ein isoliertes KI-Add-on: Sie werden zur geteilten Infrastruktur für Ihr gesamtes Datenumfeld.

Readiness-Checkliste: wo sich das Halluzinationsrisiko versteckt

Bevor Sie sich auf Ihr nächstes Produktiv-Deployment festlegen, können Sie Ihre aktuelle Dateninfrastruktur gegen diese Checkliste prüfen, um zu sehen, wo ungeerdetes Risiko über Ihre Systeme hinweg auftaucht:

• Welche Ihrer aktuellen KI-Outputs erfordern den intensivsten Human-Review, bevor sie genutzt werden können?
• Welche Kern-Unternehmensbegriffe werden über Ihre Teams in Vertrieb, Finanzwesen, Operations oder Compliance unterschiedlich definiert?
• Welche systemübergreifenden operativen Fragen sind heute zu langsam oder politisch zu heikel, um sie zu beantworten?
• Welche Ihrer aktiven KI-Tools bleiben auf Sandboxes beschränkt, weil Sie ihnen in Produktion nicht trauen?
• Welche Workflows würden schwere finanzielle oder rechtliche Haftung erzeugen, wenn ein KI-Agent auf Basis einer unverifizierten Antwort handelte?
• Welche Ihrer angebundenen Repositorien enthalten verifizierte Datenquellen und welche nur partiellen, nicht ausgerichteten Kontext?
• Wo verlässt sich Ihr Unternehmen aktuell auf menschliches Gedächtnis, um widersprüchliche Informationen über Berichte hinweg abzugleichen?

Wenn mehrere dieser Diagnosepunkte dasselbe Muster über Ihre Abteilungen hinweg zeigen, ist Ihr Genauigkeitsengpass kein Modellversagen. Es ist die fehlende Wissensschicht unter der Anwendung.

Fazit: Hören Sie auf, das Raten zu flicken, reparieren Sie das Fundament

Enterprise-KI-Halluzinationen sind kein Modelldefekt, den Sie mit einem besseren Prompt, einem größeren Kontextfenster oder einem strengeren Guardrail-Skript dauerhaft lösen. Diese Kontrollen sind wertvoll, um den operativen Boden anzuheben, stoßen aber an eine Decke, weil sie das Kernproblem umgehen, statt es zu beheben.

Um die Halluzinationsrate gegen null zu treiben, muss Ihre Dateninfrastruktur den Modellen ein maschinenlesbares Modell des Geschäfts liefern. Ihre Systeme in einer ontologie-gestützten Wissensschicht zu erden, gibt Ihren Anwendungen Zugriff auf verifizierte Datenquellen, explizite Beziehungspfade und die strukturelle Fähigkeit, sich sicher zu enthalten, wenn Evidenz fehlt.

Während Sie Ihre Architektur von einfachen Chat-Assistenten hin zu autonomen KI-Agenten bewegen, ändern sich die Einsätze grundlegend. Eine falsche Antwort in einem Test-Dashboard ist ärgerlich; eine falsche Aktion in einem kritischen Workflow kann eine Kundenbeziehung beschädigen oder die Compliance gefährden. Ihre Systeme zu erden ist keine optionale Optimierung mehr, sondern eine praktische Voraussetzung für Vertrauen.

Um zu sehen, wie eine geerdete Antwort auf eine Ihrer eigenen systemübergreifenden Fragen aussieht, zeigen wir Ihnen gern, wie eine ontologie-gestützte Wissensschicht unverbundene Unternehmensdaten in überprüfbare Antworten verwandelt.