AI-infrastructuur voor digitale producten: hoe je snel opschaalt zonder alles te herbouwen

AI toevoegen aan een bestaand digitaal product is bijna altijd lastiger dan het klinkt. Niet omdat AI zelf zo complex is, maar omdat de onderliggende architectuur er niet op gebouwd was. Je botst op latency-problemen, onbeheerste API-kosten, geen logging, geen fallbacks. Het resultaat: een redesign van de infrastructuur terwijl het product al in productie staat. Dat is duur, traag en frustrerend.

Bij Livewall bouwen we digitale producten van prototype tot productieschaal. We hebben geleerd dat de slimste manier om AI te integreren niet begint met de AI zelf, maar met de vraag: hoe ziet onze architectuur eruit als dit op 10x het volume moet draaien?

Wat AI-infrastructuur eigenlijk betekent

Als mensen het over 'AI toevoegen aan een product' hebben, bedoelen ze vaak: een API-call naar een taalmodel, een gegenereerde afbeelding, een aanbevelingsblok. Maar AI-infrastructuur is meer dan dat. Het gaat over de hele keten: welk model gebruik je, waar draait de logica, hoe sla je resultaten op, hoe monitor je kwaliteit en kosten, en wat gebeurt er als een model niet beschikbaar is?

De vier kritieke vragen bij AI-infrastructuur:

1. Waar zit de AI-logica? Edge, server of client? Edge geeft lage latency maar beperkte rekenkracht. Server geeft flexibiliteit maar kost meer bij volume. Client-side werkt voor kleine modellen maar is ongeschikt voor grote language models.

2. Welke API kies je? Managed APIs zoals OpenAI of Anthropic zijn ideaal voor prototypes. Maar als je opschaalt, wil je een abstractielaag zodat je van model kunt wisselen zonder de hele codebase te herschrijven.

3. Hoe ga je om met kosten bij volume? Een API-call die 2 cent kost bij 100 gebruikers, kost 200 euro bij 10.000. Caching van veelgevraagde outputs is geen optimalisatie, het is een architecturele vereiste.

4. Wat meet je? Response-tijd, modelprestaties, kosten per gebruiker, foutratio's. Wie dit niet van dag één bijhoudt, heeft later geen basis om te sturen.

Begin small, grow large: toegepast op AI

Ons motto 'begin small, grow large' geldt ook voor AI-infrastructuur. Bij een MVP hoef je geen eigen GPU-clusters, geen model-fine-tuning, geen complexe orchestration-laag. Gebruik managed APIs, bouw een dunne abstractielaag zodat je later van provider kunt wisselen, en instrumenteer direct.

Dat instrumenteren is het deel dat teams het vaakst overslaan. Maar als je geen zicht hebt op welke prompts de meeste tokens verbruiken, welke outputs het vaakst opnieuw gegenereerd worden, of waar de latency piekt, dan heb je op het moment van opschalen geen data om op te sturen.

Bij het project voor KLM scalable growth bouwden we een AI-gedreven workflow voor campagneproductie over 50+ markten. De infrastructuur begon klein: vaste templates, managed API-calls, een thin service layer. Maar omdat we observability vanaf dag één inbouwden, konden we precies zien waar het systeem mee worstelde naarmate het volume groeide. Zo konden we gericht optimaliseren zonder de architectuur te vervangen.

De abstractielaag: je beste investering

Een van de slimste dingen die je kunt doen bij AI-infrastructuur is een provider-agnostische abstractielaag bouwen. Klinkt zwaar, is het niet. Het betekent concreet: je AI-logica communiceert niet direct met de OpenAI API, maar met een interne service die de API-calls afhandelt. Die interne service kun je later herconfigureren om een ander model, een andere provider, of een eigen fine-tuned model te gebruiken, zonder dat de rest van je product het merkt.

Dit is precies wat we deden bij InShared, een AI-gedreven visueel platform voor on-brand campagnebeelden. We bouwden de beeldgeneratielaag los van de rest van de applicatie. Toen we van model wilden wisselen voor betere kwaliteit bij lagere kosten, was dat een aanpassing in de service-laag, geen rebuild van het product.

Hetzelfde principe geldt voor Lefboom, ons duurzaamheidsbeloningsplatform met bonnetjesscan. De AI-component voor bonnetjesherkenning is geïsoleerd in een eigen service. De rest van het platform hoeft niet te weten welk model er onder zit.

Caching: niet sexy, wel essentieel

AI-outputs cachen is een van de makkelijkste manieren om kosten te drukken en latency te verbeteren. Toch is het het eerste dat teams overslaan in de prototype-fase, met als argument 'we doen het wel als het nodig is'. Maar als je caching niet vroeg inbouwt, is het later een refactor.

De aanpak die we hanteren: cache alles wat deterministisch genoeg is. Productbeschrijvingen, template-output, categorieteksten. Gebruik semantische caching voor queries die op elkaar lijken maar niet identiek zijn. En meet altijd de cache-hitratio, zodat je weet wanneer je het model echt nodig hebt.

Bij het bouwen van de Dumpert video streaming app, 150 miljoen views per maand, leerde we dat infrastructurele beslissingen vroeg in het bouwproces exponentieel groter worden. Wat bij 10.000 gebruikers een overheadkostenpost is, is bij 10 miljoen gebruikers een bedrijfsrisico. AI-infrastractuur schaalt niet anders.

Hoe Livewall dit aanpakt

Bij Livewall starten we elk AI-product met een korte infrastructuurschets: waar zit de AI-logica, hoe wordt het gecached, wat meten we, en hoe wisselen we van model als dat nodig is. Dat kost een dag, geen sprint. Maar het voorkomt dat je drie maanden later een draaiend product moet stoppen om de architectuur te herschrijven.

Voor teams die nu een rapid prototype willen bouwen raden we aan: gebruik een managed API, bouw een service-laag, instrumenteer van dag één. Niet méér dan dat. Begin klein, maar bouw zo dat je later kunt doorgroeien zonder opnieuw te beginnen.

De vraag is niet óf AI-infrastructuur complex wordt naarmate je product groeit. Dat doet het altijd. De vraag is of je er klaar voor bent.