Welke AI-use cases
leveren écht resultaat op?

Waaraan zijn AI-use cases te herkennen die resultaat opleveren?

AI-use cases die resultaat opleveren, delen vier kenmerken: een hoog volume met weinig variatie, fouten waarvan de kosten bekend en betaalbaar zijn, een menselijke controlestap die al in het proces zit en data die al bestaat en al voor beslissingen wordt gebruikt. Technologie komt in geen van die vier kenmerken voor. Vrijwel altijd stranden de assistent die alles kan, het voorspelmodel zonder besluit erachter, de use case zonder eigenaar in de lijn en de automatisering van een proces dat beter afgeschaft kan worden.

Wat gebeurt er met AI-use cases die beginnen met het verzamelen van data?

AI-use cases die beginnen met eerst data verzamelen, schuiven minstens een jaar op. Soms is dat de juiste investering, maar dan heet het een datatraject en geen AI-use case.

Welke AI-use cases gaan bij het prioriteren niet eerst?

AI-use cases die onder de 15 punten scoren, gaan niet eerst; bij het prioriteren worden meestal vijf vragen gebruikt, elk met een score van 1 tot 5. De vijf vragen gaan over volume, variatie, datagereedheid, veiligheid en trekkracht.

Bron: artikel van Dave Willemstein. Bijgewerkt: oktober 2026.

Het patroon achter de winnaars

In use-case-sessies komt altijd hetzelfde soort ideeën boven drijven: een chatbot die alles weet, een systeem dat de markt voorspelt, een assistent die vergaderingen overbodig maakt. Ze zijn aantrekkelijk omdat ze groot klinken. Ze stranden omdat ze vaag zijn.

De use cases die het wél halen, hebben vier kenmerken gemeen. Geen van die kenmerken gaat over technologie.

1. Hoog volume, lage variatie

Een taak die duizend keer per maand op ongeveer dezelfde manier voorkomt, is een betere kandidaat dan een taak die tien keer per jaar voorkomt en telkens anders is, ook als die tweede taak duurder is per keer.

De reden is praktisch: bij hoog volume verdient een kleine verbetering zich snel terug, kun je snel meten of het werkt, en is er genoeg materiaal om het systeem te verbeteren. Bij lage frequentie duurt het een jaar voordat je weet of je iets hebt.

Een concreet voorbeeld: het samenvatten van klantgesprekken (duizenden per maand, vergelijkbare structuur) is een betere eerste use case dan het opstellen van het jaarplan, hoe waardevol dat jaarplan ook is.

2. De kosten van een fout zijn bekend en betaalbaar

Elke AI-toepassing maakt fouten. De vraag is niet of, maar wat die fout kost en wie hem opmerkt. Deze vraag wordt te vaak overgeslagen en bepaalt achteraf of de use case houdbaar is.

Drie categorieën:

• Betaalbaar en zichtbaar: een verkeerd voorgestelde samenvatting die de gebruiker direct ziet en aanpast. Ideale kandidaat.
• Betaalbaar maar onzichtbaar: een licht verkeerde voorraadvoorspelling die pas in de kwartaalcijfers opvalt. Bruikbaar, mits je monitoring inricht.
• Duur en onzichtbaar: een onterecht afgewezen kredietaanvraag. Alleen doen met een stevige controlestructuur, en zelden als eerste use case.

3. Er is al een menselijke controlestap in het proces

Dit is misschien wel het sterkste voorspellende kenmerk. Als er in het huidige proces al iemand meekijkt, controleert of accordeert, dan heb je de belangrijkste veiligheidsvoorziening al. Je verandert de rol van die persoon van uitvoerder naar controleur, en dat is een veel kleinere verandering dan het klinkt.

Omgekeerd: als een proces volautomatisch loopt zonder menselijke tussenkomst, en je wilt daar AI in zetten, dan moet je die controlestap toevoegen. Dat kost tijd, geld en draagvlak, en het maakt de businesscase kleiner dan de oorspronkelijke berekening.

4. De data bestaat al en wordt al gebruikt

Niet "de data is beschikbaar", maar "de data wordt al gebruikt om beslissingen mee te nemen". Dat verschil is groot. Data die al in gebruik is, is al opgeschoond, al gedefinieerd en al van een eigenaar voorzien. Data die ergens staat maar nergens voor gebruikt wordt, is bijna altijd van slechtere kwaliteit dan iedereen denkt.

Een use case die begint met "we moeten eerst data gaan verzamelen" schuift minstens een jaar op. Soms is dat de juiste investering, maar noem het dan een datatraject, geen AI-use case.

Vier patronen die vrijwel altijd stranden

De assistent die alles kan

"We geven iedereen een AI-assistent" is geen use case, het is een licentie. Zonder afgebakende scenario’s blijft het gebruik hangen rond de tien procent, en dan hoort de organisatie dat AI "niet werkt". Kies drie tot vijf concrete taken, maak daar kant-en-klare startpunten voor, en voeg pas later vrijheid toe.

Het voorspelmodel zonder besluit erachter

Een voorspelling die niemand omzet in een handeling, is een duur dashboard. Voordat je begint: wie kijkt naar deze voorspelling, wat doet die persoon anders bij uitkomst A dan bij uitkomst B, en heeft hij het mandaat om dat te doen? Als één van die drie antwoorden ontbreekt, stop dan.

De use case zonder eigenaar in de lijn

Als de enige enthousiasteling in het innovatieteam of het datateam zit, en er is niemand in de business die er beter van wordt, dan overleeft de use case de eerste reorganisatie niet. Zoek de persoon wiens kwartaaldoel hierdoor haalbaarder wordt. Vind je die niet, dan is het een leuk idee en geen prioriteit.

De use case die een proces automatiseert dat je zou moeten afschaffen

Dit is de pijnlijkste. Regelmatig blijkt bij de analyse dat het proces dat we willen versnellen er vooral is omdat een ander systeem slecht is ingericht. AI maakt dat proces dan goedkoper, waardoor niemand het meer afschaft. Vraag altijd eerst: waarom bestaat deze stap, en wat gebeurt er als hij verdwijnt?

Een praktische scoringsvraag

Bij het prioriteren van een lijst gebruik ik meestal vijf vragen, elk met een score van 1 tot 5:

• Hoe vaak komt deze taak voor? (volume)
• Hoe voorspelbaar is de vorm van de taak? (variatie)
• Bestaat de benodigde data al en wordt hij gebruikt? (datagereedheid)
• Is er al een controlestap of moeten we die toevoegen? (veiligheid)
• Is er een eigenaar in de lijn die er beter van wordt? (trekkracht)

Use cases die onder de 15 punten scoren, gaan niet eerst. Niet omdat ze slecht zijn, maar omdat je eerste twee use cases moeten slagen: de rest van je roadmap hangt daarvan af.