Agent-governance: rettigheder, credits og logning på én side

Af /

Agent-governance er de regler, der gælder, når en AI-agent ikke bare svarer, men handler: opretter en ordre, behandler en faktura eller ændrer en debitor. Så skal fire ting være skrevet ned: hvem agenten er, hvad den må, hvad den må koste, og hvor I kan se, hvad den har gjort. Her samler vi det på én side.

Resumé og konklusion

  • En agent, der handler, kræver andre regler end en model, der forudsiger. En churn-model markerer en kunde, og et menneske handler. En agent opretter selv salgsordren, og fejlen rammer data, før nogen har set den.
  • Rettigheder skal styres i tre lag. MCP-konfigurationen og tilladelsessættene i Business Central afgør, hvad agenten må. RLS i den semantiske model afgør, hvad den ser, når den læser via Power BI.
  • Copilot Credits skal have et loft. Business Central-agenter afregnes pr. handling, og Copilot Studio-agenter kan få et månedligt loft pr. agent. Når kvoten er brugt, stopper agenten.
  • Logningen findes, men skal slås til. MCP-værktøjskald logges i telemetrien uden postdata. Hvilke felter der blev ændret, kræver ændringsloggen.
  • AI-literacy og GDPR art. 22 gælder fra første agent. Kravet i AI Act er blødt op, men ikke fjernet, og automatiske afgørelser om personer kræver menneskelig indgriben.

Hvad agent-governance ændrer, når agenten handler

I AI-governance og ROI: de første 12 måneder i 4 kvartaler handler governance om prædiktive modeller: forecast, churn og afvigelser. Modellen markerer, og et menneske beslutter. Governance er dér fire ting på én side: data, ejer, fejlhåndtering og GDPR.

Agenter ændrer ét forhold. Sales Order Agent opretter salgstilbud og ordrer ud fra e-mails. Payables Agent behandler leverandørfakturaer. En agent i Copilot Studio eller Claude kan ændre poster via Business Central MCP-serveren, hvis den har fået skriveadgang. Mennesket står ikke længere automatisk mellem beslutning og handling. Det skal designes ind.

Derfor skal governance for agenter svare på flere spørgsmål. Hvilken identitet kalder? Hvilke objekter må den skrive i? Hvad må den koste om måneden? Hvor ser vi, hvad den har gjort? Og hvornår skal et menneske godkende?

Identitet: hvem er agenten?

Svaret afhænger af agenttypen. Business Centrals indbyggede agenter har deres egen brugerkonto. Sales Order Agent får som standard tilladelsessættet SOA – EDIT og arver ikke rettigheder fra den person, der gennemgår opgaven. Den, der opretter agenten, skal have systemtilladelsen Configure All Agents.

Agenter, der bruger Business Central MCP-serveren, arbejder med den indloggede brugers identitet og rettigheder. Ikke-Microsoft-klienter som Claude og ChatGPT kræver en app-registrering i Microsoft Entra ID med den delegerede tilladelse Financials.ReadWrite.All og administratorsamtykke. Nye agenter i Copilot Studio får siden maj 2026 automatisk et Microsoft Entra Agent ID, som kan styres med Conditional Access og følges i Entras log over logins.

Den mest risikable identitet er en service principal. Microsoft skriver om den remote Power BI MCP-server, at RLS ikke håndhæves med service principal, som ser alle de data, den har adgang til.

Rettigheder i tre lag

Rettighederne skal passe i alle tre lag, fordi det svageste lag bestemmer.

  • MCP-konfigurationen. På siden Model Context Protocol (MCP) Server Configurations afgør Unblock Edit Tools samt Allow Create, Allow Modify, Allow Delete og Allow Bound Actions pr. API-side, om agenten kan skrive. Uden konfiguration er adgangen read-only.
  • Tilladelsessæt i Business Central. Brugerens eller agentkontoens tilladelsessæt afgør, hvilke data der må læses og ændres. En kopi af SOA – EDIT kan tilpasses, selve systemsættet kan ikke.
  • RLS i den semantiske model. Læser agenten via Power BI, afgør rollerne i modellen, hvilke rækker den ser. RLS gælder kun for brugere med Viewer-rollen i workspacen og ikke for en service principal på den remote MCP-server.

Grafikken herunder viser de tre lag, og hvad der omgår hvert af dem.

Agent-governance: rettigheder i tre lag fra MCP-konfiguration til RLS
Tre lag afgør, hvad en agent må og ser. Hvert lag har en undtagelse, der skal være besluttet.

Omkostningsloft: Copilot Credits

Agenter koster pr. handling. Ifølge Microsofts side om forbrugsbaseret afregning i Business Central koster Payables Agent 50 Copilot Credits pr. faktura plus 5 pr. linje, Expense Agent 50 pr. kvittering, og Sales Order Agent mellem 2 og 5 pr. handling. I Copilot Studio koster en agent action 5 credits og et generativt svar 2.

Tag en tænkt virksomhed med 400 leverandørfakturaer om måneden og i gennemsnit fire linjer pr. faktura. Det giver (50 + 4 × 5) × 400 = 28.000 Copilot Credits om måneden til Payables Agent alene. Tallet er ikke farligt i sig selv. Det farlige er, at ingen har besluttet, hvad der sker, når det bliver dobbelt så stort.

Loftet sættes forskellige steder. Forudbetalt kapacitet kan fordeles til bestemte Power Platform-miljøer i Power Platform admin center, så Business Central-miljøet kun bruger sin andel. Ved pay-as-you-go styres budgettet i Microsoft Cost Management i Azure. Copilot Studio-agenter kan få et månedligt loft pr. agent under Licensing, Copilot Studio, Manage Agents. Når kvoten er brugt i Business Central, er AI-funktionen utilgængelig, indtil der er tilført kapacitet. Agenten stopper midt i arbejdet, og det skal nogen opdage.

Logning og audit: hvad der bliver registreret

Business Central logger MCP-aktivitet i to spor. Fra version 28.0 sendes hvert værktøjskald til Application Insights som RT0054 “MCP Server tool called” med konfigurationsnavn, værktøjsnavn, klientnavn, app-ID og resultat. Oprettelse, ændring og sletning af MCP-konfigurationer logges også som telemetri, og ifølge release-planen for 2026 release wave 1 giver Microsoft Purview et revisionsspor for konfigurationsændringerne. Telemetrien kræver, at miljøet er koblet til en Application Insights-ressource.

Telemetrien logger ikke postdata. Den fortæller, at agenten kaldte et værktøj, der ændrer debitorer, ikke hvilket felt der fik hvilken værdi. Det kræver ændringsloggen i Business Central, slået til for de tabeller, agenten må skrive i. For de indbyggede agenter viser siden Agent Tasks trin, beskeder og logposter pr. opgave, og forbruget af Copilot Credits kan følges i Power Platform admin center.

Menneskelig godkendelse, AI-literacy og GDPR art. 22

Menneskelig godkendelse er en indstilling, ikke en holdning. Sales Order Agent kan fx sættes til at kræve gennemgang af alle beskeder fra ukendte afsendere og til at stoppe, når et tilbud er oprettet eller ændret. Beslut for hver agent, hvilke handlinger der kræver et menneske, og skriv det ned.

Artikel 4 i AI Act er med forordning (EU) 2026/1744, der trådte i kraft 27. juli 2026, ændret, så virksomheder skal træffe foranstaltninger, der understøtter medarbejdernes AI-literacy, uden at garantere et bestemt niveau. De medarbejdere, der konfigurerer agenter, godkender deres handlinger og læser deres log, er de oplagte at starte med.

GDPR art. 22 giver personer ret til ikke at blive underlagt en afgørelse, der udelukkende bygger på automatisk behandling og har retsvirkning eller tilsvarende betydning for dem. Undtagelserne er kontrakt, lovhjemmel og udtrykkeligt samtykke, og ved kontrakt og samtykke skal personen som minimum kunne få menneskelig indgriben, give sit synspunkt til kende og bestride afgørelsen. En agent, der spærrer kreditten for en enkeltmandsvirksomhed, kan ramme bestemmelsen.

Skabelon: agent-governance på én side

Skabelonen er det dokument, der skal findes for hver agent, før den får skriveadgang. Felterne er:

  • Agent og formål. Navn, type (indbygget agent, Copilot Studio eller MCP-klient) og opgaven i én sætning.
  • Ejer. Én navngiven person, der godkender ændringer og læser loggen.
  • Identitet. Agentkonto, Entra Agent ID, app-registrering eller brugerens identitet. Ingen service principal uden skriftlig begrundelse.
  • Læseadgang. API-sider, semantisk model eller postkasse, og RLS-rolle, hvis agenten læser via Power BI.
  • Skriveadgang. MCP-konfigurationens navn, API-sider med Allow-rettigheder og tilladelsessæt.
  • Godkendelse. Hvilke handlinger kræver et menneske, og hvem det er.
  • Omkostningsloft. Forventede credits pr. måned, loftet, hvor det er sat, og hvem der reagerer, når kvoten er ved at være brugt.
  • Logning. Application Insights-ressource, ændringslog på tabeller og hvor ofte loggen læses.
  • Persondata og GDPR art. 22. Behandler agenten persondata, og træffer den afgørelser om personer?
  • AI-literacy og stop. Hvem er introduceret til agentens grænser, hvem kan slå den fra, og hvornår er næste gennemgang?

Grafikken herunder viser skabelonen udfyldt for en tænkt Payables Agent.

Én-sides skabelon for agent-governance udfyldt for en tænkt Payables Agent
Ti felter på én side. Et tomt felt er den første opgave, før agenten får skriveadgang.

Sådan sætter du det op i Business Central og Power Platform

  1. Slå telemetri til Application Insights til for produktionsmiljøet i Business Central admin center.
  2. Slå ændringsloggen til for de tabeller, agenten må skrive i.
  3. Opret én MCP-konfiguration pr. agent med sit eget navn, så telemetrien kan skelne agenterne via configurationName.
  4. Fordel Copilot Credits til det Power Platform-miljø, Business Central er koblet til, og sæt et månedligt loft pr. Copilot Studio-agent.
  5. Kontrollér, at auditing i Microsoft Purview er slået til, og find Business Central-hændelserne under Dynamics365BusinessCentralLog.
  6. Tilpas en kopi af agentens tilladelsessæt, og fjern det, opgaven ikke kræver.

Hvad agent-governance ikke løser

En side med felter gør ikke en agent sikker. Den gør det tydeligt, hvem der har besluttet hvad. Telemetrien fortæller ikke, om en handling var rigtig, kun at den skete. Og loftet over credits beskytter budgettet, ikke kvaliteten.

Flere af de funktioner, skabelonen bygger på, er nye eller i preview, fx Expense Agent, Copilot Studio-værktøjet til Business Central MCP og Power BI’s MCP-servere. Logfelter og indstillinger kan ændre sig. Skabelonen er heller ikke en juridisk vurdering. Træffer en agent afgørelser om personer, skal jeres databeskyttelsesrådgiver se på det.

Sådan understøtter oneBC365 det

oneBC365 er ikke en agentplatform og tilbyder ikke writeback i dag. Løsningens rolle i agent-governance er læsesiden. Business Central-extensionen eksponerer data som read-only OData v4 API-sider og tilføjer ingen proces i Business Central. Den semantiske model kan få RLS. Standardleverancen har ingen færdige roller, men den anbefalede start er én dynamisk rolle på tabellen Company, der slår brugerens e-mail op i en tabel over tilladte selskaber.

Den anden rolle er definitionerne. Når en agent læser omsætning og dækningsbidrag fra en model med beskrivelser på alle synlige measures, er det lettere at dokumentere, hvad agenten har set, og at forklare et forkert svar. Hele modellen ligger som PBIP i Git, så ændringer i definitioner kan spores. Hvordan man kommer fra rapport til handling, gennemgår vi i Writeback i Power BI, og hvor klar organisationen er, i AI readiness: 5 dimensioner.

Sådan kommer du i gang

  1. Lav en liste over alle agenter, der kører eller er på vej. Tag de indbyggede Business Central-agenter, Copilot Studio-agenter og medarbejdernes egne MCP-klienter med.
  2. Udfyld skabelonen for den agent, der har mest skriveadgang. Står et felt tomt, er det den første opgave.
  3. Sæt loft og logning op, før agenten skalerer. Credits-loft i Power Platform admin center, telemetri i Application Insights og ændringslog på de tabeller, agenten skriver i.
  4. Hold en kvartalsvis gennemgang med ejeren. Læs loggen, sammenlign forbruget med loftet, og beslut, om rettighederne skal udvides eller indskrænkes.

Relaterede artikler

Vil I se, hvordan et read-only semantisk lag med definitioner og RLS ser ud på jeres egne tal? Book en demo, og se det live på 30 minutter.

Scroll to Top