{"id":1716,"date":"2026-06-30T08:38:54","date_gmt":"2026-06-30T06:38:54","guid":{"rendered":"https:\/\/vittrup-graversen.dk\/?p=1716"},"modified":"2026-06-30T08:38:55","modified_gmt":"2026-06-30T06:38:55","slug":"llm-kontrakter-gsa-goer-datakontrol-til-krav","status":"publish","type":"post","link":"https:\/\/vittrup-graversen.dk\/index.php\/2026\/06\/30\/llm-kontrakter-gsa-goer-datakontrol-til-krav\/","title":{"rendered":"LLM-kontrakter: GSA g\u00f8r datakontrol til krav"},"content":{"rendered":"\n

Den mest interessante LLM-nyhed det sidste d\u00f8gn er ikke en ny model med en st\u00f8rre benchmarkgraf. Det er noget langt mere kedeligt og langt mere vigtigt: den amerikanske indk\u00f8bsmyndighed GSA er ved at g\u00f8re LLM-kontrakter til et sp\u00f8rgsm\u00e5l om datakontrol, leverand\u00f8rk\u00e6de og driftsansvar.<\/p>\n\n\n\n

Holland & Knight skrev 29. juni om GSA\u2019s foresl\u00e5ede klausul for \u201cBasic Safeguarding of Data within Large Language Model Artificial Intelligence Systems\u201d. Selve forslaget blev lagt i Federal Register 17. juni, men den aktuelle gennemgang er relevant, fordi den viser, hvor hurtigt LLM-indk\u00f8b flytter sig fra \u201cm\u00e5 vi bruge ChatGPT?\u201d til \u201chvem har juridisk og teknisk ansvar for data, output, modelopdateringer og underleverand\u00f8rer?\u201d.<\/p>\n\n\n\n

Det er v\u00e6rd at holde \u00f8je med, ogs\u00e5 hvis man ikke s\u00e6lger til den amerikanske stat. Offentlige krav har det med at sive ind i enterprise-markedet. F\u00f8rst som s\u00e6rkrav i store kontrakter. Senere som sp\u00f8rgeskemaer, sikkerhedsbilag og procurement-standarder. Hvis GSA f\u00e5r LLM-kontrakter ind i en mere moden kontraktform, er det et signal om, hvordan seri\u00f8se kunder kommer til at k\u00f8be AI-systemer.<\/p>\n\n\n\n

LLM\u2019en bliver ikke l\u00e6ngere behandlet som en app<\/h2>\n\n\n\n

GSA-forslaget handler ikke bare om selve modellen. Det rammer hele systemet omkring den: udviklere, operat\u00f8rer, systemintegratorer og service providers. Det er den rigtige m\u00e5de at t\u00e6nke p\u00e5. En moderne LLM-l\u00f8sning er sj\u00e6ldent \u00e9n leverand\u00f8r og \u00e9n model. Den best\u00e5r af model-API, cloud, logging, retrieval augmented generation, vektordatabaser, promptlag, sikkerhedsfiltre, evals, brugerrettigheder og ofte et par integrationslag, som ingen rigtig ejer efter tre m\u00e5neder.<\/p>\n\n\n\n

Det er pr\u00e6cis der, problemerne opst\u00e5r. Hvis en leverand\u00f8r siger \u201cvi tr\u00e6ner ikke p\u00e5 jeres data\u201d, er det kun \u00e9t sp\u00f8rgsm\u00e5l. Hvad med menneskelig review? Hvad med embeddings? Hvad med outputdata? Hvad med logs? Hvad med en underleverand\u00f8r, der leverer RAG-infrastruktur? Hvad med en modelopdatering, der \u00e6ndrer svaradf\u00e6rd uden at \u00e6ndre API-navnet?<\/p>\n\n\n\n

GSA\u2019s udkast fors\u00f8ger at g\u00f8re de sp\u00f8rgsm\u00e5l kontraktlige. Det betyder flowdown-krav til underleverand\u00f8rer, dokumenteret due diligence, kontrol med government data og krav om notifikation ved \u00e6ndringer. Ikke sexet. Men det er den slags kedelighed, der afg\u00f8r, om LLM-kontrakter kan bruges i produktion uden at governance bliver ren \u00f8nsket\u00e6nkning.<\/p>\n\n\n\n

Dataejerskab og modelopdateringer bliver driftskrav<\/h2>\n\n\n\n

En af de vigtigste detaljer er, at government data defineres bredt. Ikke kun input, men ogs\u00e5 output og specialudvikling. Holland & Knight peger p\u00e5, at den nye version samtidig indf\u00f8rer beskyttelse af leverand\u00f8rens eksisterende IP, baggrundsdata, kildekode, modelv\u00e6gte og trade secrets. Det er en praktisk balance: staten vil kontrollere sine data, men leverand\u00f8ren skal ikke tvinges til at aflevere hele sin maskine.<\/p>\n\n\n\n

For udviklere og arkitekter er den operative pointe enkel: LLM-laget skal kunne isolere kundedata fra leverand\u00f8rens tr\u00e6ningspipeline, supportpipeline og forbedringspipeline. Det skal kunne dokumenteres. Og det skal kunne overleve audits uden at alle svar bliver \u201cdet afh\u00e6nger af vores underleverand\u00f8r\u201d.<\/p>\n\n\n\n

Forslaget l\u00e6gger ogs\u00e5 pres p\u00e5 change management. Det er fornuftigt. Modelmarkedet er notorisk uroligt. Providers skifter standardmodeller, pensionerer gamle model-id\u2019er, \u00e6ndrer safety-lag, \u00e6ndrer prisstruktur og \u00e6ndrer performanceprofil. Jeg skrev tidligere om Claude modelpensionering som produktionsrisiko<\/a>. GSA-sporet peger i samme retning: en modelopdatering er ikke bare en release note. Det kan v\u00e6re en \u00e6ndring i kontraktens risikoprofil.<\/p>\n\n\n\n

Prompt injection passer perfekt ind i billedet<\/h2>\n\n\n\n

Det her h\u00e6nger ogs\u00e5 sammen med prompt injection. N\u00e5r LLM-systemer f\u00e5r adgang til dokumenter, v\u00e6rkt\u00f8jer og interne workflows, bliver \u201ctekst\u201d til et angrebsfelt. Hvis en RAG-pipeline kan hente ondsindede instruktioner fra et dokument, er det ikke nok at bede modellen om at v\u00e6re forsigtig. Man skal have runtime-kontroller, datagr\u00e6nser, rettighedsmodeller, logging og en klar id\u00e9 om, hvad systemet m\u00e5 g\u00f8re p\u00e5 brugerens vegne.<\/p>\n\n\n\n

Derfor rammer GSA-forslaget noget rigtigt. Det flytter ansvaret v\u00e6k fra modelmagi og over i systemdesign. Det samme var pointen i g\u00e5rsdagens indl\u00e6g om prompt injection som kontrolplansproblem<\/a>. LLM-sikkerhed er ikke en prompt. Det er et s\u00e6t gr\u00e6nser omkring en komponent, der b\u00e5de l\u00e6ser instruktioner og producerer handlinger.<\/p>\n\n\n\n

Hvis man driver en dansk SaaS, er den praktiske konsekvens ikke, at man skal kopiere amerikanske statsklausuler. Det ville v\u00e6re tungt og ofte forkert. Men man b\u00f8r allerede nu kunne svare p\u00e5 fem sp\u00f8rgsm\u00e5l: Hvilke kundedata sendes til hvilke modeller? Bruges data til tr\u00e6ning eller forbedring? Hvilke underleverand\u00f8rer indg\u00e5r i LLM-flowet? Hvordan h\u00e5ndteres modelskift? Og kan man dokumentere, at en kundes data kan slettes eller isoleres?<\/p>\n\n\n\n

Det her er procurement som arkitektur<\/h2>\n\n\n\n

Den gamle fejl er at lade legal, security og engineering h\u00e5ndtere LLM\u2019er i hver sin silo. Legal l\u00e6ser databehandleraftalen. Security sp\u00f8rger til SOC 2. Engineering v\u00e6lger den bedste API. Produkt lover en AI-feature. Tre m\u00e5neder senere opdager man, at ingen ejer helheden.<\/p>\n\n\n\n

GSA-sagen viser den modsatte retning: procurement bliver arkitektur. En LLM-kontrakt beskriver ikke kun pris og ansvar. Den beskriver ogs\u00e5 datagr\u00e6nser, roller i leverand\u00f8rk\u00e6den, \u00e6ndringsvarsler, kontrol med output og hvad der sker, hvis systemet ikke l\u00e6ngere opf\u00f8rer sig som aftalt.<\/p>\n\n\n\n

Det er sundt. Ikke fordi amerikansk regulering automatisk er forbilledlig, men fordi LLM\u2019er er blevet infrastruktur. N\u00e5r en komponent kan p\u00e5virke beslutninger, dokumenter, kundesupport, kode og interne processer, er det ikke l\u00e6ngere nok at k\u00f8be den som et abonnement med et par sikkerhedss\u00e6tninger i et bilag.<\/p>\n\n\n\n

Min vurdering: de n\u00e6ste 12 m\u00e5neder bliver mindre pr\u00e6get af \u201chvilken model scorer h\u00f8jest?\u201d og mere af \u201chvilken model kan vi faktisk drive, auditere og forklare?\u201d. Det lyder kedeligt. Det er ogs\u00e5 der, pengene og problemerne ligger.<\/p>\n\n\n\n

Kilder<\/h2>\n\n\n