De demo was overtuigend. Het systeem las een stapel offertes, haalde de bedragen eruit en zette ze netjes in een overzicht. Het MT knikte en het project kreeg groen licht. Een half jaar later draait het nog steeds bijna. Elke week is er een uitzondering die het systeem niet kent. Een medewerker controleert alles toch nog met de hand. Niemand durft te zeggen dat het af is.

Dat beeld zal u bekend voorkomen. Een AI-project haalt snel 80% en blijft daar dan hangen.

Kijk nog eens naar die week. De medewerker die alles nakijkt. De uitzondering die steeds terugkomt. De vraag wanneer het af is, die niemand kan beantwoorden. Geen van drieën is een technisch probleem. Een beter model of een andere leverancier lost ze dus ook niet op.

Een AI-project blijft meestal steken op vier dingen buiten de techniek.

1. Het proces staat niet op papier.
2. Niemand legde vooraf vast wanneer het klaar is.
3. Niemand las de echte uitkomsten.
4. En het systeem meldt meer dan er gebeurde.

Het bouwen zelf werd juist beter.

Programmeur Simon Willison noemt november 2025 het omslagpunt. AI-programmeerhulpen gingen toen van vaak werkend naar meestal werkend. Onderzoekers Arvind Narayanan en Sayash Kapoor zien de knelpunten nu elders. Bepalen wat u laat bouwen. Controleren of het klopt. En kennis van het bedrijf en zijn omgeving.

Dat laatste stuk is managementwerk. Hieronder de vier oorzaken, elk met een vraag die u morgen kunt stellen.

Oorzaak 1: het proces bestaat alleen in hoofden

Neem een afdeling waar acht mensen hetzelfde werk doen. Ieder doet het net iets anders. De een belt eerst, de ander mailt. De een keurt een afwijking goed, de ander legt hem bij de teamleider neer. Niemand vindt dat een probleem, want het werk komt af.

Voor een AI-systeem is dat wel een probleem. Het moet één manier leren. Welke is de goede? Daar komt bij dat u zonder vaste manier ook niet kunt controleren of het systeem het goed doet. Goed vergeleken met wie?

Het Amerikaanse AI-adviesbureau Tenex zei het onlangs in de podcast Latent Space. Een proces dat niet bestaat, kunt u niet automatiseren. Hun advies is eerst het proces vast te leggen en pas daarna het werk aan een AI-systeem te geven.

Het lastigste deel zit in de uitzonderingen. Die regelt nu iemand op gevoel en ervaring. Dat staat nergens, dus het systeem kent het niet. Precies daar ontstaat de wekelijkse uitzondering uit de opening.

Vraag 1: kan iemand dit proces in vijf stappen opschrijven, inclusief wie de uitzonderingen beslist?

Oorzaak 2: niemand schreef vooraf op wanneer het klaar is

Een demo laat zien wat een systeem kan. Hij laat niet zien wat het moet kunnen voordat u erop vertrouwt. Dat verschil wordt pas zichtbaar als het systeem in het echte werk draait.

Vaak bestaat de toets uit voorbeelden die het systeem al goed doet. Het haalt dan 100% en iedereen is tevreden. AI-adviseur Hamel Husain waarschuwt juist daarvoor. Een toets die altijd slaagt, zegt niets. De informatie zit in de gevallen die soms misgaan.

Dit overkwam mij ook. Mijn eigen werkomgeving met AI heeft een vaste proef met vragen. Een AI-beoordelaar keurt de antwoorden. Die beoordelaar haalde twee keer 20 van 20. Een mooie score, tot ik keek waartegen ik hem toetste. Dat waren alleen voorbeelden die altijd goed gaan. De lastige antwoorden uit het echte werk zaten er niet in. Die 100% zei dus vooral iets over de toets.

De oplossing is eenvoudig en wordt vaak overgeslagen. Schrijf vóór de bouw op wanneer het klaar is. Maak het toetsbaar en zet de lastige gevallen erbij. Bijvoorbeeld: van 50 offertes uit vorig jaar, inclusief de vijf rare, haalt het systeem bij 48 het juiste bedrag. De twee andere meldt het als twijfelgeval.

Vraag 2: wat moet het systeem aantoonbaar kunnen voordat u tekent dat het af is?

Oorzaak 3: niemand las de echte uitkomsten

Veel AI-projecten krijgen een dashboard. Percentage correct, aantal verwerkte documenten, tijdwinst. Husain zet "meten voordat u de uitkomsten gelezen heeft" op één in zijn lijst van zeven veelgemaakte fouten. U krijgt dan cijfers zonder richting.

Zijn werkwijze is ouderwets. Lees eerst minstens 30 echte uitkomsten zelf. Schrijf bij elke fout op wat er misging. Tel daarna welke soorten fouten het vaakst voorkomen. Pas dan weet u wat u moet meten.

Hij geeft een voorbeeld dat elke manager herkent. Een AI-assistent van een verhuurbedrijf wenste een afhakende klant een fijne dag. De klant haakte af op het budget. De automatische beoordeling vond het antwoord in orde. Een goede verkoper had andere panden voorgesteld. Dat ziet u alleen als u het gesprek leest.

Dit is werk voor iemand die het vak kent, niet voor de bouwer. De bouwer ziet of het antwoord technisch klopt. De vakman ziet of de klant er iets aan heeft.

Vraag 3: wie heeft de laatste 30 uitkomsten gelezen? Welke fouten kwamen het vaakst voor?

Oorzaak 4: het systeem meldt meer dan er gebeurde

AI-systemen formuleren stellig. Een melding "taak afgerond" of "probleem opgelost" klinkt overtuigend. Dat is precies het risico.

Het onderzoeksbureau Andon Labs laat AI-modellen in een simulatie een verkoopautomaat runnen. In een van hun verslagen beloofde het model een klant geld terug. In zijn eigen aantekeningen stond daarna dat het die betaling niet had gedaan. De klant kreeg een toezegging, het bedrijf geen terugbetaling.

Een kleinere versie kreeg ik onlangs zelf. Mijn AI-assistent meldde dat zes automatische taken geen tijdslimiet hadden. Het advies was ze allemaal een limiet te geven. Bij het nalopen van de code bleek dat ze die al hadden. Wat ontbrak, was iets anders. De melding klonk precies zo zeker als een melding die wel klopt.

Voor een manager betekent dit één regel. Een melding van het systeem is een bewering, geen bewijs. Bewijs is een meting die u zelf kunt herhalen. Leg elke "opgelost" naast de meting die het probleem eerst aantoonde.

Vraag 4: waar ziet u met eigen ogen dat het echt gebeurd is?

Terug naar het project op 80%

Pak het AI-project dat bij u blijft hangen. Leg er de vier vragen naast.

1. Kan iemand dit proces in vijf stappen opschrijven, inclusief wie de uitzonderingen beslist?
2. Wat moet het systeem aantoonbaar kunnen voordat u tekent dat het af is?
3. Wie heeft de laatste 30 uitkomsten gelezen?
4. Waar ziet u met eigen ogen dat het echt gebeurd is?

Kan uw team drie van de vier niet beantwoorden, dan ligt het probleem niet bij de techniek. Dan ligt het op tafel bij het MT.

Stefan Colin bouwt onder de naam Softwarewerkplaats maatwerksoftware, koppelingen en SEO/GEO voor het mkb.