Vendor lock-in: koden, prompts og data er jeres
Vendor lock-in betyder, at I ikke kan ændre, flytte eller stoppe en løsning uden leverandørens hjælp eller tilladelse. I AI handler det om fire ting: koden, prompts, data med loggen og den viden, der kun sidder hos leverandøren. Ligger de i jeres repo og jeres cloud, kan I skifte AI-partner en mandag og stadig køre agenten tirsdag.
Hvad er vendor lock-in i AI?
Lock-in kender I fra ERP og webshops. En agent giver flere steder at sidde fast, fordi den består af mere end kode.
- Koden: integrationerne til Business Central, Shopify og banken, og logikken, der kalder modellen.
- Prompts: agentens instruktioner, fx hvornår debitoragenten skriver venligt, og hvornår den sender til bogholderen.
- Data og log: hvad agenten har læst, hvad den har gjort, og hvem der godkendte det.
- Viden: hvorfor reglen om 30 dage blev til 45 for de ti største kunder. Står det kun i en konsulents hoved, er det også lock-in.
En AI-leverandør kan godt give jer adgang til alle fire og stadig holde jer fast. Adgang er at kunne se det. Ejerskab er at kunne ændre det, køre det og flytte det uden at spørge nogen.
Hvem ejer koden, prompts og data, når leverandøren går?
Svaret afhænger af, hvor løsningen kører. Sat op mod hinanden ser det sådan ud:
| Licensplatform hos leverandøren | I jeres egen cloud og repo | |
|---|---|---|
| Koden | Leverandørens. I har en konfiguration | Jeres, i jeres repo med fuld historik |
| Prompts | Ligger i platformens editor, ofte uden versioner | Filer i repoet, ændret og gennemgået som kode |
| Data og log | Kan eksporteres, i det format platformen vælger | Ligger i jeres Azure fra første dag |
| Modellen | Den, platformen har valgt | Den, I vælger, og den kan skiftes |
| Drifthåndbogen | Leverandørens support | Skrevet til jeres team, i repoet |
| Prisen næste år | Leverandøren sætter den | Jeres Azure-forbrug, som I kan se pr. agent |
| Når I stopper | Agenten stopper samme dag | Agenten kører videre |
Modellen er sin egen form for lock-in. I Microsoft Foundry kan I vælge mellem modeller fra OpenAI, Anthropic, Mistral og andre i samme Azure-tenant. Er agenten bygget, så modellen er én linje i en konfiguration, kan I teste en ny model en eftermiddag. Er den bygget ind i én leverandørs API, bliver det et projekt.
Seks spørgsmål til jeres AI-partner
Stil dem på første møde. En god AI-partner svarer på alle seks uden at tøve. Svarer de med en slide, ved I nok.
Hvor ligger koden?
Svaret skal være et repo i jeres GitHub eller Azure DevOps, som I har admin på.
Hvor kører agenten?
I jeres Azure-tenant, så I kan se den, slukke den og læse regningen.
Kan vi ændre en prompt selv?
Bed om at se, hvordan en ændring i debitoragentens tone kommer i drift. Hvem gennemgår den, og hvor står det?
Hvad sker der med loggen?
Hvert opslag og hver handling skal skrives et sted, I ejer, og ligge der, når leverandøren er væk.
Hvem hos os kan drive den?
Der skal stå et navn. Hvis svaret er »det klarer vi«, har I købt en afhængighed.
Hvad betaler vi, når I går?
Det bedste svar er jeres eget forbrug i Azure og intet andet. Licenser pr. bruger eller pr. agent fortsætter.
Hvad sker der, hvis I stopper samarbejdet?
Med en licensplatform er exit et projekt. I eksporterer data, skriver agenterne om i et nyt værktøj og kører de to systemer side om side i en periode. Det er dyrt nok til, at I bliver, også når I helst ville gå.
Når løsningen er jeres, er exit en dag som alle andre. Sådan ser den ud for en debitoragent, dagen efter leverandøren er gået:
Eksempel med opdigtede navne og tal.
Byg selv eller køb en platform?
Spørg hellere, hvilken del der skal være jeres. Standardfunktioner, som alle har, kan I købe. Jeres egne regler og jeres data skal I eje.
| Køb | Byg i jeres egen cloud |
|---|---|
| En intern FAQ-bot i Teams. Copilot Studio klarer det | Debitoragenten med jeres rykkerregler pr. kundegruppe |
| Bankafstemning af én konto i ét selskab. Business Central har den som standard | Afstemning af fire selskaber, valutakonti og Shopify-udbetalinger |
| Mødereferater og mailudkast. Microsoft 365 Copilot | Ugerapporten til ledelsen fra ERP, webshop og lager |
Lock-in bliver først et problem, når det, der adskiller jer fra konkurrenten, ligger i en andens editor.
Composable commerce: samme argument, flere licenser
Composable commerce er e-handelens version af samme tanke. I stedet for én stor platform sætter I webshop, PIM, søgning og checkout sammen af dele, der taler sammen via API. MACH Alliance kalder mønstret MACH: microservices, API-first, cloud-native SaaS og headless.
Idéen er god. Men fem SaaS-licenser er fem leverandører, der hver sætter deres egen pris. Og limen mellem dem er ofte en iPaaS-licens mere, hvor flowene ligger hos en partner. Så har I byttet én lock-in for seks.
Tjek, hvem der ejer integrationerne. Ligger de i jeres egen Azure med koden i jeres repo, er stakken composable. Ligger de i en lejet platform, er den bare spredt. Mere om det valg under systemintegration.
Hvornår lock-in er en fin handel
At eje alt kræver, at nogen hos jer vil eje det. Har I ingen, der kan læse en log eller godkende en ændring, er en platform med god support det ærlige valg. Så betaler I licens for, at andre tager ansvaret, og det er en rigtig handel.
Det samme gælder en proces, der aldrig ændrer sig, som momsindberetningen eller en standardrapport i Business Central. Bliv på standarden.
Alt, vi bygger, ligger hos jer fra første dag
Vi sælger ingen platform og ingen licens. Vi bygger hjernen og små agenter med ét job hver i jeres egen Azure. Koden og prompts ligger i jeres repo, loggen i jeres tenant, og hver agent har en navngiven ejer hos jer.
Jeres team bygger med fra første løsning. Undervejs skriver vi drifthåndbogen og ejerkortet, og forløbet slutter med overdragelsen: jeres team ændrer en agent, sender ændringen i drift og læser overvågningen uden os. Prisen er fast pr. trin, aftalt før vi går i gang, og første møde er gratis.
Hvad er vendor lock-in i AI?
Vendor lock-in i AI betyder, at I ikke kan ændre, flytte eller stoppe en agent uden leverandøren. Det sker, når koden, prompts, loggen eller viden om reglerne kun findes hos leverandøren. Testen er enkel: kører agenten videre dagen efter, I har opsagt aftalen?
Hvem ejer prompts, når en leverandør har skrevet dem?
Det står i kontrakten, og det skal stå der eksplicit. Prompts er en del af løsningen på linje med koden, fordi de bærer jeres regler. Bed om, at de ligger som filer i jeres repo med historik, så I kan se, hvem der ændrede hvad.
Hvad sker der, hvis vi stopper samarbejdet med vores AI-partner?
Med en licensplatform kører agenterne på leverandørens licens, så de stopper, når den stopper, og I skal bygge dem igen et andet sted. Ligger løsningen i jeres egen cloud og jeres repo, kører den videre, og I betaler kun jeres eget forbrug.
Skal vi bygge selv eller købe en AI-platform?
Køb det, der er standard og ikke ændrer sig, fx en intern FAQ-bot eller mailudkast. Byg det, hvor jeres egne regler og data er forskellen, fx rykkerflow og afstemning. Det kræver en ejer hos jer, og har I ingen, er en platform med god support det ærlige valg.
Er composable commerce en måde at undgå lock-in på?
Kun hvis I ejer integrationerne mellem delene. Composable commerce sætter webshop, PIM og checkout sammen af dele, der kan skiftes. Ligger limen i en lejet iPaaS-platform, har I flere leverandører at være afhængige af i stedet for én.
Hvor forsvinder jeres timer?
Tag den opgave med, der stjæler flest. Så siger vi ærligt, om agenter kan tage den, og hvad det kræver af jer.