Ejerskab af AI-løsningen: hvem ejer den, når konsulenten er gået hjem?

Af /

Ejerskab af AI-løsningen er det spørgsmål, de færreste stiller, før de køber, og det første, de stiller, når konsulenten er gået hjem. Hvem kan rette definitionen af dækningsbidrag? Hvor ligger agentens instruktioner? Hvem har adgang til app-registreringen? Tre ting skal ejes: data og definitioner, koden og konfigurationen, og beslutningen om, hvem der må ændre hvad.

Resumé og konklusion

  • En AI-løsning er mere end licensen. Den består af en semantisk model, instruktioner, konfiguration, app-registreringer og beslutninger. Det er dem, I skal eje, ikke kun abonnementet.
  • Afhængighed af en platform er et valg. Afhængighed af en person er en risiko. At løsningen kører på Microsofts platform er en beslutning. At kun én konsulent forstår den, er et problem.
  • Det, der ikke ligger i jeres Git og jeres tenant, ejer I ikke i praksis. Uanset hvad kontrakten siger, skal I kunne åbne, læse og ændre det uden leverandøren.
  • Dokumentation er en leverance. Skriv den ind i aftalen sammen med overdragelse af kode og adgang.
  • Beslutningen skal have en ejer i forretningen. IT kan drive løsningen, men en navngiven person i forretningen afgør, hvad tallene betyder.

Hvorfor ejerskab af AI-løsningen er en ledelsessag

Tag en tænkt grossist med 40 ansatte. En konsulent sætter en AI-assistent op, som ledelsen kan stille spørgsmål til om salg og dækningsbidrag. Det virker. Et halvt år senere beslutter økonomichefen, at fragt skal trækkes fra i dækningsbidraget. Ingen ved, om definitionen ligger i en rapport, i assistentens instruktioner eller i et regneark. App-registreringen er oprettet med konsulentens konto, og konsulenten er skiftet til en anden kunde.

Ingen af delene er teknisk svære. De er bare ikke ejet. Derfor er ejerskab af AI-løsningen en ledelsesbeslutning på linje med, hvem der må bruge hvilke værktøjer, som vi gennemgår i AI-politik på én side, og hvad løsningen må koste, som i Hvad koster AI i en SMV?

Ejerskab af AI-løsningen: de tre ting, der skal ejes

1. Data og definitioner

Den semantiske model er det sted, hvor omsætning, dækningsbidrag og debitordage er defineret. Når en AI-klient svarer på spørgsmål, læser den definitionerne derfra, som beskrevet i Spørg jeres tal: AI på den semantiske model i Power BI. Ejer I modellen, ejer I svarene. Det kræver, at modellen ligger i jeres egen Power BI-tenant, og at I har kildekoden: Power Query, measures og relationer.

2. Koden og konfigurationen

En AI-løsning består af flere stykker tekst og opsætning, end de fleste tror:

  • Modellen som kode. Et Power BI-projekt (PBIP) gemmer model og rapport som tekstfiler, der kan ligge i Git med fuld historik.
  • Instruktioner og prompts. Den tekst, der fortæller assistenten, hvilke tal den skal bruge og hvordan den skal svare.
  • Agent- og MCP-konfiguration. I Business Central kan MCP-serverens konfigurationer eksporteres som JSON-filer og importeres igen. De kan altså også versionsstyres.
  • Identiteter. App-registreringer i Microsoft Entra ID skal ligge i jeres tenant og have en ejer hos jer.

3. Beslutningen

Hvem må ændre en definition? Hvem godkender, at en agent får skriveadgang? Hvem slår den fra? Den slags beslutninger skal have en navngiven ejer i forretningen, ikke en afdeling. Rettigheder og logning for agenter er gennemgået i Agent-governance. Grafikken herunder samler de tre ting, og hvad der sker, når de ikke er ejet.

Ejerskab af AI-løsningen: data og definitioner, kode og konfiguration, beslutningen
Tre ting skal ejes. Mangler én, er I afhængige af den, der har den.

Leverandørafhængighed: hvad sker der, når konsulenten skifter?

Al software skaber afhængighed. Spørgsmålet er hvilken. At løsningen kører på Power BI og Business Central, er en platformsbeslutning, som mange partnere kan arbejde med. Det, der gør skiftet dyrt, er de fire typiske situationer herunder.

  • Koden ligger hos leverandøren. Repository, tenant eller konto tilhører leverandøren, og I har kun adgang til resultatet.
  • Løsningen er udokumenteret. M-koden har ingen kommentarer, measures har ingen beskrivelser, og instruktionerne til agenten findes kun i en chat-historik.
  • Løsningen kræver leverandørens eget værktøj. Kan modellen kun vedligeholdes i et værktøj, som én leverandør har licens til, kan I ikke skifte partner.
  • Kun én person forstår den. Selv en veldokumenteret løsning bliver dyr, hvis ingen anden har arbejdet i den.

Platformen ændrer sig også under jer. Microsofts oprindelige MCP-endpoint til forespørgsler mod Power BI er stadig i preview, og i dag anbefaler Microsoft Fabric IQ MCP-serveren i stedet. En løsning, I selv ejer og forstår, kan følge med. En løsning, kun leverandøren forstår, venter på leverandøren.

Otte spørgsmål før I køber en AI-løsning

Spørgsmålene virker både for en AI-assistent, en agent i Business Central og en Power BI-løsning. Et “nej” er ikke nødvendigvis et stop, men det skal være et bevidst valg.

  1. Hvem ejer koden og konfigurationen, når projektet er afsluttet? Står det i kontrakten?
  2. Ligger løsningen i jeres egen tenant? Model, agenter og app-registreringer, ikke kun en adgang til leverandørens.
  3. Ligger koden i et Git-repository, I har adgang til? Med historik, ikke en zip-fil ved projektets afslutning.
  4. Er den dokumenteret, så en anden kan læse den? Kommentarer i koden, beskrivelser på measures og en kort driftsvejledning.
  5. Kan en anden partner vedligeholde den? Med standardværktøjer og uden leverandørens licens.
  6. Hvem ejer definitionerne i forretningen? En navngiven person, der godkender ændringer.
  7. Hvad koster en ændring? Fast pris, timepris eller abonnement, og hvad der er inkluderet.
  8. Hvad sker der ved exit? Hvad overdrages, hvornår, og i hvilket format?

Grafikken herunder viser de fire første spørgsmål som et beslutningsdiagram med et modtræk til hvert nej.

Tjekliste før køb: fire spørgsmål om ejerskab af AI-løsningen
Et nej er ikke et stop, men det skal være et bevidst valg med en pris.

Sådan skriver I ejerskabet ind i aftalen

Ejerskab af AI-løsningen skal stå i kontrakten, ikke i salgsmaterialet. Fem punkter dækker det meste:

  • Rettigheder til koden. I ejer eller har fuld brugs- og ændringsret til det, der er udviklet til jer, inklusive model, instruktioner og konfiguration.
  • Placering. Repository, Power BI-workspaces og app-registreringer oprettes i jeres tenant og med jeres konti fra første dag.
  • Dokumentation som leverance. Kommenteret kode, beskrivelser på measures og en driftsvejledning er en del af leverancen og godkendes som den.
  • Overdragelse. Hvad leverandøren afleverer ved projektets afslutning og ved exit, og hvor hurtigt.
  • Pris på ændringer. Hvad koster vedligehold, og hvad er inkluderet i den aftalte pris.

Punkterne er en tjekliste til forhandlingen, ikke juridisk rådgivning. Lad en advokat se på formuleringen af rettighederne.

Hvad ejerskab af AI-løsningen ikke løser

At eje koden er ikke det samme som at kunne vedligeholde den. En SMV uden it-afdeling har brug for en partner, og det er fint. Pointen er, at I kan vælge en anden. Det gennemgår vi i Power BI i en SMV uden it-afdeling.

Ejerskab fjerner heller ikke afhængigheden af licenser. Sprogmodellen i Claude, ChatGPT eller Copilot ejer I ikke, og den skifter version uden at spørge. Derfor skal det, I ejer, være det, der ikke må skifte: definitionerne, rettighederne og beslutningerne. Git-integrationen i Fabric, der kobler et workspace direkte til Git, har desuden semantiske modeller og rapporter i preview, så tjek status, før I bygger processen på den.

Sådan understøtter oneBC365 det

oneBC365 er bygget, så ejerskabet ligger hos kunden. Kunden ejer koden, og BC-partneren kan vedligeholde den. Hele løsningen ligger som Power BI-projekt (PBIP) i Git med TMDL-model og PBIR-rapport, al M-kode er kommenteret inline, og der er vedligeholdelsesscripts til fx at sammenligne modeller. Modellen har beskrivelser på tabeller, kolonner og measures, og Business Central-extensionen eksponerer data som read-only OData v4 API-sider uden at ændre processer i Business Central.

Prisen er fast. Vedligeholdelsen kan I selv tage med Copilot eller agenter på en AI-klar model, eller lade oneBC365 gøre det. Hvordan vi selv arbejder med agenter, PBIP og Git, er beskrevet i AI-agenter i Power BI-udvikling. Det, oneBC365 ikke ejer for jer, er beslutningen: hvem der må ændre en definition, og hvilke AI-klienter der er godkendt.

Sådan kommer du i gang

  1. Lav en liste over jeres AI-løsninger. Tag også assistenter, agenter og MCP-forbindelser med, som enkeltpersoner har sat op.
  2. Find de tre ting for hver løsning. Hvor ligger definitionerne, hvor ligger koden og konfigurationen, og hvem ejer beslutningen?
  3. Flyt det, der ligger hos andre. Repository, app-registreringer og workspaces skal ind i jeres tenant med en ejer hos jer.
  4. Brug de otte spørgsmål ved næste indkøb. Bed om svarene skriftligt, før aftalen underskrives.

Relaterede artikler

Vil I se, hvordan en semantisk model, I selv ejer, ser ud på jeres egne tal? Book en demo, og se det live på 30 minutter.

Scroll to Top