Warum Vertragsdatenextraktionsprojekte
ins Stocken geraten, bevor sie beginnen

Warum die meisten Projekte schon vor dem ersten Tag scheitern

Die gängige Erzählung über gescheiterte Vertragsextraktionsprojekte konzentriert sich darauf, was während der Implementierung schiefgeht: Die Software war zu komplex, das Training unzureichend, die Leute haben sie nicht übernommen. Die ILTA 2024 Technology Survey bestätigt, dass 54 % der Kanzleien „Widerstand gegen Veränderungen bei den Nutzern" als größtes Hindernis nennen, und 42 % verweisen auf „nicht genug Zeit zum Lernen".

Aber dies als Problem der Nutzerakzeptanz zu betrachten, verfehlt das eigentliche Problem. Der Grund, warum Menschen neuen Extraktionstools widerstehen, ist nicht Sturheit – es ist, dass das Projekt so angelegt war, dass es etwas hervorbringt, das niemand nutzen kann. Wenn ein Paralegal die Ausgabetabelle öffnet und Parteinamen findet, die nicht übereinstimmen, Daten in drei verschiedenen Formaten und eine Spalte namens „Governing Law", die in der Hälfte der Zeilen „siehe Abschnitt 14" sagt, dann ist der Instinkt, zur manuellen Prüfung zurückzukehren, kein Widerstand gegen Veränderung. Es ist eine rationale Reaktion auf schlechte Daten.

Im Folgenden finden Sie fünf konkrete Fehler – die Art, die aus Erfahrung kommt, nicht aus der Theorie – die Vertragsdaten-Extraktionsprojekte töten, bevor sie wirklich begonnen haben. Jeder hat ein erkennbares Muster, eine Ursache, die tiefer liegt als das Symptom, und eine umsetzbare Korrektur, die das Ergebnis verändert.

Extraktion als einmaligen Export zu behandeln, garantiert veraltete Daten

Der häufigste Ausgangspunkt ist auch der gefährlichste: „Wir müssen nur alle unsere Verträge in eine Tabelle bekommen." Diese Rahmung behandelt die Vertragsdaten-Extraktion als Archivprojekt – eine einmalige Migration von PDF zu Excel, die, sobald abgeschlossen, erledigt ist.

Die Ursache liegt tiefer als Ungeduld. Die meisten Rechtsteams haben über Jahre Verträge ohne strukturierte Metadaten angesammelt, und der Rückstand fühlt sich dringend an. Es gibt eine Vorstandssitzung in zwei Wochen, oder ein Compliance-Audit, oder eine Fusion. Der Druck, etwas zu produzieren, überlagert die Disziplin, etwas zu bauen, das Bestand hat. Das Ergebnis ist eine Tabelle, die am Tag ihrer Erstellung bereits veraltet ist – denn zwischen Extraktion und Lieferung wurden drei neue Verträge unterzeichnet, und niemand weiß, wie die Datei aktualisiert werden kann, ohne die gesamte Übung zu wiederholen.

Eine Juro-Umfrage ergab, dass nur 11 % der Unternehmen ihr Vertragsmanagement als „sehr effektiv" einstufen. Die 89 %, die das nicht tun, scheitern nicht, weil ihnen Verträge fehlen – sie scheitern, weil sie Vertragsdaten als Liefergegenstand behandeln (eine Tabelle zum Übergeben) statt als Pipeline (einen wiederholbaren Prozess, der aktuell bleibt).

Die Korrektur: Bevor Sie ein einziges Feld extrahieren, definieren Sie, wie die Daten im nächsten Monat aktualisiert werden. Wenn Ihre Antwort „das finden wir später heraus" ist, bauen Sie ein Archiv, kein System. Eine wiederholbare Extraktionspipeline bedeutet, dass Sie denselben Prozess auf neue Verträge erneut anwenden können – sei es durch das Hochladen von Stapeln über ein Extraktionstool oder durch die Einrichtung eines Workflows, der Vertragsdaten zugänglich macht auf laufender Basis, nicht nur während der Projekt-Hochphase.

Alles extrahieren statt das, was Fragen beantwortet

Wenn ein Juristenteam zum ersten Mal auf ein KI-gestütztes Extraktionstool stößt, ist der natürliche Instinkt, alles erfassen zu wollen. Fünfzig Felder. Einhundert. Jeder Klauseltyp, jedes Datum, jede benannte Entität, die irgendwo im Dokument auftaucht. Das fühlt sich gründlich an. In Wirklichkeit ist es der schnellste Weg, ein Projekt zu beenden.

Die Ursache ist eine durchaus verständliche Sorge: „Was, wenn wir dieses Feld später brauchen und es nicht extrahiert haben?" Dieses von Angst getriebene Scoping erzeugt eine Feldliste, die niemand validieren, pflegen oder nutzen kann. Jedes zusätzliche Feld erhöht die Extraktionslatenz, vergrößert die Fehlerprüfungsfläche und – am kritischsten – lenkt die Aufmerksamkeit des Teams auf so viele Datenpunkte, dass Qualitätsprüfungen bei Feldern mit hohem Risiko von Rauschen verdrängt werden. Die ILTA-Studie, wonach 42 % der Kanzleien unzureichende Lernzeit anführen, steht in direktem Zusammenhang damit: Wenn Ihr Extraktionsumfang 50 Felder tief ist, hat niemand Zeit, etwas ordnungsgemäß zu überprüfen.

Betrachten Sie eine kleine Hausverwaltungsfirma mit 87 Mietverträgen. Sie könnten versuchen, jede Instandhaltungsklausel, jede Untervermietungsbeschränkung, jedes Haustierrichtlinien-Detail zu extrahieren. Oder sie könnten die fünf Felder extrahieren, die 80 % ihrer operativen Entscheidungen antreiben: Mietername, monatliche Miete, Vertragsendedatum, Kaution und automatische Verlängerungsklausel (ja/nein). Fünf Felder, 87 Verträge, alles an einem Nachmittag beantwortbar. Der zweite Ansatz erzeugt Daten, die der Betriebsleiter tatsächlich am Montagmorgen nutzt. Der erste Ansatz erzeugt eine überwältigende Tabelle, die ungeöffnet bleibt.

Die Korrektur: Bevor Sie Felder definieren, schreiben Sie die drei Geschäftsfragen auf, die die Daten beantworten sollen. Nicht „Welche Felder existieren in diesen Verträgen?", sondern „Was würde ich mit diesen Daten tun, wenn ich sie hätte?" Wenn ein Feld keiner beantwortbaren Frage zugeordnet werden kann, gehört es nicht in den Umfang. Für die meisten Teams decken 5–10 gut gewählte Felder – Parteinamen, Wirksamkeitsdaten, Geldbeträge, anwendbares Recht, Verlängerungsbedingungen – die überwiegende Mehrheit realer Fragen ab. Beginnen Sie dort. Fügen Sie weitere Felder erst hinzu, nachdem sich der erste Batch als genau und nutzbar erwiesen hat.

Parteinamendrift zerstört Berichte, bevor es jemand bemerkt

Von allen Fehlern bei der Vertragsdaten-Extraktion verursacht dieser den größten Schaden bei geringster Sichtbarkeit. In Ihrem Vertragsportfolio erscheint dieselbe Gegenpartei unter mehreren Namen: „Acme Corp." in einem Vertrag, „Acme Corporation" in einem anderen, „Acme Corporation, LLC" in einem dritten und „Acme Holdings North America" in einem vierten, der von deren internem Team erstellt wurde. Ein Extraktionstool erfasst jede Variante getreu, so wie sie erscheint. Ihre Berichte – Gegenpartei-Exposure, Verlängerungsverfolgung, Lieferantenausgabenanalyse – sind nun stillschweigend fehlerhaft.

Die Ursache liegt nicht am Extraktionstool. Es ist die Annahme, dass Vertragsparteinamen konsistent genug sind, um ohne Normalisierung als Datenbankschlüssel zu dienen. Das sind sie nie. Dieses Problem potenziert sich im großen Maßstab: Bei 200 Verträgen kann ein Mensch die Duplikate erkennen. Bei 2.000 können sie das nicht. Und bis jemand bemerkt, dass „Johnson & Associates" und „Johnson & Associates, P.C." als separate Unternehmen mit separaten Risikoprofilen verfolgt werden, sind monatelange Berichte falsch.

Im r/legaltech-Subreddit beschrieb ein Praktiker die grundlegende Lücke perfekt: „Jede Anwaltskanzlei, mit der ich spreche, hat dasselbe Problem, und keine hat es gelöst." Das Problem ist nicht, ein Extraktionstool zu finden – es geht darum, die extrahierten Daten vertrauenswürdig genug zu machen, um Entscheidungen darauf zu stützen.

Die Korrektur: Definieren Sie eine Normalisierungsregel vor der Extraktion, nicht danach. Legen Sie fest, wie die kanonische Form jedes Unternehmensnamens aussehen soll. Wenn Sie ein Tool verwenden, das die Spaltennamensextraktion unterstützt – bei der Sie festlegen, welche Daten Sie möchten (z. B. „Gegenparteiname") und die KI diese in jedem Dokument findet und extrahiert –, erstellen Sie eine Nachschlagetabelle oder Regel, die Varianten während der Extraktion einer Standardform zuordnet, nicht bei der manuellen Bereinigung. Hier kann eine berechnete Spalte nützlich sein: Sie können eine Regel definieren, die prüft, ob ein extrahierter Parteiname mit einer bekannten kanonischen Liste übereinstimmt, und Abweichungen kennzeichnet, bevor sie in Ihre nachgelagerten Systeme gelangen. Einige Teams pflegen ein lebendes Gegenpartei-Wörterbuch, das wächst, wenn neue Varianten auftauchen. Die Disziplin liegt nicht im Tool – sondern darin, anzuerkennen, dass Parteinamen unordentlich sind, und von Anfang an dafür zu planen.

Annahme, dass jede PDF maschinenlesbar ist

In einem Vertragsportfolio jeder Größe werden Sie auf gescannte PDFs stoßen — Vereinbarungen, die auf Papier unterschrieben, durch einen Scanner gezogen und als Bilder gespeichert wurden. Sie werden auf Fax-zu-E-Mail-Konvertierungen stoßen. Sie werden auf Dokumente stoßen, in denen die Textebene zwar vorhanden, aber verstümmelt ist — ein häufiges Artefakt älterer OCR-Engines. Diese Dokumente sehen gut aus, wenn Sie sie öffnen. Sie extrahieren schlecht.

Die Ursache dieses Fehlers ist ein blinder Fleck in der Art und Weise, wie Rechtsteams Dokumente bewerten. Anwälte verbringen ihre Karriere mit dem Lesen von Verträgen — sie verarbeiten Seiten visuell. Wenn jemand sagt „wir haben alle unsere Verträge digitalisiert", meint er oft „wir haben PDFs, die wir auf dem Bildschirm öffnen können". Aber es gibt einen enormen Unterschied zwischen einer PDF, die für Menschen lesbar ist, und einer, die maschinell extrahierbar ist. Eine gescannte Vereinbarung, bei der die OCR „Term" als „Tern" erzeugt hat, hindert einen Anwalt nicht daran, die Klausel zu verstehen. Sie hindert ein Extraktionstool sehr wohl daran, ein Kündigungsdatum korrekt zu identifizieren.

Hier kommt der Tool-Auswahl eine enorme Bedeutung zu. Herkömmliche template-basierte OCR-Tools — die Art, die nach Daten an bestimmten Koordinaten auf der Seite sucht — scheitern bei gescannten Verträgen katastrophal, weil die Textposition von Dokument zu Dokument variiert. Ein von Anbieter A unterzeichneter Vertrag sitzt anders auf der Seite als einer, der von Anbieter B unterzeichnet wurde, selbst wenn beide denselben Vertragstyp darstellen. Im Gegensatz dazu handhabt die Extraktion auf Basis visueller Sprachmodelle (VLM) Formatvariationen widerstandsfähiger, da sie Dokumentinhalte semantisch und nicht positionsbasiert versteht. Die KI liest das Dokument so, wie es ein Mensch tun würde: Sie lokalisiert „Wirksamkeitsdatum", indem sie versteht, was diese Wörter bedeuten, und nicht, indem sie sie an Pixelkoordinaten (x:340, y:210) erwartet.

Die Korrektur: Prüfen Sie vor der Auswahl eines Extraktionstools Ihre Vertragsformate. Ziehen Sie 20 zufällige Verträge aus dem Portfolio und kategorisieren Sie jeden: native PDF (Text auswählbar), gescannte Bild-PDF (keine Textebene) oder gemischt (einige Seiten durchsuchbar, einige nicht). Wenn mehr als 20 % gescannt sind, ist ein VLM-basierter Ansatz unverzichtbar — und Sie sollten zuerst Ihre Dokumente mit dem schlechtesten Format testen, nicht Ihre saubersten. Wenn Ihre Verträge handschriftliche Anmerkungen, Randnotizen oder gestempelte Änderungen enthalten, beziehen Sie diese ein. Das Tool, das Ihre 10 saubersten Verträge wunderbar verarbeitet, aber bei den 10 unordentlichen versagt, ist ein Tool, das eine Abdeckung von 50 % liefert.

Die Verwechslung von Dokumentenspeicherung mit Vertragsintelligenz

Dieser Fehler ist am schwersten zu erkennen, weil er in einer Sprache verborgen ist, die die Rechtsbranche etabliert hat. „Wir verwalten unsere Verträge in iManage.“ „Alles ist in NetDocuments.“ „Unsere Vertragsablage ist SharePoint.“ Jede dieser Aussagen beschreibt Dokumentenspeicherung – wo Dateien liegen – nicht Vertragsintelligenz – was diese Dateien enthalten. Die Lücke zwischen beiden ist der Ort, an dem Extraktionsprojekte scheitern.

Die Ursache ist ein Vokabularproblem, das ein Fähigkeitsproblem verschleiert. Dokumentenmanagementsysteme wie iManage und NetDocuments bieten Versionskontrolle, Zugriffsrechte und Volltextsuche. Aber die Volltextsuche über ein Vertragsportfolio beantwortet nur eine Frage: „Welche Dokumente enthalten dieses Wort?“ Sie kann nicht beantworten: „Welche Verträge laufen in den nächsten 90 Tagen ab?“, „Wie hoch ist unser gesamtes zugesagtes Ausgabevolumen mit diesem Anbieter?“ oder „Wie viele Vereinbarungen enthalten automatische Verlängerungsklauseln, die wir neu verhandeln sollten?“ Jede dieser Fragen erfordert strukturierte Daten – also Daten, die in Feldern liegen, nicht in Dateien.

Wenn ein Juristenteam sagt: „Wir verwalten unsere Verträge bereits digital“, und die Führungsebene darunter versteht: „Unsere Vertragsdaten sind zugänglich“, ist das Projekt bereits gescheitert. Die Annahme ist, dass Digitalisierung gleichbedeutend mit Datenzugriff ist. Das stimmt nicht. Ein Dokumentenmanagementsystem weiß, wo jeder Vertrag liegt. Es weiß nichts darüber, was ein Vertrag besagt.

Die Korrektur: Trennen Sie die Konzepte in jedem Projektgespräch explizit. Dokumentenspeicherung ist eine Grundvoraussetzung – notwendig, aber nicht ausreichend. Die Extraktion von Vertragsdaten ist die Ebene darüber, die gespeicherte Dateien in abfragbare Informationen verwandelt. Beides ergänzt sich, ist aber nicht austauschbar. Wenn Ihre Kanzlei in ein Dokumentenmanagementsystem investiert hat, umso besser – diese Infrastruktur erleichtert die Extraktion, weil die Dateien zentralisiert sind. Aber lassen Sie nicht zu, dass „Wir haben bereits ein Vertragssystem“ das Gespräch beendet. Was Sie haben, ist ein Ablagesystem. Was Sie brauchen, ist ein System, das Ihnen sagt, welche Verträge Aufmerksamkeit benötigen, ohne einen davon zu öffnen.

Was wirklich funktioniert: Fünf Entscheidungen, die das Ergebnis verändern

Jeder Fehler oben hat eine spiegelbildliche Korrektur. Zusammen bilden sie eine Checkliste vor Projektbeginn, die nichts kostet, aber die Folgefehler verhindert, die Gartner und ContractWorks in großem Umfang dokumentiert haben.

1. Beginnen Sie mit der Geschäftsfrage, nicht mit der Feldliste. Welche Entscheidung werden diese Daten unterstützen? Vertragsverlängerungsverhandlung? Compliance-Prüfung? Ausgabenanalyse? Die Frage bestimmt den Umfang. Wenn Sie die Frage nicht benennen können, extrahieren Sie Daten ins Leere.

2. Begrenzen Sie den Umfang beim ersten Durchgang auf 5–10 Felder. Beweisen Sie Genauigkeit und Nutzbarkeit an einem schmalen Satz, bevor Sie erweitern. Eine 5-Felder-Extraktion, die verifiziert und vertrauenswürdig ist, ist unendlich wertvoller als eine 50-Felder-Extraktion, die niemand prüft.

3. Normalisieren Sie bei der Extraktion, nicht bei der Bereinigung. Bauen Sie Standardisierungsregeln – insbesondere für Parteinamen und Datumsformate – in den Extraktionsschritt ein. Jede Stunde, die für die Bereinigung von Daten nach der Extraktion aufgewendet wird, ist eine Stunde vermeidbarer Kosten, die sich über wiederholte Durchläufe summiert.

4. Testen Sie zuerst mit Ihren schlechtesten Dokumenten. Der gescannte Vertrag von 2013 mit Kaffeeflecken und handschriftlicher Ergänzung ist Ihr bester Bewertungsfall. Wenn das Tool damit umgehen kann, haben Sie Abdeckung. Wenn nicht, kennen Sie die Lücke, bevor Sie einen Vertrag unterschreiben.

5. Planen Sie für wiederholte Durchläufe. Die erste Extraktion ist ein Meilenstein, keine Ziellinie. Stellen Sie sicher, dass Ihr Workflow – die Felddefinitionen, Normalisierungsregeln und das Ausgabeformat – nächsten Monat reproduzierbar ist, wenn 15 neue Verträge eintreffen. Batch-Extraktion, bei der Sie mehrere Verträge auf einmal hochladen und eine einzige zusammengeführte Tabelle erhalten, ist der Weg, dies nachhaltig zu machen und nicht zu einer einmaligen Kraftanstrengung.

Häufig gestellte Fragen

Funktioniert die Vertragsdaten-Extraktion bei gescannten PDFs?

Ja – aber die Qualität hängt stark von der zugrunde liegenden Technologie ab. Die Extraktion auf Basis von Vision-Large-Modellen (VLM) liest gescannte Dokumente semantisch, versteht also, was der Text bedeutet, statt ihn an festen Koordinaten zu suchen. Das kommt mit Formatvariationen bei gescannten Verträgen deutlich besser zurecht als herkömmliche koordinatenbasierte OCR. Bei stark beeinträchtigten Scans – starke Schräglage, dunkle Hintergrundartefakte, extrem niedrige Auflösung – sinkt die Genauigkeit jedoch unabhängig von der Technologie. Testen Sie immer mit Ihrer tatsächlichen Dokumentqualität, bevor Sie sich für ein Tool entscheiden.

Wie viele Felder sollten wir aus unseren Verträgen extrahieren?

Beginnen Sie mit 5–10 Feldern, die Ihre dringendsten Geschäftsfragen beantworten. Vertragsparteien, Wirksamkeitsdaten, Ablaufdaten, Geldbeträge, anwendbares Recht und ein Ja/Nein-Flag für wichtige Klauseln (Schiedsgerichtsbarkeit, automatische Verlängerung, Freistellung) decken die meisten realen Anforderungen ab. Widerstehen Sie dem Drang, alles zu extrahieren – jedes zusätzliche Feld vervielfacht den Prüfaufwand und verringert das Vertrauen in den Datensatz.

Wie gehen wir mit Parteinamen um, die zwischen Verträgen variieren?

Erstellen Sie einen Normalisierungsplan vor der Extraktion, nicht danach. Pflegen Sie eine kanonische Liste der Vertragsparteien und ordnen Sie Varianten zu. Wenn Ihr Extraktionstool berechnete Spalten oder regelbasierte Verarbeitung unterstützt, können Sie Namensabweichungen bereits bei der Extraktion kennzeichnen. Einige Teams pflegen ein gemeinsames Vertragsparteien-Wörterbuch in einer Tabellenkalkulation oder Datenbank, das mit neuen Varianten wächst. Das ist anfangs manuelle Arbeit, aber es ist der Unterschied zwischen Berichten, denen Sie vertrauen können, und Berichten, die stillschweigend fehlerhaft sind.

Können wir unser bestehendes Dokumentenmanagementsystem (iManage, NetDocuments, SharePoint) für die Vertragsdaten-Extraktion nutzen?

Ihr DMS speichert Dateien. Es extrahiert keine strukturierten Daten daraus. Die Volltextsuche in einem DMS kann finden, welche Dokumente ein Wort enthalten, aber sie kann nicht beantworten: „Wie hoch ist die Summe aller zugesagten Ausgaben über diese 40 Lieferantenverträge?" oder „Welche Mietverträge laufen im Q3 ab?" Die Vertragsdaten-Extraktion ist eine separate Ebene, die auf Ihrem DMS aufsetzt – sie liest die Dokumente, die Ihr DMS speichert, und erzeugt strukturierte, abfragbare Ausgaben. Die beiden Tools erfüllen unterschiedliche Zwecke und funktionieren am besten zusammen, nicht als Ersatz füreinander.

Wie lange dauert ein Vertragsdaten-Extraktionsprojekt in der Regel?

Bei einem Portfolio von 50–200 Verträgen mit einem fokussierten Umfang von 5–10 Feldern kann die Extraktion selbst in wenigen Stunden abgeschlossen sein, sobald Ihre Felddefinitionen und Normalisierungsregeln festgelegt sind. Der eigentliche Zeitaufwand liegt in den vorgelagerten Entscheidungen: der Definition von Geschäftsfragen, der Prüfung von Dokumentformaten und der Erstellung von Normalisierungsregeln. Diese Schritte vor der Extraktion dauern in der Regel 1–3 Tage konzentrierter Arbeit – und das Überspringen dieser Schritte ist die Ursache für die mehrmonatigen Implementierungsfehlschläge, die in den Gartner- und ContractWorks-Daten dokumentiert sind.