Gebruiksquotum: hoe technologie een grens stelt aan wat je mag verbruiken
Stel je hebt een mobiel abonnement met tien gigabyte internet per maand. Zodra je die grens bereikt, wordt je verbinding traag of moet je bijbetalen. Dat is een gebruiksquotum: een vooraf vastgestelde limiet op hoeveel je van iets mag afnemen binnen een bepaalde periode. Wat voor mobiel dataverkeer al decennia gewoon is, duikt nu overal op in de wereld van toekomsttechnologie — van clouddiensten tot kunstmatige intelligentie.
Een gebruiksquotum lijkt technisch eenvoudig, maar erachter schuilt een fundamentele vraag: hoe verdeel je schaarse digitale capaciteit — rekenkracht, opslag, netwerkbandbreedte — eerlijk en veilig onder miljoenen gebruikers of duizenden systemen? Bij grote taalmodellen zoals ChatGPT gaat het niet alleen om eerlijkheid, maar ook om kosten, stabiliteit van servers en zelfs om toezicht op de meest krachtige AI-systemen ter wereld. Dat maakt het thema relevanter dan het op het eerste gezicht lijkt.
Wat is het precies?
In de kern is een gebruiksquotum een teller die bijhoudt hoeveel een gebruiker, applicatie of organisatie van een bepaalde bron verbruikt, gekoppeld aan een maximum. Zodra dat maximum bereikt is, gebeurt er iets: de dienst wordt geblokkeerd, vertraagd, of er volgt een extra kosten.
Bij software-diensten kom je twee hoofdvormen tegen. De eerste is rate limiting: een limiet per tijdseenheid, bijvoorbeeld het aantal verzoeken ("requests") dat een programma per minuut aan een server mag sturen. Bij AI-diensten zoals de API (programmeerinterface waarmee andere software een AI-model kan aanroepen) van OpenAI wordt dit vaak gemeten in RPM (requests per minute) en TPM (tokens per minute) — een token is ruwweg een stukje tekst van enkele letters, de "munteenheid" waarin taalmodellen tekst verwerken.
De tweede vorm is een resourcequotum: een vast plafond op de hoeveelheid rekenkracht, geheugen of opslag die een systeem mag gebruiken, ongeacht de tijd. In de software die grote datacenters aanstuurt — zoals Kubernetes, een populair open source systeem voor het beheren van containers, kleine geïsoleerde softwarepakketjes — kun je exact instellen hoeveel processorkracht en geheugen een applicatie maximaal mag opeisen.
Een derde, nieuwere variant speelt zich af op een heel ander niveau: dat van trainingsrekenkracht voor AI-modellen zelf. Overheden experimenteren met drempelwaarden uitgedrukt in FLOPS (floating point operations, de rekenstappen die een computerchip per seconde uitvoert). Een AI-model dat met meer rekenkracht dan een vastgestelde drempel is getraind, valt dan onder extra meldplichten of toezicht — niet omdat het dataverbruik van een individuele gebruiker wordt beperkt, maar omdat de totale "rekenbron" die aan het trainen van het model is besteed, als risico-indicator dient.
Wat wil men ermee bereiken?
Het eerste doel is simpel: stabiliteit. Zonder limieten kan één gebruiker, per ongeluk of moedwillig, een server overbelasten waardoor de dienst voor iedereen uitvalt. Rate limits beschermen dus de betrouwbaarheid van een systeem.
Het tweede doel is eerlijke verdeling. Rekenkracht en bandbreedte zijn niet oneindig. Door quota in te stellen, zorgen aanbieders ervoor dat één grootverbruiker niet alle capaciteit opsoupeert ten koste van kleinere gebruikers.
Het derde doel is kostenbeheersing, voor zowel de aanbieder als de klant. Cloud computing en AI-verwerking kosten geld per verbruikte eenheid; een quotum voorkomt onverwacht hoge rekeningen en helpt bedrijven hun uitgaven voorspelbaar te houden.
Bij AI-modellen komt een vierde, zwaarder wegend motief bij: veiligheid en toezicht. Beleidsmakers vrezen dat steeds krachtigere AI-systemen risico's met zich meebrengen — van het genereren van desinformatie tot, in extreme scenario's, hulp bij het ontwerpen van gevaarlijke wapens. Door een meldplicht te koppelen aan een compute-drempel, hopen toezichthouders zicht te houden op de allerkrachtigste modellen zonder de hele sector op slot te zetten. Ten slotte speelt ook duurzaamheid mee: datacenters verbruiken veel elektriciteit en koelwater, en quota kunnen indirect bijdragen aan een zuiniger gebruik van rekencapaciteit.
Voorbeelden uit de praktijk
Kubernetes ResourceQuota is al sinds de vroege ontwikkeling van dit open source platform (rond het midden van de jaren 2010, kort na de eerste stabiele release in 2015) een standaardonderdeel. Beheerders van een datacenter kunnen per team of project instellen hoeveel processorkracht, geheugen en opslag maximaal gebruikt mag worden, zodat afdelingen elkaar niet in de weg zitten.
Google Cloud en Amazon Web Services (AWS) hanteren al langer een uitgebreid quotasysteem (respectievelijk "Quotas" en "Service Quotas") waarmee klanten per dienst — bijvoorbeeld het aantal virtuele servers of API-aanroepen — een limiet krijgen, deels om misbruik te voorkomen en deels om de eigen infrastructuur te beschermen tegen piekbelasting.
OpenAI werkt met "usage tiers": gebruikers van de API krijgen, afhankelijk van hoeveel ze al besteed hebben en hoe lang ze al klant zijn, hogere limieten voor requests en tokens per minuut. Een nieuwe ontwikkelaar begint met een bescheiden quotum; wie aantoonbaar en betrouwbaar meer gebruikt, klimt op naar hogere niveaus.
Op regelgevingsniveau introduceerde de Amerikaanse regering-Biden in oktober 2023 via een presidentieel decreet (executive order) een meldplicht voor AI-modellen die met meer dan 10^26 FLOPS (een 1 met 26 nullen aan rekenoperaties) zijn getraind — een poging om zicht te houden op de zwaarste modellen. President Trump trok dit decreet begin 2025 weer in, wat illustreert hoe politiek gevoelig en wisselvallig dit soort quota-achtige regelgeving is.
De Europese Unie koos in de AI-verordening (AI Act) voor een vergelijkbaar, iets lager gelegen ijkpunt: een AI-model met algemene toepassing (general-purpose AI) dat met meer dan 10^25 FLOPS cumulatieve rekenkracht is getraind, wordt automatisch aangemerkt als model met "systeemrisico" en krijgt daardoor zwaardere verplichtingen, zoals extra evaluaties en incidentmeldingen.
Hoe ver is de techniek?
Voor de alledaagse toepassingen — rate limiting, cloud-resourcequota — is dit volwassen, bewezen technologie die al decennia in gebruik is bij telecomproviders, cloudaanbieders en softwareplatforms. Het werkt betrouwbaar en is nauwelijks nog omstreden.
Voor de nieuwere toepassing bij AI-regelgeving ligt dat anders. Compute-drempels zoals de 10^25- en 10^26-FLOPS-grenzen zijn ruwe, enigszins arbitraire indicatoren: ze meten hoeveel rekenkracht in de training is gestoken, niet hoe gevaarlijk of nuttig een model daadwerkelijk is. Critici wijzen erop dat drempels snel verouderen naarmate chips efficiënter worden — waardoor een model met minder rekenkracht toch even krachtig kan zijn — en dat de daadwerkelijke naleving moeilijk te controleren is, omdat bedrijven hun trainingsrekenkracht zelf rapporteren. Ook ontbreekt internationale afstemming: de VS, EU en andere landen hanteren losse, soms wisselende regels, wat het voor wereldwijd opererende AI-bedrijven lastig maakt. Kortom, het technische deel van gebruiksquota is uitontwikkeld; het beleidsmatige deel, zeker rond AI, staat nog volop in de kinderschoenen en verandert regelmatig.
Wie werken eraan?
Aan de technische kant zijn de grote clouddiensten toonaangevend: Google Cloud, Amazon Web Services en Microsoft Azure bouwen en beheren de quotasystemen waarop een groot deel van het internet draait. De open source gemeenschap rond Kubernetes, gecoördineerd door de Cloud Native Computing Foundation (CNCF), onderhoudt het resourcequotum-systeem dat door duizenden organisaties wordt gebruikt.
AI-ontwikkelaars zoals OpenAI, Anthropic, Google DeepMind en Mistral AI implementeren zelf rate limits en usage tiers voor hun API's. Aan de regelgevende kant houden de Europese Commissie (via het AI Office, dat toezicht houdt op de AI Act) en Amerikaanse instanties zoals het National Institute of Standards and Technology (NIST) zich bezig met het opstellen en herzien van compute-drempels en veiligheidsnormen voor krachtige AI-systemen. Ook nationale overheden, waaronder het Verenigd Koninkrijk met zijn AI Safety Institute, volgen deze ontwikkelingen op de voet.