Multi-tenant AI-agentarchitectuur voor SaaS

Het draaien van AI-agents binnen een multi-tenant SaaS-product introduceert een specifieke reeks architecturale zorgen die niet bestaan in een single-tenant tool. Het AI-model zelf heeft geen concept van met welke klantdata het werkt — dus de verantwoordelijkheid om tenants goed gescheiden te houden, en om te begrijpen wat elke tenant je kost, valt volledig op hoe je eromheen architectureert.

De kernuitdaging: het model weet niets van multi-tenancy

Een AI-model verwerkt welke context je het ook geeft en produceert output op basis van die context. Het heeft geen inherent begrip dat de data van Klant A nooit zichtbaar mag zijn voor de agent van Klant B. Die isolatiegrens is iets wat je applicatielaag volledig moet afdwingen — voor elke agentinteractie precies beslissen welke tenantdata binnen bereik is en welke acties zijn toegestaan, en nooit vertrouwen op het model om een grens te respecteren die het niet kan waarnemen.

Tenantisolatie voor AI-agents

Isolatie goed doen betekent bewust zijn over twee dingen:

• Contextafbakening — elk stuk data dat een agent ontvangt (opgehaalde documenten, databaserecords, gespreksgeschiedenis) moet worden gefilterd naar de huidige tenant voordat het het model bereikt, met dezelfde toegangscontrolelogica die de rest van je multi-tenant datalaag regelt
• Actieafbakening — elke tool of actie die een agent kan aanroepen moet worden beperkt tot de bronnen van de huidige tenant, zodat een agent die aan het verzoek van Klant A werkt niets kan lezen, wijzigen of activeren dat toebehoort aan Klant B

Dit sluit aan bij het least-privilege-principe uit onze gids over threat modeling van AI-agents voor startups — in een multi-tenant context betekent least privilege ook least tenancy: een agent zou toegang moeten hebben tot exact het bereik van één tenant en niets daarbuiten.

Configuratie per tenant

De meeste multi-tenant SaaS-producten profiteren van in elk geval logische AI-agentconfiguratie per tenant, waarmee je het volgende kunt variëren:

• Gegevensbereik — tot welke van de gegevensbronnen van de tenant een agent toegang heeft
• Rechten — welke acties de agent namens die tenant mag ondernemen
• Functietoegang en gebruikslimieten — vaak gekoppeld aan het plan-niveau, zodat hogere niveaus een capabelere of hoogvolume agenttoegang krijgen
• Guardrails — eventuele tenantspecifieke beperkingen op het gedrag van de agent

Kostentoewijzing per tenant

Omdat de meeste API’s van AI-aanbieders factureren op basis van gebruik — behandeld in onze gids over AI-inferentiekosten bijhouden in je SaaS-product — moet je weten wat elke tenant je kost. De praktische aanpak is elk AI-verzoek te loggen, getagd met de tenantidentifier, waarbij tokengebruik en API-aanroepen worden vastgelegd, en vervolgens te aggregeren per tenant. Dit is essentieel voor:

• Het begrijpen van de unit economics — of een bepaalde tenant of plan-niveau daadwerkelijk winstgevend is zodra de AI-kosten zijn meegerekend
• Gebruiksgebaseerde facturering — als je tenants deels op basis van hun AI-verbruik factureert
• Anomaliedetectie — een tenant wiens AI-gebruik onverwacht piekt, wat kan wijzen op misbruik of een bug

Een praktisch kader

Zorg	Wanneer het goed te doen
Tenantdata-isolatie in agentcontext en -acties	Vanaf het begin — dit is een beveiligingsgrens, geen optimalisatie
AI-agentconfiguratie per tenant	Logisch vanaf het begin; verfijning kan incrementeel groeien
Kostenlogging per tenant	Vroeg — goedkoop om vooraf toe te voegen, pijnlijk om later te reconstrueren
Gebruiksgebaseerde facturering op AI-verbruik	Wanneer je echte tenants hebt en de werkelijke gebruikspatronen begrijpt
Anomaliedetectie op gebruik per tenant	Zodra je genoeg tenants hebt dat “normaal” betekenisvol is

Wat een MVP in een vroege fase daadwerkelijk nodig heeft

De tenantisolatiegrens moet vanaf dag één correct zijn, want een lek tussen tenants is een ernstig beveiligingsfalen ongeacht je fase. Kostenlogging per tenant is het waard vroeg toe te voegen aangezien het vooraf goedkoop en achteraf moeilijk te reconstrueren is. Geavanceerdere configuratie per tenant, gebruiksgebaseerde facturering en anomaliedetectie kunnen redelijkerwijs incrementeel worden gebouwd naarmate je echte tenants krijgt en je werkelijke gebruikspatronen leert — volgens de bredere right-sizing-discipline uit onze infrastructuurgidsen.

Veelgestelde vragen

Wat is anders aan het draaien van AI-agents in een multi-tenant SaaS-product?

De kernuitdaging is ervoor zorgen dat de AI-agent van één tenant nooit toegang kan krijgen tot, kan handelen op of kan lekken van de data van een andere tenant, terwijl je ook de AI-gebruikskosten per tenant nauwkeurig toewijst — beide moeilijker dan in een single-tenant product waar er geen isolatiegrens is om af te dwingen.

Hoe houd je tenantdata geïsoleerd wanneer een AI-agent die verwerkt?

Elk stuk context dat een agent ontvangt en elke actie die hij kan ondernemen moet worden beperkt tot één enkele tenant, afgedwongen in je applicatielaag in plaats van te vertrouwen op het AI-model zelf om grenzen te respecteren — het model heeft geen inherent concept van multi-tenancy.

Moet elke tenant zijn eigen AI-agentconfiguratie krijgen?

Vaak wel, in elk geval logisch — een configuratie per tenant laat je verschillende rechten, gegevensbereiken, functietoegang en gebruikslimieten toepassen, wat belangrijk is zowel voor beveiliging als voor het ondersteunen van verschillende plan-niveaus.

Hoe wijs je AI-kosten toe aan individuele tenants?

Log tokengebruik en API-aanroepen getagd met de tenantidentifier op het punt waar elk AI-verzoek wordt gedaan, en aggregeer vervolgens per tenant — dit is essentieel om de unit economics te begrijpen en voor gebruiksgebaseerde facturering als je die aanbiedt.

Is dit iets wat een MVP in een vroege fase volledig vooraf moet oplossen?

De isolatiegrens moet vanaf het begin correct zijn aangezien het een beveiligingskwestie is, maar geavanceerde kostentoewijzing en configuratie per tenant kunnen incrementeel worden gebouwd naarmate je echte tenants krijgt en je werkelijke gebruikspatronen begrijpt.