AI’s omvendte informationsparadoks: Din virksomheds viden bliver til leverandørens læring

3 min read

Omvendte informationsparadoks: virksomhedens AI-læring bag en sikker grænse

Den klassiske økonomiske udfordring ved information er enkel: Hvordan sælger du noget, uden at give det væk først?

Kenneth Arrow beskrev i 1962 det problem, der senere blev kendt som informationsparadokset. En køber kan ikke kende værdien af viden, før vedkommende har fået den. Men når viden først er delt, er den i praksis allerede leveret.

Med generativ AI vender problemet den anden vej.

Virksomheden køber adgang til intelligens, men for at få reel værdi skal den samtidig udlevere det, som gør virksomheden speciel: dokumenter, arbejdsgange, kundekendskab, beslutningshistorik, fejl, rettelser og interne vurderinger. Jo bedre AI-løsningen skal blive, desto mere specifik kontekst skal den have.

Det er ikke kun en dataopgave. Det er en ejerskabsopgave.

En prompt er sjældent bare en prompt

Det er nemt at reducere AI-risiko til spørgsmålet om, hvorvidt en medarbejder må indsætte fortrolige oplysninger i ChatGPT, Claude eller en anden model. Det spørgsmål er vigtigt, men for snævert.

Den værdifulde viden ligger ofte ikke i den enkelte prompt. Den opstår i loopet mellem medarbejder og model.

En jurist retter modellens kontraktudkast. En ejendomsadministrator forklarer, hvorfor en lejekontrakt skal håndteres anderledes i netop denne sag. En supportmedarbejder afviser et forkert svar og skriver den formulering, der faktisk løser kundens problem. En udvikler bygger tests, der skelner mellem kode, som ser rigtig ud, og kode, som holder i produktion.

Det er institutionaliseret erfaring. Ikke bare tekst.

Når virksomheden gemmer den erfaring som interne instruktioner, evalueringsdatasæt, agenthukommelse eller tilpassede modeller, kan den genbruges. Når den derimod ligger uklart fordelt hos en ekstern platform, mister virksomheden både overblik og forhandlingsstyrke.

Her begynder det omvendte informationsparadoks at bide: Kunden betaler for modellen, men bidrager løbende med den viden, der gør modellen anvendelig i kundens egen forretning.

Fra dataejerskab til ejerskab over læring

Cloud-æraen lærte virksomheder at tænke på dataejerskab. Hvor ligger kundedata? Hvem har adgang? Hvad sker der ved leverandørskifte? Kan data eksporteres?

AI kræver et ekstra lag. Virksomheden skal kunne svare på, hvem der ejer og kontrollerer prompts og samtalelogger, dokumentudtræk, menneskelige rettelser, evalueringsdatasæt, agenters beslutningsspor, værktøjskald og tilpassede instruktioner.

Hvis disse elementer ikke kan eksporteres, auditeres og flyttes, ejer virksomheden ikke sin AI-kapacitet. Den lejer adgang til den, mens dens vigtigste forbedringer ophobes et andet sted.

Det betyder ikke, at al AI skal køre lokalt. Det ville være en dyr dogmebeslutning for de fleste danske virksomheder. Frontier-modeller i skyen kan være det rigtige valg, især når kvalitet, hastighed og driftssikkerhed betyder mere end maksimal kontrol.

Men arkitekturen skal give virksomheden en reel udvej. Det er samme princip som i LLM-routing, hvor modelvalget bliver et kontrolplan. En virksomhed bør kunne vælge model efter opgaven uden at genopbygge hele sin viden, sine tests og sine arbejdsgange, hver gang en leverandør ændrer priser, vilkår eller produktstrategi.

Evals er virksomhedens definition af kvalitet

Den mest undervurderede AI-aktiv er ikke promptbiblioteket. Det er virksomhedens evals.

En eval fortæller, hvad et godt svar er i en konkret arbejdsgang. Den kan måle, om en agent foreslår korrekt svar til en lejer, om den finder de relevante krav i et dokument, om den respekterer godkendelsesgrænser, eller om den sender en sag videre til et menneske, når usikkerheden bliver for høj.

Modellen kan skiftes. Virksomhedens definition af kvalitet bør blive.

Det gælder også, når man bygger med private endpoints eller selvhostede modeller. Private LLM-endpoints løser noget vigtigt omkring netværk, dataflytning og adgangskontrol. De løser ikke automatisk ejerskabet over feedbacksløjfen. Hvis evals, agenthukommelse og beslutningslogik stadig er låst inde i et proprietært produkt, er afhængigheden bare flyttet et niveau.

NISTs AI Risk Management Framework peger på, at AI-risiko skal håndteres på tværs af organisation, kontekst og livscyklus. Det er en bedre ramme end den sædvanlige leverandørspørgeskematik med fokus på kryptering, datacenterregion og et ja/nej-felt om træning på kundedata.

De spørgsmål skal stadig stilles. Men de er ikke nok.

Det praktiske minimum

En dansk virksomhed, der bygger AI ind i kerneprocesser, bør have fem ting på plads.

  • En klar datagrænse: Hvilke data må forlade virksomheden, i hvilken form og til hvilke modelleverandører?
  • En intern log over agenters handlinger, værktøjskald og godkendelser, så fejl kan forklares og beslutninger genskabes.
  • Evals, der ejes og opbevares af virksomheden. De er den reelle specifikation for, hvornår AI-løsningen virker.
  • Et orkestreringslag, hvor model, kontekst, værktøjer og regler ikke er hårdt bundet til én leverandør.
  • Kontraktvilkår, der konkret regulerer brugen af input, output, telemetry og feedback.

“Vi træner ikke på dine data” er for upræcist, hvis produktet samtidig indsamler detaljerede spor om, hvordan mennesker retter, vurderer og bruger systemet.

AI bliver først værdifuld, når den får adgang til det, virksomheden allerede har lært. Derfor er det ikke nok at beskytte data. Virksomheden skal beskytte sin evne til at lære hurtigere af egne arbejdsgange end konkurrenterne gør.

Det er den ressource, der bør blive i huset.

Kilder

Denne artikel er skrevet i samarbejde med AI, og efterfølgende redigeret af et rigtigt menneske 🙂

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *