Google publiceerde op 28 oktober een handleiding voor het testen van AI-agents. Mijn praktische vertaling: spreek vooraf af wat goed genoeg is en controleer opnieuw na een wijziging.
Op 28 oktober publiceerde Google een praktische uitleg over het evalueren van AI-agents met Agents CLI. De publicatie laat zien hoe ontwikkelaars vaste testvragen kunnen uitvoeren, antwoorden beoordelen en verschillende versies vergelijken. Ook beschrijft Google hoe je zulke controles periodiek kunt draaien en een waarschuwing kunt laten geven wanneer de kwaliteit terugloopt. Het gaat om een technische handleiding, niet om de belofte dat een agent daarmee vanzelf betrouwbaar wordt.
Waarom dit voor jouw bedrijf interessant is
Mijn praktische vertaling: de vraag is niet alleen of een AI-functie vandaag een goed antwoord geeft. De vraag is ook of die functie morgen nog doet wat je met je team hebt afgesproken. Denk aan een hulpmiddel dat binnenkomende aanvragen samenvat of een vervolgvraag voorstelt. Een antwoord kan netjes zijn geschreven en toch de verkeerde informatie benadrukken.
Daarom zou ik bij zo’n toepassing eerst vastleggen wat een bruikbare uitkomst is. Moet een medewerker kunnen zien welke gegevens ontbreken? Mag het systeem een prijs noemen? En wanneer moet het stoppen en iemand laten meekijken? Die afspraken maken een beoordeling concreter dan alleen vragen of een antwoord goed klinkt.
Begin met herkenbare situaties uit je eigen werk
Je hoeft als ondernemer geen testcommando’s te leren om hier iets aan te hebben. Je kunt wel de juiste voorbeelden verzamelen. Kies een normale aanvraag, een onvolledige aanvraag en een situatie die buiten je dienstverlening valt. Schrijf er per voorbeeld bij wat je verwacht en wat het systeem juist niet mag doen.
Gebruik daarvoor fictieve of zorgvuldig geanonimiseerde gegevens. Een voorbeeld hoeft geen echte klantnaam te bevatten om duidelijk te maken welke beslissing belangrijk is. Betrek vervolgens de medewerker die straks met het resultaat verder moet. Die ziet vaak sneller dan een ontwikkelaar welke informatie ontbreekt.
Dit sluit aan op het ontwikkelen van een webapplicatie in stappen: bepaal eerst de taak en de grenzen, maak een kleine versie en beoordeel die met de mensen die ermee gaan werken.
Een wijziging vraagt om opnieuw kijken
Stel dat je de instructie aanpast omdat samenvattingen te lang zijn. Het is dan logisch om ook te controleren of belangrijke details nog terugkomen. Of je kiest later een ander model vanwege kosten of snelheid. Dan wil je dezelfde voorbeelden opnieuw kunnen bekijken, zodat je niet alleen op gevoel beslist.
Mijn advies is om vooraf af te spreken welke wijzigingen zo’n controle nodig maken en wie het resultaat beoordeelt. Leg ook vast wat er gebeurt bij twijfel. Blijft de oude versie beschikbaar? Wordt een voorstel eerst aan een medewerker getoond? Dat zijn onderdelen van de technische inrichting en het beheer van je toepassing, geen losse klus na de oplevering.
Een testsucces is geen vrijbrief
Een verzameling voorbeelden blijft een selectie. Er kunnen in het echte werk situaties ontstaan die je niet hebt bedacht. Een goede beoordeling op die voorbeelden betekent dus niet dat iedere uitkomst klopt. Voor mij is dat een reden om het gebruik klein en controleerbaar te beginnen, zeker wanneer een fout gevolgen heeft voor klanten.
De praktische stap is eenvoudig: vraag bij je volgende gesprek over een AI-toepassing niet alleen om een demonstratie. Vraag ook welke voorbeelden worden gebruikt om de kwaliteit te controleren, wie afwijkingen oppakt en hoe je na een wijziging vergelijkt. Dat levert een concreter gesprek op over bruikbaarheid, verantwoordelijkheden en onderhoud.