Moet uw product AI gebruiken? Een praktische gids

AI kan nuttig zijn in een product, maar „AI toevoegen” is geen productvereiste. Begin bij het probleem van de gebruiker, bij de beslissing die de software moet ondersteunen en bij de kosten van een verkeerde beslissing.

De druk om AI in te voeren is echt, en het gat erachter ook.

De 2026 AI Index (opent in een nieuw tabblad) van Stanford HAI meldt dat de AI-adoptie binnen organisaties in 2025 steeg naar 88 % van de ondervraagde organisaties. Er staat ook dat het gebruik van AI-agents in vrijwel elke bedrijfsfunctie „nog in het begin staat”.

Het onderzoek 2026 State of AI in the Enterprise (opent in een nieuw tabblad) van Deloitte ondervroeg 3.235 leidinggevenden in 24 landen. Het vond dat 74 % van de organisaties hoopt de omzet te laten groeien met AI, tegenover 20 % die dat al doet.

De adoptie is bijna universeel. De gerealiseerde waarde niet.

Dat gat is de reden om het even rustig aan te doen voor één gesprek voordat u zich vastlegt. De vraag is niet of AI het kan. De vraag is of deze functie, voor deze gebruiker, een probleem is met de vorm waar AI bij past.

Wanneer AI past en wanneer niet

Een gewone workflow is vaak de betere keuze wanneer de regels helder zijn. Formulieren, rechten, zoeken, berekeningen, meldingen en geplande taken hebben geen taalmodel nodig alleen omdat er een beschikbaar is.

Dit is geen dwarse positie. De Rules of Machine Learning (opent in een nieuw tabblad), de interne richtlijn van Google voor ML-engineers, opent met een directe instructie: „Wees niet bang om een product te lanceren zonder machine learning”.

De redenering: een simpele vuistregel vangt al een groot deel van de waarde. Machine learning verdient zijn plek pas als die regels te verward worden om te onderhouden.

Een conventionele workflow is meestal het betere antwoord wanneer:

• de regels opgeschreven en afgestemd kunnen worden met de eigenaren van het proces
• dezelfde invoer altijd dezelfde uitvoer moet opleveren
• de kosten van een fout antwoord hoog zijn en het juiste antwoord vooraf te kennen is
• iemand precies moet kunnen uitleggen waarom het systeem deed wat het deed
• de data al gestructureerd, gevalideerd en volledig zijn

AI verdient zijn plek wanneer de invoer rommelig of onvoorspelbaar is, of moeilijk vast te leggen met vaste regels:

• lange documenten, gespreksdraden of gespreksnotities samenvatten
• vrije-tekstberichten classificeren waarvan de formulering sterk varieert
• velden halen uit documenten die nooit één sjabloon volgen
• iemand helpen informatie te verkennen in plaats van namens die persoon te beslissen
• een eerste versie opstellen die een mens nakijkt en bewerkt

Het patroon in de tweede lijst is dat een mens in de lus blijft. De uitvoer is een concept, een suggestie of een startpunt in plaats van een eindbeslissing.

Daar verdienen deze functies meestal als eerste hun plek.

Begin met de juiste vraag

De eerste vraag is niet „welk model nemen we?” Vraag liever: „wat moet de gebruiker kunnen doen, en waar komt onzekerheid de workflow binnen?” Dat antwoord bepaalt of AI in het product thuishoort.

Bepaal vóór het bouwen hoe een goed resultaat eruitziet. Een concept-samenvatting kan volstaan met een snelle menselijke controle. Een beslissing die de software zelf neemt, vraagt misschien strakkere controles, een heldere uitleg en een veilige manier om die te stoppen of te corrigeren.

Het AI Risk Management Framework (opent in een nieuw tabblad), in januari 2023 uitgebracht als vrijwillige richtlijn van NIST, zegt het onomwonden. Onder zijn kenmerken van betrouwbare systemen is geldig en betrouwbaar zijn „een noodzakelijke voorwaarde voor betrouwbaarheid”.

Het is de basis waarop de andere kenmerken rusten. Een functie die indrukwekkend maar onbetrouwbaar is, heeft de eerste lat niet gehaald.

Vragen om te stellen voordat u zich vastlegt

Als iemand een AI-functie voorstelt, scheidt een korte lijst vragen meestal een doordacht plan van een enthousiast plan:

1. Welke taak doet dit, en hoe zouden we die zonder AI doen?
2. Wat kost een fout antwoord de gebruiker, en wie merkt het als eerste?
3. Welke data ziet de functie, en waar gaan die heen?
4. Hoe testen we het vóór de lancering, en hoe vaak daarna?
5. Wat doet het product wanneer het model niet beschikbaar of onzeker is?
6. Wat kost dit per gebruiker per maand bij tien keer het huidige volume?

Voor geen van deze vragen is technische achtergrond nodig om ze te stellen. Ze zijn wel alle lastig overtuigend te beantwoorden zonder.

Ontwerp voor menselijke controle

Menselijke controle is geen vage veiligheidsformule. Geef de beoordelaar genoeg context om de uitvoer te controleren, een heldere manier om die te bewerken en een route om een fout te melden die het productteam kan onderzoeken.

De gevestigde raamwerken vragen om toezicht dat je zwart op wit kunt aanwijzen, niet om toezicht dat je van plan bent.

De functie Map van het NIST-raamwerk verwacht dat „processen voor menselijk toezicht worden gedefinieerd, beoordeeld en gedocumenteerd in overeenstemming met het beleid van de organisatie”.

In de EU eist Article 14 of the AI Act (opent in een nieuw tabblad) dat systemen in de hoogrisicocategorie zo worden ontworpen „dat er tijdens de periode waarin zij worden gebruikt daadwerkelijk toezicht op kan worden uitgeoefend door natuurlijke personen”.

Niet elk product valt in die categorie. Het ontwerpprincipe blijft een redelijke standaard lang voordat het een wettelijke wordt.

De beveiligingsrichtlijn is het daarmee eens. De OWASP Top 10 for LLM Applications (opent in een nieuw tabblad) noemt Excessive Agency bij de risico's van 2025.

De aanbevolen mitigatie is direct: „zet human-in-the-loop-controle in om te eisen dat een mens acties met grote impact goedkeurt voordat ze worden uitgevoerd”.

Als een functie zelfstandig geld kan uitgeven, berichten kan versturen of records kan wijzigen, hoort die goedkeuringsstap bij de bouw. Het is geen latere hardeningsklus.

Leg dataregels vast vóór de bouw

Datatoegang en privacy moeten onderdeel van het ontwerp zijn. Bepaal welke informatie de functie ontvangt, waar die wordt verwerkt, hoe lang die wordt bewaard en welke mensen of systemen bij het resultaat mogen.

OWASP zet Sensitive Information Disclosure (opent in een nieuw tabblad) op de tweede plaats van zijn LLM-risico's voor 2025. De richtlijn valt terug op een regel die de meeste teams kennen en onder tijdsdruk overslaan: «beperk toegang tot gevoelige data op basis van het principe van minimale rechten».

Het model is nog een systeem met toegang tot de informatie van uw gebruikers, en hoort net zo te worden afgebakend.

De aanbieders publiceren concrete voorwaarden, en die verschillen genoeg om ertoe te doen. Drie zijn het lezen waard voordat het ontwerp vaststaat:

• Gebruik voor training. De documentatie van OpenAI over datacontroles (opent in een nieuw tabblad) stelt dat „data die naar de OpenAI-API worden gestuurd niet worden gebruikt om OpenAI-modellen te trainen of te verbeteren”, met een aparte bewaartermijn voor misbruikmonitoring.
• Bewaring. De documentatie van Anthropic over databewaring (opent in een nieuw tabblad) beschrijft zero data retention als prompts en antwoorden die na het terugkomen van het antwoord niet in rust worden opgeslagen. De eigen geschiktheidstabel merkt stateful functies aan als uitzonderingen, dus zero retention geldt niet over de hele linie.
• Waar de inferentie draait. De regio is instelbaar en apart geprijsd. De documentatie van Anthropic over dataresidentie (opent in een nieuw tabblad) merkt op dat inferentie uitsluitend in de VS „wordt geprijsd op 1,1 keer het standaardtarief”.

Als het product persoonsgegevens van mensen in de EU verwerkt, is de verplichting in de ontwerpfase expliciet.

De richtsnoeren van de Europese Commissie over gegevensbescherming door ontwerp en door standaardinstellingen (opent in een nieuw tabblad) stellen dat organisaties standaard „moeten waarborgen dat persoonsgegevens worden verwerkt met de hoogste privacybescherming”.

Dat is een beslissing die vóór de integratie wordt genomen, niet na het incident.

Plan de kosten per gebruiker

Ga er niet van uit dat een gehoste AI-dienst gratis is omdat het eerste experiment weinig kost. Gebruik, opslag, monitoring, herhaalpogingen, controletijd en toekomstige modelwijzigingen beïnvloeden alle de exploitatiekosten.

AI-aanbieders rekenen doorgaans af per verwerkte hoeveelheid tekst, dus de kosten groeien met het gebruik in plaats van met het aantal medewerkers.

De knoppen staan genoemd in de eigen prijsdocumentatie van de aanbieders (opent in een nieuw tabblad): modelkeuze, prompt-caching, token-overhead van tool-aanroepen en batchverwerking. De Batch-API van Anthropic biedt „50 % korting op zowel invoer- als uitvoertokens” voor asynchroon werk.

Een functie die tegen het volle tarief onrendabel is, kan prima zijn wanneer het werk niet direct hoeft.

Er is ook een beveiligingskant. Het OWASP-item Unbounded Consumption (opent in een nieuw tabblad) beschrijft hoe „aanvallers door een groot aantal bewerkingen te starten het kosten-per-gebruikmodel van cloudgebaseerde AI-diensten uitbuiten”.

Dit heet soms denial of wallet. Rate limits, quota's en gebruiksmonitoring horen in de eerste release, niet in de tweede.

Test eerst met echte voorbeelden

Bouw een kleine testset voordat u de functie klaar noemt. Gebruik representatieve voorbeelden, neem moeilijke gevallen mee en leg de soorten fouten vast die ertoe doen voor de mensen die het product gaan gebruiken.

Beide grote aanbieders zien dit als iets wat je eerst doet, niet als iets wat je later toevoegt.

De richtlijn van Anthropic over het ontwikkelen van empirische evaluaties (opent in een nieuw tabblad) is concreet over de vorm van een bruikbare set: „wees taakspecifiek: ontwerp evals die uw echte taakverdeling weerspiegelen. Vergeet de randgevallen niet mee te nemen!”.

De evaluatiegids van OpenAI (opent in een nieuw tabblad) beschrijft dezelfde praktijk als begrijpen hoe een applicatie presteert ten opzichte van de verwachtingen. Dat is wat een model- of promptwijziging veilig uitrolbaar maakt.

Een bruikbare evaluatie hoeft niet elk antwoord te voorspellen. Ze moet laten zien of de functie nuttig is voor haar taak, waar ze faalt en wanneer de workflow de regie moet teruggeven aan een mens.

Evalueren stopt ook niet bij de lancering. De observability-richtlijn van Microsoft (opent in een nieuw tabblad) beschrijft hoe de levenscyclus doorloopt in productie met „kwaliteits- en veiligheidsevaluatie van productieverkeer op steekproefbasis”.

Echt gebruik bevat invoer die uw testset nooit heeft bedacht.

Plan het terugvalgedrag

Ook terugvalgedrag heeft een praktisch ontwerp nodig. Als het model niet beschikbaar, te traag of onzeker is, moet het product nog steeds uitleggen wat de gebruiker vervolgens kan doen, in plaats van een lege staat of een misleidend antwoord achter te laten.

Beslis vooraf wat de functie doet in drie situaties: wanneer het model niets bruikbaars teruggeeft, wanneer het verzoek verloopt en wanneer de zekerheid laag is.

Elk daarvan is een productbeslissing met zichtbare gevolgen voor de gebruiker. Elk is nu goedkoper te nemen dan tijdens een incident.

Het is ook de moeite waard te beslissen hoe makkelijk u later van model of aanbieder zou kunnen wisselen. Prompts, evaluatiesets en een dunne laag tussen product en model bewaren die optie.

Een uitgewerkt voorbeeld

Om dit concreet te maken: stel u een supportteam voor dat verzuipt in binnenkomende e-mail. Elk bericht moet worden gelezen, ingedeeld en naar de juiste persoon geleid, en het volume is de mensen die het doen boven het hoofd gegroeid.

De reflex is te grijpen naar een AI-agent die elke e-mail leest en beantwoordt. Loop in plaats daarvan de vragen langs.

Wat is de taak, en hoe zouden we die zonder AI doen? Routeren op trefwoord en afzender doet de heldere gevallen al. Het lastige zijn de dubbelzinnige vrije-tekstberichten — precies de vorm die bij een model past.

Wat kost een fout antwoord? Een verkeerd geleide e-mail kost minuten. Een automatisch antwoord dat een terugbetalingsbeleid verzint, kost veel meer. Daarom stelt de veilige eerste versie een categorie en een concept voor; een mens verstuurt nog steeds.

Hoe testen we het? Een paar honderd al afgehandelde e-mails worden de evaluatieset, met de rommelige en ongebruikelijke er bewust bij. Als de voorgestelde categorie vaak genoeg klopt om leestijd te besparen, verdient ze haar plek.

De functie die live gaat is smal: classificeren en opstellen, een mens verstuurt, trefwoordregels doen nog steeds de voor de hand liggende gevallen, en alles wordt gelogd zodat de evaluatieset blijft groeien.

Dat is een kleiner, veiliger en goedkoper product dan de agent die het team eerst voor zich zag — en het product dat het contact met echte postvakken eerder overleeft.

Beslissen wat u bouwt

Iets met AI bouwen en AI meeleveren in het product zijn twee verschillende beslissingen. Een ontwikkelaar kan AI-tools gebruiken tijdens het schrijven van de code en toch een product opleveren dat draait op gewone software, op AI-functies, of op allebei.

Beslis bij een nieuw product eerst de kleinste bruikbare workflow. Voeg een AI-functie pas toe wanneer die deze workflow verbetert voor een omschreven gebruiker en getest kan worden met bewijs dat het team kan onderhouden.

Het sterkste AI-productplan is concreet over zijn grenzen. Het benoemt de taak, de data, de beoordelaar, het terugvalgedrag, de evaluatiemethode en de kostenaannames voordat de functie een belofte wordt.

Weegt u AI af tegen automatisering of maatwerksoftware, breng de beslissing dan vroeg in het planningsgesprek. Het juiste antwoord kan AI zijn, een workflow op regels, of helemaal geen nieuwe technologie.