Pool-model multi-tenancy med AgentCore

Princippet er enkelt at forklare, men kræver disciplin at implementere korrekt. I stedet for at hver kunde får sin egen dedikerede agent-instans, kører alle kunders forespørgsler gennem den samme underliggende pool af beregningsressourcer i AgentCore. Det, der adskiller kunderne, er ikke hardwaren, men sessionslaget: hver forespørgsel bærer en tenant-identitet, som styrer hvilke data agenten må hente, hvilke værktøjer den må kalde, og hvilken hukommelse den har adgang til undervejs i samtalen.

Det betyder i praksis, at en agent, der lige har svaret en kunde A på et spørgsmål om deres journal eller regnskab, ikke bærer nogen kontekst med videre, når den næste forespørgsel kommer fra kunde B. Isolationen sker ikke ved at spinde en ny server op for hver kunde, men ved at rammen omkring agenten - identitet, hukommelse, værktøjsadgang - nulstilles og genopbygges for hver session. Det er den samme logik, man kender fra multi-tenant SaaS-databaser, blot flyttet op i agentlaget, hvor konsekvenserne af en fejl er langt mere synlige, fordi agenten selv genererer svar baseret på det, den har adgang til.

AWS fremhæver sundhedssektoren som det oplagte eksempel, og det giver mening. En platform, der betjener flere klinikker, laboratorier eller sundhedsudbydere, har brug for at én AI-agent kan svare hurtigt og kontekstbevidst for hver enkelt klinik, uden at data fra klinik A nogensinde optræder i et svar til klinik B. Samtidig er det økonomisk urealistisk at bygge og drifte en fuldt separat AI-infrastruktur for hver eneste klinik, en klinik med ti ansatte har ikke budget til sin egen dedikerede model-instans.

Pool-modellen løser netop det spændingsfelt: en enkelt teknisk platform kan betjene mange klinikker parallelt, mens hver klinik oplever agenten, som om den var bygget specifikt til dem. Mønstret er ikke begrænset til sundhedssektoren. Det samme problem findes hos revisionshuse, der betjener flere klienter, hos advokatkontorer med adskilte sagsakter, og hos konsulenthuse, der sidder med fortrolige data fra konkurrerende virksomheder i samme branche. Fælles for dem alle er, at kravet om datamæssig adskillelse er lige så vigtigt som kravet om lav pris per bruger.

Den økonomiske pointe er den, der typisk overbeviser en ledelse hurtigst. Dedikeret infrastruktur per kunde skalerer lineært med antallet af kunder, dobbelt så mange kunder betyder groft sagt dobbelt så mange serverressourcer, dobbelt så meget overvågning og dobbelt så mange steder, hvor noget kan gå galt. Pool-modellen bryder den sammenhæng. Beregningskraften deles på tværs af kunder, og kun sessions- og identitetslaget vokser med antallet af tenants, ikke den underliggende infrastruktur.

For en virksomhed, der planlægger at gå fra ti til hundrede kunder på samme AI-løsning, er forskellen ikke marginal. Det er forskellen mellem en forretningsmodel, der kan bære vækst, og en, der bliver dyrere at drive for hver ny kunde man vinder. Det stiller til gengæld nye krav til, hvordan man tester og overvåger løsningen, for fejl i isolationslogikken rammer potentielt alle kunder på én gang, ikke kun én.

Det tekniske mønster løser ikke compliance-spørgsmålet alene. GDPR og branchespecifikke krav, som dem man kender fra sundhedsdata og finansielle data, stiller krav om, at man kan dokumentere adskillelsen, ikke blot påstå den. Det betyder i praksis, at logning, adgangskontrol og audit-spor skal designes ind i pool-arkitekturen fra starten, så man for hver eneste forespørgsel kan bevise hvilken tenant der havde adgang til hvilke data, og hvornår.

Det er her, mange multi-tenant-projekter går galt i praksis. Det er relativt let at bygge en løsning, der fungerer korrekt langt de fleste gange, men langt sværere at bygge en, hvor man kan dokumentere over for en revisor eller en tilsynsmyndighed, at isolationen er vandtæt i alle tilfælde, inklusive fejlscenarier.

For danske virksomheder, der overvejer at tilbyde AI-drevne løsninger til deres egne kunder, betyder pool-modellen, at man ikke behøver vælge mellem lav pris og god adskillelse. Man skal derimod stille de rigtige spørgsmål tidligt i projektet: hvordan håndteres tenant-identitet gennem hele agentens kæde af værktøjskald, hvordan nulstilles hukommelse og kontekst mellem sessioner, og hvordan dokumenteres adgangen bagefter.

Det er særligt relevant for virksomheder i regulerede brancher, hvor kravene til datahåndtering allerede er skærpede, og hvor en fejl i isolationen ikke bare er en teknisk detalje, men et compliance-brud med reelle konsekvenser. Mønstret fra AgentCore viser en vej, hvor man kan bygge én stabil platform i stedet for mange dyre siloer, men vejen dertil kræver, at arkitekturen tænkes igennem fra bunden, ikke lappes på efter at løsningen allerede kører for de første kunder.