Den vigtigste arkitekturbeslutning når man indfører AI i en virksomhed er ikke hvilken model man vælger. Det er hvor i systemet modellen får lov at sidde.
Den default-tilgang som leverandører og pilotprojekter ofte falder ind i, er at lade sprogmodellen være selve systemet. Brugeren skriver ind i en chat, modellen svarer, og det svar bliver behandlet som outputtet. Det fungerer på en demo. Det fungerer ikke i produktion. Og det er en holdning man som leder skal kunne genkende og afvise.
Hvad en LLM faktisk er
En sprogmodel er en sandsynlighedsmaskine. Den producerer det næste ord baseret på et statistisk mønster lært fra meget store mængder tekst. Det er en bemærkelsesværdig egenskab, og den dækker en bred vifte af opgaver — sammenfatning, klassifikation, omskrivning, kreativ generering — overraskende godt.
Men det er stadig en sandsynlighedsmaskine. Den ved ikke hvad der er sandt. Den ved ikke hvad den ikke ved. Den kan finde på ting der ser plausible ud, men ikke er. Den kan blive påvirket af tekst en bruger smider ind i prompten — en kategori af angreb der hedder prompt injection og som ikke har en endelig løsning.
Det er ikke et midlertidigt problem som næste model-version løser. Det er en grundlæggende egenskab ved teknologien. En leder der ikke har forstået det, kan blive solgt en arkitektur der lover for meget og leverer for lidt.
Kompartmentalisering som princip
Den modsatte tilgang er at indkapsle modellen. Lægge den i en kasse. Bygge traditionelle, deterministiske lag rundt om — kode der ved hvad den laver, der kan testes, der kan logges, og som kan stoppe modellen hvis den siger noget galt.
I forskningsmiljøet kaldes denne arkitektur compound AI systems. Pointen er enkel: moderne AI-applikationer består sjældent af ét model-kald. De består af mange små komponenter — datakilder, validatorer, routere, regler, cache-lag — bundet sammen af klassisk kode, hvor sprogmodellen er ét trin blandt flere.
Modellen er midten. Yderlaget er altid kode der ved hvad den laver.
Konsekvensen er konkret:
- Indhentning af data håndteres af deterministisk kode — ikke af modellen.
- Validering af input sker før det rammer modellen — ikke efter.
- Output kontrolleres mod et skema før det går videre — ikke "vi håber den svarede rigtigt".
- Routing — om svaret skal gemmes, sendes videre, eskaleres til et menneske — er regler, ikke modeludgang.
- Logging dækker hele pipelinen, så man kan rekonstruere hvorfor systemet gjorde hvad det gjorde.
Det er ikke et komplicereret princip. Det er den måde almindelige produktionssystemer er bygget på. Det nye er at den probabilistiske komponent — sprogmodellen — får lov at gøre det den er god til, og bliver holdt ude af det den ikke er god til.
Hvorfor det er en ledelsesbeslutning, ikke en teknisk
Det her er fristende at delegere til IT eller til en leverandør. Det skal man ikke.
Tre ting gør det til en ledelsesbeslutning:
Risikoprofil. En kompartmentaliseret arkitektur fejler lokalt. Et trin går galt, det fanges i næste trin, systemet stopper kontrolleret. En monolitisk AI-arkitektur fejler globalt. En forkert antagelse spreder sig gennem hele svaret. Forskellen i risikoeksponering er stor — og ledelsen er den der bærer den.
Reviderbarhed. Regulatoriske krav, GDPR, kommende AI Act, branche-specifikke compliance-rammer — alle forudsætter at man kan forklare hvorfor systemet traf den beslutning det traf. Det kan man ikke når et helt sagsforløb afhænger af én sprogmodel der genererer en sammenhængende tekst. Det kan man når hver delbeslutning er logget, valideret og tilskrivelig.
Omkostninger over tid. Sprogmodel-kald er dyre. Et velkompartmentaliseret system kalder kun modellen hvor den faktisk tilfører værdi — resten er billig deterministisk kode. Forskellen i driftsomkostninger mellem en monolitisk og en compound arkitektur kan være ti til hundrede gange. Det er et CFO-tema, ikke et udvikler-tema.
Hvad ledelsen skal kunne spørge om
En leder behøver ikke kunne bygge systemet. Men man skal kunne stille tre spørgsmål til enhver der præsenterer en AI-løsning, intern eller ekstern:
-
Hvilke dele er AI, og hvilke dele er almindelig kode? Hvis svaret er vagt eller "det meste er AI", er arkitekturen vag. Et voksent design kan tegne kassen om sprogmodellen og pege på alt det den ikke gør.
-
Hvad sker der hvis modellen svarer noget forkert? Et godt svar beskriver et valideringslag, en konfidens-tærskel, en menneskelig fallback. Et dårligt svar er "det sker sjældent" eller "vi forbedrer prompten".
-
Kan vi rekonstruere bagefter hvorfor systemet traf en konkret beslutning? Hvis logfilen kun viser brugerens spørgsmål og modellens svar, har man ingen revisionsspor. Hvis man kan se hver delbeslutning og hver validering, har man et system der hører hjemme i en virksomhed.
Det er ikke nørdede spørgsmål. Det er governance-spørgsmål forklædt som tekniske spørgsmål.
Mulighederne forsvinder ikke fordi man kompartmentaliserer
Et hyppigt misforstået modsvar er at den her tilgang dræber innovation — at man holder sprogmodellen tilbage og dermed mister potentialet.
Det er omvendt. Det er præcis fordi modellen er indkapslet at man kan slippe den løs på de opgaver den er god til. Klassifikation, sammenfatning, omskrivning, kreativ udfoldelse i et afgrænset rum — alt sammen ting hvor probabilistisk output er en feature og ikke en bug. Når modellen ved at den ikke skal være systemet, men en komponent, kan den få lov at være den komponent fuldt ud.
Det er den samme logik som med en ny medarbejder med et særligt talent. Man giver dem ikke nøglerne til hele driften. Man giver dem et veldefineret område hvor deres talent slår igennem, og man bygger struktur omkring så fejl bliver fanget tidligt. Med tiden, og når tilliden er der, kan området vokse.
Sprogmodellen er en ny medarbejder. En meget produktiv, meget hurtig, men også meget upålidelig medarbejder. Den fortjener et veldefineret område. Den fortjener struktur. Den fortjener ikke at være systemet.
Den korte version
LLM'er er probabilistiske komponenter. De skal indkapsles i traditionelle, deterministiske lag — ikke fungere som hele systemet. Kompartmentalisering giver lavere risiko, bedre reviderbarhed, lavere omkostninger og samtidig bedre udnyttelse af det modellen rent faktisk er god til.
Det er en arkitekturbeslutning. Men det er først og fremmest en ledelsesbeslutning. Lederen behøver ikke vide hvordan systemet bygges, men skal kunne kende forskel på et voksent design og et naivt et — og skal kunne stille de spørgsmål der afslører hvilket man har med at gøre. Den viden er ikke en teknisk luksus. Den er en del af jobbet nu.