Drei statt zwei Optionen

„Make or Buy“ klingt nach Eigenentwicklung oder fertigem Produkt. In der Praxis gibt es eine dritte, häufig besonders sinnvolle Variante:

  1. Buy: Standardprodukt verwenden.
  2. Integrate: vorhandene Dienste verbinden und gezielt konfigurieren.
  3. Build: eine eigene Anwendung oder Kernkomponente entwickeln.

Für KMU ist „Integrate“ oft der wirtschaftliche Mittelweg.

Wann ein Standardprodukt gewinnt

Kaufen ist sinnvoll, wenn der Prozess:

  • in vielen Unternehmen ähnlich ist,
  • durch etablierte Anbieter gut gelöst wird,
  • keine besondere Differenzierung erzeugt,
  • nur wenige individuelle Integrationen braucht.

Beispiele:

  • Videokonferenzen,
  • Standard-CRM,
  • Newsletterversand,
  • Buchhaltung,
  • allgemeine Textassistenz.

Der Vorteil liegt nicht nur in schneller Einführung. Gute Produkte bringen Sicherheitsfunktionen, Support, Skalierung und laufende Entwicklung mit.

Wann Integration besser ist

Eine betreute Integration kombiniert Standarddienste:

  • E-Mail-System,
  • Automationsplattform,
  • CRM,
  • KI-API,
  • eigene Validierungslogik,
  • kleine Freigabeoberfläche.

Diese Variante passt, wenn der Ablauf individuell ist, aber nicht jede technische Funktion neu gebaut werden muss.

Wann Eigenbau gerechtfertigt ist

Eine eigene Lösung kann sich lohnen, wenn:

  • der Prozess Wettbewerbsvorteil oder Kernwissen enthält,
  • bestehende Produkte viele manuelle Umwege erzwingen,
  • Daten und Benutzeroberfläche exakt kontrolliert werden müssen,
  • mehrere Systeme tief verbunden werden,
  • Volumen Standardlizenzen unwirtschaftlich macht,
  • langfristige Erweiterungen geplant sind.

Eigenbau bedeutet nicht, jedes Modell selbst zu trainieren. Meist werden bewährte Cloud-, Datenbank- und Modellkomponenten in einer eigenen Anwendung verwendet.

Acht Entscheidungsfragen

1. Wie einzigartig ist der Prozess?

Je allgemeiner, desto stärker spricht das für Standardsoftware.

2. Wie wichtig ist die Differenzierung?

Ein eigener Angebots- oder Serviceprozess kann strategisch sein. Interne Terminabstimmung meist nicht.

3. Welche Daten werden verarbeitet?

Die österreichische Datenschutzbehörde betont, dass bei fremden KI-Systemen geprüft werden muss, ob personenbezogene Daten an Anbieter oder andere Dritte übermittelt werden. 3

4. Welche Integrationen sind nötig?

Nicht die Zahl der Logos im App-Verzeichnis zählt, sondern ob der konkrete Konnektor Rechte, Felder und Fehlerfälle abdeckt.

5. Wie schnell ändert sich der Prozess?

Häufige Änderungen brauchen eine verständliche, testbare Architektur.

6. Was kostet der Betrieb?

Vergleichen Sie Lizenzen, API-Nutzung, Support, interne Administration und Weiterentwicklung über mehrere Jahre.

7. Wie sieht der Exit aus?

Sind Daten, Regeln, Prompts und Protokolle exportierbar? Kann ein anderer Partner übernehmen?

8. Wer trägt Verantwortung?

Bei einem Standardprodukt bleibt Prozessverantwortung trotzdem beim Unternehmen. Beim Eigenbau muss zusätzlich technische Betriebsverantwortung klar sein.

Vendor Lock-in nüchtern betrachten

Vollständige Unabhängigkeit ist unrealistisch. Auch eigene Software nutzt Betriebssysteme, Bibliotheken, Cloud-Dienste und Modelle.

Lock-in wird beherrschbar durch:

  • offene Datenformate,
  • dokumentierte Schnittstellen,
  • getrennte Geschäftslogik,
  • austauschbare Modellanbindung,
  • versionierten Quellcode,
  • vertragliche Datenexporte,
  • getesteten Rückfallweg.

MCP kann Werkzeugintegrationen standardisieren, ersetzt aber keine Sicherheitsarchitektur. Die offizielle Sicherheitsdokumentation warnt unter anderem vor Token-Weitergabe und empfiehlt klare Autorisierungsgrenzen. 4

Warum „selbst bauen ist jetzt gratis“ falsch ist

KI-gestützte Entwicklung kann Code schneller erzeugen. Eine NBER-Studie aus 2026 zeigt jedoch, dass starke Aktivitätszuwächse nur teilweise in Projekte, Releases und Nutzung übersetzt wurden. 2

Weiterhin notwendig sind:

  • Anforderungen,
  • Datenmodell,
  • Benutzererfahrung,
  • Tests,
  • Sicherheit,
  • Einführung,
  • Monitoring,
  • Wartung.

Der Eigenbau wird zugänglicher, nicht verantwortungsfrei.

KMU brauchen passende Voraussetzungen

Die OECD beschreibt eine anhaltende Lücke zwischen KI-Adoption in KMU und großen Unternehmen und nennt unter anderem digitale Reife, Daten, Kompetenzen und Finanzierung als Voraussetzungen. 1

Ein Projekt sollte deshalb nicht nur die gewünschte Funktion bewerten. Es muss fragen, ob Organisation und Daten bereit sind, die Lösung zu betreiben.

Eine einfache Bewertungsmethode

Gewichten Sie jede Option von 1 bis 5:

  • Funktionspassung,
  • Einführungszeit,
  • Datenschutz und Sicherheit,
  • Integrationsfähigkeit,
  • Änderbarkeit,
  • Nutzererfahrung,
  • Drei-Jahres-Kosten,
  • Exit-Fähigkeit,
  • interne Belastung.

Dokumentieren Sie Annahmen und Unsicherheit. Ein präziser Score ohne belastbare Eingangsdaten ist weniger wert als eine ehrliche qualitative Entscheidung.

Typische Empfehlung

Für viele KMU lautet sie:

  • Standardprodukt für allgemeine Funktionen,
  • betreute Integration für Prozessfluss,
  • individuelle Oberfläche oder Logik an den differenzierenden Stellen,
  • klare Betriebs- und Wartungsvereinbarung.

Nicht möglichst viel selbst bauen, sondern genau den Teil besitzen, der für den eigenen Prozess wichtig ist.

Fazit

Make or Buy bei KI ist keine ideologische Entscheidung. Standardprodukte sind bei allgemeinen Aufgaben stark. Individualsoftware lohnt sich bei geschäftsspezifischen Abläufen. Dazwischen liegt die häufig beste Lösung: eine professionell betreute Integration.

Die richtige Wahl berücksichtigt nicht nur den schnellen Start, sondern Daten, Lock-in, Vollkosten, Verantwortung und die nächsten Jahre des Betriebs.

Nachvollziehbar belegt

Quellen und weiterführende Dokumente

Geprüft am 28. Juli 2026
  1. 1
    OECDAI adoption by small and medium-sized enterprisesVeröffentlicht/aktualisiert: 2025
  2. 2
    NBERWriting Code vs. Shipping CodeVeröffentlicht/aktualisiert: 2026
  3. 3
    Österreichische DatenschutzbehördeKünstliche Intelligenz & DatenschutzVeröffentlicht/aktualisiert: 2026
  4. 4
    Model Context ProtocolModel Context Protocol – Security best practicesVeröffentlicht/aktualisiert: 2026

Bei Rechts- und Datenschutzthemen dient der Artikel der Orientierung und ersetzt keine individuelle rechtliche Beratung.