AI unit economics: wat het echt kost om een AI-agent te draaien in 2026

De meeste teams bepalen de prijs van hun AI-functie voordat ze weten wat het kost om die te draaien. Dat is de verkeerde volgorde, en het is de reden dat zoveel AI-producten winstgevend lijken in een pitchdeck en in productie stilletjes geld verliezen per klant.

Dit is het stuk dat vaak wordt gemist. AI unit economics, de kosten om één eenheid AI-werk te leveren, worden niet echt bepaald door de prijslijst van je modelleverancier. Ze worden bepaald door keuzes die je engineers tijdens de bouw maken: hoeveel modelaanroepen één taak veroorzaakt, hoeveel context er bij elke aanroep opnieuw wordt meegestuurd, of herhaald werk gecacht wordt, en of er iets is dat een lus stopt die uit de hand loopt. Verander die keuzes en dezelfde functie kost 5 keer meer of 5 keer minder, zonder zichtbaar verschil voor de gebruiker.

Dit artikel is geschreven voor founders, CTO's en productverantwoordelijken die al een AI-functie live hebben of vlak voor de lancering staan, en die willen dat de draaikosten een getal zijn dat ze zelf sturen in plaats van een verrassing op de maandelijkse factuur. Twijfel je nog of je met AI aan de slag gaat, dan is dit meer detail dan je nu nodig hebt.

Je leest waar het geld werkelijk naartoe gaat in een AI-agent in productie, waarom de ene klant 5 keer meer kan kosten dan de andere op hetzelfde abonnement, de 6 bouwkeuzes die je kosten per taak bepalen, en een eenvoudige manier om dit allemaal te modelleren voordat iemand code schrijft.

‍

Belangrijkste punten

• AI unit economics zijn de kosten om één eenheid AI-werk te leveren, meestal één afgeronde taak, afgezet tegen wat je ervoor rekent.

• Tokens zijn slechts 1 van de 6 kostenposten. Retrieval, tool-aanroepen, retries, menselijke controle en infrastructuur vullen de rest in.

• Gartner verwacht dat meer dan 40% van de agentic AI-projecten voor eind 2027 wordt stopgezet, met oplopende kosten als een van de belangrijkste redenen.

• ICONIQ zet de gemiddelde brutomarge op AI-producten op 45% in 2025 en een verwachte 53% in 2026, ruim onder de 80% die volwassen SaaS-teams gewend zijn.

• Prijzen per seat verbergt de schade. Een zware gebruiker op een abonnement van 50 euro kan meer AI-kosten verbruiken dan die seat opbrengt.

• Architectuur bepaalt je kosten per taak, niet de prijslijst. Modelrouting, contextdiscipline, caching en harde plafonds hebben de grootste invloed.

• Modelleer je kosten per taak vóór de bouw en meet ze daarna per klant, zodat je verliesgevende accounts in week 1 vindt in plaats van in kwartaal 3.

‍

Wat zijn AI unit economics?

AI unit economics zijn de kosten om één eenheid AI-werk te leveren, vergeleken met de omzet die die eenheid oplevert. Voor de meeste producten is de bruikbare eenheid één afgeronde taak: een supportticket beantwoord, een factuur verwerkt, een rapport opgesteld, een lead gekwalificeerd.

Kies de eenheid die je klant zou herkennen als afgerond werk, niet een technische gebeurtenis. Kosten per API-aanroep zeggen bijna niets, want één afgeronde taak kan 3 aanroepen kosten of 40, afhankelijk van hoe de agent gebouwd is. Kosten per afgeronde taak is het getal dat een technische keuze verbindt met je winst-en-verliesrekening, en het is het getal waar een investeerder of koper uiteindelijk naar vraagt.

Klassieke SaaS had deze discipline nooit nodig. Zodra de software geschreven was, kostte de 10.000e gebruiker vrijwel niets extra, dus brutomarges van boven de 80% waren normaal en prijsstelling was puur strategie. AI heeft die aanname weggenomen. Elke aanvraag heeft nu echte marginale kosten, dus de vorm van je product bepaalt je marge, en die vorm wordt tijdens de bouw vastgelegd en niet in een prijsoverleg.

‍

Waarom de draaikosten, en niet de bouwkosten, bepalen of je AI-functie overleeft

De bouwkosten zijn een eenmalig getal dat je kunt plannen, afbakenen en financieren. Die kant behandelden we in onze gids over wat het kost om een AI-agent te bouwen in 2026. De draaikosten gedragen zich anders. Ze groeien mee met adoptie en komen elke maand terug, of de functie nu klanten oplevert of niet.

Gartner verwacht dat meer dan 40% van de agentic AI-projecten voor eind 2027 wordt stopgezet, en noemt oplopende kosten als voornaamste reden, naast onduidelijke businesswaarde en zwakke risicobeheersing, in de voorspelling over agentic AI van juni 2025. Die annuleringen komen zelden doordat een model stopte met werken. Ze komen doordat een financiële review ontdekt dat de functie wordt gesubsidieerd door de rest van het bedrijf.

De marktcijfers zeggen hetzelfde, maar rustiger. Het 2026 State of AI-rapport van ICONIQ zet de gemiddelde brutomarge op AI-producten op 45% in 2025 en een verwachte 53% in 2026. Dat is een echte verbetering, en het ligt nog steeds ver van de 80% waar traditionele software iedereen aan gewend heeft. De teams die dat gemiddelde omhoog trekken hebben geen betere tarieven bedongen. Zij hebben opnieuw ontworpen hoeveel werk elke aanvraag daadwerkelijk doet.

Er is een tweede reden om hier vroeg mee te beginnen. Kosten per taak zijn een ontwerpeigenschap, geen instelling. Zodra een agent live is, betekent het veranderen van hoe hij context ophaalt of hoeveel stappen hij mag zetten dat je aan het deel van het systeem komt waar je klanten op vertrouwen. Teams die wachten tot de factuur pijn doet, bouwen de functie die ze net hebben opgeleverd opnieuw.

‍

Waar het geld werkelijk naartoe gaat in een AI-agent in productie

Modelaanroepen zijn de voor de hand liggende kostenpost en de enige die in elk budget staat. De andere 5 zijn waar ramingen sneuvelen, en samen zijn ze vaak groter dan de tokens.

Context en retrieval is de stille post. Elke zoekopdracht, elke verversing van embeddings en vooral elk token dat je bij de volgende stap opnieuw meestuurt heeft een prijs. Agents die een groeiend gesprek meenemen betalen bij elke aanroep opnieuw voor dezelfde geschiedenis, dus een taak die eruitziet als 6 korte stappen kan veel meer kosten dan 6 korte prompts.

Retries verdienen aparte aandacht omdat ze onzichtbaar zijn in een specificatie en pijnlijk op een factuur. Als een stap de validatie niet haalt, probeert de agent het meestal simpelweg opnieuw. Is de oorzaak structureel, bijvoorbeeld een tool die een vorm teruggeeft die het model niet kan verwerken, dan kan de agent meerdere volledige pogingen verbranden voordat hij opgeeft. Werk dat je nooit factureert, koop je nog steeds in.

Menselijke controle is de post die finance meteen begrijpt en engineering meestal vergeet. Als iemand 2 minuten besteedt aan het controleren van elke gegenereerde output, zijn dat echte kosten per taak, en bij serieus volume overstijgen ze de tokenkosten ruimschoots. Het is ook de post die zou moeten krimpen naarmate de agent volwassener wordt, wat hem een bruikbare graadmeter maakt voor de vraag of het systeem echt beter wordt of alleen meer gebruikt.

Infrastructuur is in de meeste builds de kleinste van de 5, en het makkelijkst om helemaal te vergeten: queues, opslag, logging en de evaluatieruns die je nodig hebt om aan te tonen dat de agent na een modelupdate nog werkt. Niets daarvan is op zichzelf duur. Alles bij elkaar is het permanent.

‍

De klant die meer kost dan hij betaalt

Gemiddelden verbergen de accounts die pijn doen. In een AI-product is het verschil tussen je lichtste en zwaarste klant geen 20% en geen factor 2. Het kan een factor 10 of meer zijn, en het komt volledig op jouw kant van de factuur terecht.

Neem één abonnement van 50 euro per seat en zet er 2 klanten op. De ene start 200 AI-taken per maand. De andere start er 900, omdat iemand jouw product heeft gekoppeld aan een workflow die je nooit had voorzien. Bij 9 cent per afgeronde taak houdt de eerste klant 32 euro over voordat andere kosten meetellen. De tweede kost 81 euro om te bedienen en verandert een betalend account in verlies.

Geen van beide klanten doet iets verkeerd. Dit is simpelweg wat er gebeurt als een vaste prijs een variabele kostenpost tegenkomt. In klassieke SaaS was de zware gebruiker je beste case study, want die bewees dat het product plakte en kostte je niets extra. In een AI-product kan de zware gebruiker je slechtste account zijn, en je weet pas welke het is als je kosten per klant meet in plaats van in totaal.

Er zijn maar 3 eerlijke antwoorden op dat verschil.

• Begrens het, met verbruikslimieten of fair-use-regels in het abonnement.

• Reken het door, met credits, verbruiksstaffels of prijzen per resultaat die meebewegen met gebruik.

• Maak het goedkoop genoeg om er niet wakker van te liggen, door de taak zo te herbouwen dat die een fractie kost van wat hij vandaag kost.

De meeste teams grijpen naar de eerste 2, want dat zijn commerciële beslissingen die je in een middag neemt. De derde is het technische antwoord, en het enige dat je positie verbetert in plaats van het probleem door te schuiven naar je klant. Het is ook het antwoord waarmee je een eenvoudige prijs kunt houden terwijl een concurrent zijn creditsysteem zit uit te leggen.

‍

Werk je dit uit voor een product dat je binnenkort lanceert, dan loopt onze SaaS AI Blueprint dezelfde keuzes door in een bouwcontext, inclusief hoe je een AI-functie afbakent zodat de draaikosten voorspelbaar blijven. Hij is gratis en je leest hem in ongeveer 20 minuten.

‍

6 bouwkeuzes die je AI-kosten per taak bepalen

Elk getal in het voorbeeld hierboven volgt uit een handvol architectuurkeuzes. Zo verschilt een kostenbewuste build van de standaardbuild, keuze voor keuze.

1. Stuur werk naar het kleinste model dat het aankan

De meeste agent-workflows zijn een mix van makkelijke en moeilijke stappen. Classificatie, extractie, routering en opmaak zijn makkelijk. Oordeelsvorming, synthese en alles wat de klant direct ziet niet. Alles naar één frontier-model sturen is de duurste gewoonte in AI-productie, en meestal een overblijfsel uit het prototype waar één model de zaak simpel hield.

De oplossing is een routeringslaag die elke stap naar het goedkoopste model stuurt dat je kwaliteitsnorm haalt, en alleen opschaalt als het vertrouwen laag is of het belang hoog. Dit is ook de knop waaraan ICONIQ een groot deel van de margeverbetering in hun steekproef toeschrijft. Goed gedaan is het onzichtbaar voor gebruikers en scheelt het een fors deel van je modelkosten.

2. Stuur minder context mee, niet meer

Als antwoorden zwak zijn, is de reflex om het model meer materiaal te geven. Die reflex is duur. Hele documenten in elke prompt plakken verhoogt de kosten per aanroep en verlaagt vaak de nauwkeurigheid, omdat de nuttige zin verdwijnt tussen duizenden irrelevante zinnen.

Retrieval die de 3 relevante alinea's teruggeeft in plaats van het handboek van 30 pagina's is goedkoper en meestal tegelijk nauwkeuriger. Behandel context als een budget dat de agent verstandig moet besteden, niet als een vangnet dat je tot de rand vult.

3. Cache het werk dat je blijft herhalen

Echt gebruik is veel repetitiever dan testgebruik. Dezelfde beleidsvraag, dezelfde productopzoeking, hetzelfde document dat in één week door 4 mensen wordt samengevat. Caching op promptniveau, op retrievalniveau en op antwoordniveau haalt een flink deel weg van de aanroepen die output produceren die je al hebt.

De technische vraag is niet of je gaat cachen, maar wat je veilig mag cachen en hoe lang. Dat is een productbeslissing over actualiteit, en die maak je beter bewust dan dat je standaard alles opnieuw berekent.

4. Zet een hard plafond op elke taak

Een agent die zelf bepaalt wanneer hij stopt, besluit dat af en toe erg laat. Geef elke taak een maximum aantal stappen en een maximumbedrag, en maak het overschrijden daarvan een afgehandelde gebeurtenis in plaats van een stille overschrijding. Een plafond verandert je worst case van onbegrensd in bekend, en dat is wat het hele model voorspelbaar maakt.

5. Vervang stille retries door een escalatiebeleid

Retries zijn prima. Ongelimiteerde retries zijn een factuurprobleem dat zich voordoet als robuustheid. Stel een retrybudget per taak in, en geef de taak daarna over aan een mens of geef een eerlijke foutmelding terug. Een overdracht kost een paar minuten van iemands tijd. Een retrylus kan veel meer kosten en alsnog mislukken.

6. Meet kosten per klant vanaf dag 1

Je kunt geen getal sturen dat je één keer per maand als totaal ziet. Voorzie elke modelaanroep, tool-aanroep en retry van een label met de klant, de functie en de taak, zodat kosten per afgeronde taak en kosten per account dashboards zijn in plaats van onderzoeken. Teams die dit vroeg inrichten vinden hun 3 verliesgevende accounts in de eerste weken. Teams die dat niet doen, vinden ze tijdens een bestuursvergadering.

‍

Hoe je je AI unit economics modelleert vóór de bouw

Je hebt hier geen financiële achtergrond voor nodig. Eén spreadsheet die je in een middag bouwt brengt je dicht genoeg bij de waarheid om goede beslissingen te nemen, en ruwweg gelijk hebben vóór de lancering is meer waard dan precies gelijk hebben erna.

• Definieer de eenheid. Benoem de taak die je klant afgerond werk zou noemen en beschrijf hoe klaar eruitziet.

• Tel de stappen. Loop één taak door en noteer elke modelaanroep, retrieval en tool-aanroep die hij veroorzaakt, inclusief de faalpaden.

• Prijs de stappen. Reken met de huidige tarieven op realistische invoer- en uitvoergroottes per stap, niet op je mooiste demo.

• Tel de onzichtbare posten mee. Neem een retrymarge, verwachte minuten menselijke controle en een vast deel infrastructuur per taak op.

• Test de uitersten. Reken het model door voor een lichte gebruiker, een gemiddelde gebruiker en de zwaarste gebruiker die je je kunt voorstellen, en controleer of alle 3 nog kloppen bij je prijs.

Wat je eruit wilt halen is één getal en één zin: kosten per afgeronde taak, en wat er waar moet zijn om dat getal te laten dalen als het volume groeit. Blijven je kosten per taak vlak terwijl je opschaalt, dan heb je een dienstverleningsbedrijf met een software-interface. Dalen ze, dan heb je een softwarebedrijf, en de markt zal je daar ook naar waarderen.

Eén praktische waarschuwing. Tarieven van leveranciers veranderen vaak en meestal naar beneden, wat teams verleidt om op toekomstige kortingen te plannen. Reken met de prijzen van vandaag. Dalende prijzen horen meevaller te zijn, nooit de aanname waar je businesscase op rust.

‍

Hoe goed eruitziet in 2026

Er is geen universele benchmark, want een juridische onderzoeksagent en een agent die supportvragen afvangt doen echt verschillend werk. Toch zijn er 3 bruikbare referentiepunten.

Het eerste is richting. Marges op AI-producten stijgen, van 45% in 2025 naar een verwachte 53% in 2026 in de cijfers van ICONIQ, en die verbetering komt uit techniek en niet uit prijszetting. Zijn je kosten per taak in 6 maanden niet bewogen, dan drijf je tegen de markt in.

Het tweede is verhouding. Als vuistregel: houd je kosten per eenheid onder 30% van de omzet die dat werk ondersteunt, en behandel alles boven 50% als een ontwerpprobleem dat je oplost voordat je distributie opschaalt. Boven die grens maakt elke nieuwe klant het gat groter.

Het derde is spreiding. Gezonde AI-producten hebben een klein verschil tussen hun mediane en hun 95e percentiel aan kosten per klant. Een groot verschil betekent dat je plafonds ontbreken of dat je prijs het verbruik niet volgt, en dat uit zich in een handvol accounts die stilletjes de marge van alle anderen opeten.

‍

Hoe wij bij Codelevate naar AI-kosten per taak kijken

Als wij een AI-build afbakenen, staan kosten per taak in de specificatie, naast nauwkeurigheid en snelheid. Ze krijgen een doel voordat de eerste regel code geschreven is, want een routeringslaag ontwerpen is veel goedkoper dan er later een inbouwen in een live agent.

In de praktijk betekent dat: de eenheid van werk benoemen, in kaart brengen welke stappen een taak echt zet, bepalen welke daarvan een frontier-model nodig hebben en welke niet, vastleggen wat gecacht mag worden, en de plafonds voor stappen en bedragen vooraf instellen. We meten kosten per taak en per klant vanaf de eerste release, zodat het getal zichtbaar is terwijl het product nog klein en makkelijk aanpasbaar is. Het is dezelfde discipline die achter ons AI-ontwikkelwerk zit, waar het doel een systeem is dat bij 100 keer het volume nog betaalbaar is, niet alleen een systeem dat goed demonstreert.

Niets hiervan maakt een AI-product goedkoop. Het maakt het voorspelbaar, en dat is wat je nodig hebt om met vertrouwen te prijzen, een marge aan een bestuur te beloven en de eenvoudige prijsstelling te houden die je klanten prettiger vinden.

‍

Conclusie

AI unit economics is geen financiële oefening die je na de lancering doet. Het is een ontwerpvoorwaarde die je vóór de bouw vastlegt, en de teams die het zo aanpakken zijn de teams wier marges in 2026 stegen terwijl de rest opnieuw met hun modelleverancier onderhandelde.

Begin met één getal. Kies de eenheid van werk, reken hem van begin tot eind door inclusief retries en menselijke controle, en leg hem naast wat je rekent. Houdt het stand voor je zwaarste klant, dan heb je een bedrijf. Houdt het alleen gemiddeld stand, dan heb je een probleem dat wacht op een groeispurt om zichtbaar te worden.

Wil je een gestructureerd startpunt, dan behandelt de SaaS AI Blueprint hoe je een AI-functie afbakent en bouwt zodat de draaikosten ingebouwd zijn in plaats van ontdekt. En wil je liever je eigen cijfers doorlopen met iemand die deze systemen heeft gebouwd, plan dan een gratis gesprek met ons team en neem je kosten per taak mee, of het feit dat je die nog niet hebt.