AI-agenter på tværs af systemer: ét semantisk lag i stedet for en dataplatform

Af /

AI-agenter på tværs af systemer lyder som et dataplatformsprojekt, men det behøver det ikke at være. Når en agent skal svare på spørgsmål, der går på tværs af Business Central, CRM, service og planlægning, afgør én ting kvaliteten: om data er samlet i et semantisk lag med fælles dimensioner og klare definitioner. Det lag kan bygges i Power BI.

Resumé og konklusion

  • Agenten bliver aldrig klogere end det semantiske lag. Copilot, Fabric data agents og MCP-klienter som Claude og ChatGPT læser tabelnavne, relationer, beskrivelser og mål. Mangler definitionen af dækningsbidrag, gætter agenten.
  • Tværgående spørgsmål kræver fælles dimensioner, ikke flere agenter. Kunde, vare, ressource, dato og sag skal betyde det samme i alle systemer, før et svar om pipeline, servicemargin eller kapacitet kan passe.
  • Et semantisk lag i Power BI har samme struktur som en dataplatform. Base, Enriched, Curated og Model svarer til bronze, silver, gold og serveringslaget, men kører uden Fabric-kapacitet, lakehouse og pipelines.
  • Nye kilder følger samme mønster. Dynamics 365 Sales, Dynamics 365 Field Service eller et planlægningssystem får hver sin kæde af lag, og de fælles dimensioner samles i Curated-laget.
  • Der er grænser, og de er kendte. Power BI Pro giver 1 GB pr. semantisk model og otte planlagte opdateringer om dagen. Rammer I dem, kan lagene flyttes til Fabric, mens rapporterne bliver stående.

Hvad AI-agenter på tværs af systemer faktisk skal kunne

Tag et spørgsmål fra en direktør i en servicevirksomhed: “Hvilke kunder med åbne salgsmuligheder over 500.000 kr. har haft mere end tre servicebesøg i kvartalet, og hvad var dækningsbidraget på dem sidste år?” Salgsmulighederne ligger i Dynamics 365 Sales. Servicebesøgene ligger i Dynamics 365 Field Service. Fakturaer og kostpriser ligger i Business Central.

En agent kan i dag læse hvert system for sig. Business Central har fx en MCP-server, der som standard giver læseadgang til API-siderne. Men så skal agenten selv finde ud af, at kunden “Jensen A/S” i CRM er debitor 10230 i Business Central, og den skal selv regne dækningsbidraget ud af to kolonner. Det er to steder, hvor svaret kan blive forkert uden at nogen opdager det.

Problemet er ikke sprogmodellen. Problemet er, at nøglerne og definitionerne ikke findes ét sted. Det er den opgave, et semantisk lag løser.

Den klassiske opskrift: dataplatform, semantisk model og agenter

Dataplatform-leverandørerne sælger typisk samme tre trin. Først et fælles datalag på Microsoft Fabric med lakehouse, pipelines og notebooks. Så en semantisk model oven på. Til sidst AI-agenter, der læser modellen. Opskriften virker, og for virksomheder med store datamængder, mange kilder eller andre forbrugere end Power BI er den det rigtige valg. Tommelfingerreglen fra Hvornår er Power BI nok? er, at en dataplatform bør overvejes, når I skal kombinere mere end 5-8 datakilder.

For en SMV med Business Central og et par andre systemer er prisen ofte større end behovet. Lakehouses, warehouses, notebooks og pipelines kan kun oprettes i et workspace med en F-kapacitet eller prøvekapacitet, ifølge Microsofts licensoversigt for Fabric. Kapaciteten skal betales, pipelines skal overvåges, og nogen skal kunne Spark, SQL og Delta-tabeller. Det er før, den første agent har svaret på noget. Vi har gennemgået forskellen i Power BI eller dataplatform: en guide for ledelsen.

Ét semantisk lag i Power BI med samme struktur

Alternativet er at udvikle det hele i Power BI’s semantiske lag. Power Query kan bygge de samme lag, som en dataplatform har, blot inde i den semantiske model. I oneBC365 hedder de Base, Enriched, Curated og Model:

  • Base (BC_) henter rådata fra kilden og gør intet andet. Svarer til bronze.
  • Enriched (ER_) omdøber, typer, tilføjer surrogatnøgler og unknown-member-rækker. Svarer til silver.
  • Curated (CU_) laver joins, genererede tabeller og fælles dimensioner. Svarer til gold.
  • Model er tabellerne i den semantiske model med relationer, mål og RLS. Svarer til serveringslaget.

Kun model-tabellerne ligger i hukommelsen. De mellemliggende forespørgsler evalueres under opdateringen og fylder intet bagefter. Løsningen kører på Power BI Pro. Detaljerne lag for lag står i Semantisk lag i Power BI: 4 lag med samme struktur som en dataplatform.

Grafikken herunder viser arkitekturen fra kildesystemerne gennem de fire lag til de agenter, der læser modellen.

AI-agenter på tværs af systemer: kildesystemer gennem Base, Enriched, Curated og Model til Copilot, data agents og MCP-klienter
Fire kilder, fire lag, én semantisk model og tre slags agenter.

Hvorfor AI-agenter på tværs af systemer står og falder med definitionerne

Alle tre slags agenter læser det samme: tabelnavne, kolonnenavne, relationer, beskrivelser og mål. Power BI’s remote MCP-server er schema-aware og genererer DAX mod den semantiske model. Den er i public preview. Fabric data agents er generelt tilgængelige, kan kombinere op til fem kilder og respekterer RLS, men kræver en betalt F2- eller P1-kapacitet og understøtter i dag kun engelsk ifølge Microsofts dokumentation.

Hvis modellen har et mål, der hedder Dækningsbidrag, med en beskrivelse af, hvordan det er beregnet, bruger agenten det. Hvis ikke, bygger den sin egen formel. Det samme gælder kunden: findes der én kundedimension med én nøgle på tværs af systemerne, kan agenten filtrere på den. Findes der tre, vælger den en.

Grafikken herunder sammenligner de to måder, en agent kan nå data på.

Agent der læser tre kildesystemer direkte sammenlignet med agent der læser ét semantisk lag
Direkte adgang giver rå tabeller. Det semantiske lag giver definitioner.

Læsevejledning: seriens fire blokke

Serien har 12 artikler i fire blokke. Læs blok 1 først, hvis I skal tage stilling til arkitekturen. Spring til blok 3, hvis I allerede har modellen og vil i gang med agenter.

Blok 1: Arkitektur

Blok 2: Kilderne

Blok 3: Agenterne

Blok 4: Fra indsigt til handling

Sådan sætter du det op i jeres model

Start med spørgsmålene, ikke med teknologien. Skriv de fem spørgsmål ned, som ledelsen stiller og ingen kan svare på uden at samle tal fra flere systemer. Notér for hvert spørgsmål, hvilke systemer der indgår.

Find derefter de fælles dimensioner. I de fleste SMV’er er det kunde, vare, ressource eller medarbejder, dato og sag. Beslut for hver dimension, hvilket system der ejer stamdata, og hvilken nøgle der binder systemerne sammen. Bruger I Business Centrals integration til Dynamics 365 Sales, er koblingen mellem debitor og konto et oplagt udgangspunkt.

Til sidst: giv hver tabel, kolonne og mål en beskrivelse, og skjul tekniske felter. Det er dét, agenterne læser.

Hvad et semantisk lag ikke løser

Power BI Pro har faste grænser. En semantisk model må højst fylde 1 GB, der kan planlægges otte opdateringer om dagen, og en opdatering skal være færdig inden for to timer. Incremental refresh virker på Pro og hjælper på både tid og mængde, men ændrer ikke loftet. Realtid er det heller ikke: data er så friske som seneste opdatering.

Skal andre end Power BI bruge data, fx et machine learning-projekt eller en anden applikation, er en lakehouse det rigtige sted. Og AI-laget kræver kapacitet under alle omstændigheder: Copilot i Power BI og Fabric data agents kræver F2 eller P1. Pointen er, at datalaget ikke også behøver det.

Sådan understøtter oneBC365 det

oneBC365 er bygget efter præcis denne arkitektur. En read-only Business Central-extension eksponerer data som OData v4 API-sider, og Power Query-modellen har flere hundrede forespørgsler fordelt på fire lag og delte funktioner, der ender i over 100 modeltabeller. Modellen dækker ni moduler med over 400 færdige mål, er oversat til dansk, engelsk og tysk og følger Microsofts anbefalinger til Copilot: stjerneskema, beskrivelser, entydige navne og skjulte tekniske felter.

Modellen er i dag bygget på Business Central-data. Strukturen er lavet, så en ny kilde kan få sin egen kæde af lag og mødes med Business Central i Curated-laget. Den udvidelse kan oneBC365 levere som en del af services. Den aftales og estimeres pr. kilde, og målet er, at de rapporter, der allerede findes, virker uændret. Den dag volumen, realtid eller andre forbrugere kræver det, kan lagene flyttes til Dataflows Gen2 eller en Fabric Lakehouse, mens rapporterne bliver stående. Kunden ejer koden, og BC-partneren kan vedligeholde den.

Sådan kommer du i gang

  1. Skriv jeres fem tværgående spørgsmål ned. Notér for hvert spørgsmål, hvilke systemer det kræver, og hvem der stiller det.
  2. Kortlæg de fælles dimensioner. Find nøglen for kunde, vare, ressource, dato og sag i hvert system, og tjek hvor mange poster der mangler en kobling.
  3. Tjek jeres licenser og tenant. Har I Power BI Pro til alle brugere? Har I en F- eller P-kapacitet til Copilot og data agents, eller skal den købes?
  4. Vælg én agent og ét spørgsmål. Test spørgsmålet mod den semantiske model, og sammenlign svaret med tallet fra Business Central, før flere får adgang.

Relaterede artikler

Vil I se, hvordan et semantisk lag med Business Central-data ser ud på jeres egne tal? Book en demo, og se det live på 30 minutter.

Scroll to Top