Aan het einde van het eerste kwartaal stelt het management de vraag: "Wat heeft AI ons opgeleverd?" De ingenieur die de pilot leidde begint door zijn aantekeningen te bladeren. Inhoud werd sneller gegenereerd. Agents namen een deel van de e-mails over. Rapporten gaan eerder de deur uit. Maar een concreet getal — hoeveel uren, hoeveel euro, wat is het verschil met vroeger — ontbreekt. Niet omdat het project mislukt is. Maar omdat niemand vóór de start heeft gemeten hoe het er daarvoor uitzag.
Deze situatie is in de praktijk vaker het geval dan zou moeten. De meeste bronnen stellen dat 75–95 % van de AI-projecten de geplande bedrijfswaarde niet haalt. Een van de belangrijkste oorzaken is niet de kwaliteit van de technologie, maar het ontbreken van een meetbaar raamwerk: geen baseline, geen vooraf afgesproken metrics, en op het moment van evaluatie vergelijken we iets met niets. Dit artikel beschrijft hoe u het goed aanpakt — van het definiëren van de baseline via de werkelijke kostenposten tot de beslissing wanneer een project werkelijk zinvol is.
Waarom de baseline de belangrijkste stap is
Vóór elke AI-implementatie bestaat er een situatie die u wilt verbeteren. Die situatie — de baseline — is de referentiewaarde waartegen u elke verbetering afmeet. Zonder haar heeft u geen ROI. U heeft alleen een verhaal.
De baseline moet het volgende vastleggen:
- Tijd — hoeveel uur per week besteedt een specifiek team aan een bepaalde taak (niet geschat, maar werkelijk gemeten of aantoonbaar uit een tracker)
- Foutpercentage — wat is de huidige foutmarge, het percentage herwerk of het aantal escalaties
- Kosten — loonkosten voor die werkzaamheden, eventueel externe kosten (outsourcing, licenties)
- Doorlooptijd — hoe lang duurt de verwerking van een verzoek van input tot output
Het probleem is dat bedrijven deze cijfers doorgaans niet paraat hebben. Tijd aan e-mails wordt niet gelogd. Foutpercentages bij de verwerking van documenten zijn nooit berekend. Het is dan ook volledig acceptabel om de baseline specifiek vóór het project te verzamelen — ook retrospectief over de afgelopen drie maanden. Essentieel is dat de baseline er is voordat de pilot van start gaat.
Voor projecten waarbij meten lastig is (bijvoorbeeld een AI-assistent voor besluitvormingsprocessen), bestaan er indirecte proxymetrics: tijd van aanvraag tot definitieve beslissing, aantal iteraties dat nodig is om een document goed te keuren, het percentage gevallen waarbij de output direct bruikbaar was zonder bewerking.
Wat tot de totale kosten behoort
Dit is waar de meeste interne business cases de realiteit vertekenen. In de presentatie verschijnen de prijs van API-tokens en misschien een softwarelicentie. De rest wordt verzwegen of uitgesteld. De werkelijke kosten van een AI-project omvatten meerdere lagen:
Ontwikkeling en integratie
- Interne ingenieurstijd of een externe leverancier voor ontwikkeling, integratie in bestaande systemen en testen
- Prototyping en experimenten die nooit in productie zijn beland (dit zijn echte projectkosten)
- Datavoorbereiding — opschoning, annotatie en structurering van invoerdata
Exploitatie — tokens en infrastructuur
Voor cloud-API-modellen zijn dit tokenkosten — bij een eenvoudige copilot kunnen die marginaal zijn, maar bij agentische oplossingen met tientallen aanroepen per dag groeien ze snel. Bij lokale implementatie zijn het hardware (GPU-server), elektriciteit en onderhoud. Een gedetailleerdere berekening hiervan vindt u in het artikel over de kosten van een AI-agent in productie.
Mensen en processen
- Change management — tijd voor training, teaminpassing en het aanpassen van workflows
- Review en toezicht — bij outputs die in productie gaan (contracten, rapporten, e-mails) moet iemand controleren. Deze tijd wordt in ROI-berekeningen stelselmatig onderschat.
- Aanpassing van systeemprompts, kwaliteitsmonitoring, afhandeling van storingen en regressies
Onderhoud en updates
Modellen veranderen, API's worden bijgewerkt en bedrijfsprocessen evolueren. Een geïmplementeerd AI-systeem is geen afgerond product — het is een levende component die regelmatig bijsturing nodig heeft. Een realistische schatting is 15–30 % van de oorspronkelijke ontwikkelkosten per jaar aan exploitatiekosten.
Het goede nieuws is dat dit overzicht juist dwingt tot scherper nadenken. We hebben projecten gezien waarbij, na uitsplitsing over alle posten, bleek dat een copilot voor één operator efficiënter was dan een uitgebreid multi-agentsysteem — omdat de totale kosten een veelvoud lager lagen bij een vergelijkbare meetbare baat.
Hoe u baten berekent — kwantitatief én kwalitatief
Wanneer u de baseline én de kosten heeft, volgt de andere kant van de vergelijking: de meetbare baten.
Directe besparingen
De eenvoudigst te berekenen categorie:
- Bespaarde tijd × uurtarief = loonbesparing. Als een agent vier uur handmatig werk per dag vervangt bij een tarief van 25 €/uur, bedraagt de jaarlijkse besparing ~26.000 €.
- Verminderd foutpercentage — als AI-documentcontrole het foutpercentage terugbracht van 8 % naar 2 %, bereken dan de correctiekosten per fout en vermenigvuldig met het verschil.
- Verwerkingssnelheid — de kortere doorlooptijd van klantvraag tot antwoord kan worden omgezet in minder escalaties of behoud van commerciële kansen.
Indirecte baten
Deze zijn reëel, maar moeilijker te kwantificeren. Denk aan verhoogde teamcapaciteit (medewerkers doen hoogwaardigere taken in plaats van routinewerk), hogere klanttevredenheid en snellere besluitvorming. Neem deze baten op in de business case, maar druk ze niet uit als een exact getal — kwantificeer ze conservatief of benoem ze als kwalitatief.
Strategische waarde
Sommige projecten zijn puur financieel niet rendabel, maar hebben strategische waarde: minder afhankelijkheid van een specifieke leverancier, naleving van regelgeving (EU AI Act, GDPR), verbetering van de data-infrastructuur die ook voor andere projecten van waarde is. Deze baten zijn een legitiem onderdeel van de business case — bestempel ze alleen duidelijk als strategisch en niet als financieel.
Payback en ROI — realistisch interpreteren
Wanneer u de cijfers heeft, is de berekening rechtlijnig:
- ROI (%) = (Totale baten − Totale kosten) / Totale kosten × 100
- Terugverdientijd = Totale kosten / Maandelijkse baten
Waar de meeste business cases strandvast lopen, is de tijdshorizon. 84 % van de CEO's verwacht realistisch gezien dat een positieve terugverdientijd meer dan zes maanden duurt. Bij complexe use cases — niet alleen een copilot, maar een agentische workflow, RAG over bedrijfsdocumentatie, integratie met ERP — is een realistische horizon 12–24 maanden. Pilots met een payback "binnen drie maanden" zijn alleen echt bij zeer eenvoudige automatiseringen met lage implementatiekosten.
Een aantal praktische adviezen bij het werken met de cijfers:
- 1.Gebruik conservatieve schattingen voor baten en realistische (niet optimistische) schattingen voor kosten
- 2.Presenteer scenario's: best case, basisscenario, worst case — met verschillende aannames over adoptie
- 3.Onderscheid eenmalige kosten (ontwikkeling, integratie) van terugkerende kosten (tokens, onderhoud, mensen)
- 4.Vergeet de aanloopperiode niet — de eerste maanden na implementatie zijn doorgaans minder efficiënt, totdat het team gewend is aan de nieuwe werkwijze
Een gerelateerd overzicht over waarom AI-pilots mislukken laat zien dat het ontbreken van meetbare doelstellingen vóór de start een van de meest voorkomende oorzaken van mislukking is.
Wanneer een project geen business case heeft
Een eerlijk onderdeel van elk ROI-raamwerk is ook de beslissing wanneer een AI-implementatie geen zin heeft. We hebben projecten gezien waarbij die beslissing te laat werd genomen — met als resultaat een halfjaars tijdverspilling zonder enige output.
Signalen dat een project onvoldoende business case heeft:
- Te kleine schaal — als een taak het team minder dan vijf uur per week kost, bereiken de implementatie- en onderhoudskosten zelden een acceptabele terugverdientijd
- Geen data — een AI-systeem zonder kwalitatieve invoerdata produceert geen bruikbare outputs. Als de data er niet is, investeer dan eerst in data-infrastructuur
- Proces is niet gedefinieerd — AI automatiseert een proces, geen chaos. Als medewerkers de stappen niet kunnen omschrijven waarmee ze een taak handmatig uitvoeren, lost AI dat niet voor hen op
- Te veel toezicht vereist — als elke AI-output even grondig moet worden nagekeken als vóór de implementatie, is de effectieve baat vrijwel nul
Een project afwijzen op basis van een ROI-analyse is geen mislukking — het is bespaarde tijd en geld die gericht kunnen worden ingezet waar er wél een echte case is.
Zachte baten — hoe ze in een business case te presenteren
De categorie "zachte baten" wordt in presentaties gebruikt om een zwak kwantitatief verhaal te verdoezelen. Dat betekent niet dat ze niet bestaan — ze bestaan, maar ze moeten anders worden benoemd.
In plaats van "verbeterde klanttevredenheid" schrijft u: "uit een meting vóór implementatie: 62 % van de klanten beoordeelde de responstijd als te traag; na de uitrol van de copilot daalde de gemiddelde responstijd van 4,2 uur naar 47 minuten." Dat is meetbaar — ook al is het een proxymetric en geen direct financieel getal.
In plaats van "hogere teamefficiëntie" schrijft u: "het team besteedde vóór de implementatie gemiddeld 12 uur per week aan het opstellen van statusrapporten; na de implementatie 2,5 uur." Als u dit niet kunt omrekenen naar euro's, presenteer het dan als een feitelijke capaciteitsbesparing — niet als een financiële baat.
Baten die werkelijk alleen een gevoel zijn (betere teammoraal, moderner bedrijfsimago) plaatst u in de strategische sectie en kent u geen numerieke waarde toe.
ROI-tracking na implementatie — waarom dat anders is dan de business case
De business case wordt vóór het project opgesteld. ROI-tracking na implementatie is een andere discipline — en de meeste bedrijven doen dit slechts oppervlakkig.
Een productie-AI-systeem zou live monitoringmetrics moeten hebben die regelmatig worden geëvalueerd:
- Volume van verwerkte taken (en de trend)
- Acceptatierate van output zonder menselijke bewerking
- Fout- of escalatiepercentage
- Werkelijk bestede toezichttijd (versus de oorspronkelijke aanname)
Deze data dienen twee doelen: ten eerste bevestigen of weerleggen ze de aannames uit de business case; ten tweede tonen ze waar het systeem degradeert — het model veroudert, invoer verandert, er treedt drift op ten opzichte van de oorspronkelijke use case. Observability van AI-systemen is een onderwerp op zich; de basis wordt gevormd door logging van elke invoer, uitvoer en agentbeslissing.
Voor bedrijven die meerdere AI-projecten parallel overwegen, is ROI-tracking op portfolioniveau cruciaal: niet alleen welk project de hoogste ROI heeft, maar ook welke projecten teamcapaciteit opslokken zonder meetbare baat.
Veelgestelde vragen
Hoe definieer ik een baseline als we geen historische data hebben?
Verzamel data vóór de start van de pilot — zelfs 4–6 weken is voldoende voor de meeste processen. Als dat niet mogelijk is, gebruik dan gestructureerde interviews met teamleden: "Hoeveel uur per week besteedt u aan deze taak? Hoeveel gevallen behandelt u per maand?" Combineer dit met bestaande systeemlogboeken (ticketsysteem, e-mailmetadata, ERP-records). Een schatting met expliciet benoemde onzekerheid is beter dan geen baseline.
Wat is een realistische terugverdientijd voor een AI-project in een industrieel bedrijf?
Voor een eenvoudige copilot (assistent voor documentatie, e-mails, rapportage): 6–12 maanden. Voor RAG over bedrijfsdocumentatie of voorspellende analyse: 12–18 maanden. Voor een complex agentisch systeem geïntegreerd met ERP/SCADA: 18–36 maanden. De uitzondering "onder 6 maanden" geldt alleen bij lage implementatiekosten en grote schaal — bijvoorbeeld wanneer één agent honderden handmatige handelingen per dag vervangt.
Hoe neem ik de kosten van fine-tuning of RAG-infrastructuur op in de ROI?
Ja — en ze moeten apart worden vermeld van de exploitatiekosten. Fine-tuning is een eenmalige kost (datasetvoorbereiding, trainingstijd, evaluatie), maar het model moet periodiek worden bijgewerkt — plan jaarlijkse herhaling in. RAG-infrastructuur (vectordatabase, embedding-pipeline, retrieval-tuning) is een vaste kost met een lage variabele component. Beide zijn investeringen in een fundament dat meerdere use cases kan bedienen — verdeel ze over de projecten die er gebruik van maken.
Wat te doen als een pilot baat aantoonde, maar de productie-implementatie dat niet repliceert?
Dit is een veelvoorkomend scenario — de meeste pilots draaien op gecureerde invoer en gecontroleerde omstandigheden. De eerste vraag: wat is de acceptatierate van werkelijke outputs (zonder bewerking)? Als die significant is gedaald ten opzichte van de pilot, is het probleem ofwel een distributieverscuiving van de invoerdata, ofwel vertegenwoordigde de scope van de pilot de werkelijke productievariabiliteit onvoldoende. Oplossing: analyse van mislukte gevallen, uitbreiding van de trainingssteekproef of versmalling van de scope tot de subset van gevallen waar het systeem betrouwbaar functioneert.
Wanneer is het zinvol om een build-vs-buy-analyse te doen vóór de ROI-berekening?
Altijd. De ROI hangt af van of u het systeem intern bouwt, een kant-en-klare oplossing koopt, of een combinatie van beide kiest. Elke variant heeft een ander kostenprofiel en een andere terugverdientijd. De build-vs-buy-afweging wordt uitgebreider behandeld in een apart artikel over deze keuze — wij raden aan dit als voorstap te lezen vóór het afronden van welke business case dan ook.
*Werkt u aan een business case voor een AI-project en heeft u hulp nodig bij het vastleggen van metrics, de baseline of het kostenmodel — dit is precies wat wij voor industriële klanten doen voordat ze aan de ontwikkeling beginnen. Neem contact met ons op voor een vrijblijvend gesprek.*