Welke AI-functies het écht waard zijn om in je software te bouwen
Met de huidige API’s plak je zo ‘AI’ op van alles. De meeste van die toevoegingen overleven het eerste echte gebruik niet. Dit is de zeef die ik gebruik voordat ik er überhaupt een aanraad.
“Moeten we er iets met AI in doen?” is inmiddels een vraag die in bijna elk softwaregesprek langskomt, en het is de verkeerde vraag — hij behandelt AI als een soort functie in plaats van als gereedschap, en zo eindig je met een chatvenster op een instellingenpagina waar niemand om gevraagd heeft. De goede vraag is smaller: is er in dit product een specifieke, terugkerende taak die een taalmodel echt beter doet dan het alternatief? Meestal is het antwoord nee, zodra je het zo precies vraagt. Soms is het een duidelijk ja. Zo houd ik die twee uit elkaar.
Past goed: rommelige invoer, nette uitvoer
Een chaotische supportmail lezen en daar een categorie, een prioriteit en een samenvatting uit halen: daar zijn taalmodellen echt goed in. Het is patronen herkennen in taal, precies waarvoor ze gemaakt zijn. Hetzelfde geldt voor een lange discussie samenvatten, een eerste versie van een antwoord opstellen, of vrije tekst uit een formulier in je bestaande categorieën indelen. Dat werkt omdat de taak van het model smal is en de uitkomst terechtkomt in een systeem dat er nog echte controles omheen heeft.
Past goed: een eerste versie, geen eindantwoord
Wat een taalmodel oplevert, is bruikbaar zolang een mens ernaar kijkt voordat het ertoe doet — een eerste productomschrijving op basis van een specificatieblad, een conceptmail die een medewerker aanpast voor die de deur uitgaat, voorgestelde labels bij een nieuw artikel. Zodra je die controle weghaalt en de uitkomst ongezien naar een klant of zo je database in laat gaan, verandert het risico volledig van vorm. Dat moet een bewuste keuze zijn, geen gevolg van “in de demo ging het goed”.
Past slecht: alles wat betrouwbaar moet kloppen
Als een verkeerd antwoord echte schade oplevert — een prijs die niet klopt, advies waar iemand rechten aan ontleent, een supportvraag die zelfverzekerd fout beantwoord wordt — dan is een taalmodel op zichzelf het verkeerde gereedschap. Punt. Verzinsels zijn geen foutje dat je eruit haalt; het hoort bij hoe deze modellen werken. De oplossing is niet “de instructie beter formuleren”, maar “laat het model nooit de laatste controle zijn op iets wat moet kloppen”.
Past slecht: dingen die al opgelost zijn
Zoeken dat prima werkt met een goede index hoeft geen “AI-zoeken” te worden. Voor een contactformulier hoeft geen chatvenster. Als het eerlijke antwoord op “waarom AI” is “omdat het verwacht wordt” in plaats van “omdat het aantoonbaar een beter resultaat geeft”, dan is dat het signaal om het niet te doen — je betaalt per verwerkt stukje tekst, en een functie die er staat voor de presentatie is een terugkerende kostenpost zonder opbrengst.
Hoe dat er in een project uitziet
Een AI-functie die het opleveren waard is, is meestal klein en specifiek, en heeft een duidelijk plan B als de dienst traag is of onzin teruggeeft — want een functie die af en toe geruisloos faalt, is erger dan geen functie. Het interessante werk zit niet in het aanroepen van die dienst. Het zit in precies bepalen waar iets dat met kansen werkt thuishoort in een systeem dat vooral voorspelbaar moet zijn.
Benieuwd of jouw idee zich leent voor een taalmodel, of dat het vooral AI-vormig is? Vertel me wat je voor ogen hebt — je krijgt hoe dan ook een recht antwoord.