Elke agent in uw onderneming moet één vraag beantwoorden voordat deze in actie komt: waar kijk ik eigenlijk naar? Een taalmodel kan een record uit Teamcenter, SAP en uw MES lezen. Op zichzelf kan het niet weten dat het "onderdeel" in alle drie hetzelfde fysieke object is, dat dit onderdeel in een assemblage zit waarvoor een open technische wijziging geldt, en dat de garantieclaim van vorige week precies naar die assemblage verwijst.
Uw medewerkers weten dit door jarenlange ervaring. Agents hebben dit op schrift nodig. Dat vastgelegde begrip is een ontologie, en zodra deze wordt gevuld met live data, wordt het een knowledge graph. Samen vormen ze de minst opvallende en tegelijk meest bepalende laag van de agentic enterprise: de laag waardoor mensen en agents vanuit dezelfde werkelijkheid werken.
Deze blog legt uit wat ontologieën en knowledge graphs zijn, hoe ze werken, waar ze in uw architectuur passen, wat de voorgedefinieerde industriële ontologieën in Siemens Intelligence Center X maakbedrijven opleveren, en wat ervoor nodig is om er zelf een te bouwen.
Weinig tijd? Hier een kort overzicht
- Agents falen op context, niet op modellen. Gartner verwacht dat 60% van de AI-projecten zonder AI-ready data wordt stopgezet. Of een agent waarde creëert of incidenten veroorzaakt, hangt ervan af of hij begrijpt wat uw data betekent.
- Een ontologie is het regelboek; een knowledge graph is de kaart die volgens dat regelboek is getekend. De graph verbindt elk onderdeel, elke wijziging en elke claim over uw systemen heen, zodat agents het pad van vraag naar antwoord kunnen volgen. Samen geven ze mensen en agents dezelfde definities, dezelfde regels en hetzelfde audittrail: de basis voor een hybride workforce die u kunt vertrouwen.
- Houd de core clean en leg context erbovenop. Uw core systems blijven onaangeroerd aan de basis. De ontologie en knowledge graph liggen er direct boven als gedeelde contextlaag, met orkestratie en AI daarbovenop waar dat zinvol is.
- Niet elke ontologielaag is gebouwd voor agents. Agents stellen vragen die niemand had voorzien, over veel systemen tegelijk. Graph Studio in Siemens Intelligence Center X is een schaalbaar graphplatform dat is ontworpen om zulke vragen op enterpriseschaal te beantwoorden, zonder prestatiegrenzen.
- Bouw voort op bewezen branchekennis. U hoeft de maakindustrie niet vanaf nul te modelleren. Voorgedefinieerde industriële ontologieën en open standaarden beschrijven de digital thread al, van engineering-stuklijst tot garantieclaim. Uw domeinexperts maken ze eigen: ze koppelen records over systemen heen en bepalen hoe het model zich ontwikkelt. Begin met één systeemoverstijgende workflow en laat elke volgende use case daarop voortbouwen.
Waarom agents vastlopen zonder context
Het model is zelden de bottleneck. De context waarmee het redeneert wel.
Gartner voorspelt dat organisaties tot en met 2026 60% van de AI-projecten zonder AI-ready data zullen stopzetten, en dat 63% van de organisaties de juiste datamanagementpraktijken voor AI mist of niet weet of ze die heeft. Specifiek voor agents verwacht Gartner dat eind 2027 meer dan 40% van de agentic-AI-projecten is stopgezet, vanwege oplopende kosten, onduidelijke bedrijfswaarde en ontoereikende risicobeheersing.
Het duidelijkste bewijs van wat context doet, komt uit een benchmark door data.world. Deze onderzoekers stelden GPT-4 zakelijke vragen over een bedrijfs-SQL-database uit de verzekeringssector. stelden GPT-4 zakelijke vragen over een SQL-database uit de verzekeringssector. Bij directe bevraging beantwoordde het model 16,7% van de vragen correct. Via een knowledge graph, gebouwd op een ontologie van dezelfde data, steeg de nauwkeurigheid naar 54,2%. Bij de moeilijkste vragen over de meest complexe schema’s scoorde directe SQL 0%, terwijl de route via de knowledge graph 36–39% haalde. Een vervolgstudie gebruikte de ontologie zelf om de queries van het model te controleren en te herstellen, en bracht de nauwkeurigheid naar 72%.
Hetzelfde model, dezelfde data. Het enige verschil was of de betekenis van de data expliciet was gemaakt. Voor een agent die niet alleen antwoordt maar ook handelt, bepaalt dat verschil of hij waarde creëert of incidenten veroorzaakt.
Waarom 72% een startpunt is, geen eindoordeel
Geen organisatie zou op basis van 72% moeten handelen, en geen goed ontworpen enterprisesysteem vraagt dat. De benchmark meet een taalmodel dat zonder vangrails zelf queries schrijft op open vragen. In productie veranderen drie dingen het beeld.
Ten eerste werkt de ontologie als controle, niet alleen als richtlijn. Queries die niet passen bij het model van de organisatie worden opgevangen en gecorrigeerd, of het systeem ziet af van een antwoord. Een bewust “ik weet het niet” is veilig. Een zelfverzekerd fout antwoord niet.
Ten tweede hangt de vereiste nauwkeurigheid af van de gevolgen. Bij het verkennen van een vraag is onzekerheid acceptabel. Bij het goedkeuren van een terugroepactie niet. Beslissingen met grote impact draaien op uitgewerkte regels en gevalideerde queries, met een menselijke goedkeuringsstap, terwijl open verkenning een ondersteunend hulpmiddel blijft.
Ten derde is elk antwoord herleidbaar. Welke data is gebruikt, welke query is uitgevoerd en wie de actie heeft goedgekeurd, wordt vastgelegd. Zo is een fout zichtbaar en te corrigeren, in plaats van verborgen.
De les uit het onderzoek is niet dat AI met ontologieën voor 72% betrouwbaar is. De les is dat het verankeren van AI in context de meest effectieve manier is om AI betrouwbaarder te maken, en eerlijk te laten zijn over waar de kennis ophoudt.
Het regelboek en de kaart
Een ontologie is het regelboek; een knowledge graph is de kaart die door dat regelboek is getekend. De twee termen worden vaak door elkaar gebruikt, maar ze hebben een andere functie.
De ontologie is een formeel vocabulaire voor uw organisatie. Ze definieert welke soorten dingen er bestaan (een pomp, een productielijn, een technische wijziging, een leverancier), welke eigenschappen ze hebben, hoe ze met elkaar in verband mogen staan en welke regels gelden. Een pomp kan in een lijn zijn geïnstalleerd. Een technische wijziging raakt één of meer onderdelen. Een onderdeel mag niet worden vrijgegeven zonder goedgekeurd ontwerp. Zonder ontologie heeft u een plaatje van punten en lijnen. Met een ontologie weet het systeem wat elk punt is en kan het erover redeneren.
De knowledge graph is dat vocabulaire toegepast op uw echte data: pomp P-101, lijn 3, wijzigingsverzoek ECR-2291 en de miljoenen verbanden daartussen, continu bijgewerkt vanuit uw core systems.
Dit onderscheid is cruciaal voor de agentic enterprise. In de ontologie leggen mensen vast wat iets voor de organisatie betekent. In de graph lezen agents en applicaties die betekenis en handelen ze ernaar. Zit de ontologie goed, dan erft elke nieuwe agent dat begrip automatisch.
Hoe een knowledge graph werkt
Een knowledge graph slaat elk feit op als triple: subject, relatie, object. Koppel genoeg triples aan elkaar en u krijgt een kaart waar mensen en agents doorheen kunnen lopen, in plaats van een datawarehouse dat ze met een dozijn moeizame joins moeten bevragen.
Triples. “Pomp P-101 is geïnstalleerd in lijn 3.” “Lijn 3 produceert product X.” “Product X bevat samenstelling 4471.” “Samenstelling 4471 heeft als eis max. 80 °C.” Elk ding is een node, elke relatie een edge. In de W3C-standaarden die de meeste enterprise graphs gebruiken, zijn dit RDF-triples, die met SPARQL worden bevraagd.
Traversal. Een vraag als “welke openstaande garantieclaims betreffen onderdelen die zijn geraakt door de technische wijzigingen van vorige maand?” loopt door PLM-, ERP- en servicedata. In een relationele wereld is dat een project. In een graph is het een pad: claim → serienummer → as-built-configuratie → onderdeel → wijziging. Agents zijn goed in het volgen van paden, zolang die paden bestaan en iets betekenen.
Ontologie vs Knowledge graph · één pad van claim naar wijziging
De linkerkolom wordt één keer geschreven, door mensen. De rechterkolom wordt continu gevuld vanuit uw systemen. Een agent die de linkerkant begrijpt, vindt de rechterkant voor elke claim, in elke fabriek.
Inferentie. Omdat de ontologie regels bevat, kan de graph feiten afleiden die niemand heeft ingevoerd. Als elke samenstelling de compliance-eisen van haar onderdelen erft, markeert nieuwe regelgeving voor één materiaal direct elk product waarin dat materiaal zit.
Entity resolution. Het moeilijkste en minst zichtbare deel. “Pump_P101” in het onderhoudssysteem, “P-101” in het MES en “asset 4471-A” in het ERP moeten over miljoenen records heen als één object worden herkend. Gaat dat mis, dan redeneren agents vol vertrouwen over drie pompen die in werkelijkheid één zijn.
Gematerialiseerd of virtueel. Een graph kan data kopiëren naar een graph store, of de data laten waar ze staat en die ter plekke mappen. De fabriek van Bosch in Salzgitter koos een ontologie voor SMT-elektronicaproductie, gemapt op bestaande databases. Machinestoringen die per machine verschillend werden geregistreerd, werden samengebracht in één ontologieklasse, zodat engineers eindelijk appels met appels konden vergelijken.
Generatieve AI verankeren. Dezelfde structuur maakt retrieval voor taalmodellen scherper. LinkedIn bouwde een graaf op basis van historische klantenservicetickets in plaats van ze als losse tekst te behandelen. In productie verkortte het systeem de mediane doorlooptijd per issue met 28,6%. De les is direct toepasbaar op een service- of kwaliteitsorganisatie in de maakindustrie: structuur wint van een grotere stapel documenten.
Waar het zit: een contextlaag bovenop een clean core
In het CLEVR Digital Renovation-principe vormen de core systems laag 1: ERP, PLM, CRM, MES en eigen applicaties, de bronsystemen die schoon en stabiel blijven. Bovenop die kern vormen de ontologie en knowledge graph laag 2: de semantische contextlaag waarmee elke laag daarboven redeneert. Orkestratie en intelligentie zitten in laag 3. In laag 4 ontmoeten mensen agents. De graph vervangt geen enkel bronsysteem; hij maakt de systemen voor elkaar begrijpelijk. Samen brengen de lagen het CLEVR-principe in de praktijk: houd de kern schoon, leg er een slim orkestratieplatform bovenop en versterk met AI waar dat zinvol is.
Vier lagen · een clean core als basis, semantische context erbovenop
Elke agent en app in de lagen daarboven haalt zijn betekenis uit dezelfde contextlaag, onder dezelfde vertrouwenslaag.
Siemens Intelligence Center X is volgens dezelfde logica opgebouwd, in vier stappen:
- Enterprisedata uit heterogene bronnen en dataplatforms.
- Context: een ontologielaag over de hele organisatie die elk datapunt betekenis geeft, geleverd door Graph Studio.
- Intelligentie: AI- en ML-modellen in AI Studio die leren van semantisch verrijkte data, die vrijwel realtime wordt ververst.
- Actie: applicaties, workflows en agents, gebouwd en georkestreerd op Mendix, allemaal geworteld in dezelfde context.
Over alle vier loopt een enterprisebrede vertrouwenslaag, met vangrails, herleidbaarheid en auditeerbaarheid voor zowel mensen als agents. De engine van Graph Studio is ontworpen voor tientallen tot honderden miljarden RDF-triples, in het geheugen, op schijf of gevirtualiseerd, en stelt de graph via MCP beschikbaar aan agents, zodat die over domeinen heen kunnen verkennen en bevragen.
De bredere markt beweegt dezelfde kant op. Microsoft maakte Fabric IQ, zijn op ontologie gebaseerde contextlaag voor agents, algemeen beschikbaar tijdens Build 2026 en stelt de ontologie via MCP open voor agents van andere leveranciers. Databricks en Google hebben hun semantische lagen in dezelfde richting ontwikkeld, en Palantir bouwt Foundry al jaren rond zijn Ontology. De vraag is niet langer of u een semantische laag voor agents nodig heeft, maar welke uw domein begrijpt en of die aansluit op de platforms die u al gebruikt. Intelligence Center X sluit aan op Microsoft Fabric, Snowflake, Databricks en Palantir in plaats van ermee te concurreren, en onderscheidt zich op twee punten: de diepgang van industriële betekenis die het vanaf dag één meebrengt, en een graph-architectuur die is gebouwd voor vragen die niemand had voorzien.
Vier benaderingen van de ontologielaag
Niet elke ontologielaag is op dezelfde manier gebouwd. Kijk onder de motorkap en de markt valt uiteen in vier architectuurbenaderingen, elk geoptimaliseerd voor een andere taak.
De eerste drie zijn sterk in waarvoor ze zijn ontworpen. Een metadatalaag maakt dashboards en SQL-analyses consistent. Een objectlaag werkt goed wanneer de beslissingen vooraf bekend zijn en de objecten daarvoor kunnen worden gecureerd. Een transactionele graphdatabase is snel wanneer een vraag start bij een bekende node, zoals één klant of één asset.
Zo werken agents niet. Een hybride workforce stelt vragen waar niemand aan dacht toen het datamodel werd ontworpen: welke leveranciers, onderdelen, fabrieken en klanten worden geraakt als dit materiaal wordt beperkt, over alle productlijnen heen? Zo’n vraag heeft geen vast startpunt en doorkruist veel stappen en domeinen tegelijk. Op een metadata- of objectlaag betekent dat eerst nieuwe modellen of pipelines bouwen. Op een transactionele graphdatabase betekent het node voor node naar buiten werken, wat trager wordt naarmate de graph en de vraag groeien.
Van de vier benaderingen is alleen een schaalbaar graphplatform ontworpen voor die vraag. Graph Studio, de contextlaag van Intelligence Center X, draait op een massaal parallelle engine die de graph over het hele cluster verdeelt, zodat elke processorkern aan elke query meewerkt. De ontologie wordt automatisch gegenereerd vanuit de bronsystemen en gekoppeld, in plaats van per bron handmatig te worden opgesteld. Dat is het verschil tussen agents die de vragen beantwoorden waarop u had gerekend, en een agentische organisatie waarin mensen en agents elke vraag kunnen stellen, zonder tegen prestatiegrenzen aan te lopen.
Dat maakt de andere benaderingen niet overbodig. Intelligence Center X sluit aan op de dataplatforms die u al gebruikt, en voegt de contextlaag toe waarmee agents over al die platforms heen kunnen redeneren.
Voorgedefinieerde industriële ontologieën: niet beginnen met een leeg blad
Een voorgedefinieerde industriële ontologie is een kant-en-klaar model van wat dingen in de maakindustrie betekenen, zodat u het uitbreidt in plaats van het zelf te bedenken. Hier onderscheidt Intelligence Center X zich van generieke semantische lagen.
Siemens levert Intelligence Center X met industriële ontologieën die branchekennis over de hele productlevenscyclus vastleggen. Out-of-the-box dekken ze de kernobjecten van de digital thread af: ontwerp, onderdeel, engineering-stuklijst (EBOM), technische wijziging, bill of process, servicestuklijst, garantieclaim, voorraad en IoT-tijdreeksen. Deze zijn live gekoppeld aan bronsystemen (PLM, ERP, CRM en eigen applicaties) en aan dataplatforms zoals Microsoft Fabric, Snowflake, Databricks en Palantir. Siemens omschrijft dit als data in context die “live, veilig, geconfigureerd en direct klaar voor gebruik” is.
Waarom dit ertoe doet, ziet u het best aan de stuklijst. Een engineering-stuklijst (EBOM) beschrijft wat het product is. Een productiestuklijst (MBOM) beschrijft hoe het wordt gemaakt. Een servicestuklijst beschrijft hoe het wordt onderhouden. In de meeste bedrijven staan deze stuklijsten in verschillende systemen, beheerd door verschillende teams, met verschillende identificaties. Een ontologie die al weet hoe een EBOM-item zich verhoudt tot zijn MBOM-tegenhanger, welke technische wijziging beide raakt en welke serviceonderdelen eruit voortvloeien, geeft agents de digital thread als navigeerbare structuur. Ze weerspiegelt bovendien decennia Siemens-ervaring met Teamcenter, Opcenter en het bredere Xcelerator-portfolio: kennis die duur is om vanaf nul opnieuw op te bouwen.
Siemens staat hierin niet alleen. Verschillende open initiatieven definiëren semantiek voor de maakindustrie, en een goede ontologiestrategie weet waar die passen:
Deze initiatieven vullen elkaar aan in plaats van te concurreren. De IOF Core is zo ontworpen dat domeinontologieën onderling consistent blijven (IOF). De Asset Administration Shell structureert assetinformatie in submodellen waarvan de IDTA de templates publiceert (all-about-industries). Een voorgedefinieerde platformontologie brengt u het snelst naar productie; door die te mappen op open standaarden blijft u interoperabel met leveranciers en klanten.
Eén eerlijke kanttekening: geen enkele voorgedefinieerde ontologie kent uw bedrijf. Uw productfamilies, naamgevingsconventies, fabrieksspecifieke processen en eigen systemen moeten nog steeds worden gemodelleerd. Voorgedefinieerde ontologieën verschuiven het werk van bedenken naar uitbreiden, en dat is het verschil tussen maanden en weken.
Wat er nodig is om een ontologie te bouwen
Ontologieontwerp is vakmanschap, geen configuratiescherm. Het slaagt wanneer het begint bij beslissingen en wordt gebouwd samen met de mensen die ze nemen. In onze ervaring volgt het zeven stappen:
- Begin bij de beslissingen, niet bij de data. Schrijf de vragen op die agents en mensen moeten kunnen beantwoorden: “Welke klanten worden geraakt als leverancier X uitvalt?” “Welke producten worden geraakt door deze wijziging?” Knowledge engineers noemen dit competency questions. Ze bepalen de scope en worden de testset.
- Hergebruik voordat u zelf bedenkt. Begin met een voorgedefinieerde industriële ontologie en open standaarden zoals de IOF Core of de Asset Administration Shell. Modelleer alleen wat uw bedrijf onderscheidt.
- Modelleer met domeinexperts aan tafel. EEngineers, planners en serviceverantwoordelijken weten wat een “release” of een “variant” echt betekent. Het integratiewerk bij Bosch liet zien dat de betrokkenheid van domeinexperts essentieel was voor zowel de ontologie als de mappings.
- Breng uw bronnen in kaart. Koppel velden in Teamcenter, SAP, het MES en uw eigen applicaties aan ontologieconcepten. Bepaal per bron of data naar de graph wordt gekopieerd of virtueel wordt bevraagd.
- Los entiteiten op. Bepaal welke records hetzelfde object in de echte wereld beschrijven, en houd die beslissingen uitlegbaar.
- Valideer aan de hand van de werkelijkheid. Draai de competency questions. Controleer de ontologie met een reasoner op logische consistentie. Laat agents de ontologie bevragen en kijk waar ze verkeerde paden nemen.
- Beheer en ontwikkel door. Versioneer de ontologie, wijs per domein eigenaren aan en houd de graph synchroon met zijn bronnen. Een graph die achterloopt op zijn bronsystemen bevat de data van gisteren, en een agent die daarop handelt, handelt op basis van het verleden.
Dit was vroeger de reden dat knowledge-graphprojecten een jaar nodig hadden voordat ze waarde opleverden. Automatisering verandert dat. Siemens positioneert automatische ontologiecreatie vanuit bronsystemen als manier om maandenlange ontologieontwikkeling overbodig te maken, en zet via MCP gekoppelde agents in om de knowledge graph zelf te helpen opbouwen en onderhouden. Onderzoek wijst dezelfde kant op: bij Boschmaakte het automatisch omvormen van een domeinontologie naar een slanker graphschema het genereren van knowledge graphs voor lasdata zeven tot acht keer sneller.
Automatisering versnelt stap 2 tot en met 5. Stap 1, 3 en 7 vervangt ze niet. Bepalen wat iets voor uw bedrijf betekent, en wie verantwoordelijk is voor die betekenis, blijft mensenwerk.
Eén ontologie voor een hybride workforce
Een hybride workforce werkt alleen als mensen en agents dezelfde definities, dezelfde regels en dezelfde grenzen delen. Alle drie liggen vast in de ontologie.
Dezelfde definities. Als een planner en een planningsagent hetzelfde bedoelen met “beschikbare voorraad” of “vrijgegeven onderdeel”, leveren overdrachten geen fouten meer op. Zonder dat draagt elke agent stilletjes zijn eigen interpretatie mee in zijn prompt, en heeft u de silo’s die u wilde doorbreken opnieuw opgebouwd.
Dezelfde regels. Beleid dat is uitgedrukt in bedrijfsconcepten in plaats van databasetabellen, geldt voor iedereen. Intelligence Center X voegt beleidsgestuurde toegangscontrole toe aan de knowledge graph, op basis van kenmerken van zowel de gebruiker als de data, zodat dezelfde regel bepaalt wat een menselijke gebruiker en een agent mogen zien. Een agent voor leverancierskwaliteit ziet wat een leverancierskwaliteitsengineer mag zien, en niets meer.
Hetzelfde spoor. Omdat elke actie verwijst naar concepten in de graph, kan de vertrouwenslaag niet alleen vastleggen wat een agent deed, maar ook waarover hij redeneerde. Dat maakt beslissingen auditeerbaar en autonomie verdedigbaar.
Dit creëert ook nieuw werk voor mensen. In onze whitepaperreeks Digital Renovation beschreven we rollen als de Agent Supervisor en de Eval Owner. Voeg er één aan toe: de Ontology Steward, de domeinexpert die eigenaar is van wat een concept betekent en wijzigingen daarin goedkeurt. Onderzoekers noemen dit profiel de knowledge scientist. Hoe u het ook noemt: organisaties die deze rol overslaan, eindigen met een graph die niemand vertrouwt.
Waar te beginnen: één proceslijn, niet de hele onderneming
U heeft geen ontologie voor de hele organisatie nodig voordat uw eerste agent live gaat. U heeft één waardevolle thread door uw systemen nodig, goed gemodelleerd, en een fundament dat meegroeit met elke volgende use case.
Kies een workflow die systemen overstijgt en vandaag pijn doet. Kwaliteit is een goede kandidaat. Siemens illustreert een typische lus van garantie naar engineering waarin klachttriage, onderzoek en rootcauseanalyse twee tot vier weken duren, en de oplossing zo’n acht. Die lus raakt garantieclaims, servicestuklijsten, as-built-configuraties, onderdelen en technische wijzigingen: precies de concepten die de voorgedefinieerde industriële ontologieën in Intelligence Center X al afdekken.
Van daaruit volgen we de CLEVR-aanpak die we bij elk agentisch programma toepassen: think big, start small, scale fast. Denk groot door de ontologie te ontwerpen als gedeeld fundament voor uw hele hybride workforce. Begin klein met één thread, uitgebreid vanuit een voorgedefinieerde ontologie in plaats van vanaf nul getekend. Schaal snel door elke nieuwe agent, app en workflow te laten hergebruiken wat de eerste de graph heeft geleerd.
Agents worden steeds slimmer. Of ze ook slimmer worden over uw bedrijf, hangt af van de laag eronder.
Find out how CLEVR can drive impact for your business
FAQ
Can't find the answer to your question? Just get in touch
