--- title: "Make or Buy bei KI-Lösungen: Eine Entscheidungshilfe für den Mittelstand" lang: de type: blog canonical: https://www.arocom.de/blog/make-or-buy-ki-loesungen alternate: https://www.arocom.de/en/blog/make-or-buy-ai author: "Axel Roth" published: 2026-04-28 last_updated: 2026-10-31 --- # Make or Buy bei KI-Lösungen: Eine Entscheidungshilfe für den Mittelstand Ob ein Unternehmen KI-Funktionen als fertiges Produkt kauft oder individuell bauen lässt, entscheiden vier Kriterien: Differenziert die Funktion das Unternehmen im Wettbewerb, wie sensibel sind die Daten, wie tief muss die Integration in bestehende Systeme reichen, und wie lange soll die Lösung leben. Kaufen gewinnt bei Standardaufgaben, Bauen bei differenzierenden Kernprozessen. In der Praxis am erfolgreichsten sind Mischformen: Standardmodelle mieten, die Integrationsschicht auf offenen Standards selbst besitzen. Eine Beispielrechnung über drei Jahre und eine Fünf-Fragen-Checkliste machen die Entscheidung rechenbar. ## Make or Buy bei KI-Lösungen: Eine Entscheidungshilfe für den Mittelstand Die Frage erreicht uns inzwischen wöchentlich, in zwei Varianten. Variante eins: "Da gibt es doch fertige Tools, warum sollen wir etwas bauen lassen?" Variante zwei: "Wir wollen nicht abhängig sein, können Sie uns das nicht selbst bauen?" Beide Reflexe sind verständlich, und beide führen ohne Prüfung in teure Sackgassen. Die Frage ist bei KI folgenreicher als bei klassischer Software. Die Werkzeuge entwickeln sich schneller, die Preismodelle der Anbieter sind jung und beweglich, und durch die Lösung fließen oft genau die Daten, die euer Geschäft ausmachen. Eine Fehlentscheidung korrigiert sich hier nicht still im Budget, sie wächst mit. Vier Kriterien bringen Ordnung in die Entscheidung. ## Die vier Kriterien **1. Differenzierung.** Erledigt die KI-Funktion etwas, das eure Wettbewerber genauso brauchen (Protokolle zusammenfassen, E-Mails vorsortieren)? Dann kaufen. Bildet sie ab, was euch von Wettbewerbern unterscheidet (eure Beratungslogik, eure Kalkulation, euer Serviceprozess)? Dann gehört die Logik in eure Hand. Ein Beispiel: Ein technischer Großhändler, dessen Stärke die schnelle und verlässliche Angebotskalkulation ist, kauft die Protokoll-KI von der Stange und lässt die Kalkulationsassistenz individuell bauen. Genau umgekehrt wäre es teuer falsch. **2. Datenhoheit.** Je sensibler die Daten (Kundendaten, Kalkulationen, Gesundheitsdaten), desto stärker spricht es für eigene Infrastruktur oder zumindest europäische Anbieter mit klaren Verträgen. Ein Standard-SaaS mit US-Datenverarbeitung scheidet für manche Branchen schlicht aus. Ein Beispiel: Ein Zulieferer, der Kundenzeichnungen unter Geheimhaltung verwaltet, darf sie nicht in ein beliebiges Cloud-Tool laden. Hier entscheidet der NDA-Anhang über die Architektur, nicht das Featureset. **3. Integrationstiefe.** Ein Tool, das für sich allein arbeitet, kann man gefahrlos mieten. Eine Funktion, die tief in CRM, ERP oder CMS eingreifen soll, wird als Fremdprodukt zur Dauerbaustelle. Als Faustregel aus unseren Projekten: Ab der zweiten Systemschnittstelle lohnt der Blick auf eine eigene Integrationsschicht. Ein typisches Muster: Der Service-Chatbot von der Stange überzeugt in der Demo, und nach dem zweiten Release-Wechsel des Anbieters bricht die ERP-Anbindung, die im Haus niemand reparieren kann. **4. Lebensdauer.** Für ein Jahr Überbrückung mietet man. Für einen Prozess, der das Unternehmen zehn Jahre tragen soll, rechnet sich Eigenes schneller, als die Monatsraten suggerieren. Ein Beispiel: Bis zum geplanten ERP-Wechsel ein Dokumenten-Tool zu mieten ist vernünftig. Den Angebotsprozess, der das Geschäft die nächste Dekade trägt, auf ein kündbares Abo zu bauen, ist es nicht. ## Der ehrliche Kostenvergleich | | Kaufen (SaaS) | Bauen (individuell) | | --- | --- | --- | | Startkosten | niedrig (Abo, Onboarding) | hoch (Projekt) | | Laufende Kosten | wachsen mit Nutzern/Nutzung | Betrieb + Inferenz, weitgehend nutzerunabhängig | | Anpassbarkeit | begrenzt auf Roadmap des Anbieters | voll, aber jede Anpassung kostet | | Abhängigkeit | Preis-, Feature- und Exit-Risiko | Abhängigkeit vom Dienstleister (vertraglich lösbar) | | Time-to-Value | Tage bis Wochen | Wochen bis Monate | | Typischer Kipppunkt | ab ~20–50 Nutzern oder 2+ Integrationen neu rechnen | rechnet sich über 3+ Jahre Laufzeit | Der häufigste Rechenfehler steckt in der zweiten Zeile: SaaS-Preise gelten pro Nutzer und Monat und wachsen mit. Individuallösungen kosten vorn, skalieren dann aber fast kostenneutral. Bei KI kommt eine Besonderheit dazu: Die Inferenzkosten (was jede Anfrage an Modellkosten erzeugt) fallen in beiden Modellen an, sind beim SaaS-Anbieter aber im Preis versteckt und eingepreist. Was das in Zahlen heißt, zeigt eine vereinfachte Beispielrechnung über drei Jahre. Die Werte sind gerundete Illustration, keine Angebotskalkulation. Ein KI-Assistenz-SaaS für 25 Nutzer zu 40 Euro je Nutzer und Monat kostet 12.000 Euro pro Jahr, über drei Jahre 36.000 Euro, Preiserhöhungen und kostenpflichtige Zusatzmodule nicht eingerechnet. Eine individuelle Lösung mit vergleichbarem Funktionsumfang liegt beispielhaft bei 45.000 Euro für den Aufbau plus rund 6.000 Euro pro Jahr für Betrieb und Modellkosten, über drei Jahre also etwa 63.000 Euro. Nach dieser Rechnung liegt das SaaS vorn, und genau so weit tragen die Listenpreise. Die Rechnung kippt, sobald einer von drei Faktoren eintritt: Die Nutzerzahl wächst Richtung 50, der Anbieter hebt die Preise an, oder eine zweite Integration kommt dazu, die beim SaaS Beratungstage kostet. Ab da rechnet sich der Eigenbau Jahr für Jahr stärker. Deshalb gehört diese Rechnung mit euren eigenen Zahlen schriftlich in jede Entscheidungsvorlage. Zwei Posten fehlen in den Listenpreisen beider Spalten und gehören trotzdem in eure Rechnung: die Einführung (Schulung, Prozessanpassung, interne Tests) und die laufende Pflege von Prompts und Konfiguration. Beide fallen an, egal ob ihr kauft oder baut, und beide werden in Anbietergesprächen verlässlich kleingeredet. ## Was in der Praxis gewinnt: drei Mischformen Die reine Make-or-Buy-Frage ist 2026 oft falsch gestellt. In unseren Projekten setzen sich Mischformen durch. Ehrlicherweise hat jede davon eine Stelle, an der sie scheitern kann, deshalb nennen wir beides: 1. **Modell mieten, Integration besitzen.** Das Sprachmodell kommt per API von OpenAI, Anthropic oder einem europäischen Anbieter und bleibt austauschbar. Die Integrationsschicht (Anbindung an CMS, CRM, Wissensbasis, idealerweise über offene Standards wie [MCP](https://www.arocom.de/wissen/ki/mcp)) gehört euch. Diese Form scheitert dort, wo die Integrationsschicht ohne Dokumentation und Tests entsteht und damit doch wieder an einer einzelnen Person oder Agentur hängt. 2. **Standard-Tools für Standardaufgaben, eigene Lösung für den Kernprozess.** Office-Copiloten für E-Mails und Protokolle kauft man. Den KI-gestützten Angebotsprozess, der euer Geschäft trägt, baut man. Scheitern sehen wir dieses Modell dort, wo niemand die Grenze pflegt: Standard-Tools wachsen schleichend in den Kernprozess hinein, bis ein kündbares Abo plötzlich geschäftskritisch ist. 3. **Kaufen mit Exit-Plan.** Wo SaaS gewinnt, gehören Datenexport und Kündigungsszenario in den Vertrag, bevor man unterschreibt. Das scheitert, wenn der Exit nur auf dem Papier existiert. Ein Datenexport, den nie jemand probeweise eingespielt hat, ist keiner. ## Fünf Fragen vor dem ersten Anbietergespräch Beantwortet diese fünf Fragen schriftlich, bevor ihr mit Anbietern oder Dienstleistern sprecht. Schriftlich deshalb, weil mündliche Antworten im Verkaufsgespräch erstaunlich beweglich werden: 1. Welche Aufgabe soll die Lösung übernehmen, und woran messen wir nach zwölf Monaten, ob sie es tut? 2. Differenziert diese Aufgabe uns im Wettbewerb, oder erledigen Wettbewerber sie genauso? 3. Welche Daten fließen hinein, wie sensibel sind sie, und wo dürfen sie verarbeitet werden? 4. Mit wie vielen bestehenden Systemen muss die Lösung sprechen, heute und in drei Jahren? 5. Was passiert beim Ausstieg nach zwei Jahren: Wem gehören dann Daten, Prompts und Integrationscode? Unser Rat als erster Schritt: Nehmt eure wichtigste geplante KI-Funktion und beantwortet die fünf Fragen noch diese Woche. Das Ergebnis trägt die Make-or-Buy-Entscheidung meist von allein. Wenn ihr dabei eine zweite Meinung wollt, ist genau das ein Fall für den [Zukunfts-Check](https://www.arocom.de/zukunfts-check). ### Können wir später von Buy zu Make wechseln? Ja, und genau dafür gibt es den Exit-Plan. Realistisch wird der Wechsel, wenn ihr von Anfang an drei Dinge sichert: regelmäßige Datenexporte in einem offenen Format, dokumentierte Prozesse (was tut das Tool fachlich genau) und keine Exklusivklauseln im Vertrag. Die häufigsten Wechselgründe, die uns in Gesprächen begegnen, sind Preiserhöhungen und Stillstand auf der Anbieter-Roadmap. Wer den Wechsel vertraglich vorbereitet hat, verhandelt dann aus einer anderen Position. ### Wie vermeiden wir Dienstleister-Lock-in beim Bauen? Vertraglich und technisch. Vertraglich gehören Quellcode, Dokumentation und Infrastrukturzugänge euch, und zwar bevor gebaut wird, nicht als nachträgliche Verhandlungsmasse. Technisch helfen offene Standards (etwa MCP für KI-Integrationen), verbreitete Frameworks statt Eigenbau-Exoten und eine Dokumentation, mit der ein zweites Team weiterarbeiten könnte. Die Testfrage an euren Dienstleister lautet: "Was bräuchte ein anderes Team, um das zu übernehmen?" Die Antwort sagt mehr als jede Referenzliste. ### Was, wenn der Anbieter morgen das Doppelte verlangt? Beim SaaS ist das ein reales Szenario, vor allem wenn KI-Funktionen nachträglich bepreist werden. Schützen könnt ihr euch vertraglich mit Preisbindung über die Laufzeit und praktisch mit einem Exit-Plan, der aktuell gehalten und einmal geprobt wird, denn die beste Verhandlungsposition ist glaubwürdige Wechselfähigkeit. Bei einer eigenen Lösung trifft das Preisrisiko nur die Modellkosten, und Modelle sind über eine saubere Provider-Abstraktion austauschbar.