Von Datenpunkten zu Entscheidungen: Wie Ontologien und Knowledge Graphs dem agentischen Unternehmen ein solides Fundament geben

Jeder Agent in Ihrem Unternehmen muss eine Frage beantworten, bevor er handelt: Was habe ich hier eigentlich vor mir? Ein Sprachmodell kann einen Datensatz aus Teamcenter, SAP und Ihrem MES lesen. Allein kann es jedoch nicht wissen, dass das „Teil“ in allen drei Systemen dasselbe physische Objekt ist, dass dieses Teil in einer Baugruppe mit einer offenen technischen Änderung steckt und dass der Garantiefall der vergangenen Woche genau auf diese Baugruppe verweist.

Ihre Mitarbeitenden wissen das aus jahrelanger Erfahrung. Agenten brauchen es schriftlich. Dieses niedergeschriebene Verständnis ist eine Ontologie, und sobald sie mit Live-Daten gefüllt ist, wird daraus ein Knowledge Graph. Zusammen bilden sie die unscheinbarste und zugleich entscheidendste Ebene des agentischen Unternehmens: die Ebene, auf der Menschen und Agenten von derselben Realität ausgehen.

Dieser Blog erklärt, was Ontologien und Knowledge Graphs sind, wie sie funktionieren, wo sie in Ihrer Architektur angesiedelt sind, welchen Mehrwert die vordefinierten Industrieontologien in Siemens Intelligence Center X für Fertigungsunternehmen bieten und was nötig ist, um selbst eine Ontologie aufzubauen.

Wenig Zeit? Hier ein kurzer Überblick

• Agenten scheitern am Kontext, nicht am Modell. Gartner erwartet, dass 60 % der KI-Projekte ohne KI-fähige Daten aufgegeben werden. Ob ein Agent Wert schafft oder Störfälle verursacht, hängt davon ab, ob er versteht, was Ihre Daten bedeuten.
• Eine Ontologie ist das Regelwerk; ein Knowledge Graph ist die Landkarte, die nach diesem Regelwerk gezeichnet wird. Der Graph verknüpft jedes Teil, jede Änderung und jeden Garantiefall über Ihre Systeme hinweg, sodass Agenten den Pfad von der Frage zur Antwort verfolgen können. Gemeinsam geben sie Menschen und Agenten dieselben Definitionen, dieselben Regeln und dieselbe Audit-Spur – die Grundlage für eine hybride Workforce, der Sie vertrauen können.
• Den Kern sauber halten und Kontext darüberlegen. Ihre führenden Systeme bleiben als Basis unangetastet. Ontologie und Knowledge Graph liegen direkt darüber als gemeinsame Kontextebene; Orchestrierung und KI kommen darüber hinzu, wo sie sinnvoll sind.
• Nicht jede Ontologieebene ist für Agenten gebaut. Agenten stellen Fragen, die niemand vorhergesehen hat, über viele Systeme zugleich. Graph Studio in Siemens Intelligence Center X ist eine skalierbare Graphplattform, die genau solche Fragen im Unternehmensmaßstab beantwortet, ohne an Leistungsgrenzen zu stoßen.
• Auf bewährtem Branchenwissen aufbauen. Sie müssen die Fertigung nicht von Grund auf modellieren. Vordefinierte Industrieontologien und offene Standards beschreiben den Digital Thread bereits, von der Konstruktionsstückliste bis zum Garantiefall. Ihre Fachexperten passen sie an Ihr Unternehmen an, führen Datensätze über Systeme hinweg zusammen und steuern, wie sich das Modell weiterentwickelt. Beginnen Sie mit einem systemübergreifenden Workflow, und lassen Sie jeden weiteren Anwendungsfall darauf aufbauen.
  ‍

Warum Agenten ohne Kontext ins Stocken geraten

Das Modell ist selten der Engpass. Der Kontext, auf dessen Grundlage es schlussfolgert, schon.

‍Gartner prognostiziert, dass Unternehmen 60 % der KI-Projekte, die nicht auf KI-fähigen Daten beruhen, bis Ende 2026 aufgeben werden. 63 % der Unternehmen verfügen entweder nicht über die richtigen Datenmanagementpraktiken für KI oder sind sich nicht sicher, ob sie diese haben. Speziell für Agenten erwartet Gartner, dass bis Ende 2027 mehr als 40 % der Agentic-AI-Projekte eingestellt werden - aufgrund steigender Kosten, unklaren Geschäftsnutzens und unzureichender Risikokontrollen

Den deutlichsten Beleg dafür, was Kontext bewirkt, liefert ein Benchmark von data.world. Sie stellten GPT-4 geschäftliche Fragen zu einer SQL-Unternehmensdatenbank aus dem Versicherungsbereich. Bei direkter Abfrage beantwortete das Modell 16,7 % der Fragen korrekt. Bei Abfrage über einen Knowledge Graph, der auf einer Ontologie derselben Daten aufbaut, stieg die Genauigkeit auf 54,2 %. Bei den schwierigsten Fragen über die komplexesten Schemata erreichte direktes SQL 0 %, der Weg über den Knowledge Graph dagegen 36–39 %. Eine Folgestudie nutzte die Ontologie selbst, um die Abfragen des Modells zu prüfen und zu korrigieren, und steigerte die Genauigkeit auf 72 %.

Gleiches Modell, gleiche Daten. Der einzige Unterschied: ob die Bedeutung der Daten explizit gemacht wurde. Für einen Agenten, der nicht nur antwortet, sondern handelt, entscheidet dieser Unterschied darüber, ob er Wert schafft oder Störfälle verursacht.

Warum 72 % ein Ausgangspunkt sind und kein Urteil

Kein Unternehmen sollte auf Basis von 72 % handeln, und kein gut konzipiertes Unternehmenssystem verlangt das. Der Benchmark misst ein Sprachmodell, das ohne Leitplanken eigene Abfragen zu offenen Fragen schreibt. Im Produktivbetrieb verändern drei Faktoren das Bild.

Erstens: Die Ontologie dient als Kontrolle, nicht nur als Orientierung. Abfragen, die nicht zum Modell des Unternehmens passen, werden erkannt und korrigiert – oder das System verzichtet auf eine Antwort. Ein bewusstes „Ich weiß es nicht“ ist sicher. Eine selbstbewusste falsche Antwort ist es nicht.

Zweitens: Die erforderliche Genauigkeit richtet sich nach der Tragweite. Beim Erkunden einer Frage ist Unsicherheit tolerierbar. Bei der Freigabe eines Rückrufs nicht. Entscheidungen mit hoher Tragweite beruhen auf definierten Regeln und validierten Abfragen mit menschlicher Freigabe, während die offene Exploration ein unterstützendes Werkzeug bleibt.

Drittens: Jede Antwort ist nachvollziehbar. Welche Daten verwendet wurden, welche Abfrage lief und wer die Aktion freigegeben hat, wird protokolliert. So wird ein Fehler sichtbar und korrigierbar, statt verborgen zu bleiben.

Die Lehre aus der Forschung ist nicht, dass KI mit Ontologien zu 72 % zuverlässig ist. Sondern dass die Verankerung von KI im Kontext der wirksamste Weg ist, sie zuverlässiger zu machen - und ehrlich darüber, wo ihr Wissen endet.
‍

Das Regelwerk und die Landkarte

Eine Ontologie ist das Regelwerk; ein Knowledge Graph ist die Landkarte, die nach diesem Regelwerk gezeichnet wird. Die beiden Begriffe werden oft synonym verwendet, erfüllen aber unterschiedliche Aufgaben.

Die Ontologie ist ein formales Vokabular für Ihr Unternehmen. Sie definiert, welche Arten von Dingen es gibt (eine Pumpe, eine Produktionslinie, eine technische Änderung, einen Lieferanten), welche Eigenschaften sie haben, wie sie miteinander in Beziehung stehen dürfen und welche Regeln gelten. Eine Pumpe kann in einer Linie verbaut sein. Eine technische Änderung betrifft ein oder mehrere Teile. Ein Teil darf ohne genehmigtes Design nicht freigegeben werden. Ohne Ontologie haben Sie ein Bild aus Punkten und Linien. Mit ihr weiß das System, was jeder Punkt bedeutet, und kann darüber schlussfolgern.

Der Knowledge Graph ist dieses Vokabular, angewendet auf Ihre realen Daten: Pumpe P-101, Linie 3, Änderungsantrag ECR-2291 und die Millionen Verbindungen zwischen ihnen, laufend aktualisiert aus Ihren führenden Systemen.

Diese Trennung ist für das agentische Unternehmen entscheidend. In der Ontologie halten Menschen fest, was im Unternehmen etwas bedeutet. Im Graph lesen Agenten und Anwendungen diese Bedeutung und handeln danach. Stimmt die Ontologie, erbt jeder neue Agent dieses Verständnis automatisch.
‍

Wie ein Knowledge Graph funktioniert

Ein Knowledge Graph speichert jeden Fakt als Tripel: Subjekt, Beziehung, Objekt. Verkettet man genügend Tripel, entsteht eine Landkarte, durch die sich Menschen und Agenten bewegen können – statt eines Data Warehouse, das sie mit einem Dutzend mühsamer Joins abfragen müssen.

Tripel. „Pumpe P-101 ist in Linie 3 verbaut.“ „Linie 3 produziert Produkt X.“ „Produkt X enthält Baugruppe 4471.“ „Baugruppe 4471 hat die Anforderung max. 80 °C.“ Jedes Ding ist ein Knoten, jede Beziehung eine Kante. In den W3C-Standards, die die meisten Unternehmensgraphen nutzen, sind das RDF-Tripel, die mit SPARQL abgefragt werden.

Traversierung. Eine Frage wie „Welche offenen Garantiefälle betreffen Teile, die von den technischen Änderungen des letzten Monats berührt wurden?“ zieht sich durch PLM-, ERP- und Servicedaten. In einer relationalen Welt ist das ein Projekt. In einem Graph ist es ein Pfad: Garantiefall → Seriennummer → As-built-Konfiguration → Teil → Änderung. Agenten können Pfaden gut folgen - solange die Pfade existieren und eine Bedeutung haben.

Ontologie vs. Knowledge Graph · ein Pfad vom Garantiefall zur Änderung

Die linke Spalte wird einmal geschrieben, von Menschen. Die rechte Spalte wird kontinuierlich aus Ihren Systemen befüllt. Ein Agent, der die linke Seite versteht, findet die rechte für jeden Garantiefall, in jedem Werk.

Inferenz. DDa die Ontologie Regeln enthält, kann der Graph Fakten ableiten, die niemand eingegeben hat. Wenn jede Baugruppe die Compliance-Anforderungen ihrer Teile erbt, kennzeichnet eine neue Vorschrift für einen Werkstoff sofort jedes Produkt, das ihn enthält.

Entity Resolution. Der schwierigste und am wenigsten sichtbare Teil. „Pump_P101“ im Instandhaltungssystem, „P-101“ im MES und „Asset 4471-A“ im ERP müssen über Millionen von Datensätzen hinweg als ein und dasselbe Objekt erkannt werden. Geht das schief, schlussfolgern Agenten selbstbewusst über drei Pumpen, die in Wirklichkeit eine sind.

Materialisiert oder virtuell. Ein Graph kann Daten in einen Graph-Speicher kopieren oder sie dort belassen, wo sie sind, und sie bei Bedarf abbilden. Das Bosch-Werk in Salzgitter: eine Ontologie für die SMT-Elektronikfertigung, abgebildet auf bestehende Datenbanken. Maschinenstörungen, die an verschiedenen Maschinen unterschiedlich erfasst wurden, wurden in einer einzigen Ontologieklasse zusammengeführt – so konnten die Ingenieure endlich Gleiches mit Gleichem vergleichen.

Generative KI verankern. Dieselbe Struktur macht auch das Retrieval für Sprachmodelle präziser. LinkedIn erstellte einen Graphen aus historischen Kundenservice-Tickets, statt sie als losen Text zu behandeln. Im Produktivbetrieb verkürzte das System die mittlere Bearbeitungszeit pro Anfrage um 28,6 %. Die Lehre lässt sich direkt auf Service- und Qualitätsorganisationen in der Fertigung übertragen: Struktur schlägt einen größeren Dokumentenstapel.
‍

Wo sie angesiedelt sind: eine Kontextebene auf einem sauberen Kern

Im CLEVR Digital Renovation Principle bilden die Kernsysteme Ebene 1: ERP, PLM, CRM, MES und Eigenentwicklungen – die führenden Systeme, die sauber und stabil bleiben. Auf diesem Kern bilden Ontologie und Knowledge Graph Ebene 2: die semantische Kontextebene, auf deren Grundlage jede darüberliegende Ebene schlussfolgert. Orchestrierung und Intelligenz befinden sich in Ebene 3. In Ebene 4 treffen Menschen auf Agenten. Der Graph ersetzt kein führendes System; er macht die Systeme füreinander verständlich. Zusammen setzen die Ebenen das CLEVR-Prinzip in die Praxis um: den Kern sauber halten, eine intelligente Orchestrierungsplattform darüberlegen und mit KI verstärken, wo es sinnvoll ist.

Vier Ebenen · ein sauberer Kern als Basis, semantischer Kontext darüber

Jeder Agent und jede App in den darüberliegenden Ebenen bezieht die Bedeutung aus derselben Kontextebene, abgesichert durch dieselbe Vertrauensebene.

‍Siemens Intelligence Center X folgt derselben Logik, in vier Schritten:

1. Unternehmensdaten aus heterogenen Quellen und Datenplattformen.
2. Kontext: eine unternehmensweite Ontologieebene, die jedem Datenpunkt seine Bedeutung gibt, bereitgestellt durch Graph Studio.
3. Intelligenz: KI- und ML-Modelle in AI Studio, die aus semantisch angereicherten, nahezu in Echtzeit aktualisierten Daten lernen.
4. Aktion: Anwendungen, Workflows und Agenten, entwickelt und orchestriert auf Mendix, alle im selben Kontext verankert.

Eine unternehmensweite Vertrauensebene erstreckt sich über alle vier Schritte, mit Leitplanken, Nachvollziehbarkeit und Auditierbarkeit für Menschen und Agenten gleichermaßen. Die Engine von Graph Studio ist darauf ausgelegt, zig bis Hunderte Milliarden RDF-Tripel zu verarbeiten – im Arbeitsspeicher, auf der Festplatte oder virtualisiert –, und stellt den Graph Agenten über MCP zur Verfügung, damit sie domänenübergreifend explorieren und abfragen können.

Der Markt bewegt sich insgesamt in dieselbe Richtung. Microsoft hat Fabric IQ, seine ontologiebasierte Kontextebene für Agenten, auf der Build 2026 allgemein verfügbar gemacht und öffnet die Ontologie über MCP auch für Agenten anderer Anbieter. Databricks und Google haben ihre semantischen Ebenen in dieselbe Richtung weiterentwickelt, und Palantir hat Foundry seit Jahren um seine Ontologie herum aufgebaut. Die Frage ist nicht mehr, ob Sie eine semantische Ebene für Agenten brauchen, sondern welche Ihre Domäne versteht und ob sie sich mit den Plattformen verbindet, die Sie bereits nutzen. Intelligence Center X verbindet sich mit Microsoft Fabric, Snowflake, Databricks und Palantir, statt mit ihnen zu konkurrieren, und hebt sich in zwei Punkten ab: durch die Tiefe der industriellen Semantik, die es vom ersten Tag an mitbringt, und durch eine Graph-Architektur, die für Fragen gebaut ist, die niemand vorhergesehen hat.

‍
Vier Ansätze für die Ontologieebene

Nicht jede Ontologieebene ist gleich aufgebaut. Ein Blick unter die Haube zeigt: Der Markt teilt sich in vier Architekturansätze, die jeweils für eine andere Aufgabe optimiert sind.

Die ersten drei Ansätze sind stark in dem, wofür sie entwickelt wurden. Eine Metadatenebene sorgt für konsistente Dashboards und SQL-Analysen. Eine Objektebene funktioniert gut, wenn die Entscheidungen im Voraus bekannt sind und die Objekte dafür kuratiert werden können. Eine transaktionale Graphdatenbank ist schnell, wenn eine Frage von einem bekannten Knoten ausgeht, etwa einem Kunden oder einer Anlage.

So arbeiten Agenten aber nicht. Eine hybride Workforce stellt Fragen, die beim Entwurf des Datenmodells niemand vorhergesehen hat: Welche Lieferanten, Teile, Werke und Kunden sind betroffen, wenn dieser Werkstoff eingeschränkt wird – über alle Produktlinien hinweg? Eine solche Frage hat keinen einzelnen Ausgangspunkt und erstreckt sich über viele Verknüpfungen und Domänen zugleich. Auf einer Metadaten- oder Objektebene bedeutet das, zuerst neue Modelle oder Pipelines zu bauen. Auf einer transaktionalen Graphdatenbank bedeutet es, sich Knoten für Knoten nach außen vorzuarbeiten – was umso langsamer wird, je größer Graph und Frage werden.

Von den vier Ansätzen ist nur eine skalierbare Graphplattform für genau diese Frage ausgelegt. Graph Studio, die Kontextebene von Intelligence Center X, läuft auf einer massiv parallelen Engine, die den Graph über den gesamten Cluster verteilt, sodass jeder Prozessorkern an jeder Abfrage mitarbeitet. Die Ontologie wird automatisch aus den Quellsystemen generiert und verknüpft, statt für jede Quelle von Hand erstellt zu werden. Das ist der Unterschied zwischen Agenten, die die eingeplanten Fragen beantworten, und einem agentischen Unternehmen, in dem Menschen und Agenten jede beliebige Frage stellen können, ohne an Leistungsgrenzen zu stoßen.

Das macht die anderen Ansätze nicht überflüssig. Intelligence Center X verbindet sich mit den Datenplattformen, die Sie bereits nutzen, und ergänzt die Kontextebene, mit der Agenten über alle Plattformen hinweg schlussfolgern können.

‍

Vordefinierte Industrieontologien: nicht bei null anfangen

Eine vordefinierte Industrieontologie ist ein fertiges Modell dessen, was Dinge in der Fertigung bedeuten – Sie erweitern es, statt es neu zu erfinden. Genau hier hebt sich Intelligence Center X von generischen semantischen Ebenen ab.

Siemens liefert Intelligence Center X mit Industrieontologien aus, die branchenspezifisches Wissen über den gesamten Produktlebenszyklus abbilden. Standardmäßig decken sie die Kernobjekte des Digital Thread ab: Design, Teil, Konstruktionsstückliste (EBOM), technische Änderung, Arbeitsplan (Bill of Process), Servicestückliste, Garantiefall, Bestand und IoT-Zeitreihen. Diese sind live mit den führenden Systemen (PLM, ERP, CRM und Eigenentwicklungen) sowie mit Datenplattformen wie Microsoft Fabric, Snowflake, Databricks und Palantir verbunden. Siemens beschreibt das als Daten im Kontext, die „live, sicher, konfiguriert und sofort einsatzbereit“ sind.

Warum das wichtig ist, zeigt sich am deutlichsten an der Stückliste. Eine Konstruktionsstückliste (EBOM) beschreibt, was das Produkt ist. Eine Fertigungsstückliste (MBOM) beschreibt, wie es hergestellt wird. Eine Servicestückliste beschreibt, wie es gewartet wird. In den meisten Unternehmen liegen diese Stücklisten in unterschiedlichen Systemen, verantwortet von unterschiedlichen Teams, mit unterschiedlichen Kennungen. Eine Ontologie, die bereits weiß, wie eine EBOM-Position mit ihrem MBOM-Gegenstück zusammenhängt, welche technische Änderung beide betrifft und welche Serviceteile sich daraus ergeben, stellt Agenten den Digital Thread als navigierbare Struktur bereit. Zugleich spiegelt sie jahrzehntelange Siemens-Erfahrung mit Teamcenter, Opcenter und dem gesamten Xcelerator-Portfolio wider - Wissen, das sich nur mit großem Aufwand von Grund auf neu erarbeiten ließe.

Siemens ist in diesem Feld nicht allein. Mehrere offene Initiativen definieren Fertigungssemantik, und eine gute Ontologiestrategie weiß, wo sie ihren Platz haben:

Diese Ansätze ergänzen sich, statt zu konkurrieren. Die IOF Core ist so konzipiert, dass Domänenontologien untereinander konsistent bleiben (IOF). Die Verwaltungsschale strukturiert Asset-Informationen in Teilmodellen, deren Vorlagen die IDTA veröffentlicht(all-about-industries). Eine vordefinierte Plattformontologie bringt Sie am schnellsten in den Produktivbetrieb; ihre Abbildung auf offene Standards hält Sie interoperabel mit Lieferanten und Kunden.

Ein ehrlicher Vorbehalt: Keine vordefinierte Ontologie kennt Ihr Unternehmen. Ihre Produktfamilien, Namenskonventionen, werkspezifischen Prozesse und Eigenentwicklungen müssen weiterhin modelliert werden. Vordefinierte Ontologien verlagern die Arbeit vom Erfinden zum Erweitern – und das ist der Unterschied zwischen Monaten und Wochen.
‍

Was es braucht, um eine Ontologie aufzubauen

Ontologiedesign ist Handwerk, keine Konfigurationsmaske. Es gelingt, wenn es bei den Entscheidungen ansetzt und gemeinsam mit den Menschen entsteht, die sie treffen. Unserer Erfahrung nach folgt es sieben Schritten:

1. Bei den Entscheidungen ansetzen, nicht bei den Daten. Halten Sie die Fragen fest, die Agenten und Menschen beantworten können müssen: „Welche Kunden sind betroffen, wenn Lieferant X ausfällt?“ „Welche Produkte sind von dieser Änderung berührt?“ Knowledge Engineers nennen sie Kompetenzfragen. Sie definieren den Umfang und werden zum Testset.
2. Wiederverwenden, bevor Sie neu erfinden. Beginnen Sie mit einer vordefinierten Industrieontologie und offenen Standards wie der IOF Core oder der Verwaltungsschale. Modellieren Sie nur das, was Ihr Unternehmen unterscheidet.
3. Mit Fachexperten am Tisch modellieren. Ingenieure, Planer und Serviceverantwortliche wissen, was eine „Freigabe“ oder eine „Variante“ wirklich bedeutet. Die Integrationsarbeit bei Bosch zeigte, dass die Einbindung von Fachexperten sowohl für die Ontologie als auch für ihre Mappings entscheidend war.
4. Quellen abbilden. Verknüpfen Sie Felder in Teamcenter, SAP, dem MES und Ihren eigenen Anwendungen mit Ontologiekonzepten. Entscheiden Sie je Quelle, ob die Daten in den Graph kopiert oder virtuell abgefragt werden.
5. Entitäten auflösen. Legen Sie fest, welche Datensätze dasselbe reale Objekt beschreiben, und halten Sie diese Entscheidungen nachvollziehbar.
6. An der Realität validieren. Führen Sie die Kompetenzfragen aus. Prüfen Sie die Ontologie mit einem Reasoner auf logische Konsistenz. Lassen Sie Agenten Abfragen stellen und beobachten Sie, wo sie falsche Pfade nehmen.
7. Steuern und weiterentwickeln. Versionieren Sie die Ontologie, benennen Sie Verantwortliche pro Domäne und halten Sie den Graph mit seinen Quellen synchron. Ein Graph, der seinen Quellsystemen hinterherhinkt, enthält die Daten von gestern, und ein Agent, der darauf handelt, handelt auf Basis der Vergangenheit.

Genau deshalb dauerten Knowledge-Graph-Projekte früher ein Jahr, bevor sie Wert lieferten. Automatisierung ändert das. Siemens positioniert die automatisierte Ontologieerstellung aus Quellsystemen als Weg, monatelange Ontologieentwicklung überflüssig zu machen, und setzt über MCP angebundene Agenten ein, die beim Aufbau und bei der Pflege des Knowledge Graph selbst helfen. Die Forschung weist in dieselbe Richtung: Bei Bosch beschleunigte die automatische Umformung einer Domänenontologie in ein schlankeres Graphschema die Knowledge-Graph-Erzeugung für Schweißdaten um das Sieben- bis Achtfache.

Automatisierung beschleunigt die Schritte 2 bis 5. Die Schritte 1, 3 und 7 ersetzt sie nicht. Festzulegen, was Ihr Geschäft bedeutet und wer für diese Bedeutung verantwortlich ist, bleibt Aufgabe des Menschen.

Eine Ontologie für eine hybride Workforce

Eine hybride Workforce funktioniert nur, wenn Menschen und Agenten dieselben Definitionen, dieselben Regeln und dieselben Grenzen teilen. Alle drei sind in der Ontologie verankert.

Dieselben Definitionen. Wenn ein Planer und ein Planungsagent unter „verfügbarem Bestand“ oder „freigegebenem Teil“ dasselbe verstehen, hören Übergaben auf, Fehler zu erzeugen. Andernfalls trägt jeder Agent stillschweigend seine eigene Interpretation in seinem Prompt mit sich, und Sie haben genau die Silos wieder aufgebaut, denen Sie entkommen wollten.

Dieselben Regeln. Richtlinien, die auf Geschäftskonzepten statt auf Datenbanktabellen beruhen, gelten für alle. Intelligence Center X ergänzt den Knowledge Graph um eine richtlinienbasierte Zugriffskontrolle, die sich an Attributen von Nutzer und Daten orientiert. So regelt dieselbe Vorschrift, was ein menschlicher Nutzer und was ein Agent sehen darf. Ein Agent für Lieferantenqualität sieht, was ein Lieferantenqualitätsingenieur sehen darf – und nicht mehr.

Dieselbe Spur. Da jede Aktion auf Konzepte im Graph verweist, kann die Vertrauensebene nicht nur protokollieren, was ein Agent getan hat, sondern auch, worüber er nachgedacht hat. Das macht Entscheidungen auditierbar und Autonomie vertretbar.

Daraus entstehen auch neue Aufgaben für Menschen. In unserer Whitepaper-Reihe Digital Renovation haben wir Rollen wie den Agent Supervisor und den Eval Owner beschrieben. Hinzu kommt eine weitere: der Ontology Steward, die Fachperson, die verantwortet, was ein Konzept bedeutet, und Änderungen daran freigibt. Forscher bezeichnen dieses Profil als Knowledge Scientist. Wie auch immer Sie es nennen: Unternehmen, die auf diese Rolle verzichten, enden mit einem Graph, dem niemand vertraut.
‍

Der Einstieg: ein Thread statt des gesamten Unternehmens

Sie brauchen keine unternehmensweite Ontologie, bevor Ihr erster Agent live geht. Sie brauchen einen wertvollen Thread durch Ihre Systeme, gut modelliert, und ein Fundament, das mit jedem weiteren Anwendungsfall wächst.

Wählen Sie einen Workflow, der sich über mehrere Systeme erstreckt und heute Probleme bereitet. Qualität ist ein guter Kandidat. Siemens zeigt einen typischen Kreislauf von der Garantie bis zur Konstruktion, in dem Reklamationstriage, Untersuchung und Ursachenanalyse zwei bis vier Wochen dauern und die Lösung rund acht. Dieser Kreislauf umfasst Garantiefälle, Servicestücklisten, As-built-Konfigurationen, Teile und technische Änderungen – genau die Konzepte, die die vordefinierten Industrieontologien in Intelligence Center X bereits abdecken.

Von dort aus gilt der CLEVR-Ansatz, den wir bei jedem agentischen Programm anwenden: Think big, start small, scale fast. Groß denken heißt, die Ontologie als gemeinsames Fundament für Ihre gesamte hybride Workforce zu konzipieren. Klein anfangen heißt, mit einem Thread zu beginnen, der auf einer vordefinierten Ontologie aufbaut, statt von Grund auf neu entworfen zu werden. Schnell skalieren heißt, dass jeder neue Agent, jede App und jeder Workflow wiederverwendet, was der erste dem Graph beigebracht hat.

Agenten werden immer intelligenter. Ob sie dabei auch Ihr Geschäft besser verstehen, hängt von der Ebene unter ihnen ab.