AI-agenter i Power BI-udvikling: sådan bygger vi oneBC365

AI-agenter i Power BI-udvikling er ikke en fremtidsvision hos os. Det er sådan, oneBC365 vedligeholdes i dag: modellen ligger som tekstfiler i Git, en AI-agent laver de gentagne ændringer efter nedskrevne regler, og et menneske gennemgår hver ændring, før den når en kunde. Her er opsætningen, og hvor grænserne går.

Resumé og konklusion

• Agenten kan kun arbejde på en model, der er tekst. Power BI-projektformatet med TMDL og PBIR gør hver tabel, hvert mål og hver rapportside til en fil, der kan læses, ændres og sammenlignes i Git.
• Én retning for ændringer. Al udvikling sker i én udviklingskopi og føres med scripts til den distributionskopi, kunderne får.
• De gentagne opgaver er skrevet ned som skills. Beskrivelser, oversættelser i tre sprog, sammenligning af modeller og genopbygning af et PBIP-projekt følger faste regler, som agenten læser, før den går i gang.
• Mennesket er reviewer, ikke tilskuer. Hver ændring gennemgås som en diff, og scripts i kontroltilstand viser forskelle uden at skrive noget.
• Agenten er god til mængde og konsistens, dårlig til betydning. Den kan skrive beskrivelser til hundredvis af mål efter samme regel. Den ved ikke, om dækningsbidraget passer med Business Central.

Forudsætningen: modellen ligger som tekst i Git

En klassisk .pbix-fil er en binær pakke. En AI-agent kan ikke læse den, og Git kan ikke vise, hvad der er ændret. Power BI-projektformatet (PBIP) deler i stedet modellen op i TMDL-filer og rapporten op i PBIR-filer. Et mål er nogle linjer tekst, en tabel er en fil, og en ændring er en diff.

På Microsoft Learn står PBIP stadig som preview. Microsoft har i Message Center (MC1465770) meddelt, at Power BI developer mode og PBIP-formatet bliver generelt tilgængelige med udrulning fra midten til slutningen af september 2026, og at PBIR bliver standardformatet for rapporter. Tjek jeres egen tenant, før I bygger processer på det.

Hos oneBC365 ligger hele løsningen som PBIP i Git. Al M-kode er kommenteret inline, og hver tabel, kolonne, mål og DAX-funktion har en beskrivelse. Det er skrevet for mennesker, men det er også det, der gør agenten brugbar: den kan læse, hvorfor et trin findes, før den ændrer det. Lagene i M-koden er beskrevet i Semantisk lag i Power BI.

Authoring-kopi og distributionskopi

Repositoriet har to kopier af samme projekt. Udviklingskopien er det eneste sted, der udvikles, og rapporten er live-forbundet til modellen i Power BI-tjenesten. Distributionskopien er TMDL og PBIR, åbner i Power BI Desktop og er den, der udrulles til en kundes workspace.

Ændringer går kun én vej, fra udvikling til distribution. De forskelle, der findes mellem kopierne, fordi Power BI Desktop og tjenesten ikke understøtter det samme, er bevidste og dokumenteret, så ingen retter dem ved en fejl.

Et lille sæt scripts holder kopierne i takt og køres altid i samme rækkefølge: ét fører koden fra udvikling til distribution, ét lægger refresh-politikkerne på igen, fordi en frisk TMDL-eksport fjerner dem, og ét viser de forskelle, der er tilbage. Alle kan køres i en kontroltilstand, der kun rapporterer.

Grafikken herunder viser flowet og hvor agenten og mennesket er involveret.

Hvad AI-agenter i Power BI-udvikling bruges til hos os

Beskrivelser efter faste regler

Hvert objekt skal have en beskrivelse på højst 200 tegn. Hvert mål starter med en kommentarblok, hvor beskrivelsen gentages. Kommentaren skal passe til koden, ikke til hensigten. Og en beskrivelse må aldrig kopieres fra et søstermål, fordi det er den hyppigste kilde til fejl: et beløbsmål, der er beskrevet som et kostmål. Reglerne er skrevet ned, og agenten følger dem.

Oversættelser i tre sprog

Modellen har cultures for da-DK, de-DE og en-US med navn, beskrivelse og visningsmappe pr. objekt. Nye objekter oversættes i en samlet runde, og et script sammenligner oversættelserne mellem de to kopier, så intet objekt mangler et sprog.

Sammenligning af modeller

Et script normaliserer de to modeller, så kun reelle forskelle vises, og de bevidste forskelle filtreres fra. Agenten kører scriptet, læser resultatet og forklarer, hvad der er drevet fra hinanden. Om forskellen skal rettes, afgør et menneske.

Genopbygning af et PBIP-projekt fra tjenesten

Når en semantisk model er ændret via XMLA-endpointet, kan den ikke længere downloades som .pbix. En skill samler en TMDL-eksport fra Tabular Editor 3 og rapporten til et lokalt PBIP-projekt: rapportens byConnection skiftes til byPath, database.tmdl renses, og til sidst tjekkes, at der ikke er rester af forbindelsen, kun én partition pr. tabel og ingen rollemedlemmer. Fremgangsmåden står i Rebuild a Power BI .pbix from a PBIR Report and an XMLA-Modified Semantic Model.

Skills og Power BI modeling MCP

En skill er en instruktionsfil med regler, eksempler og eventuelt et script, som agenten indlæser, når opgaven passer. Fordelen er, at reglerne skrives én gang og ikke skal forklares i hver samtale. Agenten arbejder på modellens kode og metadata i vores eget udviklingsmiljø. Den arbejder ikke i kundernes miljøer og behandler ikke kundernes data.

Power BI modeling MCP-serveren giver en agent adgang til at oprette og ændre tabeller, kolonner, mål, relationer og oversættelser, også i bulk, mod Power BI Desktop, et Fabric-workspace via XMLA eller en PBIP-mappe. Den er i public preview. Microsoft anbefaler at tage backup før ændringer og tilbyder en read-only-tilstand. Serveren ændrer ikke rapportsider. Forskellen på den og remote-serveren gennemgår vi i Power BI MCP-server: én til at spørge, én til at bygge.

Mennesket som reviewer

Ingen ændring når en kunde uden at være set som en diff. Det lyder som bureaukrati, men det er nødvendigt. En ændring i en gruppering i et kontoskema kan give en korrekt total og samtidig placere en post under en forkert overskrift. Koden kører uden fejl, og totalen stemmer, men rapporten viser noget forkert.

Den slags fejl finder hverken et script eller en agent alene. Det kræver en, der kender Business Central-kontoskemaet og sammenligner med tallene i Business Central. Derfor er reviewerens opgave ikke at læse hver linje, agenten har skrevet, men at kontrollere resultatet mod kilden.

Grafikken herunder opsummerer arbejdsdelingen.

Deployment hos kunden: dev, test og produktion

Med AI-agenter i Power BI-udvikling bliver det vigtigere, at ingen ændring går direkte i kundens produktion. Hos kunden flyttes modellen derfor gennem en deployment pipeline i Power BI med tre workspaces: Development, Test og Production. Ændringer fra Git lander i Dev, hvor kun navngivne personer arbejder. AI-agenten arbejder i vores udviklingsmodel og Git, ikke i kundens workspaces og ikke på kundens data. Nøglebrugerne afstemmer tallene mod Business Central i Test. Først derefter deployes til Production, hvor organisationen bruger rapporterne via en app.

Tre ting er værd at kende. En deployment kopierer kun metadata, ikke data, så den semantiske model skal opdateres i målstadiet efter første deployment. Legitimationsoplysninger, opdateringsplan og RLS-rolletildelinger følger heller ikke med og sættes én gang pr. workspace, jf. Microsofts beskrivelse af deployment-processen. Og fordi oneBC365 henter data via parameteren BaseUrl, bruges en parameterregel i Test og Production, så hvert stadie læser sit eget Business Central-miljø. Datakilderegler virker ikke på parametriserede datakilder, og der kan ikke laves regler i Dev-stadiet, ifølge dokumentationen af deployment-regler.

Stadiernes workspaces skal være Premium-workspaces: PPU eller en Premium- eller Fabric-kapacitet. Et almindeligt Pro-workspace kan ikke bruges. Vælger I PPU, skal alle, der bruger indholdet, også have en PPU-licens.

Grafikken herunder viser forløbet fra Git til produktion.

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

1. Gem modellen som PBIP og læg den i Git. Uden tekstfiler og historik kan I hverken bruge en agent eller se, hvad den har ændret.
2. Skriv jeres konventioner ned. Navngivning, præfikser, beskrivelsesregler og bevidste afvigelser. En agent følger regler, den kan læse, og gætter på resten.
3. Start i read-only-tilstand. Lad agenten forklare og sammenligne, før den må skrive. Tag backup før første ændring.
4. Tjek licensen til XMLA. Adgang via XMLA-endpointet kræver Premium, Premium per user eller Fabric-kapacitet, og en skrivning blokerer download som .pbix, jf. Microsoft Learn om XMLA.

Hvad AI-agenter i Power BI-udvikling ikke løser

Værktøjerne er unge. Power BI modeling MCP er i public preview, og implementeringen kan ændre sig markant før generel tilgængelighed. PBIP og PBIR er på vej fra preview til generelt tilgængelige i denne måned.

Agenten ved ikke, hvad jeres begreber betyder, medmindre det står i modellen. Den kan ikke vurdere, om et tal er rigtigt. Arbejdet skal deles op i afgrænsede opgaver: én regel og ét område ad gangen. Microsoft advarer desuden om, at en sprogmodel kan eksponere følsomme data fra den semantiske model, så arbejd på testdata eller i en model uden persondata. Ansvaret for, hvad der udrulles, ligger hos mennesket, og det bør stå skrevet ned som i Agent-governance: rettigheder, credits og logning på én side.

Sådan understøtter oneBC365 det

oneBC365 er bygget, så AI-agenter kan arbejde på den: PBIP med TMDL og PBIR i Git, kommenteret M-kode, beskrivelser på alle synlige tabeller, kolonner og mål, tre cultures og vedligeholdelsesscripts, der viser forskelle uden at skrive. Det er samme egenskaber, der gør modellen brugbar for Copilot og de AI-agenter på tværs af systemer, der læser den.

Kunden ejer koden, og BC-partneren kan vedligeholde den. Med oneAgent kan I selv lave AI-assisteret vedligeholdelse med Copilot eller andre agenter på en AI-klar model, eller lade oneBC365 gøre det.

Sådan kommer du i gang

1. Vælg én gentagen opgave. Beskrivelser på mål uden beskrivelse er et godt første valg, fordi resultatet er let at kontrollere.
2. Skriv reglen ned som en fil. Maks. 200 tegn, skrevet til en forretningsbruger, aldrig kopieret fra et andet mål.
3. Lad agenten lave ti, ikke to hundrede. Gennemgå de ti i en diff, justér reglen, og kør derefter resten.
4. Kontrollér mod Business Central. Vælg tre tal, agentens ændringer påvirker, og sammenlign med det samme tal i Business Central.

Relaterede artikler

• Power BI MCP-server: én til at spørge, én til at bygge
• Semantisk lag i Power BI: 4 lag med samme struktur som en dataplatform
• Agent-governance: rettigheder, credits og logning på én side
• Rebuild a Power BI .pbix from a PBIR Report and an XMLA-Modified Semantic Model
• Datafundamentet for AI: 4 krav før modellen kan bruges

Vil I se, hvordan en AI-klar model til Business Central ser ud på jeres egne tal? Book en demo, og se det live på 30 minutter.