Heb jij ook wel eens gedroomd van een robot die je werk overneemt? Nou ik wel, want ik was het reviewen van geheimhoudingscontracten (NDA’s) ondertussen méér dan zat. Steeds maar ongeveer dezelfde teksten van ongeveer hetzelfde commentaar voorzien en opletten dat dezelfde stomme valkuilen er niet weer in zitten. Dat moet toch automatisch kunnen, leek me. Dit soort documenten is immers zó standaard opgesteld. En omdat ik ook nog ooit iets met informatica had gedaan, besloot ik zelf met haar aan de slag te gaan. In oktober 2017, na ruim een jaar bouwen, lanceerde ik deze lawyerbot, en ik noemde haar NDA Lynn. En nu, bijna drie jaar later, werken we aan de gaafste feature die ik ken: Edit Mode. Lees mee in deze X-delige serie hoe we van daar naar hier kwamen.
Ik weet niet meer precies wanneer ik kwam op het idee van Lynn. Maar het lezen en becommentariëren van al die NDA’s was ik al jaren zat. Ik doe het ook al een kleine twintig jaar. Eerst bijna tien jaar bij Philips, daarna (sinds 2008) als partner bij ICTRecht. Ik schat dat ik meer dan drieduizend NDA’s heb gereviewd in die tijd. En altijd was het verhaal ongeveer hetzelfde, want op hoe veel manieren kún je nu eenmaal zeggen dat je informatie gaat delen die je dan geheim moet houden, met geschillen te behandelen in Amsterdam en geen garantie op de juistheid van de informatie.
Ik weet nog wel dat ik op zeker moment drie NDA’s van drie klanten op één dag deed. Volledig ongerelateerd alle drie, maar de teksten kwamen grotendeels overeen. Toen ging het dus knagen: zou dat te automatiseren zijn? Het is in feite alleen maar tekstvergelijking, iets waar computers veel beter in zijn dan ik. Maar het gaat wel een stapje verder dan alléén maar het bekijken of twee alinea’s grofweg dezelfde tekens bevatten.
De hype rond AI en machine learning was toen al aardig op gang. Zou het met bijvoorbeeld Google of Microsoft’s cloudbased machine learning systemen kunnen? Het zag er allemaal veelbelovend uit, maar er was één groot nadeel. There is no cloud, it’s just someone else’s computer. Ik zag het niet zitten om voor deze dienst afhankelijk te zijn van een online service van een ander, ook niet als die gratis was.
Toen kwam ik het Spaanse BigML tegen. Een sympathieke dienst, een API die je meteen een goed gevoel geeft én de mogelijkheid om ML modellen offline in te zetten. Dus gewoon zeg maar een executable op je eigen server, zodat het niet uitmaakt of hun dienst beschikbaar is of niet. Dat was precies wat ik nodig had.
Hier, het resultaat van een avondje prutsen (ja, in PHP, dat was het makkelijkste) om eens te zien hoe dat nu werkt, zo’n machine learning systeem:
do {
$res = bigML("poll", $bpid);
if (isset($res["status"]["code"])) {
if ($res["status"]["code"] != $oldstatus) {
echo "\n => ".$res["status"]["message"];
$oldstatus = $res["status"]["code"];
} else
echo ".";
} else
print_r($res);
if ($i > 0) sleep(1); $i++;
} while (($res["status"]["code"] != "5") && ($i <= 10));
Het werkte prachtig. Alleen: een machine learning systeem is niets zonder data. In mijn geval dus NDA’s. Hoe kom je daar nou aan?
Een geluk aan de NDA is dat hij zo wijdverspreid is dat je er met gemak een paar honderd op internet vindt. Dat is dus het eerste dat ik deed. Daarnaast had ik er zelf natuurlijk een heleboel, alleen die had ik voor klanten geschreven of gelezen en dan kun je dus niet zomaar die in je eigen systeem stoppen. Later, met Lynn al draaiende, zou dat geen probleem meer zijn: Lynn is gratis maar je moet me toestemming geven je NDA te gebruiken voor verbetering van de dienst. Ik heb er nu een dikke 5000. Maar in het begin was het een serieuze uitdaging om de juiste NDA’s te vinden. Daarover een volgende keer meer.
Het basisidee van Lynn is vrij rechttoe rechtaan. Je krijgt een NDA, je extraheert de tekst, je kijkt welke clausules er zijn en zegt voor iedere clausule of deze acceptabel is of niet. Er zijn tools genoeg die een geupload document kunnen converteren naar tekst, en genoeg libraries ook voor tekstmanipulatie op zich. En als je weet wat voor clausule je hebt, kun je gewoon in een tabel kijken of hij acceptabel is of niet. Maar hoe weet je nu wat voor clausule je hebt?
Machine Learning (ML) is een vorm van AI waarbij een grote hoeveelheid data wordt geanalyseerd op gemeenschappelijke onderscheidende kenmerken. Hiermee maakt het systeem een functie die grofweg zegt of iets categorie A, B of C is. Als je dan een nieuwe input hebt (in mijn geval dus een nieuwe clausule) dan kijkt het systeem met die functie in welke categorie het hoort.
Dat betekent dus dat ik een dataset moet maken die een paar honderd NDA clausules bevat. En van elke clausule heb ik diverse smaakjes nodig, zeg maar wat is een strenge beveiligingsclausule en welke is juist lekker relaxed. Dan kan een ML systeem gegeven een inputclausule zeggen of deze het meest lijkt op een strenge beveiligingsclausule of juist eerder een rechtskeuze voor Florida. En als ik dat heb, kan ik een advies uit mijn tabel halen.
Dan het volgende probleem: hoe vind je nu precies een clausule? Na een stuk of dertig NDA’s te hebben bekeken, kom ik tot de conclusie dat daar geen standaardmanier voor is. Iedereen groepeert teksten op zijn eigen manier. Soms zijn het keurig genummerde alinea’s, anderen doen een opsommingslijstje en weer anderen maken gewoon een lap tekst met willekeurig een enter hier en daar.
En dan heb je ook nog grapjassen die verderop nog even terugkomen op een onderwerp. Zo zie ik die beveiligingseisen op drie of vier plekken in het document staan, zodat je niet eens kunt spreken van een beveiligingsclausule. Of er wordt op allerlei plekken geroepen dat er aansprakelijkheid is voor X of Y.
Nee, er zit niets anders op. Niet kijken naar clausules, je hebt alleen zinnen. Dat betekent dus, extraheer de zinnen uit het document, label die met hun onderwerp en voeg alles samen dat hetzelfde onderwerp is. Dat is dan je “clausule”, en daar kun je dan een kwalificatie op doen hoe streng of relaxed die is.
Zoals je hieronder ziet, krijg je dan een systeem waarbij je twéé machine learning componenten inzet. Het eerste zegt van een zin welke categorie het is (het 1st stage model) en het tweede systeem zegt van alle zinnen uit één categorie welk smaakje daaraan te geven is (het 2nd stage model). Gelukkig zijn ML systemen razendsnel, zeker de offline modellen die BigML kan aanbieden. Want je wil echt niet per zin een aanvraag doen bij de systemen van Google of Microsoft en dan een seconde wachten op het antwoord.
Deze architectuur ziet er goed uit. Hij heeft alleen één groot nadeel: ik moet nu niet langer een paar honderd clausules van een labeltje voorzien, maar een dikke duizend zinnen. Want elke clausule telt een zin of vijf, zo ontdek ik al snel. En als ik dat heb gedaan, dan moet ik daarna ook nog eens de zinnen van dezelfde clausule bij elkaar vegen en daar weer een labeltje op plakken dat me vertelt welke smaak de clausule is.
En hoe ik daarmee aan de slag ging, dat vertel ik morgen.
(Dit is het eerste van vijf vakantieberichten.)
Arnoud
Zoals u weet, lanceerde ik 
Verder hadden we nog een mailinterface ingebouwd (forward je mail naar een speciaal adres en krijg de bevindingen teruggemaild) en een API koppeling gebouwd voor integratie van Lynn in andere diensten. Ik had mooie dromen om Lynn bijvoorbeeld aan Slack te koppelen: stuur haar een privébericht en ze reageert binnen een paar minuten in de chat met of je kunt tekenen of niet. Of nog leuker, een Outlook plugin of een koppeling met Salesforce. Stel je voor, je krijgt een mail met een NDA en in de sidebar staat meteen een bericht “deze kun je tekenen, no problem”. Maar ik had geen idéé hoe duur dat allemaal wel niet was.
Blijft over: wat ga je zeggen. Daarvoor schrijf ik een uitvoertabel, die per clausule per smaak per situatie aangeeft wat het antwoord moet zijn. Hierboven zie je een klein stukje daarvan: dit is de uitvoer voor de categorie “warranties” oftewel garanties. Wat moet je zeggen als deze standaard of juist breed gevraagd worden, of als er geen garanties in staan. Je ziet dat het antwoord net anders is als je in de give dan wel in de get of mutual situatie zit.
