Die KI-Vendor-Landschaft ist unübersichtlich. Jedes Quartal bringt neue Plattformen, neue Modellanbieter, neue Start-ups, die behaupten, jedes Problem zu lösen, und neue Preismodelle, die jeden Vergleich nahezu unmöglich machen. Für ein Mittelstandsunternehmen, das seine erste signifikante KI-Investition tätigt, ist das Risiko einer Fehlentscheidung nicht abstrakt — es ist ein sechsstelliger Fehler, der 12 Monate Rückstand bedeuten kann.

Die gute Nachricht: Sie müssen nicht den perfekten Vendor wählen. Sie müssen einen ausreichend guten Vendor wählen und dabei die Fähigkeit zum Wechsel erhalten. Diese Unterscheidung — gut genug mit Optionalität — ist das Schlüsselprinzip hinter jeder Vendor-Entscheidung, die funktioniert.

Warum Vendor-Auswahl bei KI schwieriger ist als bei klassischer Software

Klassische Enterprise-Software ist stabil. SAP funktioniert dieses Jahr genauso wie letztes Jahr. Die Vendor-Landschaft ist konsolidiert. Wechselkosten sind hoch, aber vorhersehbar. Sie treffen eine Entscheidung, leben 5–10 Jahre damit und planen Upgrades auf einem bekannten Zeitplan.

KI ist das Gegenteil. Modell-Fähigkeiten verbessern sich dramatisch zwischen Versionen. Der heutige State of the Art ist die Baseline des nächsten Quartals. Preisstrukturen ändern sich, während Anbieter mit Per-Token-, Per-Seat- und Per-Outcome-Modellen experimentieren. Neue Open-Source-Alternativen machen teure proprietäre Lösungen überflüssig. Vendors pivotieren, fusionieren oder stellen den Betrieb ein.

Eine 5-Jahres-Bindung an eine KI-Plattform einzugehen, ist wie 2008 einen 5-Jahres-Mobilfunkvertrag zu unterschreiben. Die Landschaft wird grundlegend anders aussehen, wenn der Vertrag ausläuft.

Das Vier-Ebenen-Evaluierungsframework

Wir evaluieren KI-Vendors auf vier Ebenen. Jede Ebene birgt unterschiedliches Risiko und unterschiedliche Wechselkosten.

Ebene 1: Modellanbieter

Die Foundation Models — OpenAI, Anthropic, Google, Meta (Open Source), Mistral und andere. Diese Ebene verändert sich am schnellsten und sollte als austauschbar behandelt werden.

Evaluierungskriterien: Modellqualität für Ihren spezifischen Anwendungsfall (Benchmark-Scores sind irreführend — testen Sie mit Ihren Daten), Kosten pro Transaktion bei Ihrem erwarteten Volumen, Datenverarbeitungsbedingungen (wohin werden Daten gesendet, gespeichert, verarbeitet?), EU-Datenresidenz-Optionen.

Lock-in-Risiko: Gering, wenn Sie korrekt architektonisch planen. Modelle werden über APIs mit ähnlichen Input-/Output-Formaten angesprochen. Der Wechsel von einem Anbieter zum anderen erfordert Tage, nicht Monate — vorausgesetzt, Sie haben keine anbieterspezifischen Features tief in Ihren Workflow eingebettet.

Empfehlung: Designen Sie Ihr System von Tag eins als modell-agnostisch. Verwenden Sie eine Abstraktionsschicht, die Ihnen den Wechsel des Modellanbieters ermöglicht, ohne Ihren Anwendungscode zu ändern. Das ist gängige Praxis und fügt minimale Komplexität hinzu. (Warum kommerzielle Modelle für die meisten Mittelständler der richtige Startpunkt sind, erklärt Build vs. Buy für Enterprise-KI.)

Ebene 2: KI-Plattformen und Orchestrierung

Die Middleware — Werkzeuge zum Bau von KI-Workflows, Prompt-Management, Retrieval-Pipelines, Orchestrierung mehrstufiger Prozesse. Dazu gehören LangChain, LlamaIndex, Haystack sowie Managed Platforms der Cloud-Anbieter (Azure AI, AWS Bedrock, Google Vertex AI).

Evaluierungskriterien: Unterstützt die Plattform Ihre Implementierungsmuster (Klassifikation, Extraktion, Retrieval, Orchestrierung)? Welche Hosting-Optionen gibt es (Cloud, On-Premise, Hybrid)? Wie ausgereift sind Monitoring und Observability? Wie steil ist die Lernkurve für Ihr Team?

Lock-in-Risiko: Mittel. Plattformspezifische Abstraktionen, Workflow-Definitionen und Integrationsmuster erzeugen Wechselkosten. Von einer Orchestrierungsplattform zu einer anderen zu wechseln, ist ein Projekt, keine Konfigurationsänderung.

Empfehlung: Bevorzugen Sie Open-Source-Orchestrierungstools gegenüber proprietären Plattformen, wo die Funktionalität vergleichbar ist. Wenn Sie eine Managed Cloud-Plattform nutzen, stellen Sie sicher, dass Ihre Kernlogik (Prompts, Validierungsregeln, Geschäftslogik) außerhalb der Plattform lebt und bei Bedarf extrahiert werden kann.

Ebene 3: Dateninfrastruktur

Wo Ihre Daten liegen, wie sie verarbeitet werden und wie sie in KI-Workflows einfließen. Dazu gehören Vektordatenbanken, Datenpipelines, Feature Stores und Integrationsschichten zu Ihren bestehenden Systemen (ERP, CRM, DMS).

Evaluierungskriterien: Kompatibilität mit Ihrer bestehenden Infrastruktur. Datensouveränitäts-Compliance (DSGVO, EU-Datenresidenz). Performance bei Ihren Datenvolumen. Exportfähigkeiten — können Sie Ihre Daten herausholen?

Lock-in-Risiko: Hoch. Dateninfrastruktur ist die klebrigste Ebene. Sobald Ihre Datenpipelines gebaut und Ihre Vektordatenbanken befüllt sind, ist ein Wechsel teuer und riskant. Hier entsteht das meiste reale Lock-in.

Empfehlung: Behalten Sie die Hoheit über Ihre Dateninfrastruktur. Verwenden Sie Standardformate und offene Protokolle, wo möglich. Stellen Sie sicher, dass jede Datenpipeline eine Exportfähigkeit beinhaltet. Lassen Sie nie einen Vendor das einzige Repository für Ihre operativen Daten sein.

Ebene 4: Implementierungs- und Betriebspartner

Die Unternehmen, die Ihnen helfen, KI-Workflows zu bauen, zu deployen und zu betreiben. Beratungshäuser, Systemintegratoren und spezialisierte KI-Partner.

Evaluierungskriterien: Haben sie relevante Branchenerfahrung (nicht nur KI-Erfahrung — Ihre Branche)? Transferieren sie Wissen oder schaffen sie Abhängigkeit? Wie sieht das Engagement-Modell aus (projektbasiert, Retainer, eingebettetes Team)? Wird Ihr Team das System nach dem Engagement eigenständig betreiben können?

Lock-in-Risiko: Variabel. Ein Partner, der opake Systeme baut und exklusives Betriebswissen behält, erzeugt hohes Lock-in. Ein Partner, der transparent baut, alles dokumentiert und Ihr Team befähigt, erzeugt niedriges Lock-in.

Empfehlung: Wählen Sie Partner, die sich selbst überflüssig machen. Das Engagement sollte damit enden, dass Ihr Team den KI-Workflow eigenständig betreiben und weiterentwickeln kann. Jeder Partner, der Engagements so strukturiert, dass fortlaufende Abhängigkeit entsteht, optimiert seinen Umsatz, nicht Ihre Fähigkeit.

Datensouveränität: Die nicht verhandelbare Anforderung

Für DACH-Unternehmen ist Datensouveränität kein Nice-to-have. Unter der DSGVO erfordert die Übermittlung personenbezogener Daten an außereuropäische Verarbeiter angemessene Schutzmaßnahmen. Unter branchenspezifischer Regulierung (BaFin für Finanzdienstleistungen, Versicherungsaufsichtsbehörden) dürfen bestimmte Daten die deutsche Jurisdiktion gar nicht verlassen.

Die praktischen Implikationen für die Vendor-Auswahl:

Modellanbieter: Stellen Sie sicher, dass EU-Datenverarbeitungsoptionen existieren. OpenAI über Azure bietet EU-Datenresidenz. Anthropic bietet EU-Verarbeitung über AWS Frankfurt. Open-Source-Modelle können vollständig on-premise gehostet werden.

Cloud-Plattformen: Azure (Regionen Frankfurt, Berlin), AWS (Region Frankfurt) und Google Cloud (Region Frankfurt) bieten alle EU-Datenresidenz. Bestätigen Sie, dass die Datenverarbeitung — nicht nur die Speicherung — in der Region verbleibt.

Vektordatenbanken und Dateninfrastruktur: In der EU hosten. Bei Managed Services die Datenresidenz-Bedingungen verifizieren. Self-Hosted-Optionen (Qdrant, Milvus, Weaviate auf Ihrer Infrastruktur) eliminieren die Fragestellung vollständig.

Akzeptieren Sie keine Vendor-Zusicherungen ohne Verifizierung. Fragen Sie konkret: Wo werden Daten verarbeitet (nicht nur gespeichert)? Werden Daten für Modelltraining verwendet? Können Sie einen Auftragsverarbeitungsvertrag vorlegen, der DSGVO-Anforderungen erfüllt?

Der Exit-Klausel-Test

Bevor Sie einen KI-Vendor-Vertrag unterschreiben, wenden Sie den Exit-Klausel-Test an: Wenn wir in 6 Monaten den Vendor wechseln müssten — könnten wir?

Dieser Test deckt versteckte Abhängigkeiten auf. Können Sie Ihre Daten in einem Standardformat exportieren? Können Sie den Workflow auf einer anderen Plattform nachbilden? Gehören Ihnen Ihre Prompts, Validierungsregeln und Geschäftslogik? Ist das Betriebswissen dokumentiert oder im Team des Vendors eingeschlossen?

Wenn die Antwort auf eine dieser Fragen „Nein" lautet, haben Sie ein Lock-in-Risiko identifiziert. Das bedeutet nicht, dass Sie nicht weitermachen sollten — es bedeutet, dass Sie Vertragsbedingungen verhandeln sollten, die das Risiko mindern (Datenportabilitäts-Klauseln, Source-Code-Escrow, Dokumentationsanforderungen), oder Ihr System so architektonisch gestalten, dass die Abhängigkeit reduziert wird.

Häufige Fehler

Entscheidung anhand von Demos. Jede Vendor-Demo sieht beeindruckend aus. Ihre Beschaffungsentscheidung sollte auf einem Proof of Concept mit Ihren Daten basieren, in Ihrem Maßstab, für Ihren Anwendungsfall — nicht auf einer polierten Präsentation mit handverlesenen Beispielen.

Überinvestition in Plattform vor dem Wertnachweis. Kaufen Sie keine Enterprise-KI-Plattform, bevor Sie einen einzigen Workflow in Produktion haben. Starten Sie mit leichtgewichtigen Tools, beweisen Sie den Business Case, investieren Sie dann in Infrastruktur. Das ist das Gegenteil von dem, was die meisten Vendors empfehlen — weil die meisten Vendors Plattformen verkaufen.

Total Cost of Ownership ignorieren. API-Kosten sind die sichtbare Ausgabe. Compute, Storage, Integrationsentwicklung, operatives Monitoring und Teamschulung sind die unsichtbaren. Ein Modell, das 0,01 EUR pro API-Call kostet, aber 50.000 EUR Integrationsentwicklung erfordert, ist nicht günstig.

Vendor-Auswahl als einmalige Entscheidung behandeln. Überprüfen Sie Ihren Vendor-Stack jährlich. Die Landschaft verändert sich schnell genug, dass die optimale Wahl von letztem Jahr nicht die von diesem Jahr sein muss. Bauen Sie die Optionalität zum Wechsel, ohne den Wechsel zum Standardverhalten zu machen — Stabilität hat auch einen Wert.

Die Entscheidung treffen

Vendor-Auswahl-Paralyse ist real. Die Landschaft ist komplex, die Einsätze fühlen sich hoch an, und die Optionen sind überwältigend. Hier der pragmatische Ansatz:

  1. Definieren Sie Ihren ersten Anwendungsfall spezifisch (siehe Process Mining für KI-Kandidaten)
  2. Identifizieren Sie den minimalen Vendor-Stack für diesen Anwendungsfall
  3. Priorisieren Sie Datensouveränität und Exit-Flexibilität vor Feature-Vollständigkeit
  4. Führen Sie einen zeitlich begrenzten Proof of Concept durch (2–4 Wochen) vor der Bindung
  5. Klein anfangen, lernen, erweitern

Wenn Sie Unterstützung bei der Vendor-Auswahl für Ihre spezifische Situation wünschen, buchen Sie ein Erstgespräch. Wir sind vendor-agnostisch — wir vertreiben keine Plattformen und nehmen keine Vermittlungsprovisionen — was bedeutet, dass unsere Empfehlung ausschließlich auf dem basiert, was für Ihren Anwendungsfall, Ihre Datensouveränitätsanforderungen und die Fähigkeiten Ihres Teams funktioniert.

Für den breiteren operativen Kontext siehe KI im Betrieb.

Dieser Artikel ist Teil der Reihe KI im Betrieb von Andreas Anding. Für die vollständige Methodik siehe Das KI-Betriebssystem.