Drie redenen waarom AI-projecten falen in commerciele organisaties.

De meeste AI-projecten in commerciele organisaties leveren minder op dan beloofd. Dat is geen pessimisme, dat is wat de cijfers laten zien. Internationaal onderzoek wijst uit dat ergens tussen de 70 en 85 procent van bedrijfs-AI-projecten niet de verwachte waarde realiseert.

Dat is een hoog faalpercentage voor een investering waar inmiddels tientallen miljarden in omgaan.

Wat opvalt in de projecten die wij langs zien komen: het zijn zelden technische faalpatronen. De technologie werkt meestal wel. Het zijn organisatorische, commerciele en strategische faalpatronen die zich herhalen. Drie ervan zien we zo vaak dat we ze als signaalpatronen zijn gaan beschouwen. Voor wie een AI-project overweegt of er al middenin zit, zijn ze het herkennen waard.

Faalpatroon 1: De pilot zonder productieperspectief

Een typische start. Het MT besluit dat er iets met AI moet. Een team krijgt opdracht om “te onderzoeken wat AI voor ons zou kunnen betekenen”. Er wordt een pilot gestart. Een tool wordt aangeschaft. Een use case wordt gekozen. Drie tot zes maanden later komt het team met een rapportage. De pilot heeft gewerkt. Er zijn een paar interessante toepassingen gevonden. Het MT knikt waarderend.

En dan gebeurt er niets.

Het probleem is dat de pilot nooit een productieperspectief had. Er is getest of iets technisch kan, maar niet hoe het in het bestaande proces past, hoe het wordt onderhouden, wie het bezit, hoe het wordt gefinancierd over meerdere jaren, en wat het in concrete commerciele cijfers oplevert. De pilot bewijst alleen wat technisch mogelijk is. Maar technisch mogelijk is niet hetzelfde als organisatorisch ingebouwd.

Daarna is er geen pad voorwaarts. Het team beweegt naar andere prioriteiten. De pilot blijft hangen als interessant experiment in een gedeelde drive. Een jaar later, wanneer iemand vraagt naar de stand van AI in het bedrijf, wordt naar deze pilot verwezen alsof het iets bestaands is. Maar er werkt niets in productie.

Dit faalpatroon is zo voorspelbaar dat het bijna een ritueel is. Het komt voort uit het verschil tussen “kunnen we dit?” (een onderzoeksvraag) en “willen we dit in onze organisatie inbouwen?” (een directiebesluit). De pilot beantwoordt alleen het eerste. Het tweede wordt overgeslagen. En zonder dat tweede besluit gebeurt er na de pilot niets.

Faalpatroon 2: De use case zonder data

Een tweede patroon, vaak in combinatie met het eerste. Er wordt een AI-use case gekozen die conceptueel aantrekkelijk is. Bijvoorbeeld: “we gaan met AI voorspellen welke klanten dreigen weg te lopen, zodat sales daar gericht op kan inspelen.” Mooi, concreet, commercieel relevant. Iedereen wordt enthousiast.

Tot het moment dat het projectteam ontdekt dat de data om dit te doen niet beschikbaar is. Klantgedrag wordt niet systematisch vastgelegd. Contactmomenten zitten in drie verschillende systemen die niet aan elkaar gekoppeld zijn. Sales registreert niet de signalen die voorspellend zouden zijn. Customer service heeft eigen logging die niet gedeeld wordt. De data die wel beschikbaar is, dekt zes maanden, terwijl het patroon dat je wil voorspellen zich pas over achttien maanden ontvouwt.

Dan zijn er twee mogelijkheden. Of het project wordt aangepast naar wat met de huidige data wel kan, wat meestal een veel minder commercieel relevante use case oplevert. Of het project gaat door op een gebrekkige dataset, wat onbetrouwbare voorspellingen oplevert.

Beide opties leiden tot teleurstelling. En het probleem dat hieraan ten grondslag ligt, is niet AI. Het is de data-discipline van de organisatie. AI versterkt wat je hebt, en blootlegt wat je niet hebt.

Wat de meeste organisaties dan ontdekken, is dat het echte voorwerk niet een AI-tool kopen is, maar de basis op orde brengen. Welke data leggen we vast, hoe gestructureerd, hoe lang bewaren we hem, hoe maken we hem toegankelijk over systemen heen. Dat is grondwerk dat eerst moet gebeuren, en het kost vaak meer tijd dan de AI-implementatie zelf. Veel teams stoppen op dat moment, omdat het te ver weg ligt van waar ze enthousiast over waren.

Faalpatroon 3: De tool zonder eigenaarschap

Het derde patroon: er wordt een AI-tool aangeschaft. De licentie wordt afgesloten. Het wordt gedemonstreerd aan het team. Mensen krijgen een training. Het wordt geintegreerd in een werkproces. En dan, langzaam over de eerste zes maanden, vervaagt het gebruik.

Niet omdat de tool slecht is. Maar omdat niemand de eigenaar is.

Een goede AI-toepassing in een commerciele organisatie heeft een eigenaar nodig. Iemand die het gebruik volgt, ziet waar het werkt en waar het wegzakt, aanpassingen doet, het up to date houdt met nieuwe versies, de output controleert op kwaliteit, en interventies pleegt als het uit de bocht loopt. Dat is een rol. Bij voorkeur een halve of hele dag per week structureel, niet “erbij” tot iemand die ergens tijd voor heeft.

In de meeste organisaties is die eigenaar er niet. De marketingmanager denkt dat IT erover gaat. IT denkt dat marketing erover gaat. De aanschaffer is na zes weken op een ander project en heeft geen tijd meer. Het team gaat het wel of niet gebruiken, afhankelijk van het humeur van de dag. Geleidelijk verdwijnt de discipline. Na een jaar betaal je nog wel voor de licentie, maar gebruikt niemand de tool actief meer. Dit eigenaarschapsprobleem raakt niet alleen tools, het raakt de hele rolverdeling in een commercieel team onder AI.

Eigenaarschap klinkt als HR-detail. Maar het is een commerciele beslissing. Wie eigenaarschap niet vooraf belegt en betaalt, koopt feitelijk een onderbenutte tool met een terugkerende kostenpost.

Wat de drie patronen gemeen hebben

Drie verschillende faalpatronen, maar ze delen iets fundamenteel.

Ze gaan alle drie niet over technologie. De technologie werkt in alle drie de gevallen prima. Ze gaan over de organisatorische verankering van de technologie. Over wie wat beslist, wat er met data gebeurt, wie de eigenaar is, hoe het in het werk wordt ingebouwd. Dat zijn directie-vragen, geen IT-vragen.

En ze worden alle drie veroorzaakt door te snel beginnen met “wat doen we” voordat duidelijk is “waarom doen we dit en hoe verankeren we het”. De pilot wordt gestart voordat er een productieperspectief is. De use case wordt gekozen voordat de data is gecontroleerd. De tool wordt aangeschaft voordat eigenaarschap is belegd.

Het is geen toeval dat dit zo vaak misgaat. Het is een gevolg van hoe de meeste organisaties AI op de agenda zetten: als iets dat snel moet, omdat anderen ermee bezig zijn, met het idee dat we kunnen leren door te doen. Dat klinkt energiek. Het werkt zelden.

Wat wel werkt

Wat we zien werken bij organisaties die wel resultaat boeken: een AI-traject dat in vier tot twaalf weken een toepassing in productie zet, met vooraf gemaakte afspraken over hoe het wordt ingebed, wie de eigenaar is, en welke data er nodig is. Klein genoeg om binnen drie maanden te leveren. Groot genoeg om commerciele impact te hebben. En na die eerste cyclus is de organisatie geleerd hoe het werkt, wat de echte tijd en aandacht kost, en wat de volgende stap moet zijn.

Dit is precies waar an AI-build voor is. Geen pilot, geen proof of concept. Een AI-toepassing in productie, ingebouwd in jullie stack, met eigenaarschap en documentatie, klaar voor opschaling. Vier tot twaalf weken. Vanaf EUR 15.000.

Maar dat is niet het belangrijkste van dit stuk. Het belangrijkste is dat je de drie faalpatronen herkent in elk AI-project dat in jouw organisatie wordt voorgesteld. Een pilot zonder productieperspectief, een use case zonder data, of een tool zonder eigenaarschap. Wie deze drie vooraf adresseert, voorkomt drie van de meest voorkomende redenen waarom AI-projecten teleurstellen.

---

Verder lezen over hoe AI fundamenteel commercieel werk kan herontwerpen in plaats van versieren? Onze uitgebreide pillar werkt het uit met drie concrete voorbeelden uit marketing, sales en customer success: AI als motor onder commerciele strategie.