Sådan vælger du den rigtige AI-model til din use case som udvikler

Det korte svar: sådan vælger du AI-model som udvikler

Vælg ikke AI-model ud fra hype eller modelnavn, men ud fra din konkrete use case. Start med opgavetype (fx kode, dokumenter, chat), datafølsomhed og krav til kvalitet, pris og latency. Test 2-3 kandidater med dine egne prompts og data, og vælg den model og deploymentform (hosted, open-weight eller lokal), der samlet set rammer din kvalitetsgrænse, dit sikkerhedsniveau og dit budget.

Resten af artiklen går systematisk igennem modeltyper, beslutningsmatrix, pris, compliance og en praktisk testmetode, som du kan kopiere direkte ind i dit projekt.

Hvilke typer AI-modeller skal du kende?

De fleste udvikleropgaver bør ikke starte med den største model. Start med opgavens datatyper, kompleksitet og krav til output, og vælg derefter mellem standard, reasoning, multimodal, mini eller pro-variant. Det er sjældent nødvendigt at gå i “max alt”-mode for at få noget stabilt i drift.

Som udvikler støder du typisk på disse modeltyper:

• Standard sproglige LLM’er (Language Models)
• Reasoning-modeller (forstærket til længere kæder af ræsonnement)
• Multimodale modeller (tekst + billeder, evt. lyd/video)
• Mini-/light-modeller (optimeret til pris og latency)
• Pro-/premium-modeller (større, dyrere, typisk bedst på svære opgaver)
• Open-weight modeller (vægtfiler til selv-host eller specialhosting)

Derudover har du tre grundlæggende deploymentformer, som vi vender tilbage til: hosted API, open-weight og lokal/self-hosted.

Standard LLM

En standard LLM er den “almindelige” chat- og tekstmodel. Den er god til:

• Generel tekst, forklaringer og simple transformationer
• Let kodehjælp, små snippets og dokumentation
• Prototyper og interne værktøjer uden ekstreme kvalitetskrav

Vælg typisk en standard LLM, hvis du bygger:

• En simpel chat-funktion til udviklere eller brugere
• Små CLI- eller web-tools til kodeeksempler og forklaringer
• Low-risk features, hvor fejl er til at leve med

Reasoning-modeller

Reasoning-modeller er trænet og tunet til at arbejde mere eksplicit i flere trin. De er ofte langsommere og dyrere, men stærkere på:

• Kompleks debugging og fejlfinding
• Større refaktoreringer og arkitekturforslag
• Dyb dokumentanalyse og regler/kontrakter
• Opgaver hvor fejl er dyre (compliance, økonomi, kritiske flows)

Du bør overveje en reasoning-model, når din opgave virker mere som en “mini-konsulent” end som en autocomplete.

Multimodale modeller

En multimodal model kan typisk kombinere tekst med billeder, og i nogle tilfælde også lyd og video. Det er relevant, når du fx vil:

• Læse skærmbilleder, UI-mockups eller diagrammer og generere kode
• Trække tekst ud af scannede dokumenter (OCR) og derefter analysere dem
• Bygge værktøjer til support, der forstår uploads (pdf, billeder)

Hvis din use case primært er ren tekst eller ren kode, behøver du ikke multimodalitet. Når du begynder at bruge screenshots, arkitekturdiagrammer eller pdf’er som input, er multimodalitet pludselig afgørende.

Mini- og pro-modeller

Mini-/light-modeller er designet til at være hurtige og billige. De er ofte helt fine til:

• Autocomplete i editoren
• Små helper-funktioner i UI’et
• Enkle klassifikationer eller korte svar

Pro-/premium-modeller er typisk top-tier på benchmarks og bedst til:

• Komplekse kodeopgaver og store refaktoreringer
• Avanceret dokumentforståelse og summarization på tværs af mange kilder
• High-stakes use cases, hvor fejlraten skal så langt ned som muligt

Det er almindeligt at kombinere fx en mini-model til hurtige, små kald og en pro-model til de tunge opgaver.

Open-weight modeller

Open-weight betyder, at du kan hente selve modelvægtfilen og køre den på eget hardware eller hos en hostingpartner. Det giver:

• Mere kontrol over data og drift
• Mulighed for dybere tilpasning (fine-tuning, specialprompting på systemniveau)
• Mindre vendor lock-in

Til gengæld kræver det, at du (eller dit team) faktisk har tid og kompetencer til at drive modellen. Open-weight modeller er ofte et godt valg til større organisationer, der gerne vil bygge eget økosystem, men kan være overkill til et enkelt sideprojekt.

Hvis du mangler et solidt begrebsfundament, kan du læse guiden om hvad en AI-model er som supplement.

Sådan vælger du modeltype til din use case

Vælg modellen ud fra den opgave, du faktisk skal løse, ikke ud fra modelnavn eller benchmark alene. Den bedste model er den, der rammer din kvalitetsgrænse, din sikkerhedsgrænse og dit budget på samme tid. Det kræver, at du får kravene ned på et mere konkret niveau end “bedst muligt”.

En praktisk måde er at tænke i en simpel beslutningsmatrix. Du vægter nogle få kriterier, scorer 2-3 modeller, og tager et valg ud fra tallene og din mavefornemmelse.

1. Definér use casen skarpt

Før du kigger på modeller, skal du kunne svare kort på:

• Opgavetype: Hvad skal modellen faktisk gøre? (fx code completion, dokumentanalyse, chat-support, agent-workflow)
• Fejltolerance: Hvad sker der, hvis modellen tager fejl?
• Data: Er der persondata eller fortrolige oplysninger?
• Brug: Hvor mange kald pr. dag og hvor kritisk er latency?

For kodeopgaver kan du med fordel også tænke i din samlede praksis omkring AI som “medprogrammør”, fx som beskrevet i denne guide om AI som medprogrammør.

2. Beslutningsmatrix: de vigtigste kriterier

Nedenfor er en enkel matrix, som du kan tilpasse. Giv hver model en score fra 1 til 5 per kriterium, og vægt kriterierne efter hvor vigtige de er for din use case.

For hver use case kan du justere vægtene. En intern kodeassistent til et lille team kan acceptere lidt højere pris og lavere latency-krav, mens et kundevendt supportflow med høj volumen vægter pris og svartid tungere.

3. Mapping mellem use cases og modeltyper

Som tommelfingerregel:

• Code completion / inline-hjælp: mini- eller standard LLM, lav latency vigtigere end perfekt ræsonnement.
• Code review / refaktorering: reasoning- eller pro-model, kvalitet og begrundelser vigtigere end pris.
• Testgenerering: standard eller reasoning-model med stærkt struktureret output (fx JSON med testcases).
• Dokumentanalyse: multimodal eller stor context-model, evt. kombineret med RAG-setup.
• Agent-workflows: model med stabil tool calling, god kontekststyring og robust JSON-output.

Hvis du arbejder med mere avancerede agent-setup, kan du med fordel læse om forskellen på chatbots og agenter i artiklen om AI-agenter.

4. Beslutningsregler i praksis

Når du har scoret 2-3 modeller i matrixen, kan du bruge nogle simple regler:

• Hvis en billigere model scorer næsten lige så højt på kvalitet som en dyr pro-model, så start med den billige.
• Hvis en model falder under din minimumskrav-score på kvalitet eller struktureret output, er den no-go uanset pris.
• Hvis compliance-risiko eller datafølsomhed er høj, filtrér modellerne efter deploymentform før du kigger på pris og latency.

Det er sjældent en perfekt matematisk beslutning, men matrixen gør det tydeligt, hvad du bytter væk for at spare tid eller penge.

Hvilken model er bedst til kodning, review og test?

Til simple kodeopgaver kan en hurtig og billig model ofte være nok, men til refaktorering, kodegennemgang og testgenerering bør du typisk vælge en model med bedre reasoning, struktur og stabilitet. Du kan sagtens ende med én model til editor-autocomplete og en anden til CI/CD-pipelinen.

Code completion og små snippets

Inline code completion og korte snippets kræver primært:

• Lav latency (response under få hundrede millisekunder føles bedst)
• Rimelig kvalitet (men du reviewer alligevel koden)
• Billig pris ved mange små kald

Her er mini- eller standardmodeller ofte glimrende. De skal forstå kontekst fra dine nærmeste linjer og fil, men sjældent hele repoet.

Debugging og forklaringer

Når du beder modellen forklare en stack trace, foreslå en fix-strategi eller gennemgå et stykke kode for fejl, er kravene anderledes:

• Højere krav til reasoning og fejlsøgning
• Evne til at holde flere trin i hovedet og ikke bare gætte
• Gerne mulighed for at se flere filer eller et uddrag af repoet

Her giver en stærkere standard- eller reasoning-model typisk bedre resultater. Du vil ofte ofre lidt latency og pris for færre hallucinationer og mere solide forslag.

Code review og refaktorering

Automatiseret code review og større refaktoreringer kræver:

• Stabil forståelse af koden på tværs af flere filer
• Konsekvente begrundelser (hvorfor en ændring er bedre)
• Lav hallucinationsrate i både kode og forklaringer

Her er det svært at slippe afsted med de billigste modeller. Vælg en model, der:

• Kan arbejde med større context windows (flere filer ad gangen)
• Har dokumenteret styrke på kodeopgaver
• Leverer brugbare diffs i første forsøg

Hvis du vil dykke ned i forskelle mellem kodefokuserede modeller, kan du se sammenligning som Codex vs. Claude Code for at få en fornemmelse af trade-offs.

Testgenerering og CI/CD

Til generering af unit tests, API-tests og UI-tests er kravene typisk:

• Struktureret output (gyldig kode, gyldig JSON eller testskabeloner)
• Forudsigelighed (samme prompt skal give nogenlunde samme form)
• God integration i CI/CD, så fejler er lette at reproducere

Evaluer modellerne på:

• Andel af genererede tests, der faktisk passerer
• Hvor meget du manuelt skal rette i output
• Om output kan parses maskinelt uden special-cases

Her er det vigtigt at kombinere modelvalg med en sund tilgang til automatisering og kvalitet. Du kan eventuelt læse mere om test og pipelines i egne CI/CD-guides, hvis du arbejder tungt i den retning.

En god tommelfingerregel er også: jo mere AI’en rører ved produktionskode, desto mere disciplin skal du have omkring review og kvalitet – som beskrevet i artiklen stop med bare at copy-paste AI-kode.

Hvor vigtigt er context window, multimodalitet og tool use?

Et stort context window er kun en fordel, hvis din opgave faktisk kræver mange inputtokens eller lange dokumenter. Hvis ikke, er det ofte vigtigere at vælge en model med bedre pris, lavere latency og mere stabilt output. Context-størrelse, multimodalitet og tool use er værktøjer, ikke mål i sig selv.

Context window

Context window er den mængde tekst (tokens), modellen kan have “i korttidshukommelsen” på én gang.

• Moderne modeller kan have context windows på op til omkring 1-2 millioner tokens, svarende til tusindvis af sider.
• Det er nyttigt, når du vil arbejde med hele rapporter, bøger eller større kodebaser i ét kald.
• Det løser dog ikke automatisk kvalitetsproblemer – modellen kan godt overse relevante bidder i en enorm kontekst.

Hvis du primært sender korte prompts og små uddrag, får du ikke meget ekstra værdi af et kæmpe context window, men du kan godt komme til at betale for det i pris og latency. Hvis du vil nørde dybere i tokens og context, kan du kigge på guiden om tokens, pris og context length.

Multimodalitet

Multimodale modeller er relevante, når:

• Du vil lade udviklere uploade screenshots af fejl og få forklaringer
• Du vil parse og forstå scannede pdf’er eller konsulentslides
• Du bruger billeder som del af produktet eller dev-værktøjet

Hvis din use case er ren tekst og kode, behøver du ikke nødvendigvis betale for multimodalitet. Overvej det først, når du konkret har brug for det.

Tool use / function calling og struktureret output

Tool use (ofte kaldet function calling) er modellens evne til at kalde dine egne funktioner eller API’er på baggrund af en prompt. Det er centralt i:

• Agent-workflows, der skal slå data op i dine systemer
• Systemer, hvor modellen skal vælge mellem flere værktøjer (fx “search”, “book”, “calculate”)
• Integrationer, hvor AI’en mest fungerer som en styringslogik

Her skal du teste, hvor godt modellen:

• Genererer gyldige function arguments
• Holder sig til JSON Schema eller andre kontrakter
• Kan kæde flere tool calls sammen uden at fare vild

Hvis du bygger noget med høj grad af integration, er robust tool use ofte vigtigere end raw tekstkvalitet.

Hvad koster de forskellige modelvalg i praksis?

Den reelle pris på en AI-model er ikke kun tokenprisen. Den afhænger også af outputmængde, retries, caching, drift, logging, hosting og hvor meget manuelt arbejde løsningen stadig kræver. En billig model på papiret kan ende med at blive dyrest i praksis.

De vigtigste prisbestanddele

Typisk består omkostningerne af:

• Inputtokens: pris pr. 1.000 eller 1 mio. tokens, du sender ind
• Outputtokens: pris pr. svar, modellen genererer
• Caching: rabatteret pris, hvis du genbruger samme kontekst ofte
• Retries: ekstra kald, når noget fejler eller kvaliteten er for lav
• Drift og observability: logging, metrics, dashboards, alarmer
• Hosting: hvis du selv hoster (GPU’er, storage, netværk)
• Vedligehold: tid til opsætning, opdatering, prompts, evals osv.

Tokenpriser ændrer sig løbende, så du skal altid tjekke aktuelle prisark for den leverandør, du overvejer.

En simpel TCO-formel

Du kan tænke totalomkostningen (TCO) pr. måned som:

TCO ≈ (tokenforbrug * tokenpris) + drift & observability + hosting (hvis lokal) + vedligehold

Hvor:

• tokenforbrug afhænger af antal kald, gennemsnitlig promptlængde og outputlængde
• drift & observability typisk er tid til logs, alarmer, fejlretning og mindre forbedringer
• hosting kan variere fra næsten ingenting (lille cloud-model) til markant beløb (egen GPU-cluster)

Vejledende regneeksempel

Forestil dig et internt dev-tool, der laver kodeforslag:

• 50.000 kald pr. måned
• Gennemsnit: 500 inputtokens og 300 outputtokens pr. kald (800 tokens i alt)
• Samlet tokenforbrug: 50.000 * 800 = 40.000.000 tokens pr. måned

Hvis vi antager en vejledende pris på fx 1,5 USD pr. million tokens (kun eksempel):

• Tokenomkostning ≈ 40 * 1,5 USD = 60 USD pr. måned
• Hertil kommer tid til opsætning, logging og vedligehold

Pointen er, at selv med meget brug kan API-omkostningen være lav i forhold til udviklertid, især hvis du bruger en rimelig billig model. For store eller skræddersyede løsninger kan projekter dog hurtigt lande i et niveau på måneder og titusindvis af USD, afhængigt af kompleksitet og krav.

Hvornår bliver den billige model dyr?

En billig model kan blive dyr, hvis:

• Du skal lave mange retries for at få acceptabel kvalitet
• Der går meget udviklertid på at rydde op i output
• Den fejler oftere, så du skal lave kompliceret fallback-logik

I praksis bør du måle:

• Succesrate pr. første kald: hvor ofte er svaret “good enough” uden post-processing?
• Manuel efterbearbejdning: hvor mange minutter bruger du pr. 100 kald?
• Stabilitet over tid: ændrer kvaliteten sig, når modellen opdateres?

Det er her en dybere tilgang til logging og observability hjælper. Hvis du vil se, hvordan god logging slår mavefornemmelse hver gang, er der en længere snak i guiden om observability.

Hvornår skal du vælge lokal model, open-weight eller hosted API?

Vælg lokal eller open-weight model, når kontrol, databeskyttelse eller leverandørafhængighed vejer tungere end bekvemmelighed. Vælg hosted API, når du vil have hurtig implementering, lav drift og lettere adgang til opdaterede modeller. Deploymentformen er en central del af modelvalget, ikke et eftertanke-punkt.

Hosted API

Hosted API er den klassiske “cloud-model”: du sender requests til en ekstern tjeneste, og får svar tilbage.

Fordele:

• Meget hurtig at komme i gang med
• Ingen drift af GPU’er og modelservere
• Automatiske opdateringer og adgang til nyeste modelgenerationer

Ulemper:

• Afhængighed af leverandøren (lock-in, prisændringer, rate limiting)
• Data forlader din infrastruktur (kræver klar DPA og vurdering af dataresidens)
• Mindst kontrol over versioner og ændringer

Hosted API passer godt til: prototyper, interne værktøjer uden meget følsomme data og produkter, hvor time-to-market er vigtigere end maksimal kontrol.

Open-weight med ekstern hosting

Open-weight med ekstern hosting betyder, at du bruger open source-vægte, men lader en tredjepart stå for selve drift og GPU’er.

Fordele:

• Mindre vendor lock-in: du kan i princippet flytte modellen
• Mere kontrol over, hvilken version du kører
• Bedre muligheder for tilpasning end rene black-box API’er

Ulemper:

• Du får stadig en leverandør, du skal kunne stole på
• Driften er mere kompleks end ren hosted API
• Du skal selv holde styr på modelopdateringer og kompatibilitet

Lokal/self-hosted model

Lokal eller self-hosted betyder, at du kører modellen på eget hardware (on-prem eller i din egen cloudkonto).

Fordele:

• Maksimal kontrol over data og drift
• Lettere at dokumentere dataresidens og IP-kontrol
• Mulighed for tæt integration og specialtilpasning

Ulemper:

• Du står selv for hele driften (GPU’er, scaling, sikkerhed)
• Kræver interne kompetencer og tid
• Upfront-omkostninger kan være væsentligt højere

En lokal model er især relevant, når:

• Du arbejder med meget følsomme data (sundhed, finans, personale)
• Du har hårde krav til dataresidens i bestemte regioner
• Du skal kunne forklare myndigheder og kunder helt præcist, hvor og hvordan data behandles

Her hænger valget tæt sammen med din generelle tilgang til hosting og drift. Hvis du i forvejen kæmper med hosting-beslutninger, er det værd at overveje, om du vil bygge endnu et tungt driftssystem ovenpå, eller hellere vil bruge en ekstern model-API. Overvejelserne ligner meget dem, der er beskrevet i fx guiden om hostingvalg og artiklen om databasehosting og nattesøvn.

Et enkelt beslutningstræ

• Er dine data stærkt følsomme eller regulerede?
  Ja: overvej lokal eller kontrolleret open-weight.
  Nej: gå videre.
• Har du team og tid til drift af modeller?
  Ja: open-weight eller lokal kan give mening.
  Nej: hosted API er sandsynligvis bedre.
• Er du meget bekymret for leverandørafhængighed?
  Ja: kig på open-weight modeller, som kan flyttes.
  Nej: hosted API giver typisk laveste friktion.

Hvordan tester du modeller på dine egne data og prompts?

Den bedste model er sjældent den, der ser bedst ud på papiret. Den model, der vinder, er den der stabilt klarer dine egne prompts, dine egne data og dine egne krav til format, hastighed og pris. Derfor bør du altid teste 2-3 modeller systematisk, før du binder dig.

1. Vælg en lille, repræsentativ prompt-suite

Start med 5-10 realistiske prompts eller opgaver, som faktisk ligner hverdagen:

• 3-5 nemme cases, som modellen skal kunne løse fejlfrit
• 3-5 sværere cases, hvor reasoning og robusthed bliver tydelig

Eksempler:

• Til kode: en simpel refaktorering, en bug-fix med stack trace, generering af 3 unit tests, opsummering af en kompleks funktion, forslag til forbedring af performance.
• Til dokumentanalyse: et kort dokument med simple spørgsmål, et langt dokument med tvetydige formuleringer, en pdf med tabeller, et eksempel med forvekslingsrisiko.

Hvis du vil have hjælp til at formulere gode prompts, kan du hente ideer i guiden om prompts til kodning og debugging.

2. Definér succeskriterier

For hver prompt skal du definere på forhånd, hvornår noget tæller som “bestået”. Eksempler:

• Kodeopgaver: koden kompilere, tests passerer, diff er lille og forståelig
• Dokumentspørgsmål: korrekt svar, korrekt kildehenvisning, ingen påfund
• Struktureret output: gyldig JSON i første forsøg, følger aftalt schema

Du kan score hvert svar på en 1-5 skala, fx:

• 1 = ubrugeligt
• 3 = kræver moderat retning
• 5 = kan næsten bruges direkte

3. Kør testen på mindst to modeller

Vælg minimum to, gerne tre kandidater, som du vil teste op imod hinanden:

• En hurtig/billig model
• En mellemklasse-model
• En dyrere reasoning/pro-model

Kør alle prompts mod alle modeller med samme systemprompt og konfiguration (temperature, max tokens osv.), så sammenligningen er fair.

4. Lav et simpelt scorecard

Du kan fx sætte det op i et regneark eller en lille intern webside:

Efter testen kan du beregne:

• Gennemsnitlig kvalitetsscore pr. model
• Andel “beståede” cases
• Gennemsnitlig latency pr. model
• Gennemsnitligt tokenforbrug pr. case

5. Beslutningskriterier

Brug nogle enkle go/no-go-regler:

• Vælg kun modeller, der når mindst en gennemsnitlig kvalitetsscore, du er tryg ved (fx 4,0+).
• Hvis to modeller har næsten samme kvalitet, så vælg den med lavere pris og bedre latency.
• Hvis en billig model kræver markant mere manuel efterbearbejdning, så indregn den tid i TCO’en.

Hvis du vil gå et skridt videre, kan du senere automatisk køre denne eval-suite som en del af din CI/CD, når du skifter model eller ændrer prompts, så du opdager kvalitetstab tidligt.

6. Test på “worst case”-data

Det er fristende kun at teste på rene og pæne eksempler. Lav mindst én runde med:

• Rodede prompts (reelle eksempler fra kolleger eller brugere)
• Delvist ufuldstændige data
• Spørgsmål, hvor det rigtige svar er “ved ikke”

Det er her, du ser, om modellen hallucinerer aggressivt, misforstår domænet eller begynder at fabulere. De problemer gør i praksis mere skade end en ellers lidt lavere score på nemme cases.

Hvad betyder GDPR, EU AI Act og IP for modelvalget?

Hvis du arbejder med personoplysninger, fortrolige data eller regulerede workflows, bør compliance være et valgfilter fra starten. Det peger ofte mod mere kontrolleret deployment, tydelig databehandleraftale og strengere intern governance. Compliance kommer ikke sidst i projektet, men er med til at afgøre, hvilken type løsning du overhovedet må bygge.

GDPR: persondata og databehandleraftaler

Nogle nøglespørgsmål, du bør kunne svare på:

• Sender du personoplysninger til en ekstern model-API? I givet fald hvilke typer (navn, mail, helbred, økonomi)?
• Har du en databehandleraftale (DPA) med leverandøren, der dækker brugen?
• Hvor behandles data fysisk (dataresidens)? Er der tredjelandsoverførsel uden for EU/EØS?
• Er data minimeret, så du kun sender det nødvendige?

Et markedsføringsløfte om “vi træner ikke på dine data” er ikke det samme som fuld GDPR-compliance. Du skal stadig kunne dokumentere lovligt behandlingsgrundlag, formål, sletning, dataminimering og eventuelle tredjelandsoverførsler.

EU AI Act: risikobaseret tilgang

EU AI Act arbejder med risikoniveauer for AI-systemer. Det betyder i praksis:

• Ikke alle AI-brug er “high-risk”, men du skal kunne forklare, hvad din løsning bruges til.
• Jo tættere din løsning er på at påvirke borgeres rettigheder, sundhed eller økonomi, desto højere krav til dokumentation, test og tilsyn.
• Modelvalg, logging, versionering og menneskeligt tilsyn bliver vigtige byggesten i dokumentationen.

Lovgivningen udvikler sig stadig, og for mange projekter giver det mening at involvere juridisk eller compliance-faglig rådgivning, især i større organisationer.

IP og rettigheder

Der er også et IP-lag i modelvalg:

• Hvordan håndterer leverandøren rettigheder til genererede outputs?
• Bruger du kunders eller partneres beskyttede materiale som input?
• Hvordan vil du håndtere eventuelle tvivlsspørgsmål om ophavsret i outputs?

Her er der sjældent simple ja/nej-svar. Men valget mellem hosted, open-weight og lokal model kan gøre det lettere eller sværere at dokumentere, hvad der sker med data, og hvem der har adgang.

For en bredere introduktion til governance og sikkerhed i udviklingsteams kan du kigge på artiklen om IT- og cybersikkerhed og governance i praksis.

Hvilken governance skal være på plads før du vælger model?

Selv det bedste modelvalg bliver skrøbeligt uden klart ejerskab, dokumentation og løbende opfølgning. Før du vælger model, skal du vide hvem der ejer beslutningen, hvem der godkender data, og hvem der følger kvalitet og drift. Ellers ender AI’en hurtigt som et uoverskueligt sort hul i arkitekturen.

Mini-governance-checkliste

Inden du trykker “go” på en model i produktion, bør du som minimum have styr på:

• Ejerskab: Hvem er produkt-/systemejer? Hvem kan sige “vi stopper” hvis noget går galt?
• Dataansvar: Hvem godkender, hvilke data der må sendes til modellen?
• Modelregister: Et simpelt dokument, der beskriver modelnavn, version, formål, use cases, inputtyper, outputtyper, og hvornår den sidst er evalueret.
• Eval-protokol: Din testmetode og scorecard, så du kan gentage evalueringen ved modelskift.
• Observability: Logging af kald (med passende anonymisering), fejl, latency og eventuelle kritiske hændelser.
• Fallback: Hvad sker der, hvis modellen fejler, timeouter eller pludselig leverer noget, der ikke kan bruges?

Det behøver ikke være tungt og byråkratisk, men der skal være nok struktur til, at andre end dig selv kan forstå, hvad systemet laver tre måneder senere.

Sikker integration og secrets

Når du arbejder med eksterne model-API’er, er håndteringen af API-nøgler og andre secrets en vigtig del af governance. Du bør ikke:

• Hardcode API-nøgler i repoet
• Dele nøgler i screenshots eller chattråde
• Blæse miljøvariabler ud til frontend uden omtanke

Hvis du vil have en praktisk gennemgang af, hvordan du undgår de klassiske fejl, er der nogle korte, konkrete råd i artiklerne om håndtering af tokens i webapps og 7 små regler for secrets.

Opsummering: en enkel proces til modelvalg

Hvis vi samler det hele til en lille tjekliste, ser en fornuftig proces sådan ud:

1. Definér use case: opgavetype, datafølsomhed, volumen, latency-krav.
2. Vælg kandidat-typer: standard vs. reasoning vs. multimodal, mini vs. pro, hosted vs. open-weight vs. lokal.
3. Byg en lille eval-suite: 5-10 realistiske prompts med klare succeskriterier.
4. Test 2-3 modeller: mål kvalitet, format, latency, tokenforbrug.
5. Regn på TCO: indregn ikke bare tokenpris, men også retries, drift og vedligehold.
6. Filtrér for compliance: GDPR, EU AI Act, dataresidens og IP.
7. Beslut og dokumentér: modelvalg, version, formål, eval-resultater og governance-setup.

Når først du har kørt processen én gang, er det relativt let at gentage den for nye use cases eller modelopdateringer. Den største forskel i praksis er ofte ikke, hvilken model du vælger, men om du vælger den bevidst og kan forklare hvorfor.