In-house Legal AI sollte im Pilot eine Entscheidung erzeugen, nicht bloss eine Sammlung eindrucksvoller Beispiele. In sechs Wochen kann ein In-house-Team ein oder zwei Workflows definieren, Daten- und Prüfregeln freigeben, ein festes Set realer Aufgaben testen und danach für jeden Anwendungsfall entscheiden: skalieren, anpassen oder stoppen.
Die sechs Ergebnisse des Piloten
Bevor der Kalender startet, werden die erwarteten Artefakte benannt. Ein sinnvoller Pilot hinterlässt:
eine Use-Case-Matrix;
eine Daten- und Risikoklassifikation;
ein festes Testset;
Prüf- und Eskalationsregeln;
einen Messbogen;
einen schriftlichen Go-/No-Go-Entscheid.
Diese Unterlagen halten die Arbeit fokussiert. Sie machen das Ergebnis auch dann nachvollziehbar, wenn Beteiligte später vor allem die beste Demo, nicht aber Fehler oder Kontrollaufwand erinnern.
Der umfassendere Leitfaden zu KI in der Rechtsabteilung behandelt Governance und Skalierung. Dieses Playbook konzentriert sich auf die Durchführung über sechs Wochen.
Woche 1: Anwendungsfall bestimmen
Listet wiederkehrende Aufgaben auf und bewertet Häufigkeit, Struktur, Datensensibilität, Prüfbarkeit und möglichen operativen Wert. Wählt nicht allein nach dem vermuteten Zeitaufwand. Eine Aufgabe kann viele Stunden beanspruchen und dennoch ungeeignet sein, weil Inputs zu stark variieren oder Qualität schwer messbar ist.
Nehmt höchstens zwei Workflows in den ersten Pilot. Beschreibt jeden durch Input, Verarbeitung, erwartete Ausgabe und verantwortliche Kontrolle. Beispiele sind eine Erstprüfung wiederkehrender Verträge oder die Extraktion definierter Bestimmungen aus einem kontrollierten Dokumentenset.
Formuliert auch klare Ausschlüsse. Der Pilot muss festhalten, welche Mandate, Datenklassen und Ausgabetypen nicht dazugehören. Das ist besser umsetzbar als eine allgemeine Bitte um «vernünftigen Umgang».
Use-Case-Matrix
Für jeden Kandidaten werden diese Felder ausgefüllt:
Feld | Benötigter Entscheid |
|---|---|
Input | definierter Vertragstyp oder freigegebene öffentliche Quellen |
Ausgabe | Themenliste, strukturierte Tabelle oder belegte Notiz |
Häufigkeit | genügend Aufgaben für ein erkennbares Muster |
Prüfbarkeit | klarer Standard und benannte kontrollierende Person |
Daten | erlaubte Klassifikation und erforderliche Schutzmaßnahmen |
Wert | Aufwand, Durchlaufzeit, Konsistenz oder Transparenz |
Der gewählte Anwendungsfall braucht eine verantwortliche Person, die operative Entscheide treffen kann und das Projekt nicht nur sponsert.
Woche 1: Governance-Freigabe abschließen
Zeichnet den Datenweg vom Quellsystem zum Werkzeug und zurück. Haltet fest, was hochgeladen wird, welche Metadaten entstehen, wo die Ausgabe gespeichert wird und wer zugreifen kann. Prüft aktuelle Anbieterunterlagen und Verträge für den geplanten Workflow.
Legt praktische Regeln fest: freigegebene Konten, erlaubte und verbotene Daten, Aufbewahrung, Zugriffsanforderungen, Vorfallkanal und Ereignisse, die den Pilot stoppen. Ein sicherer Fehlerzustand gehört zum Design.
Solange die Prüfung nicht abgeschlossen ist, beginnt der Test mit synthetischem, öffentlichem oder geeignet vorbereitetem Material. Vertrauliche Daten gehören nicht in den Pilot, nur weil ein Testkonto technisch verfügbar ist.
Woche 2: Testset und Ausgangslage erstellen
Wählt abgeschlossene Beispiele vor der ersten Produktnutzung. Erwartete Ausgabe und bekannte schwierige Punkte sollten vorliegen. Das Set enthält typische Fälle, einen Grenzfall und mindestens ein Beispiel, das prüft, ob das System Unsicherheit sichtbar macht.
Erfasst den bisherigen Ablauf mit konsistenten Grenzen. Vorbereitung, aktive Arbeit, Kontrolle, Korrektur und Übertragung ins führende System gehören dazu. Werden alter und neuer Prozess unterschiedlich gemessen, ist der Vergleich irreführend.
Fünf bis zehn Aufgaben pro Use Case können bei wiederkehrender und vergleichbarer Arbeit ein erstes Signal liefern. Sie tragen keinen allgemeinen Marktprozentsatz. Stichprobe und Streuung werden offen ausgewiesen.
Wochen 2–3: Prüfregeln festlegen und Testgruppe schulen
Erstellt eine einseitige Workflow-Karte. Sie zeigt freigegebenen Input, erwartete Ausgabe, zwingende Kontrollen, verbotene Abkürzungen und Eskalationsweg. Die Schulung verwendet dieselben Aufgaben und Systeme wie der spätere Pilot.
Trainiert das Erkennen von Fehlern. Teilnehmende sollten unbelegte Aussagen, übersehene Klauseln, falschen Quellenkontext und verschleierte Unsicherheit finden können. Eine Schulung, die nur erfolgreiche Eingaben zeigt, liefert keine Methode für sichere Kontrolle.
Bestimmt primäre und stellvertretende Prüfer:innen. Hat niemand Zeit für die Kontrolle, ist der Anwendungsfall operativ nicht tragfähig, auch wenn die Technologie funktioniert.
Wochen 3–5: kontrollierte reale Aufgaben durchführen
Verwendet den festgelegten Ablauf für reale Aufgaben im freigegebenen Umfang. Erfasst jeden Durchlauf, auch abgebrochene oder unbrauchbare Ergebnisse. Verändert die Aufgabendefinition nicht nach jedem Fehler, sonst entsteht kein vergleichbares Muster.
Pro Durchlauf werden dokumentiert:
Aufgabenkategorie und Schwierigkeit;
gesamte aktive Bearbeitungszeit;
Kontroll- und Korrekturzeit;
materielle Fehler oder Lücken;
Erreichen der Qualitätsgrenze;
Verwendung, Überarbeitung oder Verwerfung;
Reibung bei Übergaben und Systemwechseln.
Kurze wöchentliche Reviews klären unverständliche Anweisungen und Betriebsprobleme. Änderungen bleiben sichtbar. Wird der Workflow wesentlich neu gestaltet, beginnt eine neue Testphase; die Ergebnisse werden nicht vermischt.
Wochen 4–5: Fehler auswerten
Fehler sind in einem kleinen Pilot besonders wertvolle Evidenz. Klassifiziert sie, statt sie als Einzelfälle zu behandeln. War der Input unvollständig, die Aufgabe unklar, eine Quelle nicht verfügbar, die Antwort unbelegt, die Prüfregel missverständlich oder der Produktablauf zu umständlich?
Unterscheidet behebbares Betriebsproblem und strukturellen Fehlfit. Schulung kann inkonsistente Aufträge verbessern. Sie schafft keine fehlende Quelle und beseitigt keine ungeklärte Datenverarbeitung. Das Entscheidungsprotokoll zeigt, welche Reaktion passt.
Wiederholte materielle Fehler lösen die vorher bestimmte Stop-Regel aus. Der Pilot dient dem Lernen innerhalb einer kontrollierten Grenze, nicht der Verteidigung seiner Fortsetzung.
Wochen 5–6: den vollständigen Workflow bewerten
Fasst Adoption, Qualität, Aufwand und Ergebnis getrennt zusammen. Beginnt nicht mit Logins oder generierten Ausgaben. Zeigt Anteil der Aufgaben über der Qualitätsgrenze, Kontrollaufwand, Bandbreite des Gesamtaufwands und den beobachteten operativen Effekt.
Der Beitrag zur Messung von KI-Zeitersparnis erklärt, weshalb Kontrolle und Nacharbeit in der Rechnung bleiben müssen. Ist das Testset klein oder sind Aufgaben schwer vergleichbar, gehört diese Grenze in den Bericht.
Befragt Nutzer:innen und kontrollierende Personen getrennt. Nutzer:innen erkennen Reibung und Lernbedarf; Reviewer sehen Fehlermuster und Qualitätsrisiken. Interne Auftraggeber zeigen, ob Durchlaufzeit oder Verständlichkeit tatsächlich besser wurden.
Ende Woche 6: entscheiden
Für jeden Workflow gelten vorab definierte Ergebnisse:
Go: Qualitäts- und Betriebskriterien sind erfüllt; die Ausweitung erfolgt mit benannten Bedingungen.
Anpassen: Der Use Case ist aussichtsreich, aber Input, Umfang, Schulung oder Kontrollen müssen vor einem neuen Test geändert werden.
Stop: Der Workflow verfehlt Qualitäts-, Aufwands- oder Governance-Grenze.
Das Entscheidungsdokument nennt Umfang, Testset, Evidenz, offene Risiken, verantwortliche Person und nächsten Prüftermin. Ein bedingtes Go führt alle Bedingungen auf. Ein erfolgreicher Pilot für eine Aufgabe ist keine Freigabe für jeden Legal-AI-Anwendungsfall.
Den skalierten Betrieb vorbereiten
Bei einem Go werden Zugangsvergabe, Onboarding, Support, Monitoring und Änderungsprüfung vor zusätzlichen Nutzer:innen festgelegt. Bestimmt, welche Änderungen an Produkt oder Anbieter eine neue Bewertung des Workflows verlangen.
Bewahrt einige Referenzaufgaben für Regressionstests. Wenn sich System oder Arbeitsweise ändern, werden diese erneut durchgeführt. So wird aus dem einmaligen Beschaffungsprojekt eine Betriebsdisziplin.
CASUS kann für Dokumentenprüfung, Rechtsrecherche und verwandte Workflows evaluiert werden. Teams können mit einem eigenen kontrollierten Testset starten, sobald Daten- und Prüfschranken feststehen.
FAQ
Weshalb ein 6-Wochen-Pilot?
Er schafft Zeit für Governance, Schulung, reale Aufgaben und einen Entscheid, ohne ein offenes Experiment zu erzeugen. Aufgabenmenge und Evidenzqualität bleiben wichtiger als die exakte Dauer.
Wie viele Use Cases gehören in den ersten Pilot?
Einer oder zwei. Ein enger Umfang ermöglicht präzise Inputs, Prüfstandards und Messungen.
Wer sollte teilnehmen?
Verantwortliche aus Legal, repräsentative Nutzer:innen, benannte Prüfer:innen und die für Daten, Security, Einkauf und technischen Betrieb nötigen Funktionen.
Was ist ein materieller Fehler?
Definiert ihn vor dem Test. Beispiele sind eine unbelegte Rechtsaussage, eine übersehene vorrangige Klausel, falscher Quellenkontext oder ein anderer Mangel, der eine substanzielle Korrektur verlangt.
Was gilt, wenn der Pilot Zeit spart, aber Qualität verliert?
Der Workflow wird nicht skaliert, solange er die vereinbarte Qualitätsgrenze verfehlt. Geschwindigkeit ist erst nach akzeptabler Qualität und funktionierender Kontrolle ein Ergebnis.
