Wat kost AI in de praktijk? Waar het geld echt heen gaat

Je vraagt een offerte voor een nieuwe website en krijgt een vast bedrag terug. Je vraagt hetzelfde voor een AI-toepassing en krijgt een genuanceerder antwoord: dat hangt af van gebruik. Voor een ondernemer die gewend is aan een vaste rekening voelt dat als ontwijken. Het is geen ontwijken, het is hoe AI werkt. In deze post leggen we uit waar het geld in de praktijk naartoe gaat, zonder een bedrag te noemen dat we toch niet kunnen waarmaken.

Waarom een vast bedrag hier niet bestaat

Een licentie voor standaardsoftware koop je meestal per gebruiker of per jaar: een vast getal, ongeacht hoe druk je het systeem gebruikt. AI-modellen werken anders. Grote taalmodellen worden afgerekend per verbruikseenheid, per token, niet per abonnement. OpenAI rekent zijn API-tarieven expliciet per miljoen tokens, voor elke modelcategorie apart. Hoe meer tekst een toepassing verwerkt, hoe hoger de rekening, ook als er niets aan de configuratie verandert.

Hetzelfde patroon zie je, in een andere vorm, bij low-code platforms. OutSystems bepaalt de licentiekosten onder meer aan de hand van de schaal en complexiteit van de apps die je bouwt, gemeten in het aantal schermen, databasetabellen en API-methoden, en aan het aantal gebruikers dat de app daadwerkelijk gebruikt. Dat betekent dat een proof of concept met een handvol testgebruikers en een paar schermen op een andere schaal zit dan diezelfde toepassing zodra alle medewerkers hem dagelijks gebruiken en er functionaliteit bijkomt. Een leverancier die je vooraf een hard totaalbedrag belooft voor een AI-project, belooft dus eigenlijk iets over jouw toekomstige gebruik en de omvang van de app die hij nu nog niet kan kennen.

Dat is geen reden om AI te laten liggen. Het is wel een reden om anders te budgetteren: niet in een eenmalig bedrag, maar in een kostenmodel dat meebeweegt met wat de toepassing daadwerkelijk doet.

De kosten die je vooraf niet ziet aankomen

De rekening van het model zelf is meestal niet de grootste post. Wat vaak onderschat wordt, is het werk eromheen.

Eerst is er integratiewerk. Een AI-agent die facturen leest of e-mails samenvat, moet aangesloten worden op de systemen waar die data al staat: een mailbox, een CRM, een Excel-bestand dat al jaren de waarheid is. Dat vraagt om vooraf goed in kaart brengen welke schermen, rollen en koppelingen erbij horen, en per onderdeel bepalen of het in de eerste versie meegaat. Sla je die stap over, dan ontdek je halverwege de bouw dat er een koppeling ontbreekt die alsnog gebouwd moet worden, met alle vertraging van dien.

Daarna is er testwerk, en dat kost meer tijd dan bij traditionele software. Een AI-toepassing die soms een verkeerd antwoord geeft, faalt niet met een foutmelding maar met een plausibel klinkend maar fout resultaat. Daarom is het verstandig het onderdeel met het meeste risico als eerste apart te bewijzen, voordat je de rest bouwt. Dat kost tijd vooraf, maar voorkomt dat een tegenvaller pas in de laatste week voor livegang naar boven komt, wanneer bijsturen duur en stressvol is.

En dan is er mens in de lus: iemand die de output controleert voordat die het bedrijf in gaat. Dat is geen tijdelijke maatregel tot het model beter wordt, het is een structurele kostenpost zolang een AI-systeem beslissingen neemt die impact hebben. We schreven eerder uitgebreider over hoe je dat controlepunt inricht in mens in de lus bij AI-automatisering. De tijd die iemand daaraan besteedt, hoort in de begroting, niet in de marge.

Onderhoud stopt niet bij livegang

Een applicatie die eenmaal werkt, is bij AI niet klaar. Modelaanbieders wijzigen prijzen en modelversies, gebruikspatronen veranderen zodra medewerkers de toepassing vertrouwen en meer gaan gebruiken, en output die vandaag goed is kan morgen anders uitvallen omdat een onderliggend model is bijgewerkt.

Wie dat wil beheersen, meet het gebruik en de kosten van AI-ondersteund werk per bouwdag of per periode, in plaats van pas bij de jaarrekening te ontdekken dat de rekening is opgelopen. Zo weet je waar tijd en geld daadwerkelijk naartoe gaan, en kun je op tijd bijsturen in plaats van achteraf verrast worden.

Het loont ook om waarschuwingen en foutmeldingen in de bouw- en testomgeving elke ronde op nul te houden in plaats van ze te laten oplopen. Een stapel genegeerde waarschuwingen maakt een nieuwe, echte fout onzichtbaar, en die fout ontdek je dan pas bij een klant of gebruiker, wat altijd duurder is dan hem vooraf oppikken. Leg daarnaast kort vast wat er aan het eind van elke werkperiode af is en wat nog open staat: dat voorkomt dat een volgende sessie tijd verliest aan opnieuw uitzoeken waar iemand gebleven was, en die uitzoektijd is ook een kostenpost, ook al staat hij nergens apart op een factuur.

Wat betekent dit voor jouw bedrijf?

Een paar concrete stappen om grip te krijgen op AI-kosten zonder een vals gevoel van zekerheid te kopen:

Vraag niet om één totaalprijs voor het hele project, vraag om een kostenmodel: wat kost een periode van bouwen, wat kost verbruik bij een realistisch gebruiksvolume, en hoe schaalt dat als het aantal gebruikers groeit.

Bewijs eerst het onderdeel met het meeste risico, klein en apart, voordat je de rest laat bouwen. Dat geeft je vroeg een realistisch beeld van wat werkt en wat extra tijd kost, in plaats van pas bij livegang.

Reken mens in de lus vanaf het begin mee als vaste post in de begroting, niet als iets dat je er later bij verzint als het misgaat.

Meet gebruik en tijd vanaf de eerste bouwdag, per component, zodat je bijstuurt op feiten in plaats van op een gevoel dat de rekening ineens hoger is dan verwacht.

Wil je weten hoe zo'n kostenmodel er voor jouw situatie uitziet, met welke stappen en welke risico's? Neem contact met ons op, dan kijken we samen waar bij jou het geld daadwerkelijk naartoe zou gaan.