KI-Anbieter bewerten und Build-versus-Buy-Entscheidungen treffen

# KI-Anbieter bewerten und Build-versus-Buy-Entscheidungen treffen

Der Innovationspartner einer mittelgroßen Anwaltskanzlei hat zwei Angebote vor sich. Das eine ist ein Vertrag über 150.000 Dollar pro Jahr mit einem Legal-AI-Anbieter, der automatisierte Vertragsprüfung verspricht. Das andere ist eine grobe Schätzung des IT-Leiters der Kanzlei: drei Monate und rund 40.000 Dollar für ein schlankes internes Tool auf Basis von Standard-APIs großererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → Sprachmodelle (LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.Vollständige Definition ansehen →). Gleiches Problem, völlig unterschiedliche Wege. Das ist der Entscheidungspunkt, an dem jede Professional-Services-Firma landet, sobald KI von der „interessanten Demo“ zur Budgetposition wird.

Warum diese Entscheidung schwieriger ist, als sie aussieht

Professional-Services-Firmen (Recht, Wirtschaftsprüfung, Beratung, Advisory) verkaufen Urteilsvermögen, nicht nur Software. Das verändert die Rechnung auf eine Weise, die Anbieter nicht immer hervorheben:

• Verpflichtungen zur Mandantenvertraulichkeit (Anwaltsgeheimnis, Regeln zur Unabhängigkeit des Prüfers) begrenzen, wohin Daten gehen dürfen.
• Fachliche Genauigkeit zählt mehr als allgemeine Sprachqualität. Ein Tool, das Verträge gut zusammenfasst, aber eine jurisdiktionsspezifische Haftungsklausel übersieht, erzeugt echtes Berufsrisiko.
• Bestehende Systeme (Practice-Management-Software wie Clio oder iManage oder Audit-Plattformen) enthalten die Daten der Kanzlei bereits. Ein neues Tool, das nicht mit ihnen spricht, erzeugt Doppelarbeit, und das tötet die Adoption.

Die Build-versus-Buy-Frage sind eigentlich drei getarnte Fragen: Ist das eine Fähigkeit, die wir selbst kontrollieren müssen, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen wir sie glaubwürdig selbst bauen, und hält die Antwort des Anbieters auf die ersten beiden Fragen einer Prüfung stand?

Die Bewertungs-Scorecard

Nutzen Sie eine einfache gewichtete Scorecard, wenn Sie ein Anbieterangebot mit einem internen Build vergleichen. Bewerten Sie jede Dimension von 1 bis 5, gewichten Sie nach Bedeutung für Ihre Praxis und summieren Sie. Die Scorecard erzwingt für beide Optionen die gleiche Strenge, denn interne Projekte entgehen der Prüfung, die Anbieter erfahren, häufig.

1. Datensicherheit und Vertraulichkeit

• Wohin gehen die Daten? Werden sie von einem Drittanbieter-Modellbetreiber verarbeitet, und unter welchen Vertragsbedingungen?
• Gibt es einen Auftragsverarbeitungsvertrag (DPA) und, für EU-Mandanten, DSGVO-Konformität (Datenschutz-Grundverordnung)?
• Trainiert der Anbieter seine Modelle standardmäßig mit Ihren Daten? (Viele Enterprise-Verträge schließen das inzwischen aus, aber prüfen Sie die tatsächliche Klausel, nicht die Marketingseite.)
• Beim Build: Wer in der Kanzlei kontrolliert die Zugriffe, und gibt es einen Audit-Trail?

2. Genauigkeit bei fachspezifischen Aufgaben

• Fragen Sie nach Benchmark-Ergebnissen zu Aufgaben, die Ihren ähneln, nicht nach generischen Leaderboard-Werten. Die Leistung eines Vertragsprüfungs-Tools bei NDAs sagt wenig über seine Leistung bei grenzüberschreitender M&A-Due-Diligence.
• Verlangen Sie einen Pilot mit Ihren eigenen redigierten Dokumenten, nicht mit Demodaten des Anbieters.
• Prüfen Sie Halluzinationsraten bei zitatlastigen Aufgaben. Legal-Research-Tools hatten hier gut dokumentierte Fehlschläge, darunter sanktionierte Gerichtsschriftsätze mit erfundenen Fällen (ein seit 2023 breit berichtetes Problem).
• Beim Build: Welches Modell rufen Sie auf, und hat jemand es gegen Ihre Dokumenttypen validiert?

3. Integration in Practice-Management-Systeme

• Hat das Tool eine dokumentierte Programmierschnittstelle (APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →, ein definierter Weg, auf dem Softwaresysteme Daten austauschen), die sich mit Ihrem bestehenden Case-Management-, Billing- oder Dokumentenmanagementsystem verbindet?
• Erfordert es manuellen Export/Import, den die Mitarbeiter innerhalb weniger Wochen stillschweigend aufgeben werden?
• Beim Build: Integration ist meist der am stärksten unterschätzte Kostenblock. Ein „einfaches“ internes Tool, das Mandatsdaten nicht automatisch ziehen kann, wird zu Shelf-ware.

4. Anbieterstabilität und Lock-in

• Wie lange ist der Anbieter am Markt, und wer sind Referenzkunden in Ihrem Praxisbereich?
• Was passiert mit Ihren Daten und Workflows, wenn der Anbieter übernommen wird oder schließt? (Legal Tech hat echte Konsolidierung gesehen, z. B. die Übernahme von Casetext durch Thomson Reuters 2023.)
• Beim Build: Was passiert, wenn der einzige Entwickler, der es gebaut hat, geht?

5. Total Cost of Ownership

• Anbieter: Abo plus Implementierung plus Training plus interner Administrationsaufwand.
• Build: Entwicklung plus laufende Modell-APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Kosten plus Wartung plus Opportunitätskosten der IT-Zeit.

Ein durchgerechneter Vergleich

Nehmen Sie das Beispiel Vertragsprüfung. Grobe Schätzungen, klar als solche gekennzeichnet:

Anbieteroption: 150.000 Dollar/Jahr, Implementierungsunterstützung inklusive, Genauigkeit laut Anbieterangaben bei etwa 85 bis 90 % Übereinstimmung mit der Prüfung durch einen Senior Associate bei Standard-Handelsverträgen (Schätzung, Anbieterangabe, immer unabhängig verifizieren).

Build-Option: 40.000 Dollar Einmalaufwand mit einer Allzweck-LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.Vollständige Definition ansehen →-APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → (Kostenschätzung für Entwicklerzeit und APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Nutzung, Preise 2025 bis 2026), plus geschätzt 15.000 bis 25.000 Dollar/Jahr für laufende APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Kosten und Wartung. Genauigkeit unbekannt bis zum Test, anfangs wahrscheinlich niedriger ohne fachliches Fine-tuningFine-tuningFine-tuning adapts a pre-trained model to a specific task or domain by continuing training on a smaller, targeted dataset, improving accuracy and style for that use case.Vollständige Definition ansehen → oder Retrieval-Augmented Generation (RAG), die es in der eigenen Präzedenzbibliothek der Kanzlei verankert.

Einfacher Dreijahresvergleich der Total Cost of Ownership (TCO):

• Anbieter: 150.000 Dollar x 3 = 450.000 Dollar
• Build: 40.000 Dollar + (20.000 Dollar x 3) = 100.000 Dollar

Rein kostenseitig gewinnt der Build über drei Jahre um rund 350.000 Dollar (illustrative Schätzung, keine Prognose). Das ignoriert aber die vier anderen Dimensionen der Scorecard. Liegt die Genauigkeit des Builds bei 65 % statt 85 %, zahlt die Kanzlei an anderer Stelle: Partnerzeit für die Nachkontrolle der Ergebnisse, Risiko für das Mandantenvertrauen, mögliche Haftungsexponierung. Kostenvergleiche ohne Anpassung für Genauigkeit und Risiko sind unvollständig, und das ist der häufigste Fehler bei solchen Entscheidungen.

Wann bauen, wann kaufen

Kaufen, wenn:

• Die Aufgabe branchenweit verbreitet ist (Vertragsprüfung, E-Discovery, Transkription) und etablierte Anbieter mit Track Record existieren. Beispiele in Legal Tech sind Harvey, Relativity und Luminance; in der Wirtschaftsprüfung Tools, die auf den KI-Add-ons großererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ERP-Anbieter aufsetzen.
• Ihrer Kanzlei die interne KI-Engineering-Kapazität fehlt, um eine Modell-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → verantwortungsvoll zu betreiben.
• Geschwindigkeit beim Rollout wichtiger ist als Anpassbarkeit.

Bauen, wenn:

• Der Workflow für Ihre Praxis einzigartig ist (ein Nischen-Regulierungsbereich, eine proprietäre Methodik) und kein Anbieter ihn gut abdeckt.
• Sie technisches Personal haben, das das Tool langfristig pflegen kann, nicht nur launchen.
• Die Datensensibilität so hoch ist, dass selbst geprüfte Drittverarbeitung ein klares Nein ist (selten, aber real bei manchen Arbeiten im Regierungs- oder verteidigungsnahen Umfeld).

Hybrid (2026 zunehmend verbreitet): eine Foundation-Model-APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → lizenzieren (von OpenAI, Anthropic, Google oder ähnlich), aber die Retrieval-Schicht und die Integration intern bauen. Das bringt Modellqualität ohne vollständigen Vendor-Lock-in, zum Preis echter technischer Verantwortung im Haus.

Einen echten Pilot fahren, keine Demo

Welchen Weg Sie auch bevorzugen: Bestehen Sie auf einem Pilot mit Ihren eigenen Daten, bevor Sie etwas Mehrjähriges unterschreiben:

• Nutzen Sie redigierte oder anonymisierte echte Mandate, keine Beispieldaten des Anbieters.
• Lassen Sie die Fachleute, die das Tool tatsächlich nutzen werden (Associates, nicht nur Partner), die Ergebnisse blind bewerten und KI-Output mit von Menschen erledigter Arbeit vergleichen, ohne zu wissen, was was ist.
• Legen Sie vorab eine Zahl als Schwelle fest: zum Beispiel „Output muss bei mindestens 80 % der markierten Klauseln mit dem Urteil des Senior Reviewers übereinstimmen“ (illustrativer Schwellenwert, setzen Sie Ihren eigenen anhand Ihrer Risikotoleranz).
• Setzen Sie ein Zeitfenster: 30 bis 60 Tage, dann eine formale Go/No-go-Entscheidung mit den Scorecard-Summen vor den Partnern.

Für eine verständliche Einführung in die Bewertung der Zuverlässigkeit von KI-Systemen vor dem Einsatz ist das NIST AI Risk Management Framework (US National Institute of Standards and Technology) eine solide, kostenlose und anbieterunabhängige Quelle, die weit über den staatlichen Einsatz hinaus anwendbar ist.

🎬 [VIDEO: "Build vs Buy: The AI Decision Every Company Faces" - youtube.com - ein praxisnahes Framework zur Abwägung zwischen interner KI-Entwicklung und Anbieterlösungen, anwendbar über Professional-Services-Kontexte hinweg]

Key Takeaways

• Bewerten Sie Anbieter- und Build-Optionen auf denselben vier Dimensionen: Datensicherheit, fachliche Genauigkeit, Integration und Total Cost of Ownership. Lassen Sie nicht die Anbieter die Vergleichsbedingungen setzen.
• Kostenvergleiche sind ohne Anpassung für Genauigkeit und Risiko unvollständig. Ein günstigeres Tool, das häufiger falsch liegt, kann über Partner-Prüfzeit und Mandantenrisiko teurer werden.
• Kaufen Sie für verbreitete, ausgereifte Use Cases (Vertragsprüfung, E-Discovery); bauen Sie nur, wenn der Workflow wirklich einzigartig ist und Sie Personal für die langfristige Pflege haben.
• Pilotieren Sie immer mit Ihren eigenen echten (redigierten) Daten, bevor Sie einen Mehrjahresvertrag unterschreiben oder einen Build freigeben. Demo-Performance und Produktions-Performance sind zwei verschiedene Dinge.
• Hybride Ansätze, also ein Foundation Model lizenzieren und die eigene Integrationsschicht bauen, sind 2026 zunehmend der praktikable Mittelweg.