Worden inkoopvoorwaarden het volgende slachtoffer van legal tech?

| AE 13037 | Innovatie, Ondernemingsvrijheid | 19 reacties

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

Deel dit artikel

  1. Mijn klant heeft nog drie maanden “alleen de meest verse libraries” als tagline gehad. Dat vind ik nog helemaal zo gek nog niet, moderne software bestaat uit een aaneenschakeling van externe libraries. Dit zijn er soms zoveel dat het in bijna dagelijkse updates resulteert. Deze updaten kost wat moeite, en er kleeft risico aan (werkt het nog wel na update?), maar niet updaten geeft weer andere risico’s (beveiliging, performance). “alleen de meest verse libraries” gebruiken is dus nog zo gek nog niet 🙂

  2. Punten om in ieder geval melding van te maken of om te markeren lijken mij in ieder geval: 1. Betaaltermijnen (stel ze maken er in de inkoopvoorwaarden een jaar van, dan vind je daar als verkoper mogelijk wat van.) 2. Boeteclausules (zijn ze nog een beetje redelijk of totaal niet.) 3. Levertermijnen en gevolgen niet halen levertermijnen (bv doordat de klant de wensen wijzigt of traag op vragen reageert.)

    Als ICT’er zou ik op deze punten in ieder geval alert zijn.

  3. Wat een geweldig idee!

    Hier is mijn top 5:

    • In elk contract met een USA partij de unlimited “defend, indemnify and hold harmless” clausule, die er vaak ook zonder enig probleem weer uit wordt geschrapt wanneer je claimt dat dat belachelijk is.
    • Eisen dat leverancier “geen enkele wijziging” aanbrengt aan een SaaS-product, en een kopie op diskette willen ontvangen.
    • Een Nederlands waterbedrijf die voor de levering van een app in haar algemene inkoopvoorwaarden eiste dat we alle medewerkers regelmatig zouden laten testen op een of andere besmetting, duidelijk bedoeld voor monteurs e.d. die in aanraking kwamen met het waterleidingnet, maar van toepassing op elke medewerker van elke leverancier.
    • Een Duitse inkoper die bij het opsturen van de inkoopvoorwaarden alvast aankondigt “there will be a myriad of paperwork”
    • Een (andere) Duitse inkoper die een project een half jaar vertraagt over een discussie over een half procent van een al vrij lullig bedrag
  4. Een ml model heeft als nadeel dat de andere partij zich daarop gaat instellen. Zeg maar een model gaat maken van jouw model. Daarmee verandert de effectiviteit en betrouwbasrheid. Heb je daar een monitoring op, of is de verwachting dat die verandering zeer langzaam gaat?

    • Een beetje zoals GNNs werken? Daar heb ik niet expliciet rekening gehouden. Ik krijg wel vaak geopperd “wat nou als een creatieve advocaat dingen verstopt in andere clausules, en/of raar taalgebruik gebruikt zodat je bot het niet ziet”. Enige daarop is de data blijven reviewen en bijtrainen, plus het geruststellende besef dat dingen verstoppen in clausules (middenin een overmachtsbepaling een boetebeding) zakelijk héél slecht valt en dus denk ik ook niet in belang cliënt is. Plus raar taalgebruik leidt tot mogelijke aansprakelijkheid, want dan is de interpretatie/bedoeling van dat taalgebruik onzeker en dat wordt tegen de opsteller gebruikt.

  5. Het zou briljant zijn als we op termijn zouden kunnen toewerken naar Algemene Voorwaarden in een gestructureerd standaardformaat. Misschien in XBRL, net zoals jaarrekningen van (veel) ondernemingen dat tegenwoordig al zijn. Zodat je ook zonder al te veel AI kan bepalen waar verkoopvoorwaarden en inkoopvoorwaarden compatibel zijn, en waar ze elkaar bijten.

    Voor nu: ik beoordeel veel inkoopvoorwaarden en kijk dan vooral naar: – het expliciet niet van toepassing verklaren van verkoopvoorwaarden – fatale opleveringstermijnen i.c.m. met zware boetes – andere eenzijdig direct opeisbare boetebepalingen – ongemaximeerde (of idioot hoge) aansprakelijkheid – of overdracht van intellectueel eigendom wel beperkt is tot maatwerk-software (vaak wordt bedoeld of onbedoeld ook de standaardsoftware meegenomen) – soms wordt een eeuwigdurend en onherroepelijk Gebruiksrecht bedongen, terwijl we juist een gebruikslicentie willen afsluiten – “right to audit” bepalingen waarbij alle overlast en -kosten voor onze rekening komen – het vereisen van certificeringen waarover we niet beschikken (bijv NEN7510 ipv ISO27001) – eenzijdige recht om maatwerksoftware steeds maar niet te accepteren, waarbij het herstellen van de geconstateerde afwijkingen dan kosteloos door ons moeten worden opgelost

  6. Zelf hebben we in onze voorwaarden een aantal vrij belachelijke artikelen staan, zoals ‘we garanderen op geen enkele wijze dat het product geschikt is voor het beoogde gebruik’ en iets wat neerkomt op ‘garantie nog niet eens tot aan de deur’. De gemiddelde inkoper valt daar (terecht!) over, en dan schrappen we het artikel glimlachend.

    Les: iedere inkoper of klant die onze voorwaarden leest wil gewoon over een paar dingen zeuren, dus die hebben we alvast ingebouwd. Die geven we vrolijk op, en dan blijft de rest overeind.

    • Bekende strategie: neem wat rare eisen op die puur als wisselgeld dienen en om de aandacht van de belangrijke dingen af te leidden, zoals het voorstel om een peperduur paars fietsenhok bij een kerncentrale te bouwen, daar de hele inspraakavond over te praten, en hem dan te schrappen. Goede onderhandelaars hebben dat door, en beginnen met dat lijstje te noemen en even te zeggen, eerst dat even van tafel, en dan beginnen we met praten. Minder goede onderhandelaars (zoals ik) denken, krijg de hik maar, en zoeken een andere leverancier.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS