Sprachmodelle und andere KI-Dienste sind in vielen Unternehmen längst kein Experimentierfeld mehr. Sie beantworten Kundenanfragen, klassifizieren Dokumente, erzeugen Textbausteine und unterstützen Entwicklungsteams beim Schreiben und Prüfen von Code. Sobald solche Funktionen in geschäftskritischen Abläufen verankert sind, verändert sich die Risikolage: Ein Dienst, der gestern eine Spielerei war, ist heute Teil der Wertschöpfung.

Genau an diesem Punkt setzt die aktuelle Diskussion an. Mit dem Produktivwerden von KI wächst die Abhängigkeit von einzelnen Anbietern – und damit die Frage, wie belastbar die eigene Infrastruktur eigentlich aufgestellt ist. Als Gegenmittel werden Multi-Sourcing, Open-Weight-Modelle und europäische Angebote genannt.

Warum Anbieterbindung bei KI anders wirkt

Abhängigkeit von Lieferanten ist in der IT nichts Neues. Bei KI-Diensten kommen jedoch einige Besonderheiten zusammen, die den Wechsel schwerer machen als bei klassischer Software.

  • Verhalten statt Schnittstelle: Zwei Modelle können dieselbe technische Schnittstelle bedienen und trotzdem unterschiedlich antworten. Prompts, also die Anweisungstexte an das Modell, sind oft auf ein konkretes Modell hin optimiert.
  • Qualität ist schwer zu vergleichen: Ob eine Antwort "gut genug" ist, lässt sich nicht so eindeutig messen wie eine Datenbankabfrage. Ohne eigene Testfälle fehlt die Grundlage, um Alternativen sachlich zu bewerten.
  • Daten und Kontext: Eingebettete Wissensbestände, Vektorindizes und Feinabstimmungen hängen häufig an der jeweiligen Plattform.
  • Preis- und Modellpolitik: Modelle werden abgekündigt, ersetzt oder in ihrer Nutzung eingeschränkt. Wer nur einen Bezugsweg hat, trägt diese Änderungen ungebremst mit.

Multi-Sourcing: mehr als ein zweiter Vertrag

Multi-Sourcing bedeutet, dieselbe Funktion grundsätzlich über mehrere Anbieter beziehen zu können. Der eigentliche Wert liegt weniger im zweiten Vertrag als in der Architektur, die einen Wechsel überhaupt zulässt.

Praktisch heißt das: Die Anwendung spricht nicht direkt mit der Schnittstelle eines Anbieters, sondern mit einer eigenen Zwischenschicht. Diese Schicht kapselt Authentifizierung, Modellauswahl, Wiederholversuche und Protokollierung. Wird ein Anbieter ausgetauscht, ändert sich idealerweise nur die Konfiguration – nicht der Fachcode.

Dazu gehört ein zweiter, oft unterschätzter Baustein: eine Sammlung realistischer Testfälle aus dem eigenen Anwendungsfall. Erst damit lässt sich beurteilen, ob ein alternatives Modell die fachlichen Anforderungen erfüllt. Ohne diese Grundlage bleibt jeder Anbieterwechsel ein Bauchgefühl.

Open-Weight-Modelle als zusätzliche Option

Open-Weight-Modelle sind Modelle, deren trainierte Parameter – die Gewichte – öffentlich verfügbar sind. Sie lassen sich damit grundsätzlich auf eigener oder gemieteter Infrastruktur betreiben, statt ausschließlich als fremder Dienst genutzt zu werden.

Der Nutzen liegt vor allem in der Kontrolle: Der Betrieb ist unabhängig davon, ob ein Anbieter seine Preise ändert oder ein Modell abschaltet. Daten verlassen die eigene Umgebung nicht zwingend. Und die Modellversion bleibt so lange stabil, wie es der eigene Betrieb erfordert.

Dem stehen reale Kosten gegenüber. Betrieb, Skalierung, Aktualisierung und Absicherung liegen dann im eigenen Verantwortungsbereich – inklusive der dafür nötigen Hardware und des Personals. Für viele mittelständische Organisationen ist deshalb weniger die Frage relevant, ob alles selbst betrieben wird, sondern welche Teilbereiche überhaupt selbst betrieben werden sollten. Häufig ist eine gemischte Aufstellung tragfähiger: sensible oder besonders stabilitätskritische Aufgaben intern, breit gefächerte oder rechenintensive Aufgaben über externe Dienste.

Europäische Angebote im Blick behalten

Europäische Anbieter erweitern die Auswahl zusätzlich. Relevant sind sie nicht nur aus Gründen der Datenverarbeitung innerhalb bekannter Rechtsräume, sondern schlicht als weitere Option in der Lieferantenlandschaft. Je mehr ernstzunehmende Alternativen es gibt, desto geringer ist der Druck, eine einzelne Plattform ohne Ausweichmöglichkeit zu akzeptieren.

Entscheidend ist dabei eine nüchterne Betrachtung: Herkunft allein ersetzt keine Prüfung von Leistungsfähigkeit, Verfügbarkeit und Vertragsbedingungen. Ein Anbieter gehört in die engere Wahl, wenn er den fachlichen Anforderungen genügt – die regionale Verankerung ist ein zusätzliches Argument, kein Ersatzkriterium.

Was sich konkret vorbereiten lässt

Für Projektverantwortliche ergeben sich daraus einige praktische Ansatzpunkte, die sich unabhängig von der endgültigen Anbieterentscheidung umsetzen lassen:

  1. Bestandsaufnahme: Welche Prozesse nutzen bereits KI-Dienste, und was passiert, wenn einer davon für eine Woche ausfällt? Diese Frage trennt Komfortfunktionen von echten Abhängigkeiten.
  2. Abstraktionsschicht einziehen: Anbieteraufrufe an einer Stelle bündeln, statt sie über die gesamte Anwendung zu verteilen.
  3. Testfälle aufbauen: Zwanzig bis fünfzig typische Eingaben mit erwartetem Ergebnis reichen oft aus, um Modelle vergleichbar zu machen.
  4. Verträge und Nutzungsbedingungen lesen: Kündigungsfristen, Ankündigungszeiträume für Modellwechsel und Regelungen zur Datenverwendung sind Teil der technischen Risikobewertung.
  5. Daten portabel halten: Quelldokumente, Prompt-Sammlungen und Auswertungsergebnisse gehören in Formate, die außerhalb der jeweiligen Plattform nutzbar bleiben.

Keiner dieser Punkte verlangt eine sofortige Grundsatzentscheidung. Sie senken jedoch den Aufwand, falls eine solche Entscheidung später nötig wird.

Einordnung für Web- und Softwareprojekte

Für Webplattformen und Fachanwendungen bedeutet das vor allem: KI-Funktionen sollten von Anfang an als austauschbare Komponente entworfen werden, nicht als fest verdrahteter Bestandteil der Anwendung. Der Aufwand für eine saubere Abstraktionsschicht und eigene Testfälle ist im laufenden Projekt überschaubar, im Nachhinein dagegen deutlich höher. Wer diese Vorarbeit leistet, entscheidet über Anbieter und Betriebsmodell später aus einer Position der Wahlfreiheit – und nicht unter Zeitdruck.

Quellen