AI inkopen: welke voorwaarden legt u vast?

Bij gewone software koopt u gedrag dat vastligt: u geeft dezelfde invoer, u krijgt dezelfde uitvoer. Bij een AI-toepassing is dat niet zo. Dezelfde vraag kan een ander antwoord opleveren, en het systeem kan na een update anders reageren zonder dat er iets aan uw kant is veranderd.

Dat maakt de klassieke acceptatietest lastig. Wat u accepteert is geen vaste uitkomst maar een bandbreedte, en de vraag wordt hoe u die bandbreedte beschrijft en hoe u merkt dat hij verschuift.

Daar komt bij dat de uitkomst gevolgen kan hebben voor mensen: wie er wordt uitgenodigd, wie er als eerste wordt geholpen, welke aanvraag wordt doorgezet. Dat vraagt afspraken die bij een boekhoudpakket niet aan de orde zijn.

• Wat de leverancier moet uitleggen over de werking van het systeem, en in welke mate.
• Welke gegevens er worden gebruikt, waarvoor, en of uw invoer wordt gebruikt om modellen te trainen.
• Hoe wordt vastgesteld dat het systeem doet wat het moet doen, en hoe vaak dat opnieuw wordt getoetst.
• Wie ingrijpt als het systeem iets doet wat niet de bedoeling is, en binnen welke termijn.
• Wat er gebeurt bij een wijziging aan het model of aan de onderliggende dienst.

Van alle onderwerpen is er één die in de praktijk het meest oplevert en het minst wordt gesteld: wat gebeurt er met onze invoer? Niet alleen of die wordt bewaard, maar of die wordt gebruikt om het model te verbeteren, en of dat ook geldt voor de onderaannemer van uw leverancier.

Voor zakelijke overeenkomsten is het gebruikelijke antwoord dat invoer niet voor training wordt gebruikt. Dat staat er alleen als u ernaar vraagt, en het geldt niet automatisch voor elke laag in de keten.

Vraag daarom niet alleen naar het beleid van uw leverancier maar naar de hele keten. Als hij zelf een dienst afneemt die onder water een model aanroept, gaan uw gegevens naar een partij die u nooit heeft gekozen.

Een leverancier hoeft u geen modelgewichten te geven, en dat zou u ook niets zeggen. Wat hij wel moet kunnen: uitleggen op welke gegevens het systeem is gebaseerd, welke factoren de uitkomst het meest beïnvloeden, en waar de bekende beperkingen zitten.

Bij toezicht gaat het om iets concreters dan 'een mens kijkt mee'. De vraag is of die mens de uitkomst kan begrijpen, of hij kan ingrijpen, en of hij daar de bevoegdheid en de tijd voor heeft. Een controleur die honderd beslissingen per uur afvinkt, is formeel toezicht en feitelijk een stempel.

Leg daarom vast hoeveel tijd er per beoordeling beschikbaar is, wat de controleur ziet, en wat er gebeurt als hij het er niet mee eens is. Dat zijn drie afspraken die het verschil maken tussen toezicht op papier en toezicht in de praktijk.

• De leverancier informeert u vooraf bij een wijziging van het onderliggende model of de onderliggende dienst.
• Bij een wezenlijke wijziging krijgt u de gelegenheid om opnieuw te toetsen voordat die live gaat.
• Wordt een model uitgefaseerd, dan geldt een afgesproken termijn en een migratiepad.
• Aanpassingen die voortvloeien uit gewijzigde wetgeving vallen binnen het onderhoud en niet onder meerwerk.

Vraag om een proefopstelling met uw eigen gegevens, niet met de voorbeelden van de leverancier. Wat een systeem doet met nette demonstratiedata zegt weinig over wat het doet met uw werkelijkheid.

Kijk daarbij niet alleen naar of het goed gaat, maar naar wat er gebeurt als het misgaat. Wat doet het systeem bij een onvolledige invoer, bij een uitzonderingsgeval, bij iets wat het niet kent? Een systeem dat dan een plausibel maar fout antwoord geeft, is gevaarlijker dan een systeem dat zegt dat het het niet weet.

Laat ten slotte iemand meekijken die het vakgebied kent en niet de techniek. De vraag of de uitkomsten kloppen, is een inhoudelijke vraag, en die kan uw ICT-afdeling niet beantwoorden.

De meest gemaakte fout bij het beoordelen van een AI-toepassing is dat de ICT-afdeling het doet. Zij kunnen beoordelen of het systeem werkt, of het veilig is en of het past in de infrastructuur — maar niet of de uitkomsten inhoudelijk kloppen.

Die tweede vraag hoort bij de mensen die het werk doen. Een recruiter ziet binnen tien minuten of een rangschikking van kandidaten ergens op slaat. Een behandelaar ziet of een samenvatting het belangrijkste heeft gemist. Dat oordeel is niet te vervangen door een test.

Zet daarom bij elke beoordeling ten minste twee soorten mensen: iemand die het systeem beoordeelt en iemand die de uitkomst beoordeelt. Dat kost een dagdeel extra en het voorkomt de aanschaf waar niemand achteraf mee wil werken.

• Weten welke systemen in uw organisatie AI gebruiken. Zonder dat overzicht kunt u geen enkele afspraak nakomen.
• Zorgen dat medewerkers die ermee werken weten wat er wel en niet in mag, en waarop ze de uitkomst controleren.
• Vastleggen wie binnen uw organisatie aanspreekbaar is als er iets misgaat.
• Bijhouden welke beslissingen door een systeem zijn beïnvloed, zodat u achteraf kunt reconstrueren wat er gebeurde.

Niet op de bereidheid van leveranciers, maar op de vraag wie het weet. Een leverancier die zelf een dienst van een ander afneemt, kan uw vragen vaak niet beantwoorden zonder die ander te bellen. Dat kost tijd en het levert soms een antwoord op dat niemand wilde horen.

Het tweede knelpunt zit bij uw eigen organisatie. Contracten met goede AI-bepalingen zijn waardeloos als niemand controleert of ze worden nagekomen. De rapportage die u afspreekt, is dus geen bijzaak maar de enige manier waarop een bepaling betekenis krijgt.

Wat wél goed werkt, is klein beginnen. Eén systeem, één set vragen, één afspraak over rapportage. Dat levert een sjabloon op dat u bij het volgende contract hergebruikt, en het is aanzienlijk kansrijker dan een beleidsstuk dat alles tegelijk wil regelen.

De verleiding is groot om hier beleid van te maken: een kader dat alle AI-inkoop in de organisatie regelt. Dat kost maanden en het levert een document op dat bij het eerste concrete geval alsnog niet past.

Wat wel werkt is één systeem nemen dat u toch al gaat aanschaffen, en daar de vragen bij stellen die in dit artikel staan. Dat levert antwoorden op, een set afspraken, en inzicht in welke vragen in uw situatie het meest opleveren.

Die set is uw sjabloon voor het volgende contract. Na drie keer heeft u iets dat in uw organisatie werkt, opgebouwd uit praktijk in plaats van uit een voorbeelddocument. Dat is sneller en het wordt bovendien gebruikt.

• Wat u vraagt aan een AI-leverancier
• De AI Act en uw organisatie
• AI trainen op uw data

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.