AI in je bestaande webapplicatie: waar begin je?

Je hebt een webapplicatie die draait. Een klantportaal of een intern dashboard waar je team de hele dag in werkt. En overal om je heen hoor je over AI. Je CRM-leverancier heeft er ineens een AI-knop in zitten, en iemand in je team vraagt of "we daar ook niet iets mee moeten". Dus je vraagt je af: hoe pak je AI integreren in je webapplicatie aan, en waar begin je dan?

Het korte antwoord: bij één ding. Niet bij een AI-strategie, niet bij een chatbot die alles kan. Bij één taak in je applicatie die nu tijd kost en die je kunt meten. Hieronder lees je hoe je dat aanpakt, welke risico's erbij horen en hoe je ziet of het iets oplevert.

Waarom je met één feature begint

Waarom niet meteen overal? Omdat je nog niet weet hoe het zich gedraagt in jouw applicatie, met jouw data en jouw gebruikers. Dat leer je alleen door het te doen.

Eén feature geeft je een afgebakend experiment. Je ziet wat het model goed doet en waar het de mist in gaat. Je ziet wat het per aanroep kost. En je ziet of je gebruikers het echt gebruiken, of dat ze er na een week omheen werken. Begin je op vijf plekken tegelijk, dan weet je achteraf niet wat wat veroorzaakte.

Een eerste werkende AI-feature staat er bij ons meestal in 2 tot 4 weken. Kort genoeg om snel te leren, klein genoeg om zonder schade te stoppen.

Welke feature kies je eerst?

Niet elke taak is een goede eerste kandidaat. De beste hebben een paar dingen gemeen:

• Duidelijke input en output. Er gaat een tekst, document of formulier in, en er komt iets uit waarvan je kunt zeggen of het klopt.
• Het gebeurt vaak. Een taak die je twee keer per maand doet, levert weinig op. Een taak die je team twintig keer per dag doet wel.
• Een fout is te herstellen. Zit de AI ernaast, dan ziet een mens dat en past het aan. Begin niet met iets waar een fout meteen geld kost of zonder controle bij een klant belandt.
• Je kunt het nu al meten. Je weet ongeveer hoe lang het handmatig duurt, of hoe vaak het misgaat.

In webapplicaties zien we een paar soorten features die daar vaak aan voldoen.

Samenvatten

Een klantdossier met twintig notities, een ticket met een lange mailwisseling, een verslag van een gesprek. De AI zet een samenvatting bovenaan, je medewerker duikt alleen de details in als dat nodig is.

Classificeren en routeren

Binnenkomende berichten, aanvragen of documenten in de juiste categorie zetten en bij de juiste persoon leggen. Is dit een klacht, een vraag over een factuur of een nieuwe aanvraag? Een model is er doorgaans goed in, zolang je de categorieën helder definieert.

Zoeken in je eigen data

Je gebruikers stellen een vraag in gewone taal en krijgen antwoord op basis van jouw documenten, handleidingen of eerdere dossiers, met een verwijzing naar de bron. Dat heet RAG, en het is een stap groter dan samenvatten. Hoe het werkt en waar het misgaat, lees je in RAG uitgelegd.

Conceptteksten

Een eerste versie van een antwoord op een klantvraag, een offertetekst of een productomschrijving. Belangrijk woord: concept. Een mens leest het, past het aan en verstuurt het. Dat scheelt typwerk zonder dat je de controle uit handen geeft.

Kies er één. Liefst die waar je team nu het meest over klaagt.

Meet eerst hoe het nu gaat

Deze stap wordt bijna altijd overgeslagen, en hij is de belangrijkste. Hoe lang duurt het per keer? Hoe vaak per week gebeurt het? Hoe vaak gaat het mis of moet iets opnieuw?

Laat een paar mensen een week bijhouden hoe lang ze ermee bezig zijn. Een ruwe nulmeting is genoeg. Zonder nulmeting kun je straks alleen zeggen dat het "beter voelt", en daar baseer je geen beslissing op.

AI integreren in je webapplicatie: de roadmap

Zo ziet de route er in de praktijk uit, van één feature naar meer.

Stap 1: bouw de eerste feature achter een schakelaar

Zorg dat je de feature per gebruiker of groep aan en uit kunt zetten, zodat je terug kunt als het tegenvalt. Zet er meteen logging bij: welke input ging erin, wat kwam eruit, en wat deed de gebruiker daarna? Werd de output overgenomen, aangepast of weggegooid?

Stap 2: laat een kleine groep ermee werken

Kies een paar mensen die het werk goed kennen en eerlijk zeggen wat ze ervan vinden. Laat ze een paar weken met de feature werken, kijk naar de logging en praat met ze. Vaak doet de AI het juiste, maar op de verkeerde plek in het scherm of net te uitgebreid.

Stap 3: vergelijk met je nulmeting

Gaat de taak sneller? Gaat er minder mis? Hoe vaak moeten mensen de output corrigeren? En wat kost het per aanroep aan modelgebruik? Zet dat naast elkaar. Is het resultaat duidelijk positief, rol het dan uit naar iedereen. Twijfel je, pas het aan of stop ermee. Stoppen is ook een uitkomst, en goedkoper dan iets een jaar laten meedraaien dat niemand helpt.

Stap 4: bouw een gedeelde basis

Werkt de eerste feature, dan komt de tweede sneller, zeker als de techniek eronder netjes staat. Wij stoppen het model altijd achter een eigen laag in de applicatie: één plek waar prompts, retries, outputcontrole en kostenbewaking leven. De rest van je code praat met die laag, niet rechtstreeks met een AI-leverancier. Wil je later van model wisselen, dan pas je één plek aan. Hoe we daarover denken, lees je in AI in de lus, niet op de automatische piloot.

Stap 5: koppel AI aan meer van je systemen

Draaien een paar features goed, dan kun je AI breder laten werken: een assistent die gegevens opzoekt en acties klaarzet die een mens bevestigt. MCP is een standaard waarmee je AI zo gecontroleerd aan je software koppelt. Meer daarover in MCP: hoe je AI koppelt aan je bestaande software.

De risico's die je vooraf wilt kennen

AI gedraagt zich anders dan code die je zelf schrijft. Hier wil je vooraf over nadenken.

Foute output. Een model kan met grote stelligheid iets verkeerds zeggen. Daarom begin je met taken waar een mens meekijkt, en bouw je controles in op de output. Klopt het formaat, en bestaat de bron waarnaar het verwijst echt?

Kosten die oplopen. Elke aanroep kost geld. Bij gewoon MKB-gebruik zit je vaak op zo'n €50 tot €500 per maand aan modelgebruik. Een feature die bij elke paginaweergave een model aanroept, drijft dat snel op. Hou het per feature bij.

Privacy. Wat stuur je naar het model, en waar komt dat terecht? Check de zakelijke voorwaarden van je leverancier, regel een verwerkersovereenkomst en stuur niet meer mee dan nodig.

Afhankelijkheid van één leverancier. Modellen en prijzen veranderen snel. Met de eigen laag uit stap 4 hou je de vrijheid om te wisselen.

Niemand gebruikt het. Een feature die technisch werkt maar niet in de werkwijze van je team past, wordt genegeerd. Daarom stap 2: test met echte gebruikers voordat je uitrolt.

Hoe meet je of het iets oplevert?

Uiteindelijk wil je een simpele vergelijking kunnen maken: wat kost deze feature, en wat levert hij op? Dit hou je bij:

• Tijd per taak, voor en na. Hier zit meestal de grootste winst.
• Correctiegraad. Hoe vaak passen mensen de output aan of gooien ze hem weg?
• Gebruik. Hoeveel mensen gebruiken de feature na een maand nog?
• Kosten per aanroep tegenover de tijd die het bespaart.

Een rekenvoorbeeld, puur ter illustratie: stel dat je team 40 keer per dag een ticket samenvat en dat kost elke keer vijf minuten. Scheelt de AI daar drie minuten van, dan win je twee uur per dag. Die rekensom werkt alleen als je die vijf minuten echt hebt gemeten.

Een eerste feature is meestal een overzichtelijk traject. Wordt het een agent die zelfstandig meerdere stappen zet in je systemen, dan zit je in een andere orde van grootte. Wat dat kost, zetten we op een rij in wat kost een AI-agent laten bouwen.

Heb je nog geen webapplicatie? Dan is de eerste vraag wat voor applicatie je nodig hebt. Die keuze zetten we op een rij in native app, web app of website. Hoe wij webapplicaties bouwen, met AI erin waar dat zinvol is, lees je bij webapplicatie laten maken.

Samen kijken waar je begint?

Twijfel je welke taak in jouw applicatie de beste eerste kandidaat is? Dat zoeken we graag samen met je uit. Plan een gesprek, dan lopen we door je applicatie en je processen en kijken we waar AI echt iets oplevert. En is het antwoord dat het nu nog niet nodig is, dan zeggen we dat ook gewoon.

Veelgestelde vragen

Moet mijn webapplicatie opnieuw gebouwd worden om AI toe te voegen?

Meestal niet. Een AI-feature kun je doorgaans aan een bestaande applicatie toevoegen, via een eigen laag die met het model praat. Alleen als je applicatie sterk verouderd is of geen goede toegang tot je data biedt, wordt het lastiger. Dat zie je vooraf snel.

Hoe lang duurt het om een eerste AI-feature te bouwen?

Bij ons staat een eerste werkende AI-feature er meestal in 2 tot 4 weken, afhankelijk van de taak en hoe makkelijk we bij de benodigde data kunnen. Daarna volgt een testperiode met een kleine groep gebruikers.

Welk AI-model moet ik kiezen?

Dat hangt af van de taak, de kosten en waar je data mag staan. Belangrijker dan de eerste keuze is dat je later kunt wisselen. Daarom stoppen we het model achter een eigen laag, zodat een ander model één aanpassing is in plaats van een verbouwing.

Wat als de AI fouten maakt?

Dat gebeurt, dus daar ontwerp je voor. Begin met taken waar een mens de output ziet voordat er iets mee gebeurt, controleer de output automatisch op formaat en bronnen, en hou bij hoe vaak mensen moeten corrigeren.