Worden inkoopvoorwaarden het volgende slachtoffer van legal tech?

Wie zaken doet, kent het fenomeen: inkoopvoorwaarden. Zeg maar algemene voorwaarden, maar dan die van de klant. Gemeenschappelijke kenmerken: lang, eenzijdig (héél eenzijdig) en ze benoemen punten waar jij nooit aan gedacht had. Oh ja, en de inkoper van de andere partij kan je snel vertellen dat er niets te onderhandelen valt, dit moet nu eenmaal zo. Dat onderhandelen zal blijven, maar het lange uren steken in het doorakkeren van die teksten en opschrijven wat er anders moet, dát gaat veranderen. Dankzij Lynn Legal.

Lynn reviewt en annoteert nu al geheimhoudingscontracten (NDA’s) en verwerkersovereenkomsten, gebruik makend van machine learning (je mag het AI noemen) op basis van vele duizenden voorbeelden en de juridische inzichten van mijn bedrijf ICTRecht. Waarom nog tijd besteden aan standaard issues zoeken als Lynn dat veel sneller en net zo scherp doet?

Dan krijg je natuurlijk de vraag, kun je dit bij meerdere soorten contracten doen. De zoektocht is lastig: je hebt contracten nodig die in bulk beschikbaar zijn (maatwerk-SLA’s blijven mensenwerk om te lezen), er moet genoeg te vinden zijn en de mens moet het de tijdsinvestering eigenlijk niet waard vinden. En ja, bij die omschrijving past prima het concept van de inkoopvoorwaarden.

Tijd dus om hier een checker voor te gaan bouwen. En dat kunnen wij natuurlijk niet alleen. We zoeken ervaringen, tips, voorbeelden en ideeën over wat zo’n checker moet zeggen, waarop te letten en welke issues zijn het allerbelangrijkste.

Tevens tijd voor een stukje verhalen bij het kampvuur: wat is de raarste discussie of bepaling bij inkoopvoorwaarden die jij ooit zag?

De mijne: een groot retailconcern wilde een nieuwe app, en liet mijn klant de inkoopvoorwaarden zien. Men had daarin bepaald dat alle producten de hoogste mate van versheid moesten hebben (als in: vanochtend geplukt, vanmiddag in het schap), maar elders ook “Product” gedefinieerd zodanig dat apps er ook onder vielen. Dat leek mij raar, maar ik heb nog nooit zo’n onwerkelijke discussie gehad als toen over waarom een app niet vers zou hoeven zijn. Mijn klant heeft nog drie maanden “alleen de meest verse libraries” als tagline gehad.

Arnoud

Dankzij mijn lawyerbot weten we nu eindelijk hoe de eerste geheimhoudingsovereenkomst eruit zag

Zoals u weet, lanceerde ik in 2017 lawyerbot NDA Lynn: een online dienst die geheimhoudingscontracten oftewel NDA’s screent en direct advies geeft. De dienst is populair, ondertussen heb ik meer dan 14.000 NDA’s verzameld en ze blijven maar binnenkomen. Je ziet enorme variatie in zo ongeveer elke clausule. Sommige NDA’s zijn één kantje, andere veertien. Lijstjes en clausules worden ook steeds langer, lijkt het wel. Dus toen kreeg ik de gedachte: hier moet ik eens een statistische analyse op loslaten en zien of ik terug kan vinden wat de eerste geheimhoudingsovereenkomst moet zijn geweest. En dat is me gelukt.

Dankzij digitale historische taalkunde is het mogelijk om op basis van tekstfragmenten een serie teksten te herleiden tot “het origineel”. Ik gebruik aanhalingstekens want zeker weten doe je dat natuurlijk nooit, maar als we uitgaan van de aanname dat juristen andermans werk copypasten en daar dan dingen aan toevoegen – dus niet weghalen, want waarom zou je iets weghalen – dan kun je van clausules de steeds langere versies als ‘jonger’ beschouwen. Maar daar staat tegenover dat ook oude advocaten breedsprakig konden zijn. Je moet dus op meer zaken letten.

Een voorbeeld: een praktijk die we de laatste tien à twintig jaar zien, is dat men werkt met afkortingen. Die herken je aan hun hoofdletters. Bijvoorbeeld:

“Confidential Information” means information disclosed by the discloser or its subsidiaries to the receiver in relation to the Purpose, which is identified as confidential, or which can reasonably be considered confidential due to its nature, or the circumstances surrounding disclosure.
Tevens zijn er duidelijke scheidslijnen op basis van andere toevoegingen te trekken, zoals dat op zeker moment exportwetgeving ineens “een ding” wordt, er Supreme Court arresten komen over “entire agreement” clausules en dat NDA’s op zeker moment vaker over elektronische kopieën gaan spreken. Door naar dat soort zaken te zoeken, kun je grofweg NDA’s van een datum voorzien. Als beginjaartal houd ik daarbij 1979 aan, omdat dat het jaar was dat de eerste ‘echte’ wetgeving omtrent trade secrets van kracht werd.

Vervolgens volg ik de technologie van Gerhard Jäger, die deze truc uithaalt bij Romaanse talen:

Computational approaches to historical linguistics have been proposed since half a century. Within the last decade, this line of research has received a major boost, owing both to the transfer of ideas and software from computational biology and to the release of several large electronic data resources suitable for systematic comparative work. In this article, some of the central research topic of this new wave of computational historical linguistics are introduced and discussed. These are automatic assessment of genetic relatedness, automatic cognate detection, phylogenetic inference and ancestral state reconstruction. They will be demonstrated by means of a case study of automatically reconstructing a Proto-Romance word list from lexical data of 50 modern Romance languages and dialects.
De details zal ik u besparen, maar het komt neer op vele avonden stampwerk van mijn computer, die lange en korte versies van formuleringen vergelijkt, een hoop geblader in juridische wikipedia’s en lang gepeuter in halve clausules om te zien welke versie waar van afgeleid is. Maar het is me gelukt, en u mag hieronder klikken voor het resultaat: (Het echte nieuws is trouwens dat er kennelijk 14.000 keer een bedrijfsjurist of advocaat was die dacht, een NDA dat kan ik beter. Het is erger dan Javascript frameworks.)

Arnoud

 

De lawyerbot van de toekomst wijzigt gewoon zelf je documenten even #ndalynnweek

Artificial Intelligence is wat een computer bijna kan, las ik ooit als definitie van die term. Want op het moment dat de computer het kan, is het gewoon een ding dat een computer kan. Er is maar een korte periode waarin een computer iets kan laten zien dat we nog echt nieuw vinden. Ik heb het gevoel dat we daar nu zitten met documentanalysetools zoals NDA Lynn: de tools bestaan, en ze kunnen dingen, maar we vinden het nog wel een beetje eng. Ik ben benieuwd of Edit Mode mensen over de streep trekt. Helemaal omdat het stiekem eigenlijk niet zo ingewikkeld is.

Ik heb gemerkt dat mensen enthousiast worden over nieuwe features of werkwijzen als je ze een catchy naam geeft, vandaar dat ik dit aspect Edit Mode heb genoemd (enige associatie met vim(1) is geheel toeval). Maar het is wel een forse andere manier van werken. In plaats van een rapport met bevindingen krijg je nu in je document bevindingen terug. In de vorm van commentaar in de marge, en in de vorm van een aangepaste clausule.

Dit heeft nogal wat voeten in de aarde, maar vooral in wat er allemaal omheen moet gebeuren. Ik rijd voor mijn werk dagelijks langs een grote bouwplaats. Daar gebeurt altijd weken niets, en dan zit er ineens een verdieping bovenop het gebouw. En laatst was ik er een week niet en toen bleken die betonnen platen te zijn bekleed, gestoffeerd en behangen. Morgen eerste bewoners. Nou, al dat werk aan die betonplaten en fundering dat is nu dus ongeveer gedaan.

In de oude versie werd alle tekst gewoon geëxtraheerd uit het brondocument. Daar zijn libraries te over voor. Die tekst werd dan geclassificeerd (“dit is security, dit gaat over overmacht, dit is een partijdefinitie”, etcetera etcetera) en daarna van een smaakje (streng, eenzijdig, breed, etc) voorzien. Dan nog even opzoeken wat dat betekent (“oké, eenzijdige partijdefinitie willen we niet”) en de uitvoer op je scherm. Duidelijk. Maar nu willen we dus terug het document in, en bij de zin over security een commentaartje hangen “Deze is te streng, dit willen we niet”). En dat was er dus niet, informatie om mee terug het document in te gaan.

Nu dus wel. We nemen dus het commentaar op de clausule en stoppen dat in een comment die in de marge verschijnt:

Ziet er gaaf uit, nietwaar? En ergens ook wel, eh, AI achtig, dat een robot gewoon doet wat een mens voorheen deed met zo’n tekst. De huidige teksten zijn nog geschreven als beschouwende analyse, maar je kunt ze ook net wat pittiger schrijven als pushback naar de opsteller van het document. En dan kun je daar nog een beetje GPT-3-achtige tekstvariaties bij laten maken en dan krijg je duidelijk een robot aan het woord.

Er zit nog een lastig aspect aan. We extraheerden dus die individuele zinnen, om daarmee vervolgens clausules te maken en die van commentaar te voorzien. Maar dan moet je dus terug in het document en dan kun je alleen de commentaren aan de individuele zinnen hangen. Dat gaat dan mis als twee zinnen uit dezelfde categorie na elkaar volgen. Dan krijg je twee keer hetzelfde commentaar achter elkaar. En “op elkaar volgen” is niet zo eenvoudig te herkennen. Word stopt er soms een héle trits codes tussen, waardoor het voor software lijkt of de twee zinnen drie kilometer uit elkaar staan.

De volgende stap: het document wijzigen. Oftewel, je hebt gezien dat een clausule onacceptabel is en je wilt er wat acceptabels van maken. Hoe pak je dat aan?

Als mens ga je dan op basis van ervaring zelf wat aanpassen. Hier een stukje redelijkheid, daar een “voor zover haalbaar zonder kosten” en zo nog wat braaftaal om al te strenge clausules rustig te krijgen. Of juist omgekeerd, je schrapt “inspanning” en je maakt er “garandeert” van, je voegt wat specifieke eisen toe en maakt het zo het gewenste niveau van strengheid. Automatiseer dat maar eens.

Die bedrijfsjuristen van gisteren hadden een nog iets ander idee: laat ons zelf clausules erin zetten, en schrap dan de onacceptabele clausule zodat ‘onze’ clausule erin geplakt gaat worden. Dát gaat hem niet worden. Dan moet je gewoon je eigen NDA opsturen als tegenvoorstel. Maar onderhandelingstechnisch staat het héél raar als je zegt “deze tekst kan niet, ik heb alles geschrapt en mijn tekst erin geplakt”. Daar kom je gewoon niet mee weg.

Nee, het moet met hier een stukje erbij en daar een stukje eraf. Gelukkig zijn er tools die dergelijke aanpassingen gewoon kunnen uitrekenen: gegeven brontekst A en doeltekst B, wat moet er in A bij of af om tot B te komen? Mijn probleem is dus alleen hoe je aan de juiste doelteksten B komt.

Dat is makkelijker dan je denkt, want ik had dus een hele bak met clausules die ook nog eens in verschillende smaakjes ingedeeld is. Dat is immers de dataset waarmee ik Lynn heb gevoed. Als ik nu uit elk smaakje een selectie maak, tien clausules van de brede soort, tien van de beperkte soort en tien van de standaard/gemiddelde soort, dan zijn we er. Kijk welke soort acceptabel is voor deze klant (bijvoorbeeld de brede smaak), pak een van die tien clausules van die smaak en pas de NDA aan zodat de onacceptabele clausule (bijvoorbeeld een beperkte) verandert in die ene van brede smaak.

Dan krijg je dus dit. En ja, dit is een redline gemaakt door NDA Lynn:

De originele tekst was een hele brede: alle informatie was geheim, ongeacht hoe deze was vastgelegd. Maar dat was niet acceptabel: het moest beperkt worden: alleen informatie waar “geheim” op staat valt onder de NDA. De aanpassing zorgt daarvoor, door een clausule uit de beperkte categorie te pakken en als een redline door te voeren.

Blijft nog over de business logic die erbij hoort. Want je kunt wel alles aanpassen, maar juist bij een NDA wil je niet op elke zin commentaar geven. Zowel jij als je wederpartij willen snel tekenen zodat je door kunt met je zakelijk gesprek. Vaak zie je dus dat je alleen van de échte problemen een punt maakt, zoals de hierboven getoonde definitie van vertrouwelijkheid. Maar dat jij een net wat mooiere manier hebt om te zeggen dat de rechtbank Amsterdam bevoegd is, dat laat je gewoon zitten. Dat kost alleen maar tijd.

Tegelijkertijd is dit wel een zakelijke feature en moet je een jurist overtuigen dat zhij dit wil. Dus dan kies je voor de tijdgeteste traditie van de afdeling Sales en maak je er een configuratie-optie van. Wat wil je voor dealbreakers; een edit of alleen een comment? En voor essentials? Het meest logisch – en dus de default – wordt dat dealbreakers een edit geven en essentials een comment.

En dan zijn we er eindelijk: jij uploadt je NDA met de vraag, ik ga informatie krijgen en kan ik deze tekenen? NDA Lynn zegt ja of nee, en zo nee dan krijg je de aanpassingen die naar je wederpartij kunnen. Ondertussen kan ik lekker écht werk doen. Dat is waar legal tech over gaat.

(Dit was deel vijf van vijf vakantieberichten.)

Arnoud

Met een lawyerbot de markt op, of hoe je juristen overtuigt je dienst af te nemen #ndalynnweek

Mijn grootste fout bij de lancering van NDA Lynn was dat ik mezelf erbij verkocht. Iets preciezer: als je de bevindingen van Lynn te lezen kreeg, stond er bij dat je voor 99 euro een human review kon kopen. Hartstikke stom natuurlijk – Lynn klopt gewoon, waarom zou je nog een mens nodig hebben. (En het hele punt was nou net dat ik geen NDA’s meer hoefde te lezen. Maar dat terzijde.) Maar belangrijker, ik had vanaf het begin een custom omgeving moeten bieden. Mensen zelf laten aanpassen wat de uitvoer moet zijn. Want dan had je pas écht de kracht van AI voor juridische diensten kunnen bepalen.

Helaas duurde het even voordat we de Business Edition, zoals het is gaan heten, echt op de markt konden brengen. Je krijgt je eigen omgeving, waar je achtergrond, kleuren en teksten kunt aanpassen (en eigen URL, zij het als jouwnaamhier.ndalynn.com want dat was even het snelste). Je kunt oude gescreende NDA’s opvragen – wat nog een hele mooie bleek, want als er iets is dat in organisaties ontbreekt dan is het wel een index van de NDA’s die in je organisatie zijn getekend. Hartstikke leuk die contractmanagementsystemen maar NDA’s stopt niemand daarin.

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.

De kern van de dienst is natuurlijk dat je zelf bepaalt welke NDA’s je accepteert. Je kunt dan ook alle dealbreakers, essentials en boilerplate zelf verschuiven, en bepalen wat er moet gebeuren bij welke uitkomst. Dus als jij vindt dat een NDA gerust 10 jaar van kracht mag zijn, dan zet je dat zo in je systeem en dan zal Lynn er nooit meer over vallen. Wil jij perse Zwitsers recht, dan zal Lynn er een punt van maken als er Duits staat. En je mag dan kiezen of dat punt een dealbreaker is of gewoon iets vervelends.

Daaraan gekoppeld zit een simpele workflow: als het resultaat iets anders is dan “je kunt tekenen” dan wordt de NDA met bevindingen doorgestuurd naar de bedrijfsjurist of advocaat die je zelf invult. Zo komen alle NDA verzoeken centraal binnen, is het idee, tenzij er helemaal niets mis is met het document. En je krijgt meteen de briefing met de problemen erbij, zodat je kunt bepalen of het alsnog goed is of je er echt inhoudelijk naar wilt kijken.

Tevens is er beperkt gebruikersbeheer: je moet inloggen via de webinterface om een NDA te kunnen uploaden. In de praktijk gebruiken mensen liever de mailinterface, want dat kun je vanuit je mailprogramma doen en je krijgt een reply die met één klik leidt naar de volledige resultaatpagina. De API gebruikt eigenlijk niemand.

Ik begin met de Business Edition bij bevriende advocaten aan te bieden. Die reageren geïnteresseerd maar ook sceptisch: wat als die bot een foutje maakt, wie is er dan aansprakelijk? Geen rare gedachte, zeker voor een advocaat die uiteindelijk ook tuchtrechtelijk voor slordigheden kan worden aangesproken. Maar het levert weinig business op.

Meer succes heb ik dan ook bij bedrijven met één overwerkte bedrijfsjurist. Die kan veel tijd vermijden met deze oplossing. Opvallend genoeg krijg ik vooral aanvragen uit Zuid-Amerika en Azië. De reden? Allereerst dat Lynn een stuk goedkoper is dan de alternatieven, en daarnaast dat ik ook Spaanstalige datasets heb toegevoegd. (Die maakte ik met Bing Translate, net als de Nederlandse en de Duitse. Dat werkt prima, iedereen gebruikt dezelfde terminologie en clausules.)

En nou ja, het werkt. Het wordt afgenomen, ook door bedrijfsadviseurs en anderen die het “erbij” verkopen aan hun klanten weer. Maar heel hard gaat het niet. Ik doe een snelle enquête en het antwoord is duidelijk: je moet documenten aanpassen, niet alleen maar adviseren. Nu moet je nog alles doorlezen om te zien wáár dan die te strenge regels staan of die vijf jaar die twee moet zijn.

Dat werd Edit Mode en daar zitten we nu hard aan te werken.

(Dit is de vierde van vijf vakantieberichten.)

Arnoud

Van idee naar ontwerp, of hoe moet een lawyerbot nu werken? #ndalynnweek

Goed, ik had dus een dataset en daarmee kon ik redelijke voorspellingen doen ook. Tijd dus om het héle ontwerp van Lynn eens te maken. Dan is gelijk de eerste vraag: wat moet Lynn dan precies doen? Nou ja, mij werk uit handen nemen. Ik wil niet meer lastig gevallen worden met “kan ik deze NDA tekenen”. Het doel van Lynn was dus: wees een site die zegt of je die NDA kunt tekenen. Document uploaden, geen gezeur, ja je kunt tekenen.

Ik had zo’n systeem nog niet eerder gezien. Bestaande systemen ondersteunen advocaten in hun praktijk. Het grote voordeel is dan dat ze sneller lezen en altijd even accuraat. Je krijgt dan een document met geel gemarkeerde secties waar iets raar mee is, en je weet dat de rest dan dus standaard is. (Het is ergens heel raar dat bedrijven elkaar doodgooien met teksten waarvan een robot al zegt, dit is standaard lekker laten gaan, maar dat is een andere discussie.) Maar je moet het zelf nog steeds lezen en uiteindelijk je conclusie trekken.

Zo’n advies, gewoon ja of nee zeggen. Hoe moet dat eruit zien. Uit mijn praktijk weet ik dat mensen vaak alleen vragen of er dealbreakers in staan. Grote dingen die heel pijnlijk zijn. Een hele lange termijn. Een boetebeding. Exclusiviteit of een concurrentieverbod. Dat werk. Als je die ziet, dan mag er niet getekend worden.

Dan zijn er nog andere dingen die best vervelend kunnen zijn maar niet perse een dealbreaker. Ja, jij zit in Nederland en men wil Taiwanees recht, dat is niet handig maar even serieus, gaat er echt een rechtszaak komen hiervan? Dat wil je dus wel wéten maar om de NDA daar nu meteen op af te keuren is ook zo wat. Ik noem dit de essentials.

En dan heb je nog de boilerplate, de volkomen standaard tekst die iedereen van elkaar overneemt maar werkelijk niets relevants bevat. Dat de kopjes informatief zijn. Dat de partijen verklaren te mogen tekenen. Dat dit de gehele overeenkomst is. Dat herkent Lynn echt vrijwel perfect (wat niet raar is, in veel gevallen zou een pure string vergelijking minstens zo goed werken) maar niemand wil het weten. Dat moet dus zéér terughoudend terugkomen in de uitvoer.

Met deze opzet komt het erop neer dat Lynn dus allereerst kijkt of er dealbreakers in het document staan. Zo ja, dan is het advies om niet te tekenen. Zijn er essentials met problemen, dan mag je tekenen mits je daar even naar kijkt. (Maar zijn het er te veel, wat ik maar even arbitrair definieer als 30% van de essentials) dan mag je alsnog niet tekenen. En de boilerplate die is er maar dat betekent verder niets. Niemand gaat een NDA weigeren omdat er niets staat over hoe informatief de kopjes zijn.

Bij bovenstaande zit wel nog een impliciete aanname, namelijk aan welke kant van de tafel je zit. In het jargon van de NDA-jurist (ja, die bestaat) heb je zogeheten give, get en mutual NDA’s. Een give NDA is geschreven voor de partij die informatie geeft, en is dus heel streng in zijn voordeel. Een get NDA is er juist voor de ontvangende partij, en de mutual NDA probeert beiden even hard te beschermen. (Protip: vraag altijd de mutual NDA, dat scheelt héél veel onderhandelen.)

Je moet dus weten welke van de drie situaties je te maken hebt. Dat is dan ook de vraag (en de enige vraag) die NDA Lynn je stelt. Ga je geven, ontvangen of samen delen? Ik vraag nog meer, maar dat is optioneel en vooral voor de statistieken. Eigenlijk alleen de vraag “in welk land zit u” komt terug in het antwoord: als dat niet hetzelfde is als de rechts- en forumkeuze dan krijg je daar een waarschuwing over.

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.

En dan zijn we er. Document tekst extraheren, met een ML model de zinnen classificeren, de zinnen bij elkaar rapen, van de clausules het juiste smaakje bepalen, in de uitvoertabel opzoeken welke uitvoer je moet geven en klaar is Kees. Of Lynn dan.

We testen, en komen de nodige probleempjes tegen. Zo voegen we taaldetectie toe (“Sorry, Portugese NDA’s worden niet ondersteund”), is het extraheren van tekst uit PDF net wat ingewikkelder en staat er soms gewoon rommel in een document. Maar dat is allemaal op te lossen. Tijd om de markt op te gaan.

(Dit is de derde van vijf vakantieberichten.)

Arnoud

Van bak met data naar een werkende lawyerbot #ndalynnweek

Weet je wat het idiootste is aan AI? Dat iedereen het maar over algoritmes heeft en hoe spannend of bedrijfsgeheim die zijn. Het labelen van je data, dát is waar de kwaliteit van je systeem mee staat of valt. Ik vind het dan ook erg raar dat je overal leest dat men een blik studenten opentrekt of via diensten als Mechanical Turk willekeurige mensen labels laat zetten. Of dat wij via reCaptcha en dergelijke diensten zeggen waar zebrapaden lopen of verkeerslichten te zien zijn. Data is de kern van je dienst, dus hoezo besteed je dat uit en pronk je vervolgens met je unieke algoritmes die uiteindelijk niet ter zake doen?

Natuurlijk, studenten inzetten is goedkoop maar waar vind je de rechtenstudent die in honderd NDA’s zinnen kan herkennen als zijnde overmacht, verlenging, aansprakelijkheid met boete enzovoorts? In een rechtenopleiding krijg je welgeteld nul contracten te lezen (ja, serieus) laat staan een specifiek document als een NDA.

Dus nee, er zit niets anders op dan het zelf te doen. Gelukkig vind ik het perfecte moment om dit te doen: mijn dochter van een paar maanden oud slaapt ’s nachts beter als ik in de kamer zit, dus ik leg mijn laptop klaar en ga labelen tot ze slaapt. Zo kom ik in een paar maanden tot een volgens mij keurig gelabelde dataset. Een paar steekproeven op de resultaten laat zien dat ik redelijk consistent label, ook al heb ik geen formele criteria opgesteld om clausules te categoriseren.

Dat is ergens ook wel een beetje de makke van zo’n systeem. Er zijn geen echte categorieën waar je op terug kunt vallen, je moet zelf maar iets bedenken. Zowel het soort clausule (is een vrijwaring een vorm van aansprakelijkheid of iets heel anders) als de smaakjes daarbinnen (is een ton aansprakelijkheid erger dan een boete van 10k per gelekt geheim). Dus ik doe maar wat. Bij elke zin bedenk ik een categorie, en na driehonderd zinnen ga ik categorieën samenvoegen en splitsen.

Hier, de tagger waarmee ik al die tijd heb gewerkt om zinnen van labeltjes te voorzien. Je ziet hoe het aantal categorieën is geëxplodeerd:

En de clauser, waarmee ik groepen zinnen (clausules dus) van een smaakje kon voorzien:

Dan heb je dus een berg zinnen en bijbehorende clausules, en daarmee kun je BigML gaan trainen. Dat had nog heel wat voeten in de aarde. Het eerste datasetje deed het goed, het voelt echt héél gaaf als je dan een test doet:

galactus@toad:~> php tagtest.php
input text: "Recipient shall use the same level of security as it uses for its own sensitive information to protect the Confidential Information against unauthorized use or disclosure, but at least a reaasonable level of security."
..... bigml says: security / standard
galactus@toad:~> 
En dat klopte helemaal. Maar er zaten genoeg fouten in. In het jargon: de F1-score was maar 0,64 en dat is niet genoeg om een commerciële dienst op te drijven. Terug naar de tekentafel dus, of beter gezegd de datatafel.

Allereerst viel me op dat ik toch wel wat foutjes had gemaakt. Dit haal je uit de confusion matrix, waarbij je kunt zien welke uitvoer op welke foute manier gelabeld wordt. Dan zie je bijvoorbeeld dat ‘parties’ clausules vaak als security clausules worden aangemerkt, zodat je specifiek daar extra voorbeelden van toe kunt voegen en foutcorrectie kunt doorvoeren.

Ook ontdekte ik dat ik de nodige categorieën had die ik zelf eigenlijk niet snapte. Overlap tussen categorieën maakt dat ML systemen slecht performen. Snoeien dus, en zorgen dat je per categorie duidelijk kunt aangeven wat erin hoort. Toch het nadeel van in halfslaap taggen wellicht?

De ingewikkeldste ingreep had te maken met dit soort clausules:

Recipient shall (a) treat all Confidential Information with the highest care; (b) only permit persons having a clear need to know access; (c) evaluate the Confidential Information at its own risk; (d) comply with relevant export regulations; (e) indemnify and hold harmless Discloser from any damages in connection with usage of the Confidential Information; and (f) waive its right to a jury trial.

Welke categorie plak je hier nu weer op? Het artikel regelt van alles, van security eisen tot wie het mag zien tot aansprakelijkheid en iets met juryrechtspraak. Daar kun je dus helemaal niets mee. Dat moest worden opgesplitst. Een hele vieze reguliere expressie (dit gaat een thema worden in het verhaal) splitste zo’n clausule in meerdere tegelijk, waarbij elke één van die zes bullet items bevatte.

En wat ook nog eens leuk bleek te werken, was bij elke zin mee te geven op welke plek hij in het document stond. Een zin over Florida aan het begin van een NDA gaat meestal over waar een partij gevestigd is. Staat hij aan het einde, dan is het waarschijnlijk de rechtskeuze. Dus kreeg elke zin als extra veld mee waar hij in het document stond. En hoe lang hij was (in woorden) want dat blijkt ook uit te maken. Grof gezegd, hoe langer een zin hoe strenger de bepaling. Soms is juridisch werk heel makkelijk.

Stiekem ook nog wat reguliere expressies bij de kwalificatie van clausules. Want sommige dingen zijn inschattingen (is dit streng of juist niet), anderen zijn gewoon simpel lezen. Een rechtskeuze voor Florida is geen inschatting, dat zie je gewoon letterlijk staan. Dus als je weet dat een clausule over rechtskeuze gaat (dat zegt de 1st stage classifier) dan kijk je gewoon welk land je ziet staan in die clausule en dat zal de rechtskeuze dan wel zijn.

Idem voor duur van het contract. Een AI heeft héél veel moeite met lezen of er staat dat een contract drie jaar duurt. Maar een reguliere expressie vindt hem zo. Deze oplossing is wat lomp, maar computers zijn snel en krachtig genoeg en het scheelt ontzéttend veel in de uitvoer. Mag ik zeggen, de regexp is de ducttape van de artificial intelligence?

Als laatste truc voegde ik vlaggetjes toe. Een machine learning systeem kijkt in principe naar losse woorden, maar juist in juridische teksten gebruikt men vaak vaste uitdrukkingen (“reasonable security measures”, “confidential information”, “receiving party”) en die moet je dus niet opsplitsen. De vlaggetjes werden toegevoegd met wéér een setje reguliere expressies, en dat gaf alles bij elkaar een hele mooie verbetering: een F1 van 0,86. Genoeg om de markt mee op te durven.

(Dit is de tweede van vijf vakantieberichten.)

Arnoud

De geboorte van NDA Lynn, of hoe bouw je een lawyerbot #ndalynnweek

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

Zou je een robot vertrouwen die je juridisch advies geeft?

Afgelopen week kwam nog een interessante kwestie langs over NDA Lynn haar kwaliteiten: wie zou er durven te varen op het advies van een robot? Want nou ja, het blijft software en die maakt fouten. En leuk en aardig dat ze gemiddeld 94,1% van de zinnen correct herkent, maar een geniepige zin die net in die 6,9% valt wordt dan dus gemist. Bovendien, hoe kun je achterhalen wat Lynn nu doet, echt uitleg op zinsniveau krijg je niet. Dus moet je dat wel vertrouwen, zo’n robotadvies?

Het punt van die uitleg is een algemene zorg bij AI beslissingen en -adviezen. Veel AI opereert als black box, je gooit er een input in en je krijgt te horen wat de output is, maar over het waarom zwijgt het systeem. En als je dan in die doos kijkt, dan helpt dat maar beperkt. Vaak komt het neer op “het leek meer op categorie A dan categorie B”, maar zien welke factoren daarbij de doorslag gaven, is erg moeilijk. Ook het doorgronden van die factoren is soms een puzzel; Lynn vond bijvoorbeeld een tijd NDA’s onder Californisch recht strenger, omdat mijn traindataset toevallig veel strenge Californische en wat relaxtere Europese NDA’s bevatte.

De angst voor dit soort onduidelijkheid speelt met name bij besluiten over personen. De AVG bevat een streng verbod op geautomatiseerde besluiten op basis van profielen, en AI-gebaseerde analyses “u krijgt geen hypotheek” vallen daar natuurlijk onder. Vandaar dat er tegenwoordig veel wordt geïnvesteerd in uitlegbare AI.

Toevallig heeft BigML (de technologie achter NDA Lynn) dat ook – het systeem produceert heel grof gezegd een stapel gigantische beslisbomen en geeft het gewogen gemiddelde van elke boom z’n uitkomst als de uitslag. Je kunt dus exact zien hoe een classificatie tot stand komt: er stond “state of California” achterin, ik zag ook “security measures” dus dit is een strenge NDA. Het is uitleg, maar niet eentje waar je perse veel aan hebt.

De cynicus mag nu reageren dat uitleg van een menselijke jurist óók lastig te volgen is voor een leek. Maar daar gaan we dan toch in mee, en de reden is simpel: die jurist vertrouwen we. Hij heeft er voor geleerd, hij doet dit al tien jaar, hij heeft een dik pand en een sjiek pak dus de zaken gaan goed, hij is verzekerd tegen claims en ga zo maar door.

Een AI heeft dergelijke vertrouwensfactoren niet, dus is het veel moeilijker om in te schatten of het klopt. In een Engels onderzoek bleek bijvoorbeeld slechts 7% van de mensen een AI advies over financiën te vertrouwen. Gek genoeg zou 14% wel onder het mes gaan bij een robotchirurg. Waar zit hem het verschil? Het mentale model dat we hebben bij deze handelingen, denk ik. Dat een robot heel precies en met vaste hand kan snijden, dat is voor te stellen. Dat hij ook geen millimeter af zal wijken van waar hij moet zijn, dat is ook nog wel logisch. Maar dat een robot mijn financiële situatie snapt en een passende hypotheek uitzoekt, nee dat is bizar.

Wat zit daar dan achter? Is het het fysieke, dat we een robotarm met mesje kunnen zien en ongeveer kunnen inschatten dat dat kan werken? Of is het de intelligentie die nodig is – bij een chirurg is dat vrij rechtomlijnd, bij een advies is het veel fuzzy’er. Een hart is een concreet item dat je tegen kunt komen in een borstkas, en daar doe je dan wat mee. De opties lijken daarmee eindig. Terwijl bij een advies het veel lastiger voorstelbaar is dat zo’n robot alle situaties kan inschatten. Dus dat is enger, en dan denkt men: doe maar niet.

Dus, hoe krijgt een adviesrobot het vertrouwen in zijn kunnen omhoog? Kwestie van gewoon doen en wachten tot men omslaat?

Arnoud

Kan een robot juridisch advies geven?

Twee weken geleden lanceerde ik NDA Lynn, een AI lawyerbot die geheimhoudingscontracten (NDA’s) kan lezen. Dat gaf veel leuke reacties, en Lynn heeft aardig bijgeleerd: meer dan 400 extra NDA’s waar ik verder mee kan trainen. Opmerkelijkste observatie: veel Nederlandstalige NDA’s, terwijl Lynn toch volgens mij vrij duidelijk Engelstalig is. Dat moet dus even anders. Maar ook de nodige andere kwesties.

Veel reacties gingen natuurlijk over de kwaliteit. Lynn beoordeelt zinnen in 87% (huidige versie 93.8%) van de gevallen correct, en kan daarmee clausules dus behoorlijk goed maar niet perfect herkennen. Dat is dus een risico, ze kan een clausule dus afkeuren of roepen dat die er niet in staat, enkel omdat de bewoordingen anders waren dan in haar trainingset. Maar mijn inschatting is dat dit wel meevalt omdat het gemiddeld wel goed uitkomt. Wel een probleem is nog de afhandeling van echte fouten, zoals een document waar geen tekst uit komt (een gescande PDF) of een tekst die in het geheel geen NDA is (ik kreeg onder meer Charles Dickens Night before Christmas langs, gelukkig was het advies die niet te tekenen).

Leuk vond ik de aandacht van Sprout en Emerce, die beiden ingaan op mijn motivatie: een kleine 18 jaar bezig zijn met NDA’s heeft me een grondige hekel aan die dingen gegeven (en nee, er 400 screenen in twee weken om je lawyerbot te verbeteren hielp niet), dus een automatische adviesbot is gewoon een mooie manier om tijd vrij te maken voor de leukere dingen in het juridische werk.

Want dat is uiteindelijk waar het volgens mij om gaat met AI in het recht. Robots gaan nooit advocaten vervangen, of het hoogwaardig juridisch advies over nieuwe kwesties. Robots doen per definitie standaardwerk, oftewel dingen als het screenen van stapels documenten of het spotten van kleine stiekemigheden in standaardcontracten of algemene voorwaarden. Als je als mens die dingen niet meer hoeft te doen, maar juist de afwijkingen krijgt en daar een oplossing voor moet vinden, dan heb je toch gewoon léuker werk dankzij een robot?

Vanuit de VS kreeg ik hele andere reacties: stop right there buddy, that’s unauthorized practice of law. Een beetje juridisch advies geven zonder advocatentitel, dat kan natuurlijk niet. Nu geef ik natuurlijk geen juridisch advies in de VS, maar dit blijkt dus een dingetje: allerlei tools zoals adviesbots en documentgeneratoren worden in diverse staten als advocaatjespelen aangemerkt en dus verboden. De achterliggende argumentatie is dat alleen een gekwalificeerd advocaat met tuchtrecht, verzekering en toezicht de kwaliteit kan bieden waar de burger recht op heeft.

Bij Justia staat een overzicht van de problematiek, met name: waar trek je de grens. De interessantste definitie vond ik “if a computer could do it, it’s not the practice of law.” Anders gezegd, juridische bijstand moet per definitie door een mens worden gedaan, omdat het creativiteit en inzicht vergt om de per definitie niet vastomlijnde set regels uit de wet toe te kunnen passen op een concreet geval. Ik twijfel of ik het ermee eens ben, want volgens mij kan best een aardig deel van zulk advieswerk geautomatiseerd gedaan worden. Zeg maar de 80% van de gevallen met de standaardsituaties die gewoon helder in de wet benoemd zijn. Het leuke stuk van de juristerij begint bij die 20%, maar dat wil niet zeggen dat de rest geen juridisch advies meer te noemen is.

En nou ja, uiteindelijk is dat volgens mij het voordeel dat je kunt halen met de inzet van AI. Automatiseer het saaie werk en maak je eigen werk leuker. Op naar de volgende Lynn dus, wat mij betreft.

Arnoud

Ik heb een AI gemaakt die NDA’s kan reviewen

De blogs over legal tech van de afgelopen tijd waren voor diverse mensen (hoi) speculatie: ben je iets aan het doen op dat gebied? En jawel, dat klopte: ik heb een AI gemaakt die NDA’s reviewt, en ze heet NDA Lynn. Ze is gratis en geeft deskundig en praktisch advies of je dat geheimhoudingscontract moet tekenen of niet.

De NDA of geheimhoudingsovereenkomst is een standaardding in veel zakelijke transacties, met name in de high-tech sector. (Ik zag eens de term “Silicon Valley Handshake” voorbij komen voor het ritueel van elkaars NDA tekenen voor je koffie ging drinken.) Grofweg is het een heel standaard document: we gaan praten, we houden dingen geheim en pas na X jaar mag je erover praten, oh ja en let op je beveiliging. Maar uiteraard is elke NDA weer wat anders, dus je blijft lezen elke keer.

Natuurlijk kun je elke keer naar een advocaat of jurist en vragen om een review, maar dat kost geld. Voor zo’n standaardding voelt dat niet als de moeite waard, is mijn ervaring. En ook voor de reviewende jurist is het niet perse leuk werk: ik denk dat ik in de bijna 20 jaar dat ik dit werk doe, meer dan 1500 NDA’s heb gereviewd, en ik kan je zeggen – weinig dingen zo saai en onproductief als daarover steggelen.

Een AI heeft daar allemaal geen last van. Vandaar NDA Lynn. Ze is een support vector network (mede mogelijk door het fantastische BigML.com) dat getraind is op een grote hoeveelheid publiek beschikbare NDA’s, en de clausules daaruit kan herkennen en classificeren. De uitvoer wordt gekoppeld aan een adviestabel, en zo komt ze tot de conclusie van tekenen of niet. Wie alles over de opzet wil weten, kan dit paper lezen.

Ongetwijfeld zullen er fouten in NDA Lynn zitten, het is en blijft software. Maar het is in ieder geval beter dan die dingen handmatig blijven reviewen, of blind tekenen omdat er “MUTUAL NON-DISCLOSURE AGREEMENT” op pagina 1 staat.

Ik ben heel benieuwd wat jullie van haar vinden.

Arnoud