Warum Projekte zur Vertragsdaten-Extraktion
schon vor dem Start scheitern

Warum die meisten Projekte schon vor dem Start scheitern

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

Doch dies als reines Nutzerakzeptanzproblem zu betrachten, verfehlt den tieferen Punkt. Der Grund, warum Menschen neue Extraktionstools ablehnen, ist nicht Sturheit – sondern dass das Projekt darauf ausgelegt war, etwas zu produzieren, das niemand nutzen kann. Wenn ein Rechtsanwaltsfachangestellter die Ausgabetabelle öffnet und Parteinamen findet, die nicht übereinstimmen, Daten in drei verschiedenen Formaten und eine Spalte namens „Anwendbares Recht“, die in der Hälfte der Zeilen „siehe Abschnitt 14“ sagt, ist der Instinkt, zur manuellen Prüfung zurückzukehren, kein Widerstand gegen Veränderungen. Es ist eine rationale Reaktion auf schlechte Daten.

Im Folgenden werden fünf spezifische Fehler beschrieben – die Art, die aus Erfahrung stammt, nicht aus der Theorie – die Vertragsdaten-Extraktionsprojekte töten, bevor sie richtig beginnen. Jeder hat ein erkennbares Muster, eine tiefere Ursache als das Symptom und eine umsetzbare Korrektur, die das Ergebnis verändert.

Extraktion als einmaligen Datenexport 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 nach Excel, die nach Abschluss erledigt ist.

Der Grund liegt tiefer als bloße Ungeduld. Die meisten Rechtsabteilungen haben über Jahre Verträge ohne strukturierte Metadaten angehäuft, und der Rückstand wirkt dringend. In zwei Wochen steht eine Vorstandssitzung an, oder ein Compliance-Audit, oder eine Fusion. Der Druck, irgendetwas zu liefern, überlagert die Disziplin, etwas Nachhaltiges aufzubauen. Das Ergebnis ist eine Tabelle, die am Tag ihrer Erstellung bereits veraltet ist – weil zwischen Extraktion und Auslieferung drei neue Verträge unterzeichnet wurden und niemand weiß, wie man die Datei aktualisiert, ohne die ganze Übung zu wiederholen.

Eine Juro-Studie ergab, dass nur 11 % der Unternehmen ihr Vertragsmanagement als „sehr effektiv" bewerten. Die 89 %, die das nicht tun, scheitern nicht an fehlenden Verträgen – 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, legen Sie fest, wie die Daten im nächsten Monat aktualisiert werden. Wenn Ihre Antwort lautet „das klären wir später", bauen Sie ein Archiv, kein System. Eine wiederholbare Extraktions-Pipeline bedeutet, dass Sie denselben Prozess auf neue Verträge anwenden können – sei es durch Batch-Uploads in ein Extraktionstool oder durch die Einrichtung eines Workflows, der Vertragsdaten fortlaufend zugänglich macht, nicht nur während des Projekt-Endspurts.

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 Impuls, alles erfassen zu wollen. Fünfzig Felder. Einhundert. Jede Klauselart, jedes Datum, jede benannte Entität, die irgendwo im Dokument auftaucht. Das fühlt sich gründlich an. In Wahrheit ist es der schnellste Weg, ein Projekt zu ruinieren.

Die Ursache ist eine völlig verständliche Angst: „Was, wenn wir dieses Feld später brauchen und es nicht extrahiert haben?“ Diese angstgetriebene Abgrenzung erzeugt eine Feldliste, die niemand validieren, pflegen oder nutzen kann. Jedes zusätzliche Feld erhöht die Extraktionslatenz, vervielfacht die Fehlerprüffläche und – am kritischsten – verteilt die Aufmerksamkeit des Teams auf so viele Datenpunkte, dass Qualitätskontrollen bei wichtigen Feldern von Rauschen überlagert werden. Die ILTA-Studie, wonach 42 % der Kanzleien unzureichende Lernzeit angeben, hängt direkt damit zusammen: Wenn Ihr Extraktionsumfang 50 Felder tief ist, hat niemand Zeit, etwas richtig zu überprüfen.

Stellen Sie sich eine kleine Immobilienverwaltung mit 87 Mietverträgen vor. Sie könnten versuchen, jede Instandhaltungsklausel, jede Untermietbeschränkung, jedes Haustierregel-Detail zu extrahieren. Oder sie könnten die fünf Felder extrahieren, die 80 % ihrer operativen Entscheidungen bestimmen: Mietername, monatliche Miete, Mietende-Datum, Kaution und automatische Verlängerungsklausel (ja/nein). Fünf Felder, 87 Verträge, alles an einem Nachmittag beantwortbar. Der zweite Ansatz liefert Daten, die der Betriebsleiter am Montagmorgen tatsächlich nutzt. Der erste Ansatz produziert eine überwältigende Tabelle, die ungelesen bleibt.

Die Korrektur: Bevor Sie Felder definieren, notieren Sie die drei geschäftlichen Fragen, die Sie mit den Daten beantworten müssen. Nicht „Welche Felder gibt es 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, geltendes Recht, Verlängerungsbedingungen – die überwiegende Mehrheit der realen Fragen ab. Beginnen Sie damit. Fügen Sie weitere Felder erst hinzu, wenn sich der erste Satz als genau und nutzbar erwiesen hat.

Abweichende Parteinamen zerstören Reports, bevor es jemand merkt

Von allen Fehlern bei der Vertragsdatenextraktion verursacht dieser den größten Schaden bei geringster Sichtbarkeit. In Ihrem Vertragsportfolio taucht derselbe Vertragspartner unter mehreren Namen auf: „Acme Corp.“ in einer Vereinbarung, „Acme Corporation“ in einer anderen, „Acme Corporation, LLC“ in einer dritten und „Acme Holdings North America“ in einer vierten, die von deren internem Team verfasst wurde. Ein Extraktionstool erfasst jede Variante getreu, wie sie erscheint. Ihre Reports – Gegenparteirisiko, 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 mit der Größe: 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 Einheiten mit separaten Risikoprofilen verfolgt werden, sind monatelange Reports falsch gewesen.

Auf dem Subreddit r/legaltech beschrieb ein Praktiker die grundlegende Lücke perfekt: „Jede Kanzlei, mit der ich spreche, hat das gleiche Problem – und keine hat es gelöst.“ Das Problem ist nicht, ein Extraktionstool zu finden – es ist, die extrahierten Daten vertrauenswürdig genug zu machen, um Entscheidungen darauf zu stützen.

Die Lösung: Definieren Sie eine Normalisierungsregel vor der Extraktion, nicht danach. Legen Sie fest, wie die kanonische Form jedes Entitätsnamens lauten soll. Wenn Sie ein Tool mit Spaltennamen-Extraktion verwenden – bei dem Sie angeben, welche Daten Sie möchten (z. B. „Vertragspartei-Name“) und die KI diese in jedem Dokument lokalisiert und extrahiert – bauen Sie eine Nachschlagetabelle oder Regel auf, die Varianten während der Extraktion auf eine Standardform abbildet, nicht erst bei der manuellen Bereinigung. Hier kann eine berechnete Spalte nützlich sein: Sie definieren eine Regel, die prüft, ob ein extrahierter Parteiname mit einer bekannten kanonischen Liste übereinstimmt, und kennzeichnet Abweichungen, bevor sie in Ihre nachgelagerten Systeme gelangen. Manche Teams pflegen ein lebendes Vertragsparteien-Wörterbuch, das mit jedem neuen Variantenfund wächst. Die Disziplin liegt nicht im Tool – sondern darin, anzuerkennen, dass Parteinamen unordentlich sind, und von Anfang an dafür zu planen.

Annahme, dass jedes 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, bei denen die Textebene zwar vorhanden, aber verstümmelt ist – ein häufiges Artefakt älterer OCR-Engines. Diese Dokumente sehen beim Öffnen gut aus. Sie extrahieren furchtbar.

Der Grund für diesen Fehler liegt in einem blinden Fleck bei der Bewertung von Dokumenten durch Juristen. Anwälte verbringen ihre Karriere damit, Verträge zu lesen – sie verarbeiten Seiten visuell. Wenn jemand sagt: „Wir haben alle unsere Verträge digitalisiert“, meint er oft: „Wir haben PDFs, die wir am Bildschirm öffnen können.“ Doch es gibt einen enormen Unterschied zwischen einem menschenlesbaren PDF und einem maschinell extrahierbaren. Ein gescannter Vertrag, bei dem die OCR aus „Laufzeit“ „Laufzit“ macht, hindert einen Anwalt nicht daran, die Klausel zu verstehen. Ein Extraktionstool kann dadurch jedoch kein korrektes Enddatum ermitteln.

Hier kommt der Werkzeugwahl eine enorme Bedeutung zu. Herkömmliche templatebasierte OCR-Tools – die nach Daten an bestimmten Koordinaten auf der Seite suchen – versagen 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 von Anbieter B, selbst wenn es sich um denselben Vertragstyp handelt. Im Gegensatz dazu geht die Extraktion auf Basis von Vision Large Models (VLM) – die Dokumentinhalte semantisch und nicht positionsbasiert verstehen – wesentlich robuster mit Formatabweichungen um. Die KI liest das Dokument wie ein Mensch: Sie findet das „Wirksamkeitsdatum“, indem sie die Bedeutung dieser Wörter versteht, nicht indem sie es 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: natives PDF (Text auswählbar), gescanntes Bild-PDF (keine Textebene) oder gemischt (einige Seiten durchsuchbar, andere nicht). Wenn mehr als 20 % gescannt sind, ist ein VLM-basierter Ansatz unverzichtbar – und Sie sollten zuerst Ihre schlechtesten Formate testen, nicht Ihre saubersten. Enthalten Ihre Verträge handschriftliche Anmerkungen, Randnotizen oder gestempelte Änderungen, beziehen Sie diese mit ein. Das Tool, das Ihre saubersten 10 Verträge perfekt verarbeitet, aber an den chaotischen 10 scheitert, liefert nur 50 % Abdeckung.

Dokumentenspeicher mit Vertragsintelligenz verwechseln

Dieser Fehler ist am schwersten zu erkennen, da er in einer Sprache steckt, die die Rechtsbranche normalisiert hat. „Wir verwalten unsere Verträge in iManage." „Alles ist in NetDocuments." „Unser Vertragsrepository ist SharePoint." Jede dieser Aussagen beschreibt Dokumentenspeicher – wo Dateien leben –, nicht Vertragsintelligenz – was diese Dateien enthalten. Die Lücke zwischen beiden ist der Ort, an dem Extraktionsprojekte scheitern.

Die eigentliche Ursache ist ein Vokabularproblem, das ein Leistungsproblem überdeckt. Dokumentenmanagementsysteme (DMS) wie iManage und NetDocuments bieten Versionskontrolle, Zugriffsberechtigungen und Volltextsuche. Aber die Volltextsuche in einem Vertragsportfolio beantwortet nur eine Frage: "Welche Dokumente enthalten dieses Wort?" Sie kann nicht beantworten: "Welche Verträge laufen in den nächsten 90 Tagen aus?" oder "Wie hoch ist unser gesamtes vertraglich gebundenes Engagement bei diesem Anbieter?" oder "Wie viele Vereinbarungen enthalten automatische Verlängerungsklauseln, die wir neu verhandeln sollten?" Jede dieser Fragen erfordert strukturierte Daten – die Art von Daten, die in Feldern lebt, nicht in Dateien.

Wenn ein Rechtsteam sagt "wir verwalten unsere Verträge bereits digital" und die Führungsebene hört "unsere Vertragsdaten sind zugänglich", ist das Projekt bereits gescheitert. Die Annahme ist, dass Digitalisierung gleichbedeutend mit Datenzugriff ist. Das ist sie nicht. Ein DMS weiß, wo jeder Vertrag ist. Es weiß nichts darüber, was ein Vertrag aussagt.

Die Korrektur: Trennen Sie die Konzepte in jedem Projektgespräch explizit. Dokumentenspeicherung ist die Grundvoraussetzung – notwendig, aber nicht ausreichend. Die Extraktion von Vertragsdaten ist die darüber liegende Schicht, die gespeicherte Dateien in abfragbare Informationen verwandelt. Beide ergänzen sich, sind aber nicht austauschbar. Wenn Ihre Kanzlei in ein DMS investiert hat, großartig – diese Infrastruktur erleichtert die Extraktion, weil 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 öffnen zu müssen.

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

Jeder oben genannte Fehler hat eine spiegelbildliche Korrektur. Zusammen bilden sie eine Vorprojekt-Checkliste, die nichts kostet, aber die späteren Fehlschläge verhindert, die Gartner und ContractWorks im großen Maßstab dokumentiert haben.

1. Mit der Geschäftsfrage beginnen, nicht mit der Feldliste. Welche Entscheidung sollen diese Daten unterstützen? Vertragsverhandlung? Compliance-Prüfung? Ausgabenanalyse? Die Frage bestimmt den Umfang. Ohne eine klare Frage extrahieren Sie Daten ins Leere.

2. Umfang auf 5–10 Felder im ersten Durchlauf begrenzen. Genauigkeit und Nutzen an einer schmalen Auswahl beweisen, bevor Sie erweitern. Eine geprüfte und vertrauenswürdige 5-Feld-Extraktion ist unendlich wertvoller als eine 50-Feld-Extraktion, die niemand überprüft.

3. Bereinigung in die Extraktion verlagern, nicht in die Nachbearbeitung. Standardisierungsregeln – besonders für Parteinamen und Datumsformate – bereits im Extraktionsschritt einbauen. Jede Stunde Nachbereitung nach der Extraktion sind vermeidbare Kosten, die sich bei wiederholten Durchläufen vervielfachen.

4. Zuerst mit den schlechtesten Dokumenten testen. Der eingescannte Vertrag von 2013 mit Kaffeeflecken und handschriftlicher Ergänzung ist Ihr bester Testfall. Wenn das Tool damit klarkommt, haben Sie Abdeckung. Wenn nicht, kennen Sie die Lücke vor Vertragsunterzeichnung.

5. Auf wiederholte Durchläufe auslegen. Die erste Extraktion ist ein Meilenstein, nicht das Ziel. Stellen Sie sicher, dass Ihr Workflow – Felddefinitionen, Normalisierungsregeln und Ausgabeformat – nächsten Monat reproduzierbar ist, wenn 15 neue Verträge eingehen. Batch-Extraktion, bei der Sie mehrere Verträge auf einmal hochladen und eine einzige konsolidierte Tabelle erhalten, macht dies nachhaltig statt zu einer einmaligen Heldentat.

Häufig gestellte Fragen

Funktioniert die Vertragsdaten-Extraktion auch bei gescannten PDFs?

Ja – die Qualität hängt stark von der zugrunde liegenden Technologie ab. Die Extraktion mittels Vision Large Model (VLM) liest gescannte Dokumente semantisch, versteht also die Bedeutung des Textes, anstatt ihn an festen Koordinaten zu suchen. Dies verarbeitet Formatabweichungen in gescannten Verträgen deutlich besser als die herkömmliche koordinatenbasierte OCR. Stark beeinträchtigte Scans – starke Schräglage, dunkle Hintergrundartefakte, extrem niedrige Auflösung – verringern jedoch unabhängig von der Technologie die Genauigkeit. Testen Sie immer mit Ihrer tatsächlichen Dokumentenqualitä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äftlichen Fragen beantworten. Parteinamen, Wirksamkeitsdaten, Ablaufdaten, Geldbeträge, anwendbares Recht und ein Ja/Nein-Flag für Schlüsselklauseln (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 Gesamtvertrauen in den Datensatz.

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

Erstellen Sie einen Normalisierungsplan vor der Extraktion, nicht danach. Pflegen Sie eine kanonische Liste von Gegenparteinamen und ordnen Sie Varianten zu. Wenn Ihr Extraktionstool berechnete Spalten oder regelbasierte Verarbeitung unterstützt, können Sie Namensabweichungen bereits zum Zeitpunkt der Extraktion kennzeichnen. Einige Teams pflegen ein gemeinsames Gegenpartei-Wörterbuch in einer Tabelle oder Datenbank, das mit dem Auftauchen neuer Varianten wächst. Dies ist anfangs manuelle Arbeit, aber es ist der Unterschied zwischen vertrauenswürdigen und stillschweigend fehlerhaften Auswertungen.

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

Ihr DMS speichert Dateien, extrahiert aber keine strukturierten Daten daraus. Volltextsuche in einem DMS findet zwar Dokumente mit bestimmten Begriffen, beantwortet aber nicht „Wie hoch sind die gesamten genehmigten Ausgaben über diese 40 Lieferantenverträge?" oder „Welche Leasingverträge laufen im Q3 aus?" Die Extraktion von Vertragsdaten ist eine separate Ebene, die auf Ihrem DMS aufsetzt – sie liest die Dokumente, die Ihr DMS speichert, und erzeugt strukturierte, abfragbare Ausgaben. Beide Werkzeuge erfüllen unterschiedliche Zwecke und arbeiten am besten zusammen, nicht als Ersatz füreinander.

Wie lange dauert ein Vertragsdaten-Extraktionsprojekt typischerweise?

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 vorbereitenden Entscheidungen: Definition der Geschäftsfragen, Prüfung der Dokumentenformate und Erstellung der Normalisierungsregeln. Diese Schritte vor der Extraktion dauern in der Regel 1–3 Tage konzentrierter Arbeit – und sie zu überspringen ist die Ursache für die mehrjährigen Implementierungsfehlschläge, die die Daten von Gartner und ContractWorks dokumentieren.