AI-Strategie für Legal-Tech-Anbieter: kaufen, integrieren oder aufbauen

Wer Software für Kanzleien oder Rechtsabteilungen anbietet, kennt die Frage inzwischen aus jedem zweiten Kundengespräch: Was macht ihr eigentlich mit AI. Wettbewerber kündigen Funktionen an, Bestandskunden vergleichen, im Vertrieb fehlt die Antwort auf eine Folie. Eine AI-Strategie entsteht unter diesem Druck oft rückwärts: erst die Ankündigung, dann das Feature, dann die Frage, ob es im Alltag der Anwender trägt.

Die eigentliche Entscheidung liegt eine Ebene tiefer. Es gibt im Kern drei Wege, AI in ein Legal-Tech-Produkt zu bringen, und jeder hat einen ehrlichen Preis. Wer diesen Preis kennt, bevor er sich festlegt, entscheidet deutlich besser als unter Ankündigungsdruck.

Drei Wege, drei Preisschilder

Weg	Stärke	Preis
Fertiges Feature zukaufen	Schnell am Markt, geringes Projektrisiko	Kaum Differenzierung, Abhängigkeit vom Zulieferer
Modell-APIs integrieren	Kontrolle über Produkt und Datenfluss, überschaubarer Einstieg	Qualität, Kosten und Modellwechsel laufend zu steuern
Eigene Fähigkeit aufbauen	Echte Differenzierung, Tiefe im Produkt	Hoher Aufwand, langer Atem, Bedarf an seltenem Know-how

Zukaufen heißt: eine fertige Komponente eines Drittanbieters einbetten, etwa eine Dokumentanalyse oder einen Assistenten unter eigener Oberfläche. Das ist legitim, wenn AI für das Produkt ein Hygienefaktor ist, also etwas, das Kunden erwarten, ohne dass es die Kaufentscheidung prägt. Riskant wird es, wenn die zugekaufte Funktion das Herz des Wertversprechens sein soll: Dann verkauft man etwas, das jeder Wettbewerber ebenso einkaufen kann, und hängt bei Qualität und Roadmap vollständig am Zulieferer.

Integrieren heißt: auf Basis der großen Modellanbieter eigene Funktionen entwickeln, verbunden mit den Daten und Abläufen des eigenen Produkts. Das ist für die meisten Anbieter der sinnvolle Mittelweg, wird aber regelmäßig unterschätzt: Die erste Version ist schnell gebaut, die dauerhaft verlässliche Version ist Arbeit. Modellverhalten ändert sich mit Versionen, Kosten skalieren mit der Nutzung, und die Qualität muss laufend geprüft werden.

Aufbauen heißt heute selten, eigene Modelle zu trainieren. Es heißt, die organisatorische und technische Fähigkeit zu entwickeln, aus Basismodellen verlässliche Produktfunktionen zu machen: eigene Verarbeitungsketten, eigene Evaluationsverfahren, eigenes Verständnis der Fehlermodi. Das ist teuer und langsam, schafft aber als einziger Weg einen Vorsprung, der nicht am nächsten Modellrelease verfällt.

Was native Integration verlangt

Wer den Weg der Integration ernsthaft geht, sollte drei Investitionen von Beginn an einplanen.

Architektur. Eine tragfähige AI-Funktion ist kein Textfeld, das an das Produkt angeflanscht wird. Sie ist mit dem Datenmodell verbunden, kennt Akten, Verträge und Berechtigungen, und ihre mehrstufigen Abläufe sind sauber orchestriert. Dazu gehören versionierte Prompts und Modellstände, damit nachvollziehbar bleibt, welche Konfiguration welches Ergebnis erzeugt hat, sowie eine Kostensteuerung pro Funktion.

Evals. Systematische Evaluation ist der Unterschied zwischen einem Demo-Feature und einem Produkt. Das bedeutet: eine wachsende Sammlung von Testfällen aus realen, freigegebenen Dokumenten, definierte Kriterien für richtig und falsch, und die Regel, dass jede Änderung an Prompt oder Modell gegen diese Testfälle läuft. Ohne Evals ist jedes Modell-Update ein Blindflug, und im Rechtsmarkt endet ein Blindflug beim Kunden.

Team. Es braucht keine separate AI-Abteilung, sondern Produktteams, die beides verstehen: die fachliche Domäne und den Umgang mit probabilistischen Systemen. Und es braucht eine Person, die die Qualität der AI-Funktionen verantwortet, so wie jemand die Sicherheit oder die Verfügbarkeit verantwortet.

Anwendervertrauen als Maßstab

Juristen sind das kritischste Publikum, das man sich für AI-Funktionen aussuchen kann, und das ist ihre berufliche Pflicht. Ein erfundenes Zitat, eine übersehene Klausel, eine Zusammenfassung, die den entscheidenden Vorbehalt verschluckt: Ein einziger solcher Fall kann eine Funktion dauerhaft diskreditieren, oft gleich das gesamte Produktversprechen.

Daraus folgt eine Gestaltungslinie, die wichtiger ist als jede Modellwahl: Ergebnisse mit Quellenbindung statt freier Behauptung, nachvollziehbare Zwischenschritte statt eines undurchsichtigen Resultats, ehrlich kommunizierte Grenzen im Interface und konservative Voreinstellungen. Anwender vergleichen keine Benchmarks. Sie erinnern sich daran, ob das Werkzeug sie in den eigenen Akten je im Stich gelassen hat.

Ein Entscheidungsrahmen

Vier Fragen bringen die Entscheidung auf den Punkt.

• Ist AI für unser Produkt Differenzierung oder Hygienefaktor. Hygiene darf man zukaufen, Differenzierung nicht.
• Haben wir einen Datenzugang, der einen echten Vorteil ergibt: strukturierte Dokumente, Nutzungskontext, Rückmeldungen der Anwender. Wenn ja, spricht viel für Integration mit eigener Tiefe.
• Haben wir Team und Budget für laufende Qualitätsarbeit, nicht nur für das erste Release. Wenn nein, ist ein ehrlicher Zukauf besser als eine halbherzige Integration.
• Was erwarten unsere Anwender tatsächlich: ein Häkchen auf der Featureliste oder verlässliche Entlastung in einem konkreten Ablauf.

In der Praxis führt das häufig zu einem gestuften Weg: mit einer API-Integration in einer eng umrissenen, prüffähigen Funktion beginnen, dabei Evals und Betriebserfahrung aufbauen, und die eigene Fähigkeit gezielt dort vertiefen, wo sie Differenzierung schafft. Zukaufen bleibt für Randfunktionen legitim. Die Reihenfolge zählt: erst die Funktion, die Anwendern nachweislich Arbeit abnimmt, dann die Ankündigung.

Fazit

Kaufen, integrieren oder aufbauen ist keine einmalige Grundsatzentscheidung, sondern eine Zuordnung pro Funktion: Zukauf für Hygiene, Integration mit eigener Architektur und Evals für den Kern, Aufbau eigener Fähigkeit dort, wo Datenzugang und Domänenwissen einen haltbaren Vorsprung ergeben. Der Maßstab für jeden dieser Wege ist derselbe, und er steht nicht im Pitch-Deck: das Vertrauen der Anwender nach dem hundertsten Arbeitstag mit der Funktion.