Legal-Tech-SaaS: Dokumentenmanagement, E-Signaturen und Audit-Trails, die vor Gericht bestehen
Legal-Tech-SaaS trägt eine andere Last als die meiste B2B-Software. Ein CRM, das einen Datensatz verliert, ist ärgerlich. Eine Vertragsmanagement-Plattform, die nicht beweisen kann, wann ein Dokument von wem signiert wurde und ob es danach verändert wurde, kann den Fall eines Mandanten kosten. Die Entwicklung von Legal-Tech-SaaS muss zwei Zielgruppen gleichzeitig zufriedenstellen: die Endnutzer, die ein schnelles, benutzbares Produkt wollen, und die Gerichte, Regulierungsbehörden und gegnerischen Anwälte, die die Beweisspur der Plattform genau prüfen werden, falls jemals etwas strittig wird.
Genau hier gehen viele Legal-Tech-Projekte schief. Teams behandeln Dokumentenspeicherung, E-Signaturen und Audit-Logging als drei separate Features, die man an einen Standard-SaaS-Stack anflanscht, obwohl es in Wahrheit ein System mit einer einzigen Aufgabe ist: Beweise zu erzeugen, die ein Kreuzverhör überstehen.
Dokumentenspeicherung, die rechtlich belastbar bleibt
Ein als veränderliche Datenbankzeile gespeicherter Vertrag ist ein Risiko. Wenn ein Dokument nach der Unterzeichnung an Ort und Stelle bearbeitet werden kann und die Datenbank keine Aufzeichnung dieser Bearbeitung führt, kannst du nicht beweisen, dass die Version, die ein Gericht sieht, tatsächlich die Version ist, der die Parteien zugestimmt haben.
Die Lösung ist unveränderliche Speicherung mit nachprüfbarer Versionshistorie. Jedes signierte Dokument wird einmal geschrieben, bekommt bei der Schreiboperation einen kryptografischen Hash berechnet, und wird nie an Ort und Stelle aktualisiert. Änderungen erzeugen eine neue, mit dem Original verknüpfte Version, kein Überschreiben. In einer Symfony-Anwendung bedeutet das meist, das kanonische PDF oder XML in Object Storage abzulegen (S3-kompatibel, mit auf Bucket-Ebene aktivierter Versionierung) und den Datenbankeintrag als Metadaten zu führen: ein Hash, ein Timestamp, ein Versionszeiger und eine Referenz auf den Storage-Key. Beim Lesen berechnest du den Hash neu und vergleichst ihn mit dem gespeicherten Wert. Stimmen sie nicht überein, wurde das Dokument manipuliert, und die Anwendung sollte das sagen, statt still beschädigten Inhalt auszuliefern.
Timestamps sind hier wichtiger als in den meisten Bereichen. Eine lokale Serveruhr reicht nicht, wenn ein Streit einmal genau davon abhängt, wann ein Dokument finalisiert wurde. Vertrauenswürdiges Zeitstempeln (RFC 3161) gegen eine qualifizierte Zeitstempelstelle gibt dir einen signierten Nachweis, dass ein Dokument zu einem bestimmten Zeitpunkt in einem bestimmten Zustand existierte, unabhängig von deiner eigenen Infrastruktur. Für Legal-Workflows mit hohem Einsatz ist der zusätzliche API-Aufruf das wert.
E-Signaturen unter eIDAS: welche Stufe du wirklich brauchst
Die eIDAS-Verordnung definiert drei Stufen elektronischer Signatur, und die meisten Legal-Tech-Teams greifen entweder standardmäßig zur schwächsten, weil sie am günstigsten zu integrieren ist, oder zur stärksten, weil sie sicherer klingt, ohne zu prüfen, was der zugrundeliegende Rechtsakt tatsächlich verlangt.
Eine einfache elektronische Signatur (eine Checkbox, ein getippter Name, ein Klick-zum-Signieren-Button) ist für die meisten Verträge in der EU rechtlich gültig, aber am leichtesten anzufechten, weil sie den schwächsten Nachweis dafür liefert, wer signiert hat und ob der Inhalt danach verändert wurde.
Eine fortgeschrittene elektronische Signatur (AES) ist eindeutig mit dem Unterzeichner verknüpft, kann ihn identifizieren, wird mit Daten erstellt, die der Unterzeichner kontrolliert, und ist so mit den signierten Daten verbunden, dass jede spätere Änderung erkennbar ist. Diese Stufe sollten die meisten Vertragsplattformen für Standard-Handelsverträge anstreben: Sie ist ohne Hardware-Token erreichbar, typischerweise über eine identitätsgeprüfte Signiersitzung plus ein kryptografisches Siegel auf dem Dokument.
Eine qualifizierte elektronische Signatur (QES) ist eine AES, erstellt mit einer qualifizierten Signaturerstellungseinheit und abgesichert durch ein qualifiziertes Zertifikat eines Vertrauensdiensteanbieters auf der EU-Vertrauensliste. QES ist die einzige Stufe, die in allen EU-Mitgliedstaaten dieselbe rechtliche Vermutung der Gültigkeit trägt wie eine handschriftliche Unterschrift, und sie ist für bestimmte Kategorien vorgeschrieben: bestimmte Immobiliengeschäfte, manche Arbeitsverträge je nach Rechtsraum, und jede Vereinbarung, bei der nationales Recht sie ausdrücklich verlangt.
Liegst du hier falsch, egal in welche Richtung, hast du ein Problem. Unterversorgung (eine einfache Signatur zu nutzen, wo das Gesetz QES verlangt) kann den Vertrag unwirksam machen. Überversorgung (jeden Nutzer durch einen QES-Flow mit Identitätsprüfung und qualifiziertem Zertifikat zu schicken) fügt Reibung und Kosten zu Transaktionen hinzu, die das nicht gebraucht hätten. Der praktische Ansatz ist ein Signaturstufen-Selektor in der Workflow-Schicht: Der Dokumenttyp und der Rechtsraum bestimmen, welche eIDAS-Stufe erforderlich ist, und die Plattform leitet die Signiersitzung entsprechend an die passende Provider-Integration weiter. Wolf-Tech hat das als Strategy Pattern in Symfony umgesetzt, wobei jede Signaturstufe gegen ein gemeinsames Interface implementiert ist, damit ein Kunde mit AES für die meisten Verträge starten und QES-Unterstützung für die Teilmenge hinzufügen kann, die sie braucht, ohne den Signier-Flow neu zu architektieren.
Audit-Trails: was ein Gericht tatsächlich sehen will
Eine Signatur ist nur die halbe Beweislage. Die andere Hälfte ist der Audit-Trail, der alles zeigt, was rund um sie passiert ist: wer auf das Dokument zugegriffen hat, von welcher IP-Adresse, wann jede Aktion stattfand, und ob die Abfolge der Ereignisse in sich konsistent ist.
Das Audit-Log selbst braucht dieselben Unveränderlichkeitsgarantien wie das Dokument. Eine Append-Only-Log-Tabelle, oder besser, ein einmal geschriebenes Log, das an externen Speicher gesendet wird, den die Anwendung nachträglich nicht ändern kann, verhindert die unangenehme Situation, dass der eigene Audit-Trail der Plattform genau das ist, was vor Gericht angefochten wird. Jeder Eintrag sollte den Akteur, die Aktion, einen serverseitig erzeugten Timestamp, die IP-Adresse und einen Hash erfassen, der ihn mit dem vorherigen Eintrag verkettet, sodass jede Lücke oder Umsortierung im Log erkennbar ist.
Nichtabstreitbarkeit ist der juristische Begriff für das, worauf das hinausläuft: genug Beweise, dass ein Unterzeichner glaubhaft nicht bestreiten kann, unterschrieben zu haben. Das bedeutet, nicht nur den Klick zu erfassen, sondern den Kontext drumherum. Welche Dokumentversion im Moment der Signatur angezeigt wurde. Welche Identitätsprüfung, falls vorhanden, der Signatur vorausging. Ob der Unterzeichner die Gelegenheit hatte, das vollständige Dokument zu lesen (Scroll-Tracking ist genau aus diesem Grund verbreitet, so unvollkommen es als Proxy auch ist).
Nichts davon muss exotische Technik sein. Es muss konsistent sein, und es muss von Anfang an so konzipiert werden, statt erst hinzugefügt zu werden, nachdem ein Kunde während eines Streits danach fragt.
Der DSGVO-Aufbewahrungskonflikt, mit dem niemand plant
Legal-Tech-Plattformen sitzen an einer unbequemen Schnittstelle: Der Grundsatz der Datenminimierung der DSGVO besagt, personenbezogene Daten nicht länger als nötig aufzubewahren, während nationale gesetzliche Aufbewahrungspflichten oft verlangen, dass bestimmte Kategorien von Verträgen und zugehörigen Unterlagen über längere Zeiträume aufbewahrt werden, häufig ein Jahrzehnt oder mehr, je nach Rechtsraum und Dokumenttyp.
Diese beiden Pflichten heben sich nicht gegenseitig auf. Art. 6 Abs. 1 lit. c DSGVO liefert eine Rechtsgrundlage für Verarbeitung (einschließlich Aufbewahrung), die zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist, was die meisten gesetzlichen Aufbewahrungspflichten abdeckt. Die praktische Arbeit besteht darin, sicherzustellen, dass die Aufbewahrungsfrist dokumentiert, an eine konkrete Rechtsgrundlage pro Dokumentkategorie geknüpft und automatisch durchgesetzt wird, statt einer manuellen Bereinigung überlassen zu bleiben, die nie passiert. Ein als signierter Vertrag mit zehnjähriger Aufbewahrungspflicht markiertes Dokument sollte programmatisch von einer generischen, anderswo in der Plattform angewendeten "nach zwei Jahren löschen"-Datenminimierungsrichtlinie ausgenommen sein.
Wirklich schwierig wird es bei gemischten Datensätzen: einem Dokument, das sowohl die gesetzlich vorgeschriebenen Vertragsbedingungen als auch personenbezogene Daten enthält, die über das hinausgehen, was die Aufbewahrungspflicht abdeckt, etwa eine interne Notiz, die während der Verhandlung hinzugefügt wurde. Den ganzen Datensatz zu löschen riskiert, Beweise zu vernichten; alles zu behalten riskiert einen Verstoß gegen die Minimierung. Das praktikable Muster ist Aufbewahrung auf Feldebene statt auf Datensatzebene: Das eigentliche signierte Dokument bleibt für die gesetzliche Frist intakt, während zusätzliche personenbezogene Daten, die nicht von der Aufbewahrungspflicht abgedeckt sind, nach eigenem Zeitplan pseudonymisiert oder entfernt werden.
Wie das in der Praxis aussieht
Wolf-Tech hat Legal-Tech-Workflows für europäische Kunden gebaut, bei denen diese vier Bausteine (unveränderliche Speicherung, gestufte E-Signaturen, hash-verkettete Audit-Logs und aufbewahrungsbewusste Löschung) als ein System zusammenarbeiten statt als vier separate Module. Die Auftragsverarbeitungsverträge für Legal-Tech-Kunden sind tendenziell detaillierter als eine typische SaaS-DPA, weil der Verarbeiter Beweise handhabt, nicht nur Daten, und beide Seiten explizit klären müssen, wer für die Durchsetzung der Aufbewahrung verantwortlich ist, wer die Zeitstempel-Schlüssel hält, und was mit dem Audit-Trail passiert, wenn der Vertrag mit dem Anbieter endet.
Wenn du eine Legal-Tech-Plattform baust oder prüfst und eine zweite Meinung dazu willst, ob die Dokument- und Signaturarchitektur tatsächlich standhält, falls sie angefochten wird: Wir bieten Custom Software Development für Legal- und Compliance-lastige SaaS an, und Code-Quality-Beratung, wenn du bereits eine Plattform hast und wissen musst, wo die Beweislücken liegen, bevor ein Kunde sie für dich findet. Melde dich unter hello@wolf-tech.io, oder sieh dir mehr von unserer Arbeit auf wolf-tech.io an.