Elk dossier begint op dezelfde manier, en het begin is het saaie deel. Iemand leest het inkomende stuk — een e-mailthread, een ondertekende overeenkomst, een cliënt-Word-document dat alle kanten op gaat — en typt dezelfde dingen in het dossier die hij al honderd keer eerder heeft getypt. Partijen. Jurisdictie. Sleuteldata. De vorderingen. De feiten die uiteindelijk in de chronologie terechtkomen. Het is zorgvuldig werk, het is langzaam, en niets eraan is het werk waarvoor u heeft gestudeerd.

Dus het eerste wat we in de engine hebben gebouwd, was een module die de stukken voor u leest.

Wat hij werkelijk doet

U selecteert het document en klikt op extracteren. De assistent leest het en geeft een gestructureerde dossierkaart terug: de partijen en hun rollen, de jurisdictie, de sleuteldata, de vorderingen en de feiten die hij van belang acht voor de dossierchronologie. Elk van die gegevens is een voorstel — geen feit dat in uw dossier is geschreven, maar een feit dat u wordt aangeboden om naar te kijken.

Cruciaal is dat elk voorgesteld feit een koppeling bevat naar de exacte alinea waaruit het is gehaald. Als de assistent zegt dat de overeenkomst gedateerd was op 14 maart, kunt u doorklikken naar de regel in het document die dat zegt en het zelf in een seconde controleren, in plaats van een samenvatting te vertrouwen en te hopen.

U gaat vervolgens de lijst door. Accepteer een feit, wijs het af, of bewerk het. Alleen wat u behoudt, wordt in het dossier geschreven. Niets belandt in uw dossier dat u er niet zelf in heeft gezet.

Waarom de bevestigingsstap het punt is, niet de frictie

Het had eenvoudiger geweest om een tool te schrijven die het document leest en het dossier direct invult. Het had ook fout geweest.

Een advocaat is verantwoordelijk voor wat er in het dossier staat. Een extractie die stilletjes twintig feiten in uw dossier schrijft — sommige juist, sommige subtiel onjuist, geen enkele beoordeeld — bespaart u geen werk; ze geeft u een aansprakelijkheid die u niet heeft gelezen. De menselijke bevestiging is geen beleefdheid die we er achteraf aan hebben toegevoegd. Het is het ontwerp. Het hulpmiddel stelt voor; u beslist. Dat is de juiste taakverdeling tussen een advocaat en een machine, en we waren niet bereid die te vervagen om er indrukwekkender uit te zien in een demo.

De terugverwijzing naar de bronsalinea is wat de bevestigingsstap snel maakt in plaats van vervelend. U herleest niet het hele document om de assistent te controleren — u werpt een blik op één gekoppelde alinea per feit.

Waar de stukken blijven

Het document dat u inbrengt, verlaat uw machine niet om te worden gelezen. Het dossier leeft in uw browser, op uw eigen schijf. Wanneer de assistent het model nodig heeft voor de extractie, wordt alleen de tekst die voor die stap vereist is verzonden — en de identiteit van uw cliënt wordt gestript voordat die vertrekt, en lokaal hersteld wanneer het antwoord terugkomt. De stukken in een lopend dossier zijn het meest gevoelige wat een kantoor bewaart; de architectuur behandelt ze standaard zo, niet op verzoek.

Wat het vervangt

Vóór: een advocaat of medewerker leest het inkomende stuk, typt de partijen en data in het dossier, kopieert de sleutelalinea's over, en hoopt dat niets is gemist op een vermoeide middag.

Erna: de module levert de dossierkaart en de feitensuggesties, en u beoordeelt elk voorstel tegen zijn bron en accepteert of verwerpt het.

De besparing is reëel, maar de stillere winst is het gevoel dat niets ontbreekt — elk feit in het document is aan de oppervlakte gebracht en voor u neergelegd, in plaats van afgeschreven op of u die dag nauwkeurig genoeg heeft gelezen. Dit draait vandaag op aanvraag, één document tegelijk. Het is het eerste wat de engine met een dossier doet, omdat het het eerste is wat een werkdag met een dossier doet.

← Alle artikelen