Presse

Der vorige Teil hat den Bauplan gezeigt: Gezielt und mehrstufig suchen, die Treffer bewerten, jede Aussage an ihre Quelle binden und den Ablauf algorithmisch steuern, während die KI nur die kognitiven Schritte übernimmt. Dieser Teil geht vom selben Bauplan aus und fragt, was sich ändert, wenn er statt auf technische Entwicklungsdaten auf Verträge und Lastenhefte trifft. Es ändern sich die Form der Daten, die Kernoperation und das, was am Ende erzeugt wird. Gerade an diesen Unterschieden zeigt sich, ob die Methode wirklich taugt oder nur für einen Datensatz gebaut war.

Vom Graphen zum Fließtext

Beim Traceability-Assistenten lagen die Daten bereits als Objekte mit teils gepflegten Beziehungen vor. Die Kunst bestand darin, vorhandene Verweise zu nutzen und fehlende zu rekonstruieren. Ein Vertrag oder ein Lastenheft ist das Gegenteil: Ein langer, linearer Fließtext ohne jede maschinenlesbare Verknüpfung. Hier gibt es keine Beziehungen zu rekonstruieren, sondern erst welche zu schaffen.

Deshalb steht am Anfang ein Schritt, den es beim Graphen so nicht gab: Das Dokument wird zuerst in einzelne, fachlich eingeordnete Einheiten zerlegt. Beim Vertrag sind das Klauseln, beim Lastenheft einzelne Anforderungen. Wie diese Einheiten gespeichert und für die treffsichere Suche indexiert werden, ist in Kapitel 2 beschrieben. Hier kommt hinzu, dass die erzeugte Struktur auch den sauberen paarweisen Vergleich möglich macht. Die Form der Daten ist auch beim Fließtext Architektur, nur muss sie erst hergestellt werden, bevor die KI ins Spiel kommt.

Prüfen: Eine Frage gegen ein Dokument

Die erste Aufgabe ist das Prüfen entlang eines Kriterienkatalogs, der je nach Vertragsart angepasst wird. Die Analyse läuft Frage für Frage: Passende Klauseln finden, an ihnen die Frage beantworten, das Ergebnis mit Verweis auf die Quell-Klausel festhalten. Der Ablauf für eine einzelne Frage, von der hybriden Suche über die Bewertung bis zur quellgebundenen Ablage, funktioniert so, wie in Kapitel 2 am Haftungsbeispiel gezeigt, und wird hier nicht wiederholt.

Neu ist allein der Gegenstand: Statt zu fragen, welcher Test welche Komponente prüft, lautet die Frage nun, ob der Vertrag eine Haftungsbegrenzung enthält und wie ist sie ausgestaltet sind. Der Prüfvorgang liegt damit dem Traceability-Fall am nächsten. Die eigentliche Erweiterung bringt die zweite Aufgabe.

###Bild3###

Vergleichen: Zwei Dokumente gegenüberstellen

Das Vergleichen hat im Traceability-Fall kein Gegenstück und ist die eigentliche Neuerung. Nehmen wir die Frage: „Weichen die Haftungsregelungen im Kundenvertrag von unseren Standardbedingungen ab, und wo entsteht daraus ein Risiko?“ Verglichen werden dabei nicht Texte, sondern Regelungen. Zu jeder relevanten Klausel des einen Dokuments sucht die Anwendung über dieselbe hybride Suche die sachlich entsprechende Klausel des anderen, auch dann, wenn beide völlig anders formuliert sind. Für jedes Paar entscheidet anschließend ein eng umrissener KI-Schritt über das Verhältnis der beiden Regelungen: Deckt die eine die andere ab? Verschärft sie sie? Widerspricht sie ihr? Oder fehlt auf einer Seite eine notwendige Gegenregelung?

Die Befunde werden nach Schweregrad geordnet, damit der kritische Konflikt nicht neben der harmlosen Abweichung untergeht. Bei einem Konflikt kann der Assistent dann einen Schritt weitergehen, den es beim Traceability-Assistenten nicht gibt, und einen Formulierungsvorschlag erzeugen. Dieser ist klar als KI-Vorschlag markiert. Der Assistent schreibt den Vertrag nicht um, sondern legt eine prüfbare Variante daneben. Auch dieser erzeugende Schritt bleibt an die Quell-Klauseln gebunden und ist damit nachprüfbar.

Lastenhefte: Derselbe Mechanismus, andere Einheiten

Ein Lastenheft hat eine andere innere Struktur als ein Vertrag. Es gibt Muss-Kriterien, Kann-Kriterien, Randbedingungen, offene Punkte, aber es lässt sich genauso in benennbare Einheiten unterteilen. Damit greift derselbe Mechanismus mit anderer Zielrichtung.

Bei der Angebotserstellung lautet die Frage etwa: „Welche Muss-Anforderungen im Lastenheft sind in unserem Angebot noch nicht ausreichend berücksichtigt?“ Dazu wird Dokument gegen Dokument verglichen, aber nicht auf Konflikt, sondern auf Abdeckung. Der Assistent stellt jede Muss-Anforderung ihrer Entsprechung im Angebot gegenüber, markiert, was offen ist, und ordnet es nach Wichtigkeit. Dieselbe nach Einheiten geordnete Arbeitsweise mit einem anderen Ziel.

Wo die Verantwortung bleibt

Gerade weil es bei der Vertrags- und Lastenheftanalyse um Rechtsfragen und Verpflichtungen geht, wiegt die Grenze schwerer als im Engineering-Fall. Der Assistent ist eine Prüf- und Vergleichshilfe, keine Rechtsberatung. Er strukturiert, beschleunigt und belegt; er findet die relevanten Klauseln, macht Abweichungen und Konflikte sichtbar und schlägt Formulierungen vor. Ob ein Konflikt wirklich einer ist und wie er gelöst wird, entscheidet der Mensch.

Deshalb ist die lückenlose Quellbindung hier nicht nur ein Qualitätsmerkmal, sondern rechtlich von zentraler Bedeutung: Sie erlaubt, jeden Befund und jeden Vorschlag sofort am Originaltext zu prüfen, statt ihm blind zu vertrauen. Der Assistent übernimmt die Fleißarbeit, nicht die Verantwortung, eine Grenzziehung, die für ein juristisches Publikum maßgeblich ist.

###Bild4###

Dasselbe Fundament für zwei Gebäude

Dasselbe Fundament trägt hier in zwei völlig verschiedene Gebäude: Anforderungen, Komponenten und Tests aus der Entwicklung auf der einen, Klauseln, Fristen und Haftungsregeln aus dem Vertrag auf der anderen Seite. Unterschiedlicher könnten Inhalte und Fachleute kaum sein. Die folgende Gegenüberstellung zeigt, was sich von einem Fall zum anderen verschiebt:
 

Der letzte Teil dieses Kapitels führt die Fäden zusammen: Wie werden aus solchen Demonstratoren Produktfunktionen, und wie fließen sie in die PROSTEP-Produkte und die Entwicklungsprozesse unserer Kunden ein?