Legal-Tech-Software braucht mehr als Dokumentenerstellung

Legal Tech ist einer der fünf Bereiche, in denen wir Software entwickeln. Der häufigste Irrtum, den wir hier sehen: Man sucht den Wert des Produkts in den Dokumenten, die es erzeugt. Der eigentliche Wert liegt darin, dass die Regel im System jedes Mal auf dieselbe Weise funktioniert.

Betrachtet man die Präsentation eines Rechtstechnologieprodukts, sieht man mit hoher Wahrscheinlichkeit Folgendes. Es erstellt Vertragsentwürfe, schlägt Klauseln vor, formatiert das Dokument. Das sind nützliche Funktionen. Das Problem ist: Die eigentliche Frage des Gebiets ist das nicht, und das Problem, das diese Werkzeuge angeblich lösen, ist in Wahrheit der leichteste Teil des Problems.

Die eigentliche Frage liegt hier. Eine Organisation unterliegt einer rechtlichen Pflicht. Es wird eine Auslegung darüber getroffen, was diese Pflicht bedeutet. Die Auslegung wird in einem Dokument festgehalten. Dann wird dieses Dokument in einem Ordner abgelegt, und der tägliche Betrieb der Organisation läuft weiter, ohne von diesem Dokument zu wissen. Diese Trennung zwischen Dokument und System ist der teuerste Fehler, den ich in der Praxis sehe, und kein Vertragsvorlagen-Tool löst ihn.

Auslegung ist Sache des Menschen, Anwendung Sache des Systems

Eine Regel in Software umzusetzen bedeutet nicht, die Regel in Code zu schreiben. Dazwischen liegt ein Schritt, der sich nicht automatisieren lässt.

Artikel 7 des Gesetzes Nr. 6698 regelt, dass personenbezogene Daten gelöscht, vernichtet oder anonymisiert werden, wenn die Gründe, die ihre Verarbeitung erfordern, entfallen. Diese Vorschrift ist klar. Aber was bedeutet "der Wegfall des Grundes" konkret für die Rechnungsdaten einer Organisation? Das Ende der Kundenbeziehung, den Ablauf der steuerrechtlichen Aufbewahrungsfrist, oder das jeweils spätere der beiden? Diese Frage beantwortet eine Juristin oder ein Jurist. Die gegebene Antwort ist eine Auslegung, und solange diese Auslegung nicht dokumentiert wird, wird sich sechs Monate später niemand mehr erinnern, warum genau diese Frist gewählt wurde.

Hier beginnt die Aufgabe der Software. Nachdem die Auslegung getroffen wurde, dafür zu sorgen, dass sie jedes Mal in derselben Weise angewendet wird und dass die Anwendung nachweisbar ist. Verfügen Sie über ein System, das dies leistet, nutzen Sie Rechtstechnologie. Erzeugen Sie nur Vorlagen, nutzen Sie eine Textverarbeitung.

Was geschieht, wenn sich Dokument und System trennen

Gehen wir ein konkretes Beispiel durch. In der Aufbewahrungsrichtlinie einer Organisation steht, dass Kundenkommunikationsdaten zwei Jahre aufbewahrt werden. Bei einer Prüfung wird diese Richtlinie vorgelegt.

Die Prüferin oder der Prüfer stellt eine einzige Frage. Welche Komponente setzt diese Frist um?

Die Antwort fehlt meistens. In der Datenbank gibt es ein Feld created_at, aber kein expires_at. Es gibt keinen Vorgang, der den Datensatz bei Fristablauf löscht. Selbst wenn gelöscht wird, erzeugt dies keinen Nachweis. Am Ende kann die Organisation nicht zeigen, dass sie tut, was in ihrer Richtlinie steht. Die Richtlinie selbst ist kein Beweis, sondern allenfalls eine Absichtserklärung.

Der Weg, dieses Bild zu korrigieren, besteht nicht darin, einen besseren Richtlinientext zu schreiben. Er besteht darin, dem Datenmodell ein Feld hinzuzufügen, das die Aufbewahrungsfrist trägt, eine Komponente zu schreiben, die die Frist umsetzt, und dafür zu sorgen, dass diese Komponente bei ihrer Ausführung einen Nachweis erzeugt. Sind alle drei vorhanden, wird der Richtlinientext nicht länger zur bloßen Behauptung, sondern zur Beschreibung dessen, was das System tatsächlich tut.

Die fünf Glieder der Kette

Dass ein Rechtstext zu einer im System funktionierenden Kontrolle wird, geschieht in fünf Schritten. Die Reihenfolge dieser Schritte ist wichtig, und wird einer davon übersprungen, wird das Ergebnis unzuverlässig.

Zunächst wird die Vorschrift festgestellt. Die anzuwendende Regel und, falls vorhanden, ihre Ausnahme werden bestimmt. Danach erfolgt die Auslegung, das heißt, es wird entschieden, was die Regel im konkreten Geschäftsprozess bedeutet. Dieser Schritt obliegt dem Menschen und muss dokumentiert werden. Im dritten Schritt wird die Auslegung an die Architektur geknüpft, indem festgelegt wird, welches Feld welche Regel trägt. Im vierten Schritt wird die Komponente geschrieben, die die Regel im Betriebszeitpunkt anwendet. Im fünften Schritt wird die Ausführung dieser Komponente dokumentiert.

Eine ohne vorherige Auslegung geschriebene Kontrolle wendet die falsche Regel an. Eine Kontrolle, die keinen Nachweis erzeugt, nützt bei einer Prüfung nichts. Der Fehler, den ich häufig sehe, besteht darin, den dritten und vierten Schritt zu überspringen und direkt zum fünften überzugehen. Die Organisation führt ein Protokoll, trägt dort etwas ein, aber es ist nicht klar, welche Regel dieses Protokoll als angewendet zeigt.

Die Frage des Anwaltsmonopols

Es gibt eine Grenze, die jede Person, die in diesem Bereich Produkte entwickelt, kennen muss. Artikel 35 des Rechtsanwaltsgesetzes Nr. 1136 hat die Bearbeitung von Rechtsangelegenheiten und die Erteilung rechtlicher Gutachten den Rechtsanwälten vorbehalten.

In der Praxis bestimmt das, was Ihr Produkt sagen darf und was nicht. "In Ihrem Vertrag fehlt diese Klausel" zu sagen, ist Information. "Unterschreiben Sie diesen Vertrag nicht, er wird sich zu Ihren Lasten auswirken" zu sagen, ist eine Stellungnahme. Die Grenze dazwischen ist schmal und muss beim Produktdesign bewusst gewahrt werden. Die verlässlichste Methode, diese Grenze zu wahren, besteht darin, dass das System die Entscheidung nicht selbst trifft und hinter jedem Ergebnis eine menschliche Entscheidung sichtbar bleibt.

Diese Grenze wirkt wie ein Hindernis, ist aber in Wirklichkeit eine gute Gestaltungsbeschränkung. Ein System, das die Entscheidung nicht übernimmt, übernimmt bei einem Fehler auch nicht die Verantwortung, und das verhindert, dass Nutzende dem System blind vertrauen.

Was künstliche Intelligenz verändert hat und was nicht

Die Verarbeitung natürlicher Sprache bringt bei der Dokumentenprüfung einen echten Effizienzgewinn. Einen bestimmten Klauseltyp unter Hunderten von Verträgen zu finden, war früher eine Sache von Wochen. Jetzt dauert es Stunden.

Was sich nicht ändert, ist die Verantwortung. Lässt sich nicht nachvollziehen, aus welchem Dokument und welchem Absatz das vom Modell erzeugte Ergebnis stammt, ist dieses Ergebnis keine Feststellung, sondern eine Vermutung. Ebenso gilt: Zeigt das System ein Ergebnis, bei dem es sich nicht sicher ist, nicht unterscheidbar von einem, bei dem es sich sicher ist, vertraut die nutzende Person allen gleichermaßen, und der Fehler fällt nicht auf.

Sind diese beiden Bedingungen nicht erfüllt, wird der erzielte Effizienzgewinn später durch das entstehende Risiko wieder aufgezehrt. Das Schlimmste daran: Man weiß nicht, wann sich dieses Risiko verwirklicht.

Womit anfangen

Beim Start eines unternehmensweiten Rechtstechnologieprojekts empfehle ich, eine einzige Pflicht auszuwählen. Alle auf einmal anzugehen, klingt gut, aber in der Praxis wird keine davon fertig.

Für die gewählte Pflicht werden alle fünf Glieder vollständig aufgebaut. Die Vorschrift wird festgehalten, die Auslegung wird dokumentiert, an das Datenmodell geknüpft, die Kontrolle läuft, der Nachweis wird erzeugt. Diese Arbeit ist in sechs Wochen abgeschlossen, und am Ende haben Sie keinen Bericht, sondern eine funktionierende Kontrolle und einen bei einer Prüfung vorzeigbaren Nachweis.

Die zweite Pflicht geht viel schneller. Denn das Schwierige ist nicht die Regel, sondern die Kette zum ersten Mal aufzubauen.