LLM-kontrakter: GSA gør datakontrol til krav

Den mest interessante LLM-nyhed det sidste døgn er ikke en ny model med en større benchmarkgraf. Det er noget langt mere kedeligt og langt mere vigtigt: den amerikanske indkøbsmyndighed GSA er ved at gøre LLM-kontrakter til et spørgsmål om datakontrol, leverandørkæde og driftsansvar.

Holland & Knight skrev 29. juni om GSA’s foreslåede klausul for “Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems”. Selve forslaget blev lagt i Federal Register 17. juni, men den aktuelle gennemgang er relevant, fordi den viser, hvor hurtigt LLM-indkøb flytter sig fra “må vi bruge ChatGPT?” til “hvem har juridisk og teknisk ansvar for data, output, modelopdateringer og underleverandører?”.

Det er værd at holde øje med, også hvis man ikke sælger til den amerikanske stat. Offentlige krav har det med at sive ind i enterprise-markedet. Først som særkrav i store kontrakter. Senere som spørgeskemaer, sikkerhedsbilag og procurement-standarder. Hvis GSA får LLM-kontrakter ind i en mere moden kontraktform, er det et signal om, hvordan seriøse kunder kommer til at købe AI-systemer.

LLM’en bliver ikke længere behandlet som en app

GSA-forslaget handler ikke bare om selve modellen. Det rammer hele systemet omkring den: udviklere, operatører, systemintegratorer og service providers. Det er den rigtige måde at tænke på. En moderne LLM-løsning er sjældent én leverandør og én model. Den består 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åneder.

Det er præcis der, problemerne opstår. Hvis en leverandør siger “vi træner ikke på jeres data”, er det kun ét spørgsmål. Hvad med menneskelig review? Hvad med embeddings? Hvad med outputdata? Hvad med logs? Hvad med en underleverandør, der leverer RAG-infrastruktur? Hvad med en modelopdatering, der ændrer svaradfærd uden at ændre API-navnet?

GSA’s udkast forsøger at gøre de spørgsmål kontraktlige. Det betyder flowdown-krav til underleverandører, dokumenteret due diligence, kontrol med government data og krav om notifikation ved ændringer. Ikke sexet. Men det er den slags kedelighed, der afgør, om LLM-kontrakter kan bruges i produktion uden at governance bliver ren ønsketænkning.

Dataejerskab og modelopdateringer bliver driftskrav

En af de vigtigste detaljer er, at government data defineres bredt. Ikke kun input, men også output og specialudvikling. Holland & Knight peger på, at den nye version samtidig indfører beskyttelse af leverandørens eksisterende IP, baggrundsdata, kildekode, modelvægte og trade secrets. Det er en praktisk balance: staten vil kontrollere sine data, men leverandøren skal ikke tvinges til at aflevere hele sin maskine.

For udviklere og arkitekter er den operative pointe enkel: LLM-laget skal kunne isolere kundedata fra leverandørens træningspipeline, supportpipeline og forbedringspipeline. Det skal kunne dokumenteres. Og det skal kunne overleve audits uden at alle svar bliver “det afhænger af vores underleverandør”.

Forslaget lægger også pres på change management. Det er fornuftigt. Modelmarkedet er notorisk uroligt. Providers skifter standardmodeller, pensionerer gamle model-id’er, ændrer safety-lag, ændrer prisstruktur og ændrer performanceprofil. Jeg skrev tidligere om Claude modelpensionering som produktionsrisiko. GSA-sporet peger i samme retning: en modelopdatering er ikke bare en release note. Det kan være en ændring i kontraktens risikoprofil.

Prompt injection passer perfekt ind i billedet

Det her hænger også sammen med prompt injection. Når LLM-systemer får adgang til dokumenter, værktøjer og interne workflows, bliver “tekst” til et angrebsfelt. Hvis en RAG-pipeline kan hente ondsindede instruktioner fra et dokument, er det ikke nok at bede modellen om at være forsigtig. Man skal have runtime-kontroller, datagrænser, rettighedsmodeller, logging og en klar idé om, hvad systemet må gøre på brugerens vegne.

Derfor rammer GSA-forslaget noget rigtigt. Det flytter ansvaret væk fra modelmagi og over i systemdesign. Det samme var pointen i gårsdagens indlæg om prompt injection som kontrolplansproblem. LLM-sikkerhed er ikke en prompt. Det er et sæt grænser omkring en komponent, der både læser instruktioner og producerer handlinger.

Hvis man driver en dansk SaaS, er den praktiske konsekvens ikke, at man skal kopiere amerikanske statsklausuler. Det ville være tungt og ofte forkert. Men man bør allerede nu kunne svare på fem spørgsmål: Hvilke kundedata sendes til hvilke modeller? Bruges data til træning eller forbedring? Hvilke underleverandører indgår i LLM-flowet? Hvordan håndteres modelskift? Og kan man dokumentere, at en kundes data kan slettes eller isoleres?

Det her er procurement som arkitektur

Den gamle fejl er at lade legal, security og engineering håndtere LLM’er i hver sin silo. Legal læser databehandleraftalen. Security spørger til SOC 2. Engineering vælger den bedste API. Produkt lover en AI-feature. Tre måneder senere opdager man, at ingen ejer helheden.

GSA-sagen viser den modsatte retning: procurement bliver arkitektur. En LLM-kontrakt beskriver ikke kun pris og ansvar. Den beskriver også datagrænser, roller i leverandørkæden, ændringsvarsler, kontrol med output og hvad der sker, hvis systemet ikke længere opfører sig som aftalt.

Det er sundt. Ikke fordi amerikansk regulering automatisk er forbilledlig, men fordi LLM’er er blevet infrastruktur. Når en komponent kan påvirke beslutninger, dokumenter, kundesupport, kode og interne processer, er det ikke længere nok at købe den som et abonnement med et par sikkerhedssætninger i et bilag.

Min vurdering: de næste 12 måneder bliver mindre præget af “hvilken model scorer højest?” og mere af “hvilken model kan vi faktisk drive, auditere og forklare?”. Det lyder kedeligt. Det er også der, pengene og problemerne ligger.