Kosten-batenanalyse maken voor een AI-project

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 7 augustus 2026

De introductie van Large Language Models (LLM’s) en generatieve AI-toepassingen binnen de bedrijfsvoering van het midden- en kleinbedrijf (MKB) wordt vaak gedreven door technologisch enthousiasme of de vrees om achter te blijven. Wanneer een AI-initiatief echter de fase van verkennende gesprekken voorbij is, heeft de directie of het bestuur een zakelijke onderbouwing nodig. Die onderbouwing is de kosten-batenanalyse (KBA).

Een kosten-batenanalyse voor een AI-project is geen marketingdocument of een inveloefening om een vooraf gekozen oplossing goed te praten. Het is een formeel besluitstuk dat structureel inzicht biedt in de investeringen, de verwachte rendementen en de risico's over de gehele levenscyclus van de software. Omdat AI-systemen afwijken van traditionele software — onder meer door stochastisch gedrag, variabele verwerkingskosten en continue modelontwikkeling — vereist een KBA voor AI een specifieke aanpak. Deze handleiding beschrijft stap voor stap hoe u een solide kosten-batenanalyse als besluitstuk opbouwt.

1. Het fundament: Vergelijk altijd drie alternatieven

Een van de meest gemaakte fouten bij de onderbouwing van een AI-investering is het maken van een binair vergelijk: de voorgestelde AI-oplossing afzetten tegen de huidige situatie alsof die voor altijd ongewijzigd blijft. Een professionele KBA stelt daarom verplicht drie volwaardige alternatieven naast elkaar op:

1. Alternatief 0: Niets doen (Status Quo & Autonome ontwikkeling)
   Dit is de werkelijke referentie. "Niets doen" betekent niet dat de kosten nul zijn. Het omvat de voortzetting van het huidige proces, inclusief verwachte stijgingen van loonkosten, frictie in de schaalbaarheid en het risico van marktverlies als concurrenten efficiënter worden. Het vormt de de baseline waartegen alle investeringen worden afgemeten.
2. Alternatief 1: Procesoptimalisatie zonder AI (Low-tech / Regelgebaseerd)
   Voordat u investeert in complexe taalmodellen, moet u analyseren hoeveel winst er te behalen valt met traditionele middelen. Denk aan het herontwerpen van de werkstroom, betere formulieren, standaardiseerbare sjablonen of regelgebaseerde automatisering (RPA of klassieke API-koppelingen). Vaak blijkt dat 40% tot 60% van het probleem opgelost kan worden zonder AI, tegen een fractie van de onderhoudskosten. Alternatief 1 voorkomt dat u AI-budget gebruikt voor het oplossen van gebrekkige procesinrichting.
3. Alternatief 2: Het AI-integratievoorstel
   De voorgestelde oplossing waarin LLM's, agentic workflows of geautomatiseerde verwerking centraal staan. Dit alternatief wordt afgemeten aan zowel Alternatief 0 als Alternatief 1. Pas als Alternatief 2 aantoonbaar meer nettowaarde levert dan Alternatief 1, is het AI-component gerechtvaardigd.

Voor een correcte afweging tussen zelf bouwen, een bestaand pakket afnemen of een hybride vorm kiezen, zie de verdiepende analyse over bouwen of kopen van AI-functionaliteit.

2. Scope en tijdshorizon afbakenen

Een kosten-batenanalyse valt of staat met heldere grenzen. Wanneer de scope te breed wordt getrokken, worden indirecte baten vervuild met onbewijsbare veronderstellingen. Wordt de scope te nauw gekozen, dan worden essentiële randvoorwaarden zoals datacleaning of licenties over het hoofd gezien. Raadpleeg voor de exacte afkadering van uw initiatief de richtlijnen voor AI-project scoping.

Het hanteren van één universele tijdshorizon

Kies voor alle drie de alternatieven exact dezelfde tijdshorizon. Voor MKB-softwareprojecten is een periode van 36 maanden (3 jaar) de standaard. Een kortere horizon (bijvoorbeeld 12 maanden) doet geen recht aan de eenmalige opstartkosten. Een langere horizon (zoals 5 jaar) is bij AI-technologie onbetrouwbaar vanwege de hoge innovatiesnelheid, dalende API-tarieven en veranderende wetgeving.

Zorg ervoor dat de gekozen horizon rekening houdt met het afschrijvingsmodel van uw organisatie en dat alle kasstromen worden ingedeeld per kwartaal of per jaar.

3. De kostenkant: Van eenmalige investering tot verborgen exploitatie

De totale eigendomskosten (Total Cost of Ownership of TCO) van AI-systemen zijn complexer dan die van klassieke SaaS-pakketten. Waar traditionele software primair bestaat uit vaste licentiekosten, kent AI een mengvorm van vaste infrastructuur, variabele consumptiekosten en doorlopende menselijke supervisie.

Eenmalige kosten (CAPEX / Opstart)

• Onderzoek en Proof of Concept (PoC): De uren en middelen die zijn gebruikt om de technische haalbaarheid te valideren.
• Data-infrastructuur en opschoning: Het verzamelen, anonimiseren, labelen en structureren van interne documenten of databases. Dit beslaat in de praktijk vaak 30% tot 50% van het initiële budget.
• Systeemintegratie en software-engineering: De bouw van API-koppelingen, middleware, vector-databases, backend-logica en de gebruikersinterface.
• Inkoop en licentie-inrichting: Juridische toetsing, privacy-impactassessments (PIA/DPIA) en het afsluiten van enterprise-overeenkomsten.
• Verandermanagement en opleiding: Het trainen van medewerkers, het schrijven van werkwijzen en het begeleiden van de organisatorische transitie.

Terugkerende operationele kosten (OPEX)

• Verwerkings- en infrastructuurkosten: Variabele kosten voor tokenverbruik bij externe API's of de huur van dedicated GPU-capaciteit. Voor een gedetailleerde vergelijking tussen open-source hosting en closed-source API's verwijzen we naar het overzicht over TCO van open versus closed source modellen.
• Database- en zoekinfrastructuur: Hostingkosten voor vector-databases (bijvoorbeeld Pinecone, Qdrant ofpgvector), opslag van embeddings en traditionele cloudinfrastructuur.
• Toezicht en menselijke controle (Human-in-the-Loop): AI-systemen in zakelijke omgevingen vereisen steekproefsgewijze of volledige controle door gekwalificeerde medewerkers om hallucinaties en fouten op te vangen. Deze arbeidstijd moet direct als operationele kostenpost worden opgevoerd.
• Onderhoud, prompt-herijking en evaluaties: Wanneer modelleveranciers een LLM updaten of deprecaten, moeten prompts, embeddings en evaluatiesets (evals) opnieuw worden afgesteld en getest. Dit vereist structurele ontwikkeltijd.

Om deze terugkerende IT-uitgaven gedurende de beheerfase beheersbaar te houden, is het raadzaam om de principes van het monitoren van API-kosten op te nemen in het besluitstuk.

4. De batenkant: Harde, zachte en niet-kwantificeerbare effecten

Baten mogen in een KBA nooit worden opgevoerd als vage beloftes. Elk voordeel moet worden gecategoriseerd en onderbouwd volgens een helder mechanisme.

Harde baten (Direct kwantificeerbaar in euro's)

Harde baten zijn directe, aantoonbare financiële meevallers. De belangrijkste regel hierbij is: bespaarde tijd is pas geld als die tijd ook daadwerkelijk anders wordt besteed of leidt tot een reductie in loonkosten.

Als een AI-toepassing een medewerker 30 minuten per dag bespaart, maar die tijd wordt opgevuld met informeel overleg, is de financiële baat nul. Pas wanneer de bespaarde tijd aantoonbaar leidt tot minder overwerk, het niet hoeven invullen van een vacature (FTI-reductie) of een directe stijging van het declarabele volume, mag dit als harde baat worden meegeteld.

Zachte baten (Indirect kwantificeerbaar)

Zachte baten betreffen prestatie-indicatoren die indirect een financiële waarde vertegenwoordigen:

• Verkorting van de doorlooptijd: Een snellere offerteverwerking verhoogt de conversie. Onderbouw dit met historische conversiecijfers.
• Kwaliteitsverbetering en reductie van fouten: Minder menselijke fouten in gegevensverwerking leidt tot minder herstelwerk en lagere claim- of compensatiekosten.
• Capaciteitsvergroting: Het verwerken van meer transacties of klantaanvragen zonder dat het personeelsbestand evenredig hoeft te groeien.

Niet-kwantificeerbare baten (Kwalitatief)

Sommige effecten zijn strategisch waardevol, maar laten zich niet betrouwbaar uitdrukken in getallen. Denk aan een hogere medewerkerstevredenheid door het verdwijnen van repetitief werk, of het opbouwen van interne kennis over AI-integratie. Vermeld deze punten expliciet in een afzonderlijke kwalitatieve paragraaf in het besluitstuk, maar neem ze niet op in de netto contante waarde (NCW) of de financiële eindberekening.

Voor een gedetailleerde uitwerking van de rekenmethodieken rondom deze voordelen verwijzen we naar de gids over de ROI van AI-projecten berekenen.

5. Omgaan met onzekerheid: Bandbreedtes en gevoeligheidsanalyse

Het bepalen van kosten en baten bij AI-projecten kent een hogere mate van onzekerheid dan traditionele IT-investeringen. Het is daarom onverantwoord om in de KBA te rekenen met enkele puntschattingen (bijvoorbeeld "dit project levert precies € 45.000 op").

Werken met drie scenario's

Stel voor elk alternatief drie scenario's op:

1. Pessimistisch scenario (Conservative): Hoge integratiekosten, lage adoptiegraad onder medewerkers (bijv. 40%), hoge API-kosten en noodzaak voor intensive menselijke controle.
2. Realistisch scenario (Base Case): Verwachte doorlooptijden, gemiddelde adoptie (bijv. 70%), normale API-tarieven en geplande controles.
3. Optimistisch scenario (Best Case): Snelle adoptie (90%+), hoge kwaliteitswinst en verdere daling van de modelkosten.

Gevoeligheidsanalyse (Sensitivity Analysis)

Identificeer de twee of drie variabelen die de financiële uitkomst het sterkst beïnvloeden. In AI-projecten zijn dit vrijwel altijd:

• De daadwerkelijke tijdswinst per transactie.
• Het percentage output dat menselijke correctie vereist (error rate).
• De adoptiegraad van de eindgebruikers.

Demonstreer in het besluitstuk wat er met het rendement gebeurt als de tijdbesparing 50% lager uitvalt dan gehoopt, of als de toezichtkosten verdubbelen. Dit geeft de directie inzicht in het veiligheidsmarge van het project.

6. Fictief rekenvoorbeeld: KBA-structuur voor een MKB-organisatie

Om de opbouw van een kosten-batenanalyse inzichtelijk te maken, toont de onderstaande tabel een fictief rekenvoorbeeld voor een middelgrote dienstverlener (50 medewerkers) die de verwerking van inkomende klantaanvragen wil automatiseren. De horizon is vastgesteld op 36 maanden.

Let op: Alle onderstaande bedragen en uren zijn expliciet fictief en dienen uitsluitend als illustratie van de tabelstructuur in de KBA.

In dit fictieve voorbeeld levert Alternatief 1 (procesoptimalisatie zonder AI) al een besparing van € 28.000 op tegen een lage initiële investering. Alternatief 2 (het AI-project) vergt een aanzienlijk hogere opstartinvestering (€ 45.000), maar levert over 36 maanden een netto voordeel op van € 57.000 ten opzichte van niets doen, en € 29.000 ten opzichte van Alternatief 1. Het besluitstuk moet nu aantonen of het extra risico van Alternatief 2 opweegt tegen deze € 29.000 meeropbrengst.

7. Waarom de terugverdientijd bij AI misleidend kan zijn

In klassieke IT-businesscases is de terugverdientijd (payback period) een populaire metriek: "binnen hoeveel maanden is de investering terugverdiend?". Bij AI-projecten kan het sturen op enkel deze metriek tot verkeerde beslissingen leiden.

De oorzaak hiervan is tweeledig:

1. Prijs- en kwaliteitsverschuivingen: De kosten voor modelaanroepen (API-tokens) zijn historisch gezien snel gedaald, terwijl de prestaties per model toenemen. Een berekening die gebaseerd is op de tarieven van vandaag kan over 18 maanden een gunstiger beeld laten zien.
2. Structurele onderhoudsdruk: Anders dan bij traditionele software, waar een pakket na oplevering jarenlang zonder grote aanpassingen kan draaien, vereisen AI-systemen continue aandacht. Modellen worden door leveranciers uitgewisseld, prompts verliezen hun werking bij updates en invoerdata verandert. Hierdoor zakt de operationele kostencurve niet naar nul, maar blijft er sprake van een structurele ondergrens aan beheeruitgaven.

Gebruik de terugverdientijd daarom hooguit als secundaire indicator en vertrouw primair op de Netto Contante Waarde (NCW) met een adequate verdisconteringsvoet.

8. Wanneer stop je met rekenen? De stap naar een proefproject

Het maken van een kosten-batenanalyse heeft grenzen. Wanneer de aannames over tijdswinst, foutenpercentages en de benodigde hoeveelheid menselijke controle te ver uit elkaar liggen, heeft het geen zin om wekenlang door te rekenen aan theoretische modellen. De onzekerheid in de KBA is op dat moment te groot om een investeringsbesluit op te baseren.

In die situatie is de juiste conclusie van de KBA niet "ja" of "nee", maar het voorstellen van een gefaseerd besluit:

• Keur het hoofdbudget nog niet goed.
• Stel een beperkt budget beschikbaar voor een afgebakende proef.

Een gerichte proefperiode heeft als enig doel om de 2 tot 3 meest kritieke aannames uit de KBA in de praktijk te valideren. Hoe u zo'n overzichtelijke testfase opzet, leest u in het draaiboek voor een AI-pilot in 30 dagen. Na het afronden van de pilot worden de gemeten gegevens ingevuld in de KBA, waarna een definitief besluit over de volledige uitrol kan worden genomen.

9. Veelgemaakte fouten in de KBA-praktijk

Bij het beoordelen van kosten-batenanalyses voor AI-projecten komen accountants en directieleden regelmatig dezelfde structurele tekortkomingen tegen. Zorg dat uw besluitstuk de volgende vier valkuilen vermijdt:

Fout 1: Baten dubbeltellen

Het opvoeren van tijdsbesparing én extra omzet als losse posten, terwijl ze voortkomen uit dezelfde capaciteit. Als een adviseur dankzij AI minder tijd kwijt is aan administratie, kunt u de bespaarde salarisuren rekenen óf de extra declarabele uren die hij in die tijd maakt, maar nooit allebei tegelijk.

Fout 2: Pilotkosten verwarren met structurele kosten

Veronderstellen dat de kosten uit de pilotfase representatief zijn voor de productiefase. Een pilot maakt vaak gebruik van dure, generieke API-modellen en handmatige overzichten. In productie kunnen de kosten per transactie lager liggen door optimalisatie, maar staan daar hogere kosten voor beveiliging, monitoring en SLA's tegenover. Zie voor de stap naar opschaling de handleiding over de overgang van pilot naar productie.

Fout 3: Mensuren tegen het verkeerde tarief waarderen

Het waarderen van bespaarde interne uren tegen extern ingehuurde consultancy-tarieven, of het rekenen met een gemiddeld uurtarief inclusief overhead voor taken die door medewerkers in een lagere loonschaal worden uitgevoerd. Reken uitsluitend met de directe werkgeverslasten van de specifieke rol die de taak daadwerkelijk uitvoert.

Fout 4: De kosten van menselijk toezicht (Human-in-the-Loop) vergeten

Ervan uitgaan dat het AI-systeem 100% zelfstandig en foutloos opereert. In vrijwel alle B2B-processen (zoals contractanalyse, klachtafhandeling of financiële codering) blijft menselijke steekproef of eindcontrole noodzakelijk. Als de controle van een door AI gegenereerd document 5 minuten duurt, en het handmatig opstellen duurt 15 minuten, is de werkelijke winst 10 minuten per document — niet 15 minuten.

Samenvattend besluitvormingskader

Een professionele kosten-batenanalyse voor een AI-project geeft de directie helderheid door structuur te bieden in een onzekere markt. Door verplicht drie alternatieven te vergelijken, de operationele en toezichtskosten volledig mee te nemen, en te rekenen met scenario's, voorkomt u dat uw organisatie investeert in technologische experimenten zonder zakelijk rendement.

Als de uitkomst van de KBA aantoont dat Alternatief 2 (de AI-oplossing) ook in het pessimistische scenario beter presteert dan procesoptimalisatie zonder AI (Alternatief 1), beschikt u over een solide fundament voor de investeringsaanvraag. Zijn de aannames nog te zacht, gebruik de KBA dan om de randvoorwaarden voor een gecontroleerde pilot vast te stellen.