AI in je software inbakken – wanneer wel en wanneer niet?

Proven technology, zoals we dat kennen, of AI gebruiken voor je business case? Robot of aap, om in de metafoor te blijven. En laten we wel wezen, zo eenvoudig is die keuze niet. Tussen de extremen van AI wens- en doemdenken, zit het domein van het realistische en het haalbare. Daar kijken we vandaag naar.

Wanneer niet?

Je kunt een hele categorie AI-kandidaten op voorhand uitschakelen omdat er betere technische alternatieven zijn, of omdat het sowieso geen goed idee is. Laten we een reeks van vragen doorlopen en kijken wat daaruit komt.

"Moet je bijvoorbeeld de AI inzetten om je database te doorzoeken?"

Nee, dat kan prima met andere technieken, van SQL tot NoSQL.

"Moet je de AI dan inzetten om in documenten te zoeken?"

Nee, daarvoor zet je eerst andere technieken in, zoals bijvoorbeeld Elastic Search, waarmee effectief zoeken in vrije tekst mogelijk wordt gemaakt.

"Moet je de AI wél inzetten om voor jou beslissingen in de software te nemen?"

Nee, hooguit een voorzet, waarna een mens de knoop doorhakt. De resultaten zijn helaas te vaak niet goed genoeg.

Wanneer dan wel?

Op hoofdniveau zijn de meest interessante zaken om te adresseren de volgende:

• reduceren repetitieve handelingen, zoals het doorspitten van grote volumes aan data op aanwezigheid van anomalieën en het ter beoordeling doorgeven van een kleinere, behapbare lijst aan een mens
• complexe taken eenvoudig maken, zoals het opzetten van een samenspel aan handelingen om data uit een systeem te halen of het handmatig schrijven van een query in een exotische taal

Er zijn andere cases mogelijk, bijvoorbeeld op het gebied van beeldherkenning of voorspellende analyses en wellicht heb je zelf een goed idee wat met AI zou kunnen. De kern is echter de volgende regel en die mag daarom op een tegeltje:

Overal AI inzetten?

"Maar, maar, maar we kunnen toch overal gewoon AI inzetten? Waarom niet? AI kan toch alles?"

Kan, maar dat is over het algemeen geen goed idee. De belangrijkste reden daarvoor is dat het inbouwen van AI in je software doorgaans duurder en complexer is dan het bouwen van traditionele software. Er zijn goede redenen waarom zoveel AI-projecten het levenslicht niet zien, ondanks initieel enthousiasme tijdens de eerste testen.

Om dat te begrijpen, moet je besef hebben van de maatregelen die getroffen moeten worden om de geïntegreerde AI in goede banen te leiden, zoals:

• AI in software werkt niet zoals je chatbot; Als je als gebruiker met een AI praat, dan ben je gewend gewone tekst terug te krijgen, maar software wil juist voorspelbare gestructureerde output hebben, zodat het daarop kan voortborduren. Je zult de AI in een keurslijf moeten dwingen om het goed geïntegreerd te laten werken in software. (AI vs machine)
• prompt-centrisch; werkelijk alles draait om de prompt, dus je proces moet zo ingericht zijn dat je inzicht hebt in de opbouw en de werking van de prompt. Omdat de prompt "gewone tekst" is, kun je dat niet op de traditionele manier unit-testen. (context engineering)
• gevoel voor werking AI; AI kent allerlei bijzonderheden die veel invloed hebben op de werking, zoals bijvoorbeeld dat je niet onnodig veel context mee wil geven, omdat dat het resultaat en de kosten negatief beïnvloedt. Maar ook het instellen van de juiste temperatuur, oftewel heel kort door de bocht, de voorspelbaarheidsschuif van de AI. (context rot)
• data verzamelen; omdat je geen directe grip hebt op de werking van de AI, moet je verzorgen dat je je prompt en response opslaat, samen met metadata, zodat je de context hebt voor de analyse.
• data analyseren; de verzamelde data moet bekeken worden en fouten gecategoriseerd. Samen met feedback van gebruikers en hetgeen je ziet in de foutcategorieën, pak je de categorieën aan die het meest urgent zijn.
• prompt verbeteren; je speelt de verzamelde prompts na. Prompts voor Google Gemini 2.5 Flash Lite kun je bijvoorbeeld naspelen in de AI Studio van Google. De prompt kun je op punten bijslijpen om een – nog niet echt onderbouwd, vibe – gevoel te krijgen voor het effect van de wijziging.
• AI evals; je bouwt een evaluatieset op om voorbij het vibe-testen te komen, is het zaak om een evaluatie-set op te stellen die je kunt draaien bij i) het vervangen van je AI-model, ii) het upgraden van je AI-model en iii) het veranderen van je prompt. De evaluatieset geeft je onderbouwing voor het verschil vóór en ná de wijziging.
• ruimte voor verduidelijking; als de AI niet begrijpt wat er gevraagd wordt, dan moet een structuur beschikbaar zijn waar het om opheldering kan vragen. Daarna kan het alsnog de vraag proberen te beantwoorden. (flow)
• valideren resultaten; dat waar de AI mee terugkomt, moet getoetst worden op correctheid, bij voorkeur door programmacode. Daaruit kan komen dat het resultaat van de AI niet door de validatie komt.
• herstel van validatiefout; in geval van een validatiefout, moet het proces door kunnen gaan. Dat zou bijvoorbeeld kunnen door de vraag opnieuw te stellen aan de AI.
• interventie; als de AI met een gevalideerd resultaat is teruggekomen, dan kan het nog steeds zijn dat het niet voldoet aan de verwachting van de gebruiker. Op dat moment moet ingegrepen kunnen worden, bijvoorbeeld door de prompt te verduidelijken, door een herkansing af te dwingen of door de controle over te nemen en de keuze zelf te maken.
• grip op kosten; de kosten voor AI modellen lopen sterk uiteen, met in de extremen zelfs een verschil van 200 keer. Als je niet weet wat je doet, dan kun je de bietenbrug opgaan zodra de rekening op je deurmat valt. Het is zaak om te wéten (inzicht in kostenmodel) en te méten (inzicht in gebruik, telemetrie). (kosten)
• grip op compliance; er zijn wettelijke redenen (AVG/GDPR, AI Act) om goed na te denken over hoe je AI in je software inzet. Ook kan het zijn dat je klanten strenge eisen hebben op gebied van AI. Zorg dat je hier rekening mee houdt, bv door de AI-module optioneel te maken, of binnen de vereiste kaders te laten werken. (compliance, 8QL)

Vergelijk dat met soortgelijke functionaliteit, maar dan zonder AI en je ziet direct dat de inzet van AI meer organisatie vereist dan reguliere, old school software.

Bedachtzaam AI inzetten

Laten we oppassen niet het kind met het badwater weg te gooien. We weten nu dat het voorkeur heeft om proven technology in te zetten als het kan, maar dat er soms cases zijn die zich niet goed laten vatten in die manier van werken. Als de business case sterk is, dan is het wel degelijk de moeite om AI in je software in te bouwen.

Wij hebben dat inmiddels gedaan bij ons product Tingit, zoals terug te lezen is in ons verslag van de inceptie, bouw en risicoanalyse van onze 8QL agent, een AI assistent die een gewone gebruikersvraag via een chatbot omzet in een domeinspecifieke query waarmee gebruikers opgehaald worden uit het systeem.

Daarnaast hebben we een proof-of-concept lopen voor een assistent waarmee je op basis van een met OpenAPI gedocumenteerde API een reeks AI agents aan het werk zet om een functionele ETL pipeline te bouwen.

Niet overtuigd of nog vragen? We gaan graag het gesprek aan om te kijken of jouw business case geschikt is voor het integreren van AI in je software.