Hoe beheer je AI-ontwikkelkosten per klant?
Zodra AI-agents echt ontwikkelwerk doen, ontstaat er een kostenpost met een lastige eigenschap: hij wordt veroorzaakt door losse tickets, maar komt binnen als één bedrag aan het eind van de maand, op een kaart van het bedrijf en niet van een klant. Dat verschil maakt AI-kosten onbeheersbaar in de beleving. Los de toewijzing op en de beheersing volgt vanzelf.
Vier vragen om te beantwoorden voordat je opschaalt
Bureaus die comfortabel met agents werken, hebben op alle vier een concreet antwoord. Bureaus die zich er ongemakkelijk bij voelen, kunnen de laatste twee meestal niet beantwoorden.
- Wiens rekening is het? Betaal je een leverancier een opgehoogd tarief voor inference, of betaal je je eigen aanbieder rechtstreeks?
- Welk model draait waar? Eén model voor alles is de duurst mogelijke configuratie.
- Wat is het plafond? Een limiet die het werk daadwerkelijk stopt, geen dashboard dat je achteraf bekijkt.
- Wie veroorzaakte het? Welke klant, welk project, welk ticket. Zonder dit zijn AI-kosten overhead, en overhead gaat van je marge af.
Eigen sleutel: betaal de aanbieder, niet een tussenpersoon
De standaardconstructie bij de meeste AI-tools is dat de leverancier inference inkoopt en met marge aan jou doorverkoopt. Dat is makkelijk, en het betekent dat er een derde partij zit tussen jou en een kostenpost die meegroeit met je productie.
Je eigen provideraccount koppelen verandert die verhouding: de tool regelt het proces, je aanbieder factureert je tegen zijn eigen tarieven, en niemand zet er een marge tussen. Het betekent ook dat je van model kunt wisselen als de prijzen veranderen, zonder te wachten tot een leverancier een verlaging doorgeeft. Suporta werkt zo: je kiest per agent de aanbieder en het model, op je eigen sleutel.
De goedkopere route: draaien op een developermachine
Er is een tweede uitvoeringsmodel dat de meeste teams over het hoofd zien. Je developers betalen vaak al voor een abonnement op een codeerassistent. Als tickets uit de wachtrij door de eigen machine van een developer kunnen worden opgepakt en met dat abonnement worden uitgevoerd, zijn de extra tokenkosten van een run nul, omdat je capaciteit gebruikt die je al hebt gekocht.
Het houdt het werk bovendien binnen je bestaande ontwikkelomgeving: de agent draait waar je developer werkt en pusht met jullie eigen gegevens, dus de code blijft in de Git-workflow die je al gebruikt. Suporta noemt dat lokale modus, in te stellen per organisatie met uitzonderingen per project — de details staan op de pagina voor developers.
Een model per agent, niet één model per bedrijf
De fasen in een pijplijn stellen echt verschillende eisen, en premiumtarieven betalen voor de goedkope fasen is waar de meeste vermijdbare kosten heen gaan.
| Agent | Wat hij nodig heeft | Verstandige keuze |
|---|---|---|
| Planner | Begrip van een onbekende codebase, goed oordeel | Je sterkste model. De goedkoopste plek om dure fouten te voorkomen. |
| Coder | Consistentie en instructies volgen over veel bestanden | Een capabel algemeen model, in balans met de kosten |
| Reviewer | Een diff lezen, testuitvoer interpreteren | Middenklasse. Je eigen tests doen eerst het zware werk. |
| Documentatiecontrole | Tekst vergelijken met een wijziging | Het goedkoopste model dat kan lezen. Laat hem permanent aanstaan. |
Eén structurele besparing is meer waard dan elke modelkeuze: draai je eigen testsuite vóór het reviewmodel. Een build die op linting of unittests faalt, kost niets om af te wijzen en hoort nooit bij een model aan te komen.
Een plafond dat stopt, geen rapport dat beschrijft
Alleen waarschuwingen zijn een manier om achteraf te horen dat er een probleem was. Drie maatregelen samen geven echte voorspelbaarheid:
- Een maandplafond in je eigen valuta, met een waarschuwing rond 80 procent en een harde stop op het plafond. Die harde stop is het punt.
- Een schakelaar per agent. Is de optionele testagent deze maand de dure, zet die fase dan uit zonder de hele pijplijn op te geven.
- Selectief automatisch starten. Zet automatische runs alleen aan op de projecten waar je ze wilt, en uitsluitend voor echt nieuwe tickets, zodat niemand per ongeluk een vloot agents op een backlog van twee jaar loslaat.
Werk dat op een developermachine draait, verbruikt het budget niet, want het kost niets aan tokens. Die asymmetrie is nuttig: ze maakt de goedkope route ook de voor de hand liggende.
Toewijzing: de stap die kosten in een factuurregel verandert
Hier houden AI-kosten op eng te zijn. Worden tokenkosten per fase gemeten en op het ticket geboekt, dan rollen ze net als uren op: ticket naar project naar klant. Vanaf dat moment kun je de vraag beantwoorden die ertoe doet — wat heeft deze klant ons deze maand gekost, in mensen en in machines — en kun je er een opslag op zetten als je contracten dat toelaten.
De discipline is dezelfde als bij declarabele uren: de kosten worden vastgelegd waar het werk gebeurde, zodat niemand ze later hoeft te reconstrueren. Een ticket dat twee ontwikkeluren en een klein bedrag aan modelkosten kostte, hoort je beide getallen naast elkaar te tonen.
Hoe je het doorbelast, en hoe je erover praat
Er zijn drie verdedigbare posities, en de enige onverdedigbare is een kostenpost doorberekenen die de klant niet kan zien en niet heeft afgesproken.
| Model | Hoe het werkt | Past wanneer |
|---|---|---|
| Opgenomen in het tarief | AI is bedrijfskosten, het uurtarief blijft gelijk | De kosten zijn klein ten opzichte van de uren en je wilt er geen gesprek over |
| Doorbelast met opslag | De kosten per klant komen als regel op de factuur, met jouw marge | De kosten zijn substantieel en je contract staat kostenposten toe |
| Verwerkt in de schatting | Tickets met agenthulp worden gewoon in punten geschat | Werk voor een vaste prijs, waarbij de klant een resultaat koopt |
Wat je ook kiest, zorg dat je het getal kunt laten zien. Een klant die vraagt "wat kostte de AI vorige maand op ons project" en een precies antwoord krijgt, is gerustgesteld. Een klant die hoort "dat splitsen we niet uit", trekt zijn eigen conclusies.
Checklist kostenbeheersing AI
- check_circleJe betaalt je aanbieder rechtstreeks, of draait op een developerabonnement, in plaats van doorverkochte inference te kopen
- check_circleElke agent heeft een model dat bij zijn taak past, niet één model voor alles
- check_circleJe eigen tests en linting draaien voordat er een reviewmodel wordt aangeroepen
- check_circleEr is een maandplafond, met een waarschuwing ervoor en een harde stop erop
- check_circleAutomatisch starten staat per project aan, en alleen voor nieuwe tickets
- check_circleKosten worden per fase geboekt en rollen op naar ticket, project en klant
- check_circleLokale runs melden hun verbruik eerlijk, inclusief wanneer het een schatting is
- check_circleJe hebt schriftelijk vastgelegd hoe AI-kosten terugkomen in wat je factureert
Gerelateerde artikelen
Alle artikelen arrow_forward
AI coding agents voor softwareteams: waar menselijke controle nodig blijft
De nuttige vraag is niet of een agent de wijziging kan schrijven. De vraag is wie verantwoordelijk is als het misgaat, en wat het proces daaraan doet.
Urenregistratie per klant voor softwarebureaus: zo houd je grip op facturatie
Urenregistratie mislukt om een saaie reden: het gebeurt ergens anders dan het werk. Haal die afstand weg en het nauwkeurigheidsprobleem lost zichzelf grotendeels op.
De complete workflow voor softwarebureaus: ticket, sprint, development, testing en facturatie
Tien fasen, en de waarde zit in de koppelingen en niet in de fasen. Dit is het naslagwerk dat we zelf gebruiken, inclusief wat er bij elke overdracht misgaat en hoe je dat merkt.