Die richtigen Seitenlesen
Wie ein Legal-Team MiruIQ als Software für Vertragsanalyse einsetzte, um spezifische Klauseldaten aus über 2.000 Verträgen zu extrahieren, ohne eine einzige Seite zu lesen.
Über 80.000 Seiten reduziert auf strukturierte Befunde pro Klauseltyp. Die Due-Diligence-Zeitachse drastisch verkürzt. Jeder Befund bis auf die konkrete Seite nachvollziehbar.
Ein Unternehmensrechtsteam steht bei einer Akquisitions-Due-Diligence vor einem virtuellen Datenraum mit über 2.000 Dokumenten à 30–80 Seiten. Die Associates brauchen spezifische Klauseln: Change-of-Control-Bestimmungen, Haftungsobergrenzen bei Freistellungen, Kündigungsrechte. Jede Seite zu lesen wäre eine Sechs-Wochen-Aufgabe für vier Personen.
Eingang
Die Inhalte des Datenraums werden per S3 oder FTP in die Pipeline synchronisiert. Als Vertragsanalyse-Software läuft MiruIQ dabei DSGVO-konform On-Premises oder im Schweizer Hosting; jedes Mandat bleibt in Ihrer Umgebung.
Semantische Klassifizierung
Jedes Dokument wird von mehreren Semantic Classifiern parallel bewertet: einer pro gesuchtem Klauseltyp. Jeder Classifier ist mit einer Beschreibung und Beispielen konfiguriert, wie diese Klausel in der Praxis aussieht: Ein Kündigungs-Classifier kennt Kündigungsformulierungen über verschiedene Vertragsstile hinweg, ein Change-of-Control-Classifier erkennt Akquisitionstrigger und Zustimmungsvorbehalte, ein Freistellungs-Classifier identifiziert Haftungsobergrenzen und Ausnahmen. Nur Dokumente, die semantisch zu einem Klauseltyp passen, laufen weiter; alles andere wird übersprungen.
Klausel-Struktur-Klassifizierung
Jeder Semantic Classifier speist seinen eigenen Structure Classifier, der die konkret zu extrahierenden Felder für diesen Klauseltyp definiert. Die Kündigungs-Struktur definiert Felder wie Kündigungsfrist in Tagen, Wirksamkeitsdatum nach Zugang und Vertragsstrafen. Die Change-of-Control-Struktur erfasst Auslösebedingungen, Zustimmungserfordernisse und Abtretungsrechte. Die Freistellungs-Struktur spezifiziert Haftungsobergrenzen, Ausnahmen und Nachhaftungsfristen. So wird juristische Dokumentenextraktion zu einem Schema-Problem: Jeder Klauseltyp ist eine Struktur, und die Vertragsdatenextraktion befüllt diese Struktur Feld für Feld.
Extraktion
Jeder Structure Classifier speist seinen eigenen Extractor, der die tatsächlichen Werte aus den Dokumentseiten zieht. Der Kündigungs-Extractor liest Kündigungsfrist und Nachlaufzeit aus den relevanten Absätzen. Der Change-of-Control-Extractor erfasst Auslöseereignisse und Zustimmungserfordernisse. Der Freistellungs-Extractor zieht Haftungsobergrenzen und Nachhaftungsfristen. Jeder Extractor liefert strukturierte Daten, bereit für nachgelagerte Systeme.
Output
Die Extractors erzeugen zwei Outputs. Die Quelldokumente werden in S3 gespeichert; Associates können sich bei Bedarf zum Original durchklicken, um einen Befund zu verifizieren. Gleichzeitig werden die extrahierten Werte als Due-Diligence-Matrix nach PostgreSQL geschrieben: pro Dokument, welche Klauseln gefunden wurden, auf welchen Seiten, mit Kernbegriffen und Risiko-Flags. Die Associates arbeiten mit dieser Matrix statt mit Rohdokumenten. Wird ein neuer Klauseltyp relevant (z. B. Wettbewerbsverbote), wird ein neues Triplett aus Semantic Classifier, Structure Classifier und Extractor ergänzt, ohne etwas anderes zu ändern: juristische Dokumentenautomatisierung, die mit dem Deal mitwächst.
Semantic-First-Filterung
Mehrere Semantic Classifier laufen parallel, jeder konfiguriert mit Beschreibungen und Beispielen eines bestimmten Klauseltyps. Nur semantisch passende Dokumente laufen weiter; alles andere wird übersprungen, bevor Struktur oder Extraktion greifen.
Parallele Struktur-Erweiterung
Jeder Semantic Classifier speist seinen eigenen Structure Classifier. Der Semantic Classifier entscheidet, ob die Klausel vorhanden ist; der Structure Classifier definiert, welche Felder daraus extrahiert werden. Neue Klauseltypen kommen als neue Classifier-Paare hinzu, ohne bestehende zu verändern.
Gekoppelte Klassifizierung & Extraktion
Jeder Structure Classifier speist seinen eigenen dedizierten Extractor. Die Struktur definiert, wonach gesucht wird; der Extractor zieht die tatsächlichen Werte. Das Paar agiert als Einheit, wiederverwendbar über verschiedene Pipelines hinweg.
Semantic-First-Pipelines pro Klausel: Jeder Klauseltyp hat seinen eigenen Semantic Classifier (mit Beispielen), seine eigene Strukturdefinition und seinen eigenen Extractor. Das Triplett agiert als Einheit; neue Klauseltypen kommen hinzu, ohne bestehende anzufassen.
Fragen zur Vertragsanalyse
Was Legal-Teams zur automatisierten Vertragsanalyse fragen.
Alles, was sich als Schema definieren lässt: Vertragsparteien, Fristen, Kündigungsfristen, Kündigungsklauseln, Change-of-Control-Bestimmungen, Haftungsobergrenzen. Jeder Klauseltyp wird zu einer Struktur, und die juristische Dokumentenextraktion befüllt sie Feld für Feld, über einen gesamten Datenraum hinweg, nicht Vertrag für Vertrag.
Indem die KI dort bleibt, wo die Dokumente sind. MiruIQ läuft auf der kanzleieigenen Infrastruktur oder im Schweizer Hosting mit lokalen Modellen und State-Isolation pro Pipeline; kein Dokument, kein Embedding und kein Extraktionsergebnis liegt je bei einem externen KI-Anbieter.
Ein Muster gefunden, das zu Ihrem Workflow passt?
Jedes Muster besteht aus denselben modularen Komponenten: Classifier, Extractors, Validatoren und Konnektoren. Lassen Sie uns die richtige Kombination für Ihre Dokumente finden.