Verträge mit KI analysieren: Extraktion, Vergleich und menschliche Prüfung

Problem und Zielgruppe

Ein mittelständisches Unternehmen hat selten zehn Verträge im Blick, sondern hunderte: Rahmenverträge mit Lieferanten, Mietverträge für Standorte, Software-Lizenzen, Kundenverträge, Kooperationsvereinbarungen, dazu die dazugehörigen Nachträge und Anhänge. Die Informationen darin – Laufzeiten, Kündigungsfristen, Preisanpassungsklauseln, Haftungsgrenzen – liegen fast immer als Fließtext in PDFs vor, oft über Jahre gewachsen, unterschiedlich formuliert, in verschiedenen Ablagen. Wer wissen will, welche Verträge sich in den nächsten drei Monaten automatisch verlängern oder welche Kunden eine ungewöhnliche Haftungsklausel akzeptiert haben, durchsucht das heute meist manuell – wenn überhaupt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die prüfen, ob und wie KI diese Auswertung unterstützen kann. Er beantwortet die zentralen Fragen: Welche Daten lassen sich extrahieren, wie werden Klauseln vergleichbar, wie bleibt die Ausgabe nachprüfbar, was bleibt zwingend juristische Aufgabe, und wie schützt man dabei die Daten.

Das eigentliche Problem, das dieser Artikel adressiert, ist nicht technisch, sondern eine Vergleichbarkeitslücke: Vertragsinformationen sind über viele Dokumente verstreut und in unterschiedlicher Sprache formuliert – kaum jemand kann sie schnell nebeneinanderlegen. KI kann diese Lücke bei der Extraktion und Strukturierung schließen. Bei der rechtlichen Bewertung kann sie das nicht, und das ist keine Frage der Technologiereife, sondern der Aufgabe selbst: Eine Klausel ist wirksam oder unwirksam, riskant oder unkritisch – abhängig vom konkreten Kontext, von Rechtsprechung und von Auslegung. Das ist eine juristische Entscheidung, keine Extraktionsaufgabe.

Begriffe und Abgrenzung

Für den Rest des Artikels unterscheiden wir drei Schritte, die in der Praxis oft vermischt werden:

• Extraktion ist das Herausziehen einzelner Felder aus einem Dokument – etwa Vertragsparteien, Laufzeit oder Zahlungsbetrag – als strukturierte Daten, meist mit Verweis auf die Fundstelle im Original.
• Vergleich ist das Nebeneinanderstellen gleichartiger Felder oder Klauseln aus mehreren Verträgen, um Abweichungen von einem Standard oder zwischen Verträgen sichtbar zu machen.
• Bewertung ist die inhaltliche, rechtliche Einordnung einer Klausel oder eines Vertrags – ob sie wirksam, ausgewogen, verhandelbar oder riskant ist.

Nur die ersten beiden Schritte sind heute mit vertretbarer Zuverlässigkeit automatisierbar. Wer „Vertragsanalyse mit KI” mit „KI prüft, ob unser Vertrag gut ist” gleichsetzt, überschätzt, was das Werkzeug leisten kann, und unterschätzt, was danach noch an menschlicher Arbeit bleibt.

Wichtig ist auch die Abgrenzung zur klassischen Volltextsuche: Eine Suche nach dem Wort „Kündigung” findet Textstellen, versteht aber nicht, ob es sich um eine ordentliche, außerordentliche oder automatische Verlängerungsklausel handelt. Extraktion mit einem Sprachmodell oder einem spezialisierten Dokumentendienst geht einen Schritt weiter: Sie ordnet den Fund einem definierten Feld zu – aber auch das ist noch keine Bewertung.

Welche Daten kann KI extrahieren?

Spezialisierte Extraktionsdienste für Vertragsdokumente sind darauf ausgelegt, ein festes Set an Feldern zuverlässig herauszuziehen. Microsofts Vertragsmodell in Azure AI Document Intelligence etwa analysiert den Dokumenttext per OCR und extrahiert unter anderem Vertragsparteien, Gerichtsstand, Vertrags-ID und Titel als strukturierte JSON-Daten – aus Scans, fotografierten Dokumenten und digitalen PDFs gleichermaßen. Über sogenannte Query Fields lassen sich zusätzlich eigene Feldnamen definieren, etwa Zahlungsbedingungen, Zahlungsdatum oder Vertragsende, die das Modell dann gezielt sucht.

In der Praxis funktioniert das am zuverlässigsten bei Feldern, die strukturiert oder stark standardisiert auftreten:

• Formale Angaben: Vertragsparteien, Vertragsnummer, Unterschriftsdatum, Vertragslaufzeit, Gerichtsstand.
• Numerische Angaben: Preise, Zahlungsfristen, Vertragswerte, Stückzahlen – sofern sie in erkennbarer Form (Tabelle, klar formatierter Fließtext) vorliegen.
• Wiederkehrende Klauseltypen: Kündigungsfristen, Verlängerungsklauseln, Zahlungsbedingungen – wenn sie in ähnlicher sprachlicher Form über viele Verträge hinweg auftreten.

Deutlich unzuverlässiger wird es bei individuell ausgehandelten Klauseln mit ungewöhnlicher Formulierung, verschachtelten Verweisen auf andere Vertragsteile oder Verhandlungssprache, die vom Standard abweicht. Ein wichtiger, oft übersehener Praxispunkt: Manche der gängigen Extraktionsmodelle sind primär für englischsprachige Dokumente trainiert und optimiert. Für deutschsprachige Vertragsbestände muss man das vor der Auswahl eines Werkzeugs prüfen – ein Modell, das in einer Demo mit englischen Musterverträgen überzeugt, liefert bei deutschen AGB und Rahmenverträgen nicht automatisch dieselbe Qualität.

Aus meiner Projekterfahrung ist die Erwartungshaltung hier der größte Stolperstein: Extraktion ersetzt keine Volltexterfassung „auf Zuruf”, sondern liefert am besten belastbare Ergebnisse, wenn vorher definiert ist, welche zehn bis fünfzehn Felder überhaupt gebraucht werden. Wer „extrahiere alles Relevante” als Auftrag gibt, bekommt unscharfe Ergebnisse und keinen Maßstab, um deren Qualität zu beurteilen.

Wie vergleicht man Klauseln?

Der eigentliche Nutzen entsteht selten aus der Extraktion eines einzelnen Vertrags, sondern aus dem Vergleich über viele Verträge hinweg – etwa: Welche unserer fünfzig Lieferantenverträge haben eine Kündigungsfrist unter drei Monaten? Bei welchen Kundenverträgen weicht die Haftungsklausel von unserem internen Standard ab?

Damit das funktioniert, braucht es vorher eine Klassifikation der Klauseltypen, die verglichen werden sollen – nicht den gesamten Vertragstext, sondern definierte Kategorien wie Kündigung, Haftung, Gewährleistung, Preisanpassung, Vertraulichkeit. Für jede Kategorie wird dann pro Vertrag die passende Textstelle extrahiert und einem gemeinsamen Format zugeordnet. Erst dieser Zwischenschritt macht Verträge überhaupt vergleichbar, weil unterschiedliche Formulierungen auf dieselbe Kategorie gemappt werden.

Eigene Vergleichsmatrix als Arbeitsmodell:

Klauseltyp	Was pro Vertrag extrahiert wird	Typischer Abweichungs-Check
Kündigung	Frist, Form, ordentlich/außerordentlich, automatische Verlängerung ja/nein	Frist kürzer/länger als interner Standard?
Haftung	Haftungsobergrenze, Ausschlüsse, Verweis auf gesetzliche Haftung	Fehlt eine Obergrenze ganz?
Zahlung	Zahlungsziel, Skonto, Preisanpassungsmechanismus	Zahlungsziel länger als üblich vereinbart?
Vertraulichkeit	Geltungsdauer nach Vertragsende, Ausnahmen	Endet die Pflicht sofort mit Vertragsende?
Gerichtsstand/Recht	Anwendbares Recht, Gerichtsstand	Abweichendes Recht ohne erkennbaren Grund?

Eigenes Vergleichsraster Philogic Labs – die konkreten Kategorien und Schwellenwerte müssen pro Unternehmen und Vertragstyp angepasst werden.

Ein solches Raster ist ein Arbeitsmittel, keine Rechtsauskunft: Es zeigt, wo ein Vertrag vom Standard abweicht, nicht, ob die Abweichung ein Problem ist. Diese Einordnung – akzeptabel, verhandelbar, kritisch – ist der Übergang von Vergleich zu Bewertung und gehört in juristische Hände.

Wie zeigt man Quellenstellen?

Bei Verträgen mit rechtlicher Wirkung ist ein extrahierter Wert ohne Rückverweis auf die Fundstelle im Original praktisch wertlos – niemand kann eine Zahl oder eine Klausel prüfen, ohne zu wissen, wo im Dokument sie steht. Seriöse Extraktionsdienste liefern deshalb zu jedem Feld nicht nur den Wert, sondern auch die Position im Dokument zurück: Seite, Textabschnitt oder Koordinaten, teils zusätzlich einen Konfidenzwert, der angibt, wie sicher sich das Modell bei der Erkennung war.

Für die praktische Umsetzung heißt das: Jede extrahierte Klausel in einer Vergleichsübersicht sollte anklickbar oder zumindest referenziert auf die exakte Stelle im Originaldokument sein – nicht als isolierter Textschnipsel, sondern mit Kontext davor und danach. Das ist besonders wichtig bei Sprachmodell-gestützter Extraktion (im Unterschied zu spezialisierten Dokumentendiensten), weil Sprachmodelle plausibel klingende, aber inhaltlich falsche Zusammenfassungen erzeugen können, wenn sie nicht eng an den Originaltext gebunden sind. Ein System, das nur eine Zusammenfassung ausgibt, ohne die Fundstelle zu nennen, ist für Verträge mit rechtlicher Bedeutung ungeeignet – unabhängig davon, wie überzeugend die Zusammenfassung klingt.

Zwei praktische Kontrollen, die ich in Projekten mit einbaue: Erstens ein Stichproben-Check, bei dem eine geschulte Person eine Zufallsauswahl der extrahierten Felder gegen das Original prüft, bevor ein Werkzeug produktiv geht. Zweitens ein Schwellenwert für niedrige Konfidenzwerte, unterhalb dessen ein Feld automatisch als „manuell zu prüfen” markiert wird, statt unkommentiert in die Vergleichsübersicht zu laufen.

Was bleibt juristisch?

Diese Trennung ist der Kern des Artikels, deshalb hier noch einmal explizit: Extraktion und Vergleich sind technische, weitgehend automatisierbare Schritte. Die rechtliche Bewertung ist es nicht – und das ändert sich absehbar auch nicht durch bessere Modelle, weil die Aufgabe selbst eine andere ist. Eine Klausel auszulegen bedeutet, sie im Licht von Gesetzeswortlaut, Rechtsprechung und den konkreten Umständen des Einzelfalls zu bewerten. Das ist genuin juristische Arbeit.

Rechtlich ist diese Trennung inzwischen auch regulatorisch verankert. Die europäische KI-Verordnung (Stand Juli 2026, keine Rechtsberatung) stuft in Anhang III bestimmte KI-Systeme als Hochrisiko ein – darunter, unter Ziffer 8(a), KI-Systeme, die von oder im Auftrag einer Justizbehörde eingesetzt werden, um bei der Recherche und Auslegung von Sachverhalt und Recht sowie bei der Anwendung des Rechts auf einen konkreten Sachverhalt zu unterstützen, oder vergleichbar in der alternativen Streitbeilegung. Diese Hochrisiko-Kategorie zielt auf KI-Einsatz durch oder im Auftrag von Gerichten und vergleichbaren Stellen – ein unternehmensinternes Werkzeug zur Vertragsextraktion, das keine rechtliche Entscheidung trifft, sondern Fundstellen und Felder liefert, fällt nach dieser Abgrenzung typischerweise nicht darunter. Das entbindet aber nicht davon, den eigenen Einsatzzweck sauber zu dokumentieren und im Zweifel juristisch prüfen zu lassen, ob eine geplante Anwendung eher Richtung Bewertung als Richtung Extraktion geht.

Praktisch heißt das für den Aufbau eines Vertragsanalyse-Workflows: Das System liefert Fundstellen, Felder und Abweichungen von einem definierten Standard. Jede Ausgabe, die eine Empfehlung oder Bewertung enthält („diese Klausel ist riskant”, „dieser Vertrag sollte angepasst werden”), braucht eine sichtbare menschliche Prüfung und Freigabe, bevor sie irgendwo verwendet wird – intern in einer Entscheidung oder extern gegenüber einem Vertragspartner. Wer diesen Prüfschritt aus Effizienzgründen wegrationalisiert, verschiebt das Risiko nicht weg, sondern verdeckt es nur.

Wie schützt man Daten?

Verträge enthalten fast immer personenbezogene und häufig geschäftskritische Daten: Namen von Ansprechpartnern, Gehälter in Anstellungsverträgen, Konditionen, die gegenüber Wettbewerbern vertraulich bleiben sollen. Bevor ein Vertragsbestand in ein KI-Werkzeug hochgeladen wird, braucht es geklärte Antworten auf mehrere Fragen.

Rechtsgrundlage. Wer personenbezogene Daten aus Verträgen verarbeitet, braucht dafür eine Rechtsgrundlage nach Artikel 6 DSGVO. Für Unternehmen ist das in der Praxis meist die Erfüllung des Vertrags selbst (Artikel 6 Abs. 1 lit. b) für die Daten der Vertragsparteien oder ein berechtigtes Interesse (Artikel 6 Abs. 1 lit. f) für die interne Auswertung eines Vertragsportfolios – Letzteres verlangt eine Abwägung, keinen Automatismus, und ausdrücklich nicht mehr Daten, als für den Zweck nötig sind.

Auftragsverarbeitung. Wird ein externer KI-Dienst eingesetzt, ist zunächst zu klären, in welchem Verhältnis man zum Anbieter steht: Auftragsverarbeitung nach Artikel 28 DSGVO, gemeinsame Verantwortlichkeit nach Artikel 26, oder getrennte Verantwortlichkeit. Die Auftragsverarbeitung ist regelmäßig die vorzugswürdige Konstellation, weil sie klare Zuständigkeiten schafft – sie erfordert aber einen bindenden Vertrag mit dem Anbieter, der genau festlegt, wofür die Daten verwendet werden dürfen.

Datenminimierung statt Komplett-Upload. Landesdatenschutzbehörden weisen ausdrücklich darauf hin, dass der Einsatz von KI keine großzügigere Datenverarbeitung rechtfertigt – „viel hilft viel” gilt nicht. Praktisch heißt das: nicht den gesamten Vertragsordner ungeprüft in ein Tool laden, sondern vorab festlegen, welche Vertragstypen und welche Felder tatsächlich verarbeitet werden müssen.

Zweckbindung beim Anbieter. Zu prüfen ist außerdem, ob der Anbieter hochgeladene Vertragsdaten zur Verbesserung seines eigenen Modells nutzt. Sobald das der Fall ist, dient die Verarbeitung nicht mehr allein dem eigenen Zweck, sondern auch dem des Anbieters – das ist eine wichtige vertragliche Klarstellung, die vor dem produktiven Einsatz eingeholt werden sollte, nicht danach.

Sensible Daten. Enthalten Verträge besondere Kategorien personenbezogener Daten – etwa Gesundheitsdaten in Versicherungs- oder Arbeitsverträgen –, gelten zusätzlich die verschärften Anforderungen nach Artikel 9 DSGVO. Solche Verträge gehören nicht ungeprüft in ein allgemeines KI-Werkzeug.

Umsetzung: Wie ein Vertragsanalyse-Workflow entsteht

Aus meiner Praxis hat sich ein Vorgehen in vier Schritten bewährt, bevor überhaupt ein Werkzeug ausgewählt wird:

1. Feldliste definieren. Gemeinsam mit den Fachbereichen die zehn bis fünfzehn Felder festlegen, die tatsächlich gebraucht werden – nicht „alles”, sondern die Felder, die eine konkrete Entscheidung ermöglichen (etwa: Welche Verträge laufen in den nächsten sechs Monaten aus?).
2. Klauselkategorien für den Vergleich festlegen. Welche Klauseltypen sollen über Verträge hinweg vergleichbar sein? Hier lohnt sich die Abstimmung mit der Rechtsabteilung oder externer juristischer Beratung, damit die Kategorien später auch für die Bewertung brauchbar sind.
3. Werkzeug mit Fundstellen-Rückgabe auswählen. Nur Werkzeuge in die engere Auswahl nehmen, die zu jedem Feld eine nachvollziehbare Fundstelle liefern, und deren Datenschutzbedingungen (Auftragsverarbeitung, keine Nutzung für Modelltraining ohne Zustimmung) vorab prüfen.
4. Pilot mit begrenztem Vertragsbestand und definierter Prüfschleife. Nicht den gesamten Vertragsbestand auf einmal verarbeiten, sondern mit einer überschaubaren, klar abgegrenzten Gruppe starten (zum Beispiel: alle laufenden Lieferantenrahmenverträge einer Kategorie), inklusive Stichprobenprüfung gegen das Original, bevor die Ergebnisse in eine Entscheidung einfließen.

Ein Vertragsanalyse-Workflow läuft dabei häufig als Teil eines größeren Backoffice-Setups – etwa gekoppelt an Dokumentenverarbeitung für den Posteingang oder an bestehende Freigabeprozesse. Wer diesen Ablauf für den eigenen Vertragsbestand einordnen will: Wir prüfen im Rahmen unserer KI-Beratung Backoffice-Abläufe konkret auf Machbarkeit, bevor ein Werkzeug beschafft wird.

Risikomatrix: Risiken und Gegenmaßnahmen bei der KI-gestützten Vertragsanalyse

Risiko	Beschreibung	Gegenmaßnahme
Fehlerhafte Extraktion ohne Prüfung	Ein Feld wird falsch erkannt und ungeprüft in eine Entscheidung übernommen	Konfidenzwerte nutzen, Stichprobenprüfung vor Produktivbetrieb, Fundstellen-Pflicht
Verwechslung von Extraktion und Bewertung	Eine Zusammenfassung wird als rechtliche Einschätzung missverstanden	Klare Kennzeichnung, dass Ausgaben Rohdaten sind; Freigabeprozess vor Verwendung
Datenschutzverstoß durch Voll-Upload	Ganze Vertragsarchive werden ungeprüft in ein Tool geladen	Datenminimierung, vorab definierte Feldliste, Auftragsverarbeitungsvertrag
Zweckentfremdung beim Anbieter	Vertragsdaten fließen in das Training des Anbietermodells ein	Vertragsbedingungen vor Einsatz prüfen, Opt-out bzw. Ausschluss vertraglich festhalten
Sprach- und Formatgrenzen	Extraktionsmodell ist primär für andere Sprache/Formate optimiert, Qualität bei deutschen Verträgen sinkt	Vor Auswahl mit eigenen, repräsentativen Verträgen testen, nicht nur mit Demo-Dokumenten
Fehlende Verantwortlichkeit	Niemand prüft, ob Ergebnisse noch stimmen, wenn sich Vertragsmuster ändern	Benannte Betriebsverantwortung, regelmäßige Stichproben auch nach dem Rollout

Eigene Risikomatrix Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten.

Risiken & Grenzen

Über die Matrix hinaus gehören zur ehrlichen Einordnung noch drei grundsätzliche Punkte:

• Kein Ersatz für Vertragsmanagement. Ein Extraktionswerkzeug liefert Daten, aber kein Fristenmanagement, keine Eskalationslogik und keine Governance. Wer diese Prozesse nicht ohnehin hat, sollte sie parallel zur Technik aufbauen – sonst bleiben extrahierte Daten ungenutzt liegen.
• Vertragsbestände sind heterogen. Rahmenverträge, Individualverträge, AGB und Nachträge unterscheiden sich stark in Struktur und Formulierung. Ein Werkzeug, das bei standardisierten Lieferantenverträgen gut funktioniert, liefert bei individuell verhandelten Kundenverträgen oft deutlich schwächere Ergebnisse – das sollte vor der Auswahl getestet, nicht nach dem Rollout entdeckt werden.
• Kosten und Zeit lassen sich vorab nur als Bandbreite nennen. Wie viel Aufwand ein Vertragsanalyse-Projekt macht, hängt stark davon ab, wie viele Vertragstypen einbezogen werden, wie sauber die Feldliste vorab definiert ist und wie tief die Anbindung an bestehende Systeme (etwa ein Vertragsmanagement- oder ERP-System) gehen soll. Belastbare Zahlen entstehen erst nach einer kurzen Analysephase mit dem eigenen Vertragsbestand – pauschale Festpreise vor dieser Analyse sind ein Warnsignal.

Checkliste: Verträge mit KI analysieren

1. Wir haben eine feste Liste von zehn bis fünfzehn Feldern definiert, die extrahiert werden sollen – nicht „alles Relevante”.
2. Wir haben Klauselkategorien für den Vergleich festgelegt und mit juristischer Expertise abgestimmt.
3. Das gewählte Werkzeug liefert zu jedem Feld eine nachvollziehbare Fundstelle im Original, nicht nur einen isolierten Wert.
4. Wir haben mit eigenen, repräsentativen deutschsprachigen Verträgen getestet, nicht nur mit Demo-Dokumenten des Anbieters.
5. Die Rechtsgrundlage für die Verarbeitung ist geklärt, ein Auftragsverarbeitungsvertrag mit dem Anbieter liegt vor.
6. Wir laden nur die tatsächlich benötigten Vertragstypen und Felder hoch, nicht den kompletten Vertragsordner.
7. Geprüft ist, ob der Anbieter hochgeladene Daten zur eigenen Modellverbesserung nutzt – und ausgeschlossen, wenn nicht gewünscht.
8. Jede Ausgabe mit Bewertungscharakter durchläuft eine sichtbare menschliche Prüfung, bevor sie verwendet wird.
9. Es gibt eine Stichprobenprüfung vor dem Produktivbetrieb und in regelmäßigen Abständen danach.
10. Eine Person trägt die Betriebsverantwortung für den Workflow, inklusive Reaktion auf neue Vertragsmuster.