Van AI bouwen naar AI beslissen

Een jaar geleden begon een eerste gesprek vaak met een bouwvraag. Kun je een chatbot maken? Kun je onze documenten doorzoekbaar maken? Kun je deze workflow automatiseren?

Dat werk bestaat nog, maar het is minder vaak het echte probleem. Bij een klant bleek bestaande software een bruikbaar alternatief voor maatwerk. Bij een andere opdracht lag het probleem in het gebruik van software die er al was: mensen lieten de beschikbare functies liggen, en meer bouwen zou dat niet oplossen. Sindsdien onderzoek ik eerst wat er al kan, en bepaal ik daarna wat er nog gebouwd moet worden.

Bouwen is minder schaars

ChatGPT, Claude, Copilot en verticale tools lossen meer standaardwerk op dan twee jaar geleden. Een goede prompt in een bestaand product is soms sterker dan een maatwerkapp van €15.000.

De complexiteit is verhuisd. Het bouwen kost weken. Beslissen welk probleem je aanpakt, hoe het in de bestaande workflow past, wie eigenaar wordt en hoe je meet of het werkt, is minstens de helft van het werk. Het zwaartepunt verschuift van bouwen naar kiezen.

De cijfers wijzen dezelfde kant op. In het BCG-onderzoek uit 2024 onder 1.000 bestuurders in 59 landen had 74% van de bedrijven nog geen aantoonbare waarde uit AI laten zien; 26% haalde er al waarde uit. Dat is een indeling van bedrijven en geen slagingspercentage van losse pilots. Het laat wel zien dat toegang tot tools weinig zegt over resultaat.

AI-consultancy of zelf bouwen?

Bouw zelf als het probleem, de gebruikers en de eigenaar al vastliggen en je een eigen engineer hebt die het systeem na de eerste release onderhoudt. Haal advies als je nog niet weet welk probleem het grootst is of welke pilot productie verdient. Er is een derde vorm: iemand die de keuze maakt, de eerste versie bouwt en daarna overdraagt aan je eigen team.

Een duidelijk teken dat je eerst advies nodig hebt: er draait van alles in een demo, maar niets in het dagelijks werk. Een slecht teken bij een adviseur: een rapport zonder productiepad. Wat ik in een Scan van een week doe, staat op mijn pagina over AI-consultancy. Of je iemand beter in dienst kunt nemen, beschrijf ik bij forward deployed engineer.

Wanneer laat je AI-automatisering bouwen?

Laat bouwen als het probleem, de gebruikers en de eigenaar vastliggen en geen bestaand product het werk doet. Weet je nog niet welk probleem het grootst is, of wie het systeem na de eerste release onderhoudt, dan heb je eerst een beslissing nodig.

Deze vragen maken het verschil duidelijk:

• Waar zit de meeste handmatige tijd?
• Wie gebruikt dit elke week?
• Welke data mag het systeem wel en niet zien?
• Wie onderhoudt het na de eerste release?
• Wat is na vier weken goed genoeg om te meten?

Een tool zonder die antwoorden wordt snel een demo: hij werkt in een schermopname en verdwijnt alsnog uit het werkproces.

Kijk ook naar het platform voordat je begint. Tijdens een implementatie bleek het gekozen platform niet alles te ondersteunen wat het ontwerp nodig had, en dat los je niet op met een betere prompt. Sindsdien bekijk ik vóór de kickoff vier dingen: het AI-platform, de eigen systemen, de licenties en wie er moet beslissen.

Wat komt er kijken bij een chatbot-implementatie?

Een chatbot-implementatie begint met een afspraak op papier over wat hij moet kunnen, en eindigt met een test op echte vragen. Leg vast welke vragen hij beantwoordt, met welk foutpercentage, in welk systeem, en wie dat beoordeelt. “Een werkende chatbot” is als opdracht te vaag.

In een demo vallen drie dingen niet op. De chatbot moet zijn bronnen tonen en zeggen wat hij niet weet, want voor gebruikers weegt één fout zwaarder dan 99 goede antwoorden. Hij moet getest worden op vragen uit het dagelijkse werk, en niet alleen op de testset van de bouwer. En iemand in de organisatie moet eigenaar zijn en de antwoorden bijhouden als de onderliggende documenten veranderen.

De meeste bedrijven hebben geen toolprobleem

Veel teams denken dat ze een toolprobleem hebben. Ze hebben een beslissingsprobleem. Welk probleem is groot genoeg? Welke use case is klein genoeg? Wie in de organisatie kan het dragen? Wat moet je juist niet bouwen? Die vragen komen vóór de implementatie. Ze bepalen of je over een jaar een systeem hebt dat dagelijks gebruikt wordt, of een pilot waar niemand meer eigenaar van is.

Daarom begin ik smal: één workflow met één team en één eigenaar, maximaal vier weken bouwen. Op dag vijf beslissen we samen of de case simpel genoeg is om door te bouwen. Na vier weken meten we en beslissen we of we doorzetten.

Drie vragen voor wie je ook inhuurt

Of je nu een adviseur, een bureau of een freelancer inhuurt, deze drie vragen uit mijn memo scheiden snel de goede van de gladde antwoorden:

• Heb je het materiaal gezien voordat je een prijs noemde? Hoeveel documenten, hoeveel uitzonderingen, hoeveel systemen?
• Wanneer is het eerste moment waarop we kunnen stoppen zonder gezichtsverlies? Ligt dat pas na vier weken, dan is het te laat.
• Op wiens data test je, die van jullie of die van ons? En kunnen we de test zelf draaien?

Advies zonder productiepad is te licht

Mijn werk zit tussen advies en bouw in. Ik maak een scherpe keuze en zet die door tot een systeem dat onder echte gebruikers draait. Soms betekent dat nee zeggen tegen een vraag die verkeerd gesteld is. Klopt de keuze, dan bouw ik, en ik draag over voordat het systeem afhankelijk wordt van de bouwer.

Ik bouw voor mezelf en voor opdrachtgevers. Signal Match, een van mijn eigen producten, herschrijft en anonimiseert kandidaat-cv’s. Business Boosters bouwde ik voor een opdrachtgever die eigenaar is van het product; het vindt B2B-prospects voor gerichte acquisitie. Beide draaien onder echte gebruikers en zijn gebouwd met dezelfde regels: smal starten, meten en stoppen als het niet werkt.