Een demo is het slechtste moment om een AI-systeem te beoordelen. Je ziet wat het systeem kan, op een voorbeeld dat de leverancier zelf heeft gekozen. Voor kenniswerk telt vooral wat een systeem níét doet: geen bron verzinnen, geen tekst wijzigen zonder dat iemand het ziet, je gegevens niet meenemen naar een plek die je niet kent. Dat laat een demo niet zien. Dat staat in de documentatie en het contract, of het staat nergens.
Stuur je vragen daarom vóór de demo, op papier. Een schriftelijk antwoord kun je naast dat van een tweede leverancier leggen, aan het contract hangen en een jaar later nog teruglezen. Bovendien valt een vaag antwoord op papier veel sneller op dan in een gesprek waarin iemand enthousiast door de schermen klikt.
Zes lagen, zes vragen
De vragen volgen TRACES, het model waarmee VergeLabs elk systeem toetst.
TRACES zijn de zes lagen waarop je een AI-systeem toetst: Trail, Retrieval, Approval, Constraints, Expertise, Storage. Ontbreekt een laag, dan zit daar een risico.
Per laag staat hieronder de vraag die je zo kunt overnemen, wat een bruikbaar antwoord bevat en hoe een ontwijkend antwoord klinkt. Dat laatste is minstens zo nuttig, want ontwijkende antwoorden lijken op elkaar, welke leverancier ze ook geeft.
T · Trail
De vraag. Wat legt het systeem vast bij elk antwoord en elke wijziging: de bron, de bewering, wie het goedkeurde en wanneer? En kunnen wij dat exporteren?
Bruikbaar. Een opsomming van de velden, een voorbeeld van een export, en de toezegging dat het spoor vanzelf ontstaat terwijl iemand werkt. Moet een medewerker zelf iets bijhouden, dan gebeurt dat in een drukke week gewoon niet.
Ontwijkend. "Alles wordt gelogd." Vraag dan door, want een log van wie wanneer inlogde is iets anders dan een spoor van welke bewering op welke bron rust.
R · Retrieval
De vraag. Uit welke bronnen antwoordt het systeem, en wat gebeurt er als het antwoord daar niet in staat?
Bruikbaar. Alleen uit een verzameling die jullie zelf afbakenen, met bij elk antwoord een verwijzing naar de passage, en een "weet ik niet" als die passage ontbreekt. Nog beter: het systeem kan laten zien welke beweringen in een tekst géén bron hebben. Zoeken alleen kan afwezigheid nooit aantonen.
Ontwijkend. "Hallucinaties zijn tot een minimum beperkt." Of: "Het model is getraind op betrouwbare data." Beide antwoorden gaan over het model, niet over jullie bronnen.
A · Approval
De vraag. Waar in het werk bevestigt een mens de inhoud, verschilt dat per soort wijziging, en wordt die bevestiging vastgelegd?
Bruikbaar. Een beschrijving van het moment van goedkeuren, per passage of per soort wijziging, met de bron ernaast. Een tikfout herstellen vraagt nu eenmaal geen vakinhoudelijk oordeel, een cijfer herschrijven wel.
Ontwijkend. "De gebruiker blijft altijd zelf verantwoordelijk." Dat is een disclaimer, geen functie.
C · Constraints
De vraag. Welke handelingen kan het systeem technisch níét uitvoeren, ook niet als een gebruiker erom vraagt?
Bruikbaar. Een korte lijst, bijvoorbeeld versturen, publiceren, iets toezeggen aan een klant of gegevens buiten de eigen omgeving zetten. Met de uitleg dat die blokkade in de software zit, buiten het model.
Ontwijkend. "Het model is geïnstrueerd om dat niet te doen." Een instructie is een verzoek. Een model dat iets niet mag, kan het in principe nog steeds; een systeem dat het niet kán, niet.
E · Expertise
De vraag. Welke beslissing blijft bij onze vakmensen, en hoe maakt het systeem die beslissing lichter?
Bruikbaar. Een benoemde beslissing, zoals de conclusie, de beoordeling of de vrijgave, en een concreet hulpmiddel daarbij. Denk aan de bronpassage naast de bewering, zodat niemand de hele bron hoeft door te lezen.
Ontwijkend. "Het systeem neemt het denkwerk uit handen." Voor werk dat onder jullie naam de deur uitgaat, is dat precies het verkeerde argument.
S · Storage
De vraag. Waar staan onze gegevens, worden ze gebruikt om modellen te trainen, en in welk artikel van welk contract staat dat?
Bruikbaar. Een regio, een lijst van subverwerkers en een verwijzing naar een artikel in de verwerkersovereenkomst.
Ontwijkend. "Wij nemen privacy zeer serieus." Of "AVG-proof", zonder document erbij.
Zo lees je de antwoorden
Geef elk antwoord een van drie oordelen: aanwezig, half of afwezig. Aanwezig betekent dat het antwoord concreet is en dat je het in een document terugvindt. Half betekent dat de functie bestaat maar dat je moet doorvragen, of dat ze alleen mondeling is toegezegd. Afwezig is een ontwijkend antwoord, of geen antwoord.
Niet elke laag weegt even zwaar. Welke het zwaarst weegt, hangt af van waar jullie eigen werk kwetsbaar is, en dat laat het tweede model zien. SEAL beschrijft de vier fasen die kenniswerk doorloopt: Source, Edit, Approve en Launch.
SEAL laat zien welke fase lekt. TRACES is waarmee je toetst of een systeem dat lek kan dichten.
Lekt het bij Source, omdat niemand bijhoudt waar een bewering vandaan komt, dan kun je Retrieval niet missen. Lekt het bij Edit, omdat een tekst na het herschrijven niet meer tegen de bron wordt gelegd, dan gaat het om Trail en Approval. Een systeem dat op juist die laag afwezig scoort, valt af, hoe goed de rest ook is.
Wat je deze week kunt doen
- Kies het systeem dat jullie overwegen. Een systeem dat al in gebruik is, werkt net zo goed.
- Zet de zes vragen in één mail aan de leverancier. Vraag om schriftelijke antwoorden, met een verwijzing naar documentatie of contract waar dat kan.
- Zet de antwoorden in een tabel met drie kolommen: laag, antwoord, oordeel.
- Tel de lagen met afwezig. Staat er een afwezig op de laag die bij jullie het zwaarst weegt, dan weet je genoeg.
Wie eerst zelf de openbare documentatie wil nalopen, kan de leverancierscan op deze site gebruiken. Die legt een systeem langs dezelfde zes lagen.