Google AI en rate limits: modelkeuze is infrastructuur
Rate limits zijn geen voetnoot meer
AI-platforms worden vaak gekozen op modelkwaliteit. Begrijpelijk. Maar zodra je een AI-flow in productie zet, tellen limieten, beschikbaarheid en voorspelbaarheid net zo hard mee. Een slim model dat op het verkeerde moment afknijpt, is geen strategie. Het is een risico met een nette demo eromheen.
De video over Google’s positie in AI is vooral interessant door het signaal eromheen. Niet omdat één YouTube-fragment de waarheid over Google bewijst, maar omdat gebruikers in de comments concreet praten over token- en rate limits. Dat is precies waar veel B2B-teams te laat naar kijken.
De verkeerde vraag: welk model is het slimst?
De vraag “welk model is het slimst?” klinkt logisch, maar is voor productie te smal. Je wilt weten of het model slim genoeg is voor de taak, of de API stabiel genoeg is voor je proces, en of je team begrijpt wat er gebeurt als de limiet wordt geraakt.
| Vraag | Demo-denken | Productie-denken |
|---|---|---|
| Kwaliteit | Welke output is het mooist? | Welke output is betrouwbaar genoeg voor deze taak? |
| Kosten | Wat kost een prompt? | Wat kost deze workflow per maand bij echt gebruik? |
| Limieten | Wanneer krijg ik een fout? | Wat gebeurt er met klantproces en fallback? |
| Beheer | Wie klikt op run? | Wie monitort logs, latency en failures? |
Dat verschil lijkt klein, maar daar zit de winst. In een losse test kun je wachten. In een klantproces niet. Dan moet je systeem weten wat de volgende stap is.
Vendor-risk begint bij iets saais: logging
Als je niet logt welke provider, welk model, welke statuscode en welke fallback is gebruikt, kun je later alleen nog gokken. En gokken is precies wat je niet wilt als een offertegenerator, intakeflow of interne assistent ineens stopt.
- Log provider, model en versie per request.
- Bewaar latency en foutmeldingen gestructureerd.
- Meet hoeveel requests tegen rate limits aanlopen.
- Maak per workflow duidelijk welke fallback acceptabel is.
- Zet kosten per workflow naast waarde, niet alleen naast tokens.
Wat betekent dit voor Funnel Adviseur-klanten?
Voor de meeste MKB- en B2B-teams is de oplossing niet “alles zelf hosten”. Dat is ook weer zo’n reflex. De oplossing is eerst bepalen welke AI-processen kritisch zijn. Pas daarna kies je of Google, OpenAI, Claude, open-source of een hybride setup past.
Bij marketing-automation is dat verschil concreet. Een AI-nurture die af en toe later draait is vervelend. Een leadkwalificatie die midden in een salesproces stopt, kan omzet kosten. Een intern research-script mag falen. Een klantportaal liever niet.
| Workflow | Risico bij limiet | Logische maatregel |
|---|---|---|
| Content research | Laag tot middel | Retry of batch later draaien. |
| Lead scoring | Middel tot hoog | Fallbackmodel en statusmelding. |
| Klantportaal antwoord | Hoog | Strakke guardrails, fallback en mens-route. |
| Interne samenvatting | Laag | Wachtrij is vaak genoeg. |
Een praktische fout die ik vaak zie: teams bouwen eerst de prompt en pas daarna het proces. Dan werkt de demo prima, maar niemand weet wat er gebeurt als de provider een limiet teruggeeft, de output leeg is of de kosten ineens oplopen. Dat is geen detail voor later. Dat is onderdeel van het ontwerp.
Zeker bij B2B-marketing en klantprocessen moet je onderscheid maken tussen taken die mogen wachten en taken die direct moeten doorlopen. Een interne samenvatting kan best een uur later klaar zijn. Een lead die net een aanvraag doet, wil geen workflow die stilvalt omdat een gratis laag vandaag anders reageert dan gisteren.
Daarom hoort modelselectie thuis in dezelfde discussie als CRM, Consent Mode, data-opslag en automation. Niet omdat alles zwaar en corporate moet worden, maar omdat je anders losse AI-trucjes stapelt zonder te weten welke schakel de klantreis draagt.
De nuchtere route is klein beginnen. Eén workflow, één meetpunt, één fallback. Als dat staat, schaal je door. Niet andersom. Want “we gebruiken AI” klinkt aardig, maar “we weten wat er gebeurt als AI niet reageert” is pas volwassen.
Maandag starten: één AI-risk kaart
Maak geen groot AI-governance-document voordat je weet waar het pijn doet. Pak je drie belangrijkste AI-workflows en zet ze in één tabel. Wat doet de workflow? Welke provider gebruikt hij? Wat gebeurt er bij rate limit? Wie merkt het als eerste?
- Kies drie AI-workflows die echt gebruikt worden.
- Noteer provider, model, kosten en limieten.
- Test bewust een foutpad of fallback.
- Leg vast welke data naar welke provider gaat.
- Beslis welke workflow een tweede model nodig heeft.
Dat is geen sexy werk. Maar wel het verschil tussen “we doen iets met AI” en een systeem dat blijft werken als de gratis laag, quota of prijs verandert. Kijk verder dan je neus lang is….
Maak die keuze ook zichtbaar voor de mensen die met de workflow werken. Sales hoeft geen modelkaart te lezen, maar moet wel weten wanneer een AI-score vertraagd is. Marketing hoeft niet alle quota te kennen, maar moet wel snappen waarom een batch later draait. Techniek hoeft niet elke campagne te begrijpen, maar moet wel de impact van een foutpad kennen. Dat is de laag waar AI volwassen wordt: niet in de prompt, maar in de overdracht tussen teams.
Een goede AI-stack heeft daarom drie simpele afspraken. Eén: wat is de normale route? Twee: wat is de fallback-route? Drie: wie krijgt een melding als beide routes niet voldoen? Als je die drie antwoorden niet hebt, ben je nog niet klaar voor schaal. Dan heb je een slimme functie, maar nog geen betrouwbaar proces.
