En AI-funktion i et softwareprodukt hviler på fem valg, der bør tages, før den første linje kode skrives: hvilken model funktionen bygger på, hvor modellen kører, hvilke data den får at se, hvordan I måler kvaliteten, og hvad I gør, hvis modellen ændrer sig eller forsvinder. De valg er sværere at lave om bagefter end selve brugerfladen. Her gennemgås de i den rækkefølge, en ledelse kan følge, uanset om I selv koder.
Med en AI-funktion menes her en funktion, kunden møder i produktet, og som bygger på en sprogmodel, altså den type AI, der læser og skriver tekst. Er spørgsmålet stadig, om funktionen overhovedet skal bygges, så start med hvilket problem AI skal løse.
Købt tjeneste, åben model eller egen model
De fleste softwarevirksomheder har tre muligheder.
- Købt tjeneste. I sender tekst til en udbyders model over et programmeringsinterface, et API, og får svar tilbage. Det er den korteste vej, og udbyderen står for den tunge drift.
- Åben model, som I selv kører. Modellen ligger på jeres egne servere eller hos jeres cloududbyder. I får mere styr på, hvor data er, og hvornår modellen skiftes, og til gengæld overtager I driften, kapaciteten og opdateringerne.
- Egen trænet model. Det kræver data, særlig viden og tid, som få softwarevirksomheder har. Det giver mening, når modellen er selve produktets forskel på markedet, og det er sjældent udgangspunktet.
Et brugbart råd er at starte med den enkleste løsning, der kan bevise værdien, og bygge koden, så modellen kan skiftes. Samme tankegang som i bygge, købe eller integrere gælder her: det, der gør jer forskellige, skal I eje, og resten kan I leje.
Data er det dyreste valg at lave om
En sprogmodel kender ikke jeres kunder. Den bliver nyttig, når den får de rigtige oplysninger med i hvert spørgsmål. Tre spørgsmål afgør designet:
- Hvilke data skal funktionen bruge, og hvor ligger de i dag?
- Må netop denne bruger se de data, funktionen henter?
- Er data rene nok, eller er det halvdelen af projektet at få dem i orden?
Mange funktioner henter relevante dokumenter frem og lægger dem ved spørgsmålet. Teknikken kaldes RAG, retrieval augmented generation. Den ser enkel ud i en prøve, men adgangsstyringen skal holde hele vejen, og det er det punkt, der oftest bliver undervurderet. Det er uddybet i kundedata i AI-funktionen.
Spørg også udbyderen, hvor data behandles, om de gemmes, og om de bruges til at træne modellen. Svarene skal stå i aftalen og kunne gives videre til jeres egne kunder.
Kvalitet skal kunne måles fra starten
En almindelig funktion virker eller virker ikke. En AI-funktion virker i nogle tilfælde og fejler i andre, og den kan svare forskelligt på samme spørgsmål. Derfor skal I allerede i valget af model have en lille samling af virkelige eksempler med det svar, I ønsker. Så kan I sammenligne modeller på jeres egen opgave i stedet for på udbydernes oplysninger. Metoden er beskrevet i artiklen om test af AI-funktioner.
Beslut også, hvad et forkert svar koster. Et forkert forslag til en overskrift er en lille gene. Et forkert tal i en rapport til en kunde er noget andet, og det bør påvirke både design og model.
Afhængighed af én udbyder
Modeller bliver udskiftet, ændrer adfærd og udgår. Det er en driftsbetingelse, I skal bygge efter. Praktisk betyder det:
- Kaldet til modellen samles ét sted i koden, så et skift rammer få filer.
- Instruktionerne til modellen ligger i versionsstyring og behandles som kode.
- I har prøvet mindst én anden model på jeres testeksempler, så I ved, hvad et skift vil betyde.
- I har en plan for, hvad funktionen gør, når udbyderen er nede. Det kan være en pæn besked og en vej uden AI.
Leverandørafhængighed i bredere forstand er et ledelsesspørgsmål, men her handler det om at holde prisen på et skift nede med få, kedelige beslutninger.
Omkostninger, der følger brugen
Købte modeller afregnes som regel efter forbrug. Det ændrer økonomien i et produkt, der sælges med fast pris pr. bruger, for en ivrig bruger koster nu mere end en stille. Ledelsen bør derfor kende tre ting, før funktionen går i luften:
- Hvad driver forbruget? Længden af tekst, antal kald og valg af model.
- Hvor er loftet pr. kunde, og hvad sker der, når det nås?
- Kan en billigere model klare de lette opgaver, mens en stærkere tager de svære?
Mål forbruget pr. kunde fra første dag. Tallene hører med i prisfastsættelsen af funktionen, og uden dem gætter I.
Tjek reglerne, før I lægger jer fast
Bygger I på en sprogmodel og leverer funktionen under eget navn, kan I selv få en rolle efter EU’s AI-forordning, og en chat i produktet skal kunne fortælle brugeren, at det er AI. Afklar det tidligt, se udbyder eller idriftsætter. Funktioner, der påvirker folks job, uddannelse eller kredit, skal vurderes særskilt.
Sådan bruger I listen
Skriv valgene ned på én side, før udviklingen begynder: model, placering, data, måling, reserveplan, forbrug. Det tager en eftermiddag, og den side er det, I vender tilbage til, når nogen vil ændre retning. Den, der har ansvaret for arkitekturen, bør skrive den, og ledelsen bør læse den.
Det skal I lade være med
- At vælge model efter en sammenligning på nettet · test på jeres egen opgave med jeres egne eksempler.
- At sprede modelkald ud over hele koden · et skift af model bliver så en større ombygning.
- At starte med at træne en egen model · det binder folk og data, før værdien er vist.
- At give funktionen fri adgang til alle data · adgang er nemmest at give smalt fra begyndelsen.
Det skal I kræve af den eksterne
- ☐ Et beslutningsnotat på én side om model, data og måling.
- ☐ Forklaring af valgene i et sprog, en ikke-teknisk ledelse kan tage stilling til.
- ☐ Klare krav til, hvad udbyderen skal svare på om data og modelskift.
- ☐ En plan for forbrug og et loft pr. kunde.
- ☐ Modelvalg, der er begrundet i jeres behov og uafhængigt af provision eller partnerskaber.
Senest gennemgået: november 2026.
Næste skridt
Læs også: AI-agenter i produktet · Arkitekturbeslutninger, der er dyre at lave om
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
