Kontrakter til AI: Modelklausuler, evals og leverandørstyring (uden at drukne i jura)

Skrevet af Kåre Bjørn Jensen assisteret af AI

AI-indkøb ligner softwareindkøb – lige indtil det ikke gør. Du køber ofte en sandsynlighedsmaskine, der ændrer sig over tid (model-opdateringer), og som kan være svær at “accept-teste” binært. Derfor bliver kontrakten ikke bare et bilag, men selve styringen af risiko, drift og ansvar [3].

1) Hvorfor AI-kontrakter er “anderledes”

I klassiske IT-kontrakter kan man ofte teste funktioner som ja/nej. Med generativ AI handler kvalitet om præcision, fejltyper, bias og kontekst – og om hvem der har ansvaret, når output rammer ved siden af. Det internationale advokatfirma Bird & Bird peger bl.a. på behovet for at aftale, hvornår en løsning anses som “god nok”, og hvordan man tester en probabilistisk model i praksis [3].

2) EU’s modelklausuler: god start – men ikke hele kontrakten

EU’s modelklausuler (MCC-AI) er lavet som et AI-specifikt bilag, især til højrisiko-systemer, og har også en “light” version til ikke-højrisiko. De adresserer typisk ting som risikostyring, data governance, human oversight, cybersikkerhed og transparens – mens “light” kan skære hårdere greb som audit-rettigheder og conformity-krav ned [2]. Samtidig understreges det, at klausulerne primært hjælper med AI-Act-compliance og ikke automatisk løser IP, ansvar, betalingsvilkår osv. [3]

3) Nye compliance-krav rammer indkøb direkte (også uden for EU)

Fra 2. august 2025 skal udbydere af general-purpose AI-modeller i EU bl.a. leve op til transparens- og copyright-forpligtelser, og de mest avancerede/systemisk risikable modeller får ekstra krav om sikkerhed og governance [1].

I USA viser OMB’s nye indkøbsramme for føderale myndigheder samme retning: kontrakter for LLM-indkøb skal bl.a. kræve acceptable use policy, model/system/data cards og mekanismer til at rapportere problematiske outputs – og myndigheder skal opdatere procurement-politikker senest 11. marts 2026 [8].

4) “Must-have” klausuler (kort og praktisk)

Hvis du kun tager 10 ting med i udbud/kontrakt, så gør det disse:

1. Roller & ansvar (kunde, leverandør, underleverandører; hvem er “provider/deployer” i AI-Act-forstand).
2. Databehandling (GDPR-roller, databehandleraftale, underdatabehandlere, logging).
3. Model-ændringsstyring (release notes, version-pinning, re-test ved “material changes”) [4].
4. Eval-krav før go-live (testdesign, datasæt, fejltyper, acceptkriterier) [3].
5. Løbende evals + red-teaming (periodisk, dokumenteret; hvad udløser ekstra test) [4].
6. Incident-rapportering (hvad er en “serious incident”, tidsfrister, kontaktvej) [4].
7. Audit-spor (logs, prompt/response-spor hvor lovligt, beslutningsgrundlag, revisionsadgang).
8. Sikkerhed (adgangsstyring, kryptering, isolation, supply-chain krav).
9. IP & output-rettigheder (hvad må gemmes/genbruges; træning på kundedata; licenser).
10. Exit & portabilitet (export, sletning, skift af leverandør, “no hostage data”).

5) Offentlig sektor i DK: brug sandkasse-læringen og de nye vejledninger

I Danmark har Digitaliseringsstyrelsen udsendt en vejledningspakke om forbudte AI-praksisser (AI-Act artikel 5), som er relevant at “screene” imod allerede i behovsafklaringen – før udbuddet låses [6]. Samtidig viser de første sandkasse-slutrapporter (bl.a. kommunale og forsikringscases), at det ofte er test på rigtige data, DPIA’er(konsekvensanalyser af databeskyttelse), og rollefordeling (dataansvarlig/databehandler) der afgør, om projektet kan gå fra pilot til drift [7].

6) Klassiske faldgruber (og hvordan du undgår dem)

• “Overimplementering”: man kopierer lovkrav ukritisk og ender med urealistiske forpligtelser [3].
• Ingen change control: modellen ændrer sig, men kontrakten gør ikke [4].
• Ingen eval-beviser: leverandøren lover – men dokumenterer ikke (cards, tests, logs) [8].
• Manglende exit: data og workflows kan ikke flyttes uden høj friktion.

Huske-sætning til indkøb: Køb ikke kun funktioner – køb dokumentation, testdisciplin og en exit-rampe.

Kilder

[1] EU-Kommissionen, “EU rules on general-purpose AI models start to apply…” (2. august 2025). (digital-strategy.ec.europa.eu)

[2] Cliffe Dekker Hofmeyr, “An overview of the European Union’s Model Contractual Clauses for Artificial Intelligence” (3. september 2025). (cliffedekkerhofmeyr.com)

[3] Bird & Bird, “AI, lovtekster og kontraktklausuler – en ny (uhellig) alliance” (2025). (twobirds.com)

[4] Responsible AI Platform (AIActblog), “Procurement under the EU AI Act: model clauses to embed the GPAI code in contracts” (2025). (Responsible AI Platform)

[5] OECD, pressemeddelelse om “Governing with Artificial Intelligence” (18. september 2025). (OECD)

[6] Digitaliseringsstyrelsen, “Nye vejledninger om forbudt brug af AI” (20. oktober 2025). (digst.dk)

[7] Jura360, “Slutrapporter fra første runde af den regulatoriske sandkasse om AI” (22. oktober 2025). (Jura360)

[8] U.S. OMB, Memorandum M-26-04, “Increasing Public Trust in Artificial Intelligence Through Unbiased AI Principles” (11. december 2025). (whitehouse.gov)

AI-Basics, del 9

Data, træning og ophavsret: Hvad betyder sagerne for din virksomhed?

Skrevet af Kåre Bjørn Jensen assisteret af AI

I 2025-26 er ophavsret i Generativ AI rykket fra “juridisk niche” til noget, der påvirker indkøb, datapraksis og medarbejderpolitik. To spor går igen i næsten alle diskussioner: (1) træningsdata (må en model trænes på beskyttet materiale?) og (2) output + bevisførelse (hvornår bliver output for tæt på kilden – og hvad skal gemmes i en retssag?).

1) USA: Når “output-lighed” og chatlogs bliver et forretningsvilkår

Et klart signal kom i den sammenlagte OpenAI-ophavsretssag (flere relaterede sager behandlet samlet), hvor en føderal dommer i oktober 2025 afviste OpenAIs forsøg på at få output-baserede ophavsretskrav smidt ud. Dommeren lagde vægt på, at påstanden om “substantial similarity” (at output kan ligge tæt på værkernes beskyttede elementer) var tilstrækkeligt plausibel til at gå videre [1].

Samtidig viser retssagen mellem New York Times og OpenAI en anden praktisk risiko: logs og samtaler kan blive omdrejningspunkt. I november 2025 beskrev Ars Technica konflikten om et krav om at udlevere 20 millioner (af-identificerede) ChatGPT-samtaler som led i discovery, hvor OpenAI argumenterede for, at kravet var for bredt og problematisk for privatliv [2].

Og i oktober 2025 blev en central bevaringsforpligtelse (“preservation order”) formelt afviklet/ændret gennem en aftale mellem parterne, som blev indgivet til og godkendt af retten – et konkret eksempel på, at datalagring kan ændre sig hurtigt, afhængigt af sagens proces [3].

Praktisk pointe til virksomheder: spørg altid til dataopbevaring (hvad gemmes, hvor længe?), retslige bevaringspåbud i forbindelse med retssager (“litigation holds”), og om I kan få enterprise/zero-retention på følsomme flows – for i værste fald kan “slet” i brugergrænsefladen (UI) være noget andet end “slet” i juraens verden [2][3].

2) EU: fra “opt-out” i teorien til maskinlæsbare standarder i praksis

Fra 2. august 2025 begyndte EU’s AI Act-regler for general-purpose AI (GPAI) at gælde, inkl. copyright-forpligtelser og transparenskrav for udbydere, når modeller bringes på EU-markedet [4].

Og i december 2025 tog Kommissionen næste skridt: en officiel konsultation om protokoller for at “reservere rettigheder” mod text-and-data-mining – dvs. hvordan rettighedshavere kan udtrykke et opt-out på en måde, som AI-udbydere faktisk kan opdage og efterleve i deres data- og træningspipelines [5].

Praktisk pointe til danske organisationer: EU-linjen bevæger sig mod, at “opt-out” skal være mere standardiseret og machine-readable, så man kan handle på det i indkøb, governance og leverandørkrav – ikke kun i juridiske noter [5].

3) UK: intensiv politisk kamp om TDM og “opt-out”

I UK er retningen stadig politisk omstridt, men 2025-26 har budt på flere formelle milepæle: Regeringen har publiceret en “statement of progress” om copyright og AI (med forpligtelser til kommende rapporter og impact-vurderinger) [6], og spørgsmålet er blevet løftet i en officiel parlamentarisk erklæring (15. december 2025) [7].

Samtidig peger britiske mediedækninger på massiv modstand mod en model, hvor træning på ophavsretligt materiale er “default”, og skabere selv skal opt-out [8].

4) Tjekliste: sådan gør du risikoen håndterbar (uden at stoppe innovation)

1. Klassificér brugen: intern assistance vs. kundevendt output vs. “genbrug i produkter”.
2. Indkøbskrav: Aftal på forhånd, hvad der bliver gemt (og hvor længe), hvordan I får data slettet igen, hvilke spor der logges til dokumentation, og om jeres data kan ende med at blive brugt til at forbedre leverandørens AI.
3. Output-policy: hvornår må AI-tekst publiceres, og hvornår kræves kildetjek/omskrivning? (især ved resuméer).
4. Logs som aktiv/risiko: definer, hvad I logger, og hvorfor – og hvem der kan tilgå det ved tvister [2][3].
5. Hold øje med EU-standardisering for opt-out/protokoller og opdater kontraktbilag løbende [5].

Kilder

[1] U.S. District Court (S.D.N.Y.), Opinion & Order (27. okt 2025) – afviser OpenAIs motion to dismiss ift. output-baserede ophavsretskrav. (Courthouse News)

[2] Ars Technica, “OpenAI fights order to hand over 20 million private ChatGPT conversations” (12. nov 2025). (arstechnica.com)

[3] U.S. District Court (S.D.N.Y.), Stipulation and Order to Terminate… Preservation Order (9. okt 2025). (cdn.arstechnica.net)

[4] EU-Kommissionen, “EU rules on general-purpose AI models start to apply…” (2. aug 2025). (digital-strategy.ec.europa.eu)

[5] EU-Kommissionen, “Consultation on protocols for reserving rights from text and data mining…” (1. dec 2025; lukker 23. jan 2026). (digital-strategy.ec.europa.eu)

[6] UK Government (GOV.UK), “Copyright and AI: statement of progress…” (publiceret 2026). (GOV.UK)

[7] UK Parliament, Written Statement HCWS1165 “Copyright and Artificial Intelligence” (15. dec 2025). (questions-statements.parliament.uk)

[8] The Guardian, “Boost for artists… as only 3% back UK active opt-out plan” (16. dec 2025). (The Guardian)

AI-Basics, del 10

Generativ AI i myndigheder: Hvad virker – og hvad skal væk?

Skrevet af Kåre Bjørn Jensen assisteret af AI

Generativ AI er allerede rykket ind i mange offentlige organisationer, ofte via velkendte værktøjer som Microsoft Copilot og ChatGPT. Potentialet er stort, men konsekvensen af fejl er også større end i mange private sammenhænge: borgernes retssikkerhed, tillid til myndigheden og håndtering af følsomme data. Derfor er den nyttige tommelfingerregel ikke “kan vi?”, men kan vi – må vi – bør vi? [2].

Hvad der typisk giver værdi (når det gøres rigtigt)

Der er tre mønstre, der går igen, når Generativ AI skaber værdi uden at skabe uro:

1) Tekstarbejde med menneske som redaktør

Udkast, omskrivning, opsummering og oversættelse, hvor en fagperson altid gennemgår, retter og godkender før noget sendes ud [2].

2) “Kontrolleret AI” på egne kilder (spørg jeres dokumenter – med kilder)

Når AI’en primært svarer ud fra jeres egne, godkendte dokumenter, og det tydeligt fremgår, hvad svaret bygger på, så AI’en ikke finder på paragraffer eller “opfundne” kilder.

3) Møde- og notatstøtte med klare spilleregler

Transskription og resumé kan spare tid, men kræver faste retningslinjer for, hvad der må indtastes, og hvordan output må bruges. KL fremhæver bl.a. gennemsigtighed (“vær åben om brugen”) og løbende opdatering af retningslinjer [2].

Hvad der bør ud af drift (eller aldrig ind)

To faldgruber går igen i den offentlige sektor:

A) Ukontrolleret brug af åbne tjenester med følsomt indhold

KL er meget direkte: personoplysninger må ikke deles i offentligt tilgængelige AI-løsninger, medmindre værktøjet er vurderet og godkendt til den type behandling [2].

B) Brug der er i konflikt med AI-forordningens forbud

Digitaliseringsstyrelsen har (20/10-2025) udgivet en pakke med seks vejledninger om forbudt brug af AI – bl.a. skadelig manipulation/vildledning, udnyttelse af sårbarheder, social bedømmelse, ikke-målrettet indsamling af ansigtsbilleder til databaser og følelsesgenkendelse på arbejdspladser/uddannelsesinstitutioner [1].

Sandkassen: hvad kan man teste i praksis?

Et konkret dansk holdepunkt er den regulatoriske AI-sandkasse. Datatilsynet/Digitaliseringsstyrelsen offentliggjorde (22/10-2025) slutrapporter fra to projekter: Trygs “Dokumentassistent” og kommunernes / Systematics “Talt” (støtte til dokumentation i omsorgsjournal) [3]. Læringen kredser om retligt grundlag, test på rigtige data, udvælgelse af cases, risikovurdering og rolle-/ansvarsfordeling i samarbejder [3].

Governance og måltal, der faktisk hjælper

En praktisk minimumsmodel i myndigheder:

• Systemejer (faglig værdi samt beslutning om, hvad løsningen omfatter – og ikke omfatter)
• Jura/DPO (GDPR, hjemmel, logning, leverandørvilkår)
• IT-sikkerhed (adgang, datatab, integrationer)
• Faglig reviewer (kvalitet, bias, fejlretning)
• Drift/controlling (KPI’er + auditspor)

KPI’er der ofte virker: andel output med menneskelig godkendelse, fejltype-frekvens (fx at AI’en henviser til en forkert regel eller bestemmelse), tid sparet pr. proces, samt antal “stop-hændelser” (hvor brugeren afbryder pga. usikkerhed).

Case-skabelon (kan copy-pastes til kommunen / styrelsen)

1. Formål + afgrænsning (hvad må AI aldrig gøre?)
2. Datatyper (persondata? fortrolige oplysninger?)
3. Værktøj (åben/lukket, hvor data behandles, og hvilke opbevaringsperioder der gælder for data og logfiler)
4. Brugspolitik (input-regler + krav til transparens) [2]
5. Testdesign (repræsentative cases, acceptkriterier, “red flags”)
6. Drift (logning, reviewflow, incident-proces)
7. Revision (kvartalsvis: hvad virker, hvad skal strammes?)

Kilder

[1] Digitaliseringsstyrelsen-Nye vejledninger om forbudt brug af AI (20.10.2025). (digst.dk)

[2] KL-Guide om brug af generativ AI til kommunerne, Version 2.0 (December 2025). (KL)

[3] Datatilsynet-Slutrapporter fra første runde af den regulatoriske sandkasse om AI (22.10.2025). (Datatilsynet)

[4] Dataetisk Råd-Myndighederne har ikke taget stilling til centrale spørgsmål om kunstig intelligens (udgivelse hos Dataetisk Råd, 2026).

AI-Basics, del 11

Fra pilot til effekt: Sådan måler du generativ AI uden at snyde dig selv

Skrevet af Kåre Bjørn Jensen assisteret af AI

Mange organisationer har efterhånden gennemført en række pilotprojekter med generativ AI. Udfordringen er, at mange projekter bliver hængende dér: De virker “sådan nogenlunde”, men det er uklart, om de skaber varig værdi, og hvad der skal til for at skalere sikkert. OECD peger netop på, at mange AI-initiativer i den offentlige sektor forbliver i pilotfasen, fordi governance, kompetencer og skalering halter efter teknologien [1].

Den praktiske nøgle i 2026 er at gøre generativ AI til et almindeligt produktionssystem: med KPI’er, tests, driftsovervågning – og en tydelig business case.

1) Start med at adskille tre slags “værdi”

Det lyder banalt, men det er her, mange målinger går galt:

A) Adoption (brug): Hvor meget bruges løsningen – og af hvem?

B) Effekt (adfærd): Ændrer den arbejdsmønstre (møder, mail, dokumentproduktion)?

C) Business value (resultat): Bliver der faktisk sparet tid/penge eller løftet kvalitet?

Microsofts Copilot Control System lægger præcis denne opdeling til grund: readiness/adoption, productivity impact og business value/ROI – og understreger, at du bør koble brugsdata med egne organisationsmålinger (fx fra SAP, Workday eller Salesforce), hvis du vil tæt på reel effekt [2].

2) Mål på opgaven – ikke på “gode svar”

Generativ AI er ikke traditionel software: kvalitet handler ikke kun om korrekthed, men også om relevans, sikkerhed, bias og omkostning – og det kan ændre sig, når løsningen er sat i drift. Microsoft beskriver derfor “continuous evaluation” som nødvendigt for at opdage kvalitetsdrift, hallucinationer og utilsigtet bias over tid [3].

Et godt minimumssæt af KPI’er for en AI-løsning i drift kan fx være:

• Opgavesucces: Bliver opgaven løst – uden eller med menneskelig hjælp?
• Overdragelsesgrad: Hvor ofte må et menneske tage over undervejs?
• Faktatroværdighed/kildeforankring (hvis løsningen bruger dokumenter som grundlag): Kan svaret spores tilbage til konkrete kilder, og holder det sig til dem?
• Regel- og sikkerhedsoverholdelse: Overtrædes interne retningslinjer, lovkrav eller sikkerhedspolitikker?
• Omkostning og svartid: Hvad koster en løst opgave, og hvor lang tid tager den i “værste fald”/spidsbelastning (fx 95%-niveauet)?

En nyere litteraturgennemgang gennemgår 28 forskellige målepunkter og kobler dem til kvalitetskravene i ISO/IEC 25023. Formålet er at gøre det lettere for praktikere at vælge netop de mål, der passer til det, systemet skal kunne i praksis [4]. Google anbefaler en beslægtet, test-drevet tilgang: Man fastlægger på forhånd vurderingskriterier og målepunkter og afprøver dem på et evalueringssæt, så kvalitet vurderes mere systematisk – og mindre ud fra mavefornemmelser [5].

3) Brug ét “realitets-check”: Mennesker overvurderer ofte gevinsten

Hvis du vil have én påmindelse om, hvorfor målinger skal være objektive: METR’s RCT på erfarne open-source udviklere fandt, at deltagerne troede, AI sparede tid – men i praksis brugte de 19% længere tid, bl.a. pga. review af AI-output og ventetid på generering af indhold [6]. Det betyder ikke “AI virker ikke” – men at ROI afhænger af opgavetype, workflow og disciplin.

4) Tjekliste: “før du skalerer”

1. Har I et eval-datasæt med 20-50 realistiske cases pr. use case? [3][5]
2. Har I defineret stop-kriterier (hvilke fejl er uacceptable)?
3. Kan I forklare effekten i kroner/timer/kvalitet – ikke kun i “oplevelse”? [2]
4. Har I overvågning: fejltyper, cost per task, latency, policy breaches? [3]
5. Er der en klar ejer, der kan ændre proces og træning – ikke kun “AI-teamet”? [1]

5) Case-skabelon (klar til at kopiere)

Use case: (fx “udkast til afgørelsesbrev”)

Brugere: (hvem, hvor ofte)

Opgavemål: (task success + kvalitetskrav)

Eval-datasæt: (cases + rubrics)

Human-in-the-loop: (hvornår kræves godkendelse)

Drift: (monitorering, incident-proces, kvartalsvis re-eval)

Business case: (tid/penge/kvalitet + baseline før/efter)

Kilder

[1] OECD – “OECD encourages responsible use of AI by governments…” (18. sep 2025). https://www.oecd.org/en/about/news/press-releases/2025/09/oecd-encourages-responsible-use-of-ai-by-governments-to-strengthen-efficiency-effectiveness-and-trust.html

[2] Microsoft Learn – “Copilot Control System measurement and reporting” (senest opdateret 13. okt 2025). https://learn.microsoft.com/en-us/copilot/microsoft-365/copilot-control-system/measurement-reporting

[3] Microsoft TechCommunity – “Continuous Evaluation Framework” (8. jan 2026). https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/evaluating-generative-ai-models-using-microsoft-foundry%E2%80%99s-continuous-evaluation-/4468075

[4] ScienceDirect – “Measuring the quality of generative AI systems…” (2025). https://www.sciencedirect.com/science/article/pii/S0950584925001417

[5] Google Cloud Docs – “Define your evaluation metrics (Vertex AI GenAI eval)” (opdateret 2026). https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/determine-eval

[6] arXiv – “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (indsendt 12. jul 2025; revideret 25. jul 2025). https://arxiv.org/abs/2507.09089

AI-Basics, del 12

RÅ TEKST – SKAL TILRETTES FØR PUBLICERING

RAG 2.0: Sådan bygger du en videnassistent, der kan angive kilder – og tåle virkeligheden

Skrevet af Kåre Bjørn Jensen assisteret af AI

Mange har allerede prøvet “chat med vores dokumenter”. Det virker… lige indtil det ikke gør. Typisk fejler løsningen ikke på “AI-magi”, men på hverdagskaos: dubletter, gamle versioner, uklare ejerskaber og dokumenter, der ligner hinanden så meget, at systemet vælger tilfældigt. Det kaldes ofte version drift: informationen er teknisk korrekt, men organisatorisk forkert – og derfor farlig i praksis. [1]

RAG (Retrieval-Augmented Generation) er stadig et af de mest robuste mønstre til at gøre Generativ AI mere kildetro. Men i 2025-26 er der en tydelig modenhedsbølge: RAG 2.0 handler mindre om “en vector database” og mere om datahygiejne + metadata + evaluering i drift.

1) RAG er en søgemaskine før det er en chatbot

Hvis du vil have kildetro svar, skal du først gøre det muligt at finde de rigtige kilder. Microsofts arkitekturguides fremhæver, at det ikke bare er en teknisk detalje, hvordan du deler dokumenterne op i mindre, søgbare tekststykker (fx afsnit eller procedureregler). Det valg er afgørende for både kvalitet, omkostning og relevans: Hvis tekststykkerne er for store, bliver søgningen dyr og upræcis; hvis de er for små, risikerer du at miste vigtig sammenhæng. [2]

En pragmatisk tommelfingerregel i 2026: Chunking (opdeling i tekststykker) er et produktvalg. Du vælger en “enhed” af viden, der giver mening i dit domæne (afsnit, proceduretrin, tabel-sektioner, mødeafsnit osv.) – og du tester dig frem. [2]

2) RAG 2.0 starter med berigelse: metadata, der kan sortere støjen fra

Når dokumenter ligner hinanden, er semantik alene ikke nok. Derfor anbefaler Microsoft at berige chunks med felter som titel, summary, keywords, tags, entities – og vigtigst: source, så du kan citere og spore tilbage til originalen. [3]

Det matcher nyere forskning: metadata kan reducere “forveksling” mellem næsten ens dokumenter, og strategier som metadata-prefixing eller samlede metadata-embeddings kan forbedre retrieval i strukturerede, repetitive dokumentsamlinger. [7]

Praktisk oversat til dansk virkelighed: du får markant bedre resultater, hvis du kan filtrere på fx “gældende”, “godkendt”, “senest opdateret”, afdeling, produktlinje, geografi, version” – i stedet for at håbe, at modellen “gætter rigtigt”. [1][3][7]

3) Hentning af kilder, der ikke smadrer budgettet

En klassisk fejl er at sende for meget kontekst med i prompten. Microsoft viser et eksempel på “context-aware chunking” og en mere intelligent hentning af relevante tekststykker (altså hvordan systemet finder og udvælger de mest relevante bidder fra jeres dokumenter, før AI’en svarer). Det kan sænke tokenforbruget markant – de nævner op til ca. 85% lavere tokenforbrug i deres eksempel – samtidig med bedre præcision. [5] Uanset om tallet rammer præcis i dit miljø, er pointen vigtig: En videnassistent i drift er også et spørgsmål om omkostninger, ikke kun kvalitet.

4) Evaluer som et produktionssystem – ikke som en demo

RAG 2.0 kræver, at du kan måle: er svaret forankret i kilderne, relevant og dækkende? Microsofts RAG-evaluators lægger netop vægt på fx groundedness (siger modellen noget udenfor konteksten?) og response completeness(mangler der væsentlige dele ift. ground truth?). [4]

Og her kommer en vigtig 2025-26-pointe: mange benchmarks tester “lokal RAG” (find et par relevante chunks). Men virkelige vidensopgaver er ofte “global RAG”: at samle, tælle, sortere og syntetisere på tværs af en hel dokumentsamling. GlobalQA-benchmarket viser, at det er svært – og derfor bør du teste den type spørgsmål, før du lover ledelsen, at “videnassistenten kan alt”. [6]

5) Tjekliste: sådan gør du det “produktionsegnet”

• Dokument-disciplin: Én sandhedskilde, færre vedhæftninger og tydelig status/gyldighed (så du minimerer “version drift”). [1]
• Metadata først: Version, godkendelse, ejer, dato, afgrænsning, tags – og et tydeligt link til kilden, så svar kan dokumenteres. [3][7]
• Opdeling som designvalg: Test 2–3 måder at dele indholdet op på, og mål både kvalitet og omkostninger. [2][5]
• Løbende måling i drift: Følg faste KPI’er for kildeforankring, dækningsgrad og relevans – ikke kun et engangstjek ved lancering. [4]
• Test på tværs: Medtag spørgsmål, der kræver, at systemet samler og sammenfatter viden fra flere dokumenter – ikke kun finder ét godt afsnit. [6]

Kilder

[1] TechRadar Pro – “What is Version Drift in AI?” (1. okt 2025). (TechRadar)

[2] Microsoft Learn (Azure Architecture Center) – “Develop a RAG Solution: Chunking Phase” (sidst opdateret 21. nov 2025). (Microsoft Learn)

[3] Microsoft Learn (Azure Architecture Center) – “Develop a RAG Solution: Chunk Enrichment Phase” (sidst opdateret 21. nov 2025). (Microsoft Learn)

[4] Microsoft Learn – “Retrieval-Augmented Generation (RAG) evaluators” (sidst opdateret 16. jan 2026). (Microsoft Learn)

[5] Microsoft TechCommunity – “Context-Aware RAG System with Azure AI Search to Cut Token Costs and Boost Accuracy” (23. okt 2025). (TECHCOMMUNITY.MICROSOFT.COM)

[6] arXiv – “Towards Global Retrieval Augmented Generation: A Benchmark for Corpus-Level Reasoning” (submitted 30. okt 2025). (arXiv)

[7] arXiv – “Utilizing Metadata for Better Retrieval-Augmented Generation” (submitted 17. jan 2026). (arXiv)

Vi laver journalistik om AI, fordi udviklingen går hurtigere end den offentlige samtale.

På AI Portalen forsøger vi at skabe overblik, perspektiv og kritisk indsigt i en teknologi, der allerede former alt fra arbejdsmarkedet til demokratiet — ofte uden at nogen bremser op og forklarer, hvad der foregår.

Hvis vores artikler hjælper dig med at forstå AI lidt bedre, så overvej at støtte arbejdet.

Et medlemskab gør én ting mulig: at vi kan blive ved med at undersøge, dokumentere og forklare, hvordan AI påvirker Danmark — uden investorer, uden PR-interesser og uden at jage hype.

Bliv medlem og vær med til at styrke uafhængig journalistik om AI.