Make, Buy oder Mieten: 4 Entscheidungen, bevor Sie sich bei KI an einen Anbieter binden

Bei KI entscheidet nicht der Preis über die Bindung, sondern die Frage, wie teuer der Ausstieg wäre. 2026 ist das keine theoretische Überlegung mehr. Viele Unternehmen haben ihre ersten Anbieter ausgewählt, als es vor allem darum ging, überhaupt zu starten – schnell, pragmatisch, mit dem System, das gerade verfügbar war. Jetzt stehen die ersten Verlängerungen an, und damit eine Frage, die bei der Auswahl keine Rolle spielte: Wie frei sind wir eigentlich noch?

Das Muster ist bekannt aus anderen Technologiewellen, trifft bei KI aber schneller zu. Ein Fachbereich beginnt mit einem Standardassistenten. Nach einigen Monaten hängen daran Integrationen in CRM und ERP, hunderte abgestimmte Anweisungen, eine gepflegte Wissensbasis, Schulungsunterlagen, Arbeitsanweisungen und das stille Erfahrungswissen der Belegschaft, wie man mit genau diesem System umgeht. Nichts davon stand im Angebot. Alles davon ist Bindung.

Hinzu kommt, dass sich Preismodelle bewegen. Eine solide kalkulierte Position kann schnell teurer werden – und die Verhandlungsmacht ist gering, wenn ein Wechsel realistisch Monate dauert. Die verbreitete Annahme, man könne einen KI-Anbieter notfalls in wenigen Wochen tauschen, hält der Praxis selten stand.

Warum also gerade jetzt über Make, Buy oder Mieten sprechen? Ganz einfach: Weil die Entscheidung nicht mehr nur ein Beschaffungsvorgang ist. Sobald ein KI-System in einem Kernprozess sitzt, entscheidet die Anbieterwahl mit darüber, wo Ihr Betriebswissen entsteht, wer über Änderungen bestimmt und wie teuer Ihre nächste Option wird. Das ist eine strategische Frage – und sie gehört vor die Unterschrift, nicht in die Verlängerungsrunde.

In diesem Artikel stelle ich Ihnen vier Entscheidungen vor, die Sie treffen sollten, bevor Sie sich an einen Anbieter binden – von der Abgrenzung zwischen Kernfähigkeit und Commodity über die Frage, was von Ihren Daten bleibt, bis hin zur ehrlichen Bewertung der Ausstiegskosten und der Klärung, wer das System betreibt und für seine Ergebnisse einsteht.

Entscheidung #1: Kernfähigkeit oder Commodity? – was ins Haus gehört und was Sie einkaufen

Die Diskussion über Make or Buy kippt häufig in ein Extrem. Entweder soll alles selbst gebaut werden, weil KI als Zukunftsthema gilt und man sich nicht abhängig machen will – mit dem Ergebnis, dass knappe Entwicklerkapazität in Dinge fließt, die man für wenig Geld mieten könnte. Oder es wird alles eingekauft, bis irgendwann auch jene Logik beim Anbieter liegt, die den eigenen Wettbewerbsvorteil ausmacht.

Stellen Sie sich stattdessen vor, Sie sortieren jedes Vorhaben in drei Kategorien. Commodity: Fähigkeiten, die in jedem Unternehmen gleich aussehen – Textentwürfe, Transkription, Übersetzung, Recherche, allgemeine Assistenz. Diese werden gemietet, und die einzige relevante Frage ist, ob Datenschutz und Betriebsmodell passen. Differenzierend: alles, was Ihren Vorsprung ausmacht – Ihre Preis- und Margenlogik, Ihre Prüfregeln, Ihre Kundenhistorie, Ihre Fertigungs- oder Serviceerfahrung. Diese Logik gehört unter Ihre Kontrolle, auch wenn die Rechenleistung von außen kommt. Und dazwischen: Fähigkeiten, die Sie einkaufen, aber selbst konfigurieren und besitzen müssen.

Ein Beispiel aus dem Vertrieb: Ein Assistent für Angebote nutzt selbstverständlich ein zugekauftes Modell – es gibt keinen Grund, Sprachverarbeitung selbst zu entwickeln. Aber die Regeln, welche Rabattstufe bei welchem Kundensegment vertretbar ist, welche Mindestmarge gilt und welche Gegenleistung ein Nachlass erfordert, sind Ihr Geschäft. Diese Regeln dürfen nicht als Konfiguration in einem fremden System verschwinden, aus dem Sie sie nicht exportieren können. Sie sollten dokumentiert, versioniert und unabhängig vom Anbieter lesbar vorliegen.

Hilfreich ist eine einfache Prüffrage: Würde ein Wettbewerber mit demselben System automatisch dasselbe Ergebnis erzielen? Wenn ja, ist es Commodity – mieten. Wenn nein, liegt der Unterschied in etwas, das Ihnen gehören muss.

Das Ergebnis? Sie investieren eigene Kapazität dort, wo sie Wirkung hat, und kaufen den Rest ein. Gleichzeitig verhindern Sie den häufigsten strategischen Fehler: dass das eigene Geschäftswissen als Nebenprodukt in der Konfiguration eines Anbieters landet.

Entscheidung #2: Wohin fließen Ihre Daten – und was bleibt, wenn der Vertrag endet?

In Auswahlprozessen wird die Datenfrage meist gründlich gestellt – allerdings nur für den laufenden Betrieb. Geprüft wird, wo verarbeitet wird, ob Eingaben zum Training verwendet werden und welche Zertifizierungen vorliegen. Was fast nie geprüft wird: Was passiert am Ende des Vertrags?

Dabei entsteht der eigentliche Wert häufig erst im Betrieb. Nicht die Ausgangsdaten sind das Entscheidende, sondern das, was sich über Monate ansammelt: formulierte Anweisungen, Korrekturen der Mitarbeitenden, Freigabeentscheidungen, Bewertungen guter und schlechter Antworten, gepflegte Wissensbestände, Ausnahmeregeln. Das ist angelerntes Betriebswissen – und es ist oft deutlich wertvoller als die Lizenz, die man dafür bezahlt hat.

Stellen Sie sich vor, jeder Vertrag beantwortet vor der Unterschrift fünf Fragen. Welche Daten und Artefakte entstehen erst im System? Wem gehören sie vertraglich? In welchem Format und mit welchem Aufwand sind sie exportierbar – maschinenlesbar oder als PDF-Sammlung? Was wird nach einer Kündigung gelöscht, in welcher Frist, und wie wird das nachgewiesen? Und bleibt etwas beim Anbieter, das er weiterverwenden darf?

Ein Beispiel aus dem Kundenservice: Ein Team arbeitet 18 Monate mit einem Assistenzsystem und korrigiert dabei tausende Antwortvorschläge. Genau diese Korrekturen sind der Grund, warum das System inzwischen brauchbar ist. Liegt sie beim Anbieter und ist nicht exportierbar, beginnt jeder Wechsel bei null – und das weiß der Anbieter in der Verlängerungsverhandlung genauso gut wie Sie.

Das Ergebnis? Sie behandeln Ihr Betriebswissen als Vermögenswert und nicht als Nebenprodukt. Exportierbarkeit gehört damit in dieselbe Kategorie wie Datenschutz: ein Ausschlusskriterium, nicht ein Nice-to-have.

Entscheidung #3: Was würde der Ausstieg kosten? – Lock-in entsteht nicht im Vertrag, sondern in der Arbeit

Die meisten Vergleichstabellen in Auswahlprozessen enthalten Preis, Funktionsumfang, Sicherheitsmerkmale und Referenzen. Was sie nie enthalten, ist die Zahl, die später über Ihre Verhandlungsposition entscheidet: die Kosten eines Wechsels.

Der Grund für diese Lücke ist, dass Lock-in sich nicht im Vertrag versteckt, sondern in der täglichen Arbeit aufbaut. Anweisungen und Abläufe werden über Monate auf das Verhalten eines bestimmten Modells abgestimmt. Integrationen werden gegen eine bestimmte Schnittstelle gebaut. Schulungen, Arbeitsanweisungen und Prüfroutinen beziehen sich auf eine bestimmte Oberfläche. Nichts davon ist dramatisch für sich – zusammen ergibt es einen Aufwand, der einen Wechsel von einer Entscheidung in ein Projekt verwandelt.

Stellen Sie sich vor, jede KI-Beschaffung beantwortet eine einzige zusätzliche Frage, schriftlich und mit Zahlen: Was würde es uns kosten, in sechs Monaten zu gehen – an Zeit, an Geld, an Risiko? Wer diese Frage beantworten kann, verhandelt anders. Und wer sie nicht beantworten kann, hat seine Verhandlungsmacht bereits abgegeben, ohne es zu merken.

Aus der Antwort ergeben sich meist vier Maßnahmen von selbst. Erstens eine schlanke Zwischenschicht für die kritischen Anwendungsfälle, sodass das Modell austauschbar bleibt und nicht jede Anweisung beim Wechsel neu geschrieben werden muss. Zweitens Besitz und Versionierung aller Anweisungen und Konfigurationen auf Ihrer Seite. Drittens kürzere Vertragslaufzeiten dort, wo der Markt sich schnell bewegt – Planungssicherheit über drei Jahre ist bei KI selten ein Vorteil. Viertens ein ernsthaft geprüfter zweiter Anbieter für die wenigen Anwendungsfälle, deren Ausfall oder Verteuerung Sie wirklich treffen würde.

Wichtig ist das Maß. Vollständige Unabhängigkeit ist teuer und meist unnötig; sie erzeugt Komplexität, die sich für einen Textassistenten nie rechnet. Entschieden wird daher nach Kritikalität: Wo würde eine Verdopplung des Preises oder ein Ausfall von zwei Wochen wehtun – und wo nicht?

Das Ergebnis? Sie bezahlen bewusst für Optionen statt sie unbewusst zu verlieren. Und Sie führen Verlängerungsgespräche aus einer Position, in der ein Nein tatsächlich möglich ist.

Entscheidung #4: Wer betreibt es – und wer steht für die Ergebnisse ein?

Viele Beschaffungsprozesse enden mit der Unterschrift. Damit beginnt aber erst der Teil, der über Zufriedenheit und Kosten entscheidet: der Betrieb. Und hier klaffen Erwartung und Vertrag häufig auseinander. Übliche Service-Zusagen beziehen sich auf Verfügbarkeit – dass das System erreichbar ist. Was ein Unternehmen tatsächlich braucht, ist eine Zusage zur Ergebnisqualität und zur Veränderung im Zeitverlauf.

Stellen Sie sich vor, vor der Unterschrift werden vier Punkte geklärt. Erstens die Qualitätsprüfung: Wer kontrolliert in welchem Takt, ob das System noch das tut, was es soll – und auf welcher Stichprobenbasis? Zweitens die Verantwortung: Wer trägt die Folgen einer fehlerhaften Empfehlung, und an welcher Stelle ist ein Mensch zwingend eingebunden? Drittens die Nachweisfähigkeit: Welche Protokolle und Dokumente liefert der Anbieter, damit Sie gegenüber Revision, Prüfern und regulatorischen Anforderungen nachweisen können, wie Entscheidungen zustande kamen? Viertens die Änderungen: Wie und wie früh werden Sie informiert, wenn der Anbieter das zugrunde liegende Modell wechselt oder anpasst?

Der vierte Punkt wird am häufigsten übersehen und ist der unangenehmste. Ein Modellupdate kann das Verhalten eines Systems verändern, ohne dass in Ihrem Haus jemand etwas getan hat. Formulierungen verschieben sich, Einschätzungen fallen anders aus, eine eingespielte Anweisung liefert plötzlich ein anderes Ergebnis. Wer dafür kein Testfenster und keine Änderungsmitteilung vereinbart hat, erfährt es aus Beschwerden der Fachbereiche.

Ein Beispiel aus Finance: Ein Assistent erstellt Abweichungsanalysen, die in die Managementberichte einfließen. Hier genügt keine Verfügbarkeitszusage. Nötig sind nachvollziehbare Quellenangaben zu jeder Aussage, eine definierte monatliche Qualitätsprüfung, eine benannte interne Verantwortung und die vertragliche Zusage, dass Modelländerungen vorher angekündigt und in einer Testumgebung prüfbar sind.

Das Ergebnis? Sie kaufen keine Software, sondern eine Betriebsbeziehung – und gestalten sie entsprechend. Das verhindert die typische Enttäuschung im zweiten Jahr, in der ein System formal funktioniert, aber niemand mehr für seine Ergebnisse einsteht.

Zum LinkedIN Post

---