De echte kosten van AI toevoegen aan je product: tokens, infrastructuur en onderhoud

Kopers die een AI-functie afbakenen, beginnen bijna altijd met het schatten van de API-rekening en stoppen daar, en de API-rekening is meestal het kleinste stukje van de echte kosten. Het volledige plaatje begrijpen vóór het afbakenen, niet nadat de eerste factuur binnenkomt, is wat voorkomt dat de economie van een AI-functie een verrassing wordt.

Tokenkosten zelf zijn makkelijk te onderschatten omdat ze schalen met gebruik op manieren die niet zichtbaar zijn in een prototype. Een functie die een paar euro per dag kost bij een handvol testgebruikers kan aanzienlijk meer kosten zodra het echt productievolume verwerkt, vooral als de taak lange input, opgehaalde context, of een meerstaps-redeneerketen betreft die per gebruikersactie meerdere modelaanroepen maakt in plaats van één.

Retrieval-infrastructuur, als je functie moet redeneren over je eigen data in plaats van algemene kennis, is vaak de grootste verborgen kostenpost, en het is engineeringtijd, geen API-uitgave. Een chunkingpipeline, een embedding- en vectorzoeklaag, en de logica die bepaalt wat wordt opgehaald voor een gegeven zoekopdracht bouwen en onderhouden is een echt doorlopend systeem, geen eenmalige opzetstap, en het kost meestal meer aan engineeringuren dan de modelaanroepen die het voedt.

Evaluatie en monitoring zijn doorlopende kosten die niet eindigen bij lancering. Een echte evaluatieset moet worden onderhouden naarmate nieuwe faalpatronen in productie opduiken, en productiemonitoring, het loggen van wat werd opgehaald en gegenereerd voor elke echte zoekopdracht, heeft infrastructuur en iemands doorlopende aandacht nodig. Evaluatie behandelen als een eenmalig vinkje vóór lancering in plaats van een doorlopende praktijk is hoe AI-functies na lancering stilzwijgend verslechteren zonder dat iemand het merkt tot een klant klaagt.

Prompt- en modelonderhoud is een kostenpost waar kopers vrijwel nooit budget voor reserveren. Prompts die goed werkten tegen één modelversie kunnen zich anders gedragen na een modelupgrade, en providers werken hun modellen bij op hun eigen schema, niet op het jouwe. Tijd budgetteren om prompts opnieuw te valideren en aan te passen aan modelwijzigingen, doorlopend, maakt deel uit van de echte kosten van het draaien van een AI-functie in productie, geen eenmalige bouwkost.

Human-in-the-loop terugval heeft ook echte, vaak onderschatte kosten. Als je functie gevallen met lage betrouwbaarheid doorstuurt naar een mens, en dat zou het moeten doen voor alles wat klantgericht is, is de tijd van die persoon onderdeel van de operationele kosten van het systeem, geen gratis vangnet. Een functie afbakenen zonder rekening te houden met terugvalvolume levert doorgaans een supportteam op dat verrast is door hoeveel van de "geautomatiseerde" functie toch op hun bord belandt.

De eerste versie van een AI-functie is zelden de versie die uiteindelijk tegen volledig productieverkeer draait, en budgetteren alsof dat wel zo is, is een veelvoorkomende planningsfout. Tussen prototype en een versie betrouwbaar genoeg voor echt gebruik zit meestal minstens nog één betekenisvolle iteratie, op prompts, op retrieval, op terugvaldrempels, gestuurd door wat de evaluatieset en vroege productiedata daadwerkelijk laten zien. Die iteratie is echt afgebakend werk, geen buffer.

Niets hiervan is een argument tegen het bouwen van AI-functies, het is een argument om ze af te bakenen met het volledige kostenplaatje in plaats van alleen de tokenprijs. Een nauw afgebakende, goed doordachte functie met een realistisch budget voor retrieval-infrastructuur, evaluatie en doorlopend onderhoud is een solide investering. Dezelfde functie afgebakend op alleen een geschatte API-rekening is degene die drie maanden later over budget terugkomt.