AI-systemarkitektur
AI bliver et spørgsmål om systemarkitektur
De seneste års AI-kapløb har været domineret af modeller: større kontekstvinduer, bedre reasoning, multimodalitet og højere benchmarkperformance.
Men i takt med at AI flytter fra prototype til produktionssystem, ændrer optimeringsproblemet sig. Modelkvalitet er stadig vigtig, men skal nu balanceres mod latency, compute, dataadgang, sikkerhed, sporbarhed og omkostninger.
Det betyder, at spørgsmålet ikke længere alene er, hvilken model der performer bedst. Det er, hvilken systemarkitektur der samlet set giver den bedste løsning.
Fra modelperformance til systemperformance
I en prototype er det nærliggende at sende alle opgaver til den mest kapable model. I produktion er det sjældent så enkelt.
En større model kan forbedre kvaliteten, men øger typisk både latency og inferensomkostninger. Mere kontekst kan reducere behovet for retrieval, men gør hvert kald tungere. Retrieval kan til gengæld holde konteksten dynamisk og målrettet, men introducerer nye fejlkilder i søgning, ranking og adgangskontrol.
Det samme gælder agentiske workflows. Flere reasoning- og tool-use-trin kan løse mere komplekse opgaver, men hvert ekstra trin tilføjer både omkostning og en ny mulighed for fejl.
Derfor bliver det relevante mål ikke kun modelperformance, men systemperformance.
Et kundeservicesystem kan eksempelvis route simple klassifikationsopgaver til en mindre model, hente kundedata deterministisk og kun aktivere en større model, når sagen kræver egentlig ræsonnering. Den arkitektur kan være både billigere, hurtigere og mere robust end at lade én stor model håndtere hele processen.
AI-arkitektur er et spørgsmål om trade-offs
Et AI-system kan ikke optimeres lag for lag. Valg ét sted flytter ofte problemet et andet sted.
- Mere kontekst vs. retrieval: Store context windows kan reducere retrieval, men øger latency og inferensomkostninger. Retrieval giver friskere og mere selektiv kontekst, men introducerer fejlmuligheder i søgning, ranking og permissions.
- Større model vs. model routing: Én stærk model forenkler arkitekturen. Routing mellem mindre og større modeller kan optimere pris og performance, men kræver klassifikation, fallback-logik og evaluering af selve routingen.
- Autonomi vs. sikkerhed: Flere tools og bredere permissions gør agenter mere kapable, men øger samtidig angrebsflade og blast radius.
- Flere agenttrin vs. robusthed: Iteration kan forbedre resultatet, men øger latency, compute og risikoen for, at fejl akkumulerer gennem workflowet.
- Observability vs. dataeksponering: Detaljerede traces er nødvendige for debugging, evals og audit, men kan selv indeholde prompts, persondata og forretningskritisk information.
Pointen er, at model, kontekst, retrieval, tools, permissions, evals og compute skal optimeres som ét samlet system.
Agenten ændrer sikkerhedsmodellen
Agentisk AI gør dette systemperspektiv særlig vigtigt.
Når en model får adgang til eksterne datakilder og tools, bliver et forkert output ikke nødvendigvis slutpunktet. Det kan blive input til en handling.
Prompt injection er derfor mere end et problem med dårlige prompts. En agent kan møde manipulerende instruktioner i eksempelvis en webside, mail eller et dokument, som den samtidig forventes at behandle som data. Forsvar kan derfor ikke alene baseres på at identificere og filtrere ondsindet input. Systemet bør også begrænse konsekvensen, hvis manipulationen lykkes.
Det flytter sikkerhedsarbejdet mod permissions, isolation og afgrænsede interfaces.
En indkøbsagent kan eksempelvis få lov til at læse tilbud og generere et ordreudkast, men ikke selv sende ordren. En agent med databaseadgang kan få et snævert query-interface frem for generelle databasecredentials.
Målet er ikke at antage, at modellen altid opfører sig korrekt. Det er at reducere systemets blast radius, når den ikke gør.
Observability bliver mere end driftsmålinger
Probabilistiske systemer udfordrer også den traditionelle forståelse af test og drift.
Det er ikke tilstrækkeligt at vide, at et API-kald lykkedes, og at svartiden lå inden for SLA'en. Man skal også kunne undersøge, hvilken kontekst modellen fik, hvilke tools der blev kaldt, hvordan et agentforløb udviklede sig, og om resultatet faktisk havde den ønskede kvalitet.
Det gør evals, traces og versionsstyring til en del af produktionsarkitekturen.
Men også her opstår et trade-off. Jo mere detaljeret et agentforløb logges, desto bedre kan det analyseres og auditeres. Samtidig kan traces indeholde følsomme data, modelinput og oplysninger fra interne systemer.
Observability-laget bliver dermed selv et sikkerheds- og governanceproblem.
Governance flytter ind i arkitekturen
Den udvikling forstærkes af reguleringen.
EU's AI Act kræver blandt andet teknisk dokumentation fra udbydere af general-purpose AI-modeller, mens modeller med systemisk risiko mødes af yderligere krav om risikovurdering, hændelsesrapportering og cybersikkerhed. Kommissionens håndhævelsesbeføjelser på GPAI-området gælder fra 2. august 2026.
For systemarkitekten er pointen ikke kun juridisk.
Hvis organisationen skal kunne dokumentere modelversioner, datatilgange, konfigurationer og handlinger, skal provenance og auditability understøttes teknisk. Governance kan derfor ikke nødvendigvis tilføjes efter deployment; dele af den skal designes ind i systemet.
Compute er også et designvalg
Det samme gælder den fysiske infrastruktur.
AI-workloads varierer voldsomt i ressourceforbrug. Ifølge IEA kan reasoning, videogenerering og agentiske workloads bruge hundreder eller tusinder af gange mere energi pr. forespørgsel end simpel tekstgenerering. Samtidig voksede elforbruget i AI-fokuserede datacentre med omkring 50 procent i 2025.
Compute bliver derfor ikke kun et kapacitetsproblem for infrastrukturen. Det er en arkitekturparameter.
En agent, der foretager ti modelkald, er ikke den samme workload som én inferens. En større model er ikke nødvendigvis det bedste valg til alle trin. Og en marginal kvalitetsforbedring kan være dyr, hvis den multipliceres over millioner af kald.
Model routing, caching, context management og antallet af agenttrin bliver dermed ikke bare softwarevalg. De påvirker direkte latency, økonomi og ressourceforbrug.
Den næste konkurrenceparameter ligger omkring modellen
Bedre modeller vil fortsat flytte grænsen for, hvad AI-systemer kan.
Men efterhånden som modellerne bliver integreret i produktionssystemer, bliver deres værdi i stigende grad bestemt af arkitekturen omkring dem: hvordan data hentes, hvordan workloads routes, hvilke handlinger modellerne må foretage, hvordan resultater evalueres, og hvordan fejl begrænses.
Det flytter også det centrale engineering-spørgsmål.
Ikke kun hvilken model performer bedst? Men: Hvilken kombination af model, data, tools, kontrolmekanismer og compute giver det bedste system?
Det er dér, en stadig større del af konkurrencen om at bygge robuste AI-systemer flytter hen.
Læs mere:
Kontakt
Få hjælp nu
Find relevante, kvalitetssikrede kurser og efteruddannelse.