Build, Buy oder Automate: Die richtige KI-Lösung wählen

Mehr als die Hälfte der deutschen Unternehmen nutzt laut ifo-Konjunkturumfrage vom Mai 2026 inzwischen KI in ihren Geschäftsprozessen – 54,5 %. Interessant ist, wie sie das tun: Knapp drei Viertel der KI-nutzenden Unternehmen setzen auf kostenpflichtige externe Lösungen, 48,4 % nutzen kostenfreie Anwendungen, und nur 18,7 % entwickeln eigene KI-Systeme. Die Praxis hat die Grundsatzfrage also längst beantwortet: Kaufen ist der Normalfall, Bauen die Ausnahme. Trotzdem beobachte ich in Gesprächen mit kleinen und mittleren Unternehmen regelmäßig beide Extreme – die einen wollen sofort „etwas Eigenes mit KI” entwickeln lassen, die anderen abonnieren das dritte Tool für ein Problem, das eigentlich zwischen den vorhandenen Systemen liegt.

Dieser Artikel gehört zu unserem Themen-Cluster KI-Strategie und beantwortet die Entscheidungsfrage systematisch: Wann reicht Standardsoftware, wann ist Workflow-Automation die bessere Wahl, wann lohnt Eigenentwicklung – und wie triffst und dokumentierst du diese Entscheidung so, dass sie in zwei Jahren noch nachvollziehbar ist.

Das Problem: Die Tool-Frage kommt zu früh

Die Build-Buy-Automate-Entscheidung geht typischerweise auf zwei Arten schief, und beide haben dieselbe Ursache: Es wird über Lösungen gesprochen, bevor das Problem sauber beschrieben ist.

Variante 1: Zu früh gebaut. Jemand hat eine konkrete Vorstellung („wir brauchen ein eigenes KI-Tool für unsere Angebote”) und holt Angebote von Entwicklungsdienstleistern ein. Was fehlt: die Prüfung, ob ein existierendes Tool oder eine Automatisierung zwischen den vorhandenen Systemen dasselbe Ergebnis für einen Bruchteil des Aufwands liefert. Eigenentwicklung wirkt attraktiv, weil sie nach Kontrolle und Passgenauigkeit klingt – die dauerhafte Betriebslast (Wartung, Sicherheit, Weiterentwicklung, Personalabhängigkeit) taucht im ersten Angebot selten auf.

Variante 2: Zu früh gekauft. Ein Tool-Abo ist schnell abgeschlossen, und nach zwei Jahren stellt sich heraus: Es gibt fünf Abos, drei davon überlappen sich, keines ist in die Kernprozesse integriert, und die Daten stecken in Silos. Das Statistische Bundesamt liefert dazu einen aufschlussreichen Befund: Von den Unternehmen, die keine KI einsetzen, nennen 45 % Inkompatibilität mit dem vorhandenen Bestand an Geräten, Software und Systemen als Grund und 44 % Schwierigkeiten mit Verfügbarkeit oder Qualität der Daten. Genau diese beiden Probleme entstehen – oder verschärfen sich –, wenn Tools ohne Integrationsplan angeschafft werden.

Der Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU – also an die Konstellation, in der diese Entscheidung meist ohne eigene Softwarearchitektin und ohne Einkaufsabteilung für IT getroffen wird. Zur Einordnung der Ausgangslage: 2025 nutzten laut Statistischem Bundesamt 23 % der kleinen Unternehmen (10–49 Beschäftigte) und 36 % der mittleren (50–249) KI-Technologien, gegenüber 57 % der Großunternehmen. Der Abstand liegt nicht an fehlenden Ideen, sondern an fehlender Kapazität für genau die Bewertungsarbeit, um die es hier geht – 72 % der Nicht-Nutzer nennen fehlendes Wissen als Hürde.

Build, Buy, Automate: Was ist was?

Die drei Optionen sind keine Produktkategorien, sondern Antworten auf die Frage „Wo entsteht die Lösung?”:

• Buy (Standardsoftware): Du kaufst oder abonnierst ein fertiges Produkt und passt deinen Prozess daran an. Beispiele: ein CRM mit KI-Funktionen, ein Transkriptionsdienst, ein KI-Assistent wie ChatGPT oder Claude im Team-Tarif. Die Lösung gehört dem Anbieter, du nutzt sie.
• Automate (Workflow-Automation): Du verbindest bestehende Systeme, sodass Daten und Aufgaben ohne manuelles Zutun fließen – mit Plattformen wie Make, n8n oder Zapier oder mit leichtgewichtigen Skripten. KI kommt dabei oft als einzelner Schritt in der Kette vor: eine eingehende Mail klassifizieren, ein Dokument zusammenfassen, Daten aus einem PDF extrahieren. Du baust wenig Neues, orchestrierst aber Vorhandenes.
• Build (Custom Development): Du lässt Software entwickeln, die es so nicht zu kaufen gibt – vom internen Tool mit KI-Anbindung bis zur eigenen Anwendung auf Basis von Sprachmodell-APIs. Die Lösung gehört dir, mit allen Rechten und allen Pflichten.

Zwei Abgrenzungen sind wichtig. Erstens: „Build” heißt heute fast nie, ein eigenes KI-Modell zu trainieren. Gemeint ist in der Regel Anwendungsentwicklung auf bestehenden Modellen – das ist um Größenordnungen günstiger, bleibt aber ein Softwareprojekt mit allem, was dazugehört. Zweitens: Die Grenzen sind fließend. Eine Automation mit zwanzig Schritten und eigener Logik ist faktisch ein kleines Build-Projekt; ein Standardtool mit umfangreicher Konfiguration und Schnittstellenanbindung ebenso. Entscheidend ist nicht das Etikett, sondern wer die Lösung langfristig versteht, betreibt und ändern kann.

Wann reicht Standardsoftware?

Kurz: fast immer dann, wenn dein Problem nicht besonders ist. Das klingt banal, ist aber der am häufigsten übersehene Punkt. Die meisten Prozesse in einem KMU – E-Mail-Bearbeitung, Terminplanung, Buchhaltungsvorbereitung, Standardtexte, Recherche, Übersetzung, Meeting-Zusammenfassungen – sind branchenübergreifend nahezu identisch. Für identische Probleme gibt es ausgereifte Produkte, an denen sich ganze Anbieter-Teams abarbeiten. Dagegen anzubauen ist ökonomisch sinnlos.

Standardsoftware ist die richtige Wahl, wenn alle vier Bedingungen erfüllt sind:

1. Der Anwendungsfall ist branchenüblich. Andere Unternehmen haben exakt dasselbe Problem – ein starkes Signal, dass es reife Tools gibt.
2. Ein etabliertes Tool deckt den Kern ab. Nicht jede Randanforderung – den Kern. Die Frage ist nicht „kann das Tool alles, was wir uns wünschen?”, sondern „deckt es das ab, weswegen wir suchen?”.
3. Du kannst deinen Prozess anpassen, ohne etwas aufzugeben. Wenn dein Ablauf nur Gewohnheit ist, passe ihn dem Tool an. Wenn er ein echter Wettbewerbsvorteil ist, ist das ein Argument gegen Buy.
4. Datenschutz und Datenhoheit sind geklärt. Auftragsverarbeitung, Speicherort, und vor allem: Bekommst du deine Daten in einem nutzbaren Format wieder heraus? Ohne Exportweg kein Abschluss – das ist meine feste Regel.

Der häufigste Buy-Fehler ist nicht das falsche Tool, sondern das isolierte Tool: gekauft für ein Team, nie in die umliegenden Prozesse integriert, nach einem Jahr ein weiterer Posten auf der Kreditkartenabrechnung. Deshalb gehört zu jeder Buy-Entscheidung die Frage: Wie kommen Daten hinein und wieder heraus, und wer nutzt das Ergebnis weiter?

Wann ist Workflow-Automation besser?

Automation ist die richtige Antwort, wenn deine Einzelsysteme in Ordnung sind, aber die Arbeit zwischen ihnen liegt. Typische Signale:

• Jemand überträgt regelmäßig Daten von System A nach System B (Bestellungen ins ERP, Leads ins CRM, Rechnungsdaten in die Buchhaltung).
• Eingehende Anfragen werden manuell gesichtet, kategorisiert und weitergeleitet.
• Berichte entstehen durch Zusammenkopieren aus mehreren Quellen.
• Dokumente werden gelesen, um wenige Kerninformationen zu extrahieren.

Das sind Übergabeprobleme, keine Werkzeugprobleme – und ein neues Tool löst sie nicht, es fügt nur eine weitere Insel hinzu. Genau hier hat KI die Automation in den letzten Jahren deutlich stärker gemacht: Früher scheiterten Automatisierungen an unstrukturierten Inhalten (Freitext-Mails, PDFs, Gesprächsnotizen), heute übernimmt ein Sprachmodell-Schritt das Klassifizieren, Extrahieren und Zusammenfassen, und der Rest der Kette bleibt klassische, deterministische Automation.

Automation hat gegenüber Build zwei strukturelle Vorteile: Sie ist in Tagen bis wenigen Wochen umsetzbar statt in Monaten, und sie ist reversibel – ein Workflow lässt sich abschalten oder umbauen, ohne dass eine Investition abgeschrieben werden muss. Gegenüber Buy hat sie den Vorteil, dass sie vorhandene Systeme aufwertet, statt ein neues zu ergänzen.

Ehrliche Grenze: Automation erbt die Qualität der Systeme, die sie verbindet. Wenn die Stammdaten schlecht gepflegt sind oder ein System keine brauchbare Schnittstelle hat, automatisierst du Chaos – nur schneller. Und ein KI-Schritt in einer Automation braucht immer eine Antwort auf die Frage, was bei unsicheren Ergebnissen passiert: Bei allem, was Außenwirkung hat oder Geld bewegt, gehört eine menschliche Freigabe in die Kette.

Wann lohnt Custom Development?

Eigenentwicklung ist die Option mit dem größten Potenzial und dem größten Risiko – und sie ist selten die richtige erste Antwort. Zur Erinnerung: Nur 18,7 % der KI-nutzenden Unternehmen in Deutschland entwickeln laut ifo eigene KI-Systeme, und darunter sind überproportional Großunternehmen mit eigenen IT-Teams.

Build lohnt sich, wenn alle vier Bedingungen zusammenkommen:

1. Der Prozess differenziert dich. Er ist ein Grund, warum Kunden bei dir kaufen – nicht bloß Verwaltung. Differenzierende Prozesse an ein Standardtool anzupassen hieße, den Vorteil einzuebnen.
2. Kein Standardtool bildet ihn ab. Und zwar nach ernsthafter Recherche, nicht nach einer halben Stunde Googeln. Die Tool-Landschaft ändert sich schnell; was 2024 eine Lücke war, ist heute oft ein Produkt.
3. Die Anforderung ist stabil. Eigenentwicklung amortisiert sich über Jahre. Wenn sich der Prozess selbst noch monatlich ändert, baust du auf Sand – dann erst mit Automation stabilisieren, später bauen.
4. Der Betrieb ist gesichert. Software ist nie fertig. Sicherheitsupdates, API-Änderungen der KI-Anbieter, neue Anforderungen: Jemand muss dauerhaft zuständig sein – intern oder über einen Partner mit Wartungsvereinbarung. Das ist die Bedingung, an der Build-Vorhaben in KMU am häufigsten scheitern sollten, bevor sie starten.

Aus meiner eigenen Praxis als Entwickler und Berater: Der sinnvollste Einstieg in Build ist fast nie „die große Lösung”, sondern ein kleines internes Werkzeug, das aus einer bewährten Automation herauswächst – wenn die Automationsplattform an ihre Grenzen kommt, die Logik aber längst im Alltag validiert ist. Dann baust du etwas, dessen Nutzen bewiesen ist, statt etwas, dessen Nutzen du hoffst.

Die Entscheidungsmatrix: Build, Buy oder Automate

Die folgende Matrix ist mein Arbeitsmodell aus Beratungsprojekten. Sie ersetzt keine Einzelfallprüfung, sortiert aber in wenigen Minuten, in welche Richtung ein Anwendungsfall tendiert. Bewerte deinen Use Case entlang der sieben Kriterien und zähle, in welcher Spalte die meisten Treffer landen.

Kriterium	Buy (Standardsoftware)	Automate (Workflow-Automation)	Build (Eigenentwicklung)
Art des Problems	Ein Werkzeug fehlt	Übergänge zwischen Systemen kosten Zeit	Kern des Geschäftsmodells wird abgebildet
Verbreitung des Problems	Branchenüblich, viele Anbieter	Üblich, aber in deiner System-Kombination	Spezifisch für dein Unternehmen
Differenzierung	Prozess ist austauschbar	Prozess ist Standard, Tempo zählt	Prozess ist Wettbewerbsvorteil
Stabilität der Anforderung	Egal – Anbieter entwickelt weiter	Mittel – Workflows sind schnell änderbar	Hoch – muss Jahre tragen
Zeit bis zum Nutzen	Tage	Tage bis wenige Wochen	Monate
Reversibilität	Mittel (Kündigung + Datenexport)	Hoch (abschalten, umbauen)	Niedrig (Investition gebunden)
Betriebslast bei dir	Niedrig (Anbieter betreibt)	Mittel (Workflows überwachen, pflegen)	Hoch (Wartung, Sicherheit, Weiterentwicklung)

Eigenes Modell Philogic Labs. Lesehilfe: Bei gemischtem Bild gilt die Reihenfolge der geringsten Bindung – erst Buy oder Automate prüfen, Build nur bei klarem Übergewicht in der rechten Spalte.

Zwei Muster aus der Praxis, die die Matrix sichtbar macht: Wer bei „Differenzierung” und „Verbreitung” links landet, aber trotzdem bauen will, hat meist ein Kontrollbedürfnis, kein Build-Problem. Und wer überall in der Mitte landet, hat den häufigsten KMU-Fall – die Lösung ist eine Automation zwischen vorhandenen Systemen, kein neues Produkt.

Welche Lock-in-Kosten zählen?

Lock-in wird meist auf Lizenzkosten verengt. Die eigentlichen Bindungskosten liegen woanders, und sie betreffen alle drei Optionen – auch Build:

• Daten-Lock-in: Bekommst du deine Daten vollständig, strukturiert und in einem offenen Format wieder heraus? Prüfe das vor Vertragsschluss praktisch, nicht anhand der Marketingseite. Ein Tool ohne brauchbaren Export verhandelt bei der Kündigung aus einer Position der Stärke.
• Prozess-Lock-in: Nach zwei Jahren hat sich dein Ablauf dem Tool angepasst – Formulare, Begriffe, Gewohnheiten. Ein Wechsel kostet dann nicht nur Migration, sondern Umlernen im ganzen Team.
• Integrations-Lock-in: Jede Schnittstelle, die du auf einen Anbieter zuschneidest, verteuert den Wechsel. Deshalb: Integrationen wo möglich über offene Standards und über eine Automationsschicht führen, die du kontrollierst – dann tauschst du bei einem Wechsel ein Modul, nicht das Nervensystem.
• Wissens-Lock-in: Wenn das Prozesswissen nur noch in der Tool-Konfiguration steckt (oder im Kopf der einen Person, die die Automation gebaut hat), bist du gebunden, egal was im Vertrag steht. Dokumentation ist die günstigste Lock-in-Versicherung.
• Modell-Lock-in (KI-spezifisch): Wer auf Sprachmodell-APIs baut, sollte Prompts und Logik so kapseln, dass der Modellanbieter wechselbar bleibt. Die Modelllandschaft ändert sich schneller als jede andere Ebene des Stacks.

Und die unbequeme Wahrheit zu Build: Eigenentwicklung beseitigt den Lock-in nicht, sie verlagert ihn. Statt an einen Anbieter bist du an deine eigene Wartungsfähigkeit gebunden – und an die Verfügbarkeit der Menschen, die den Code verstehen. Das kann die richtige Wahl sein; es ist nur kein Gratisvorteil.

Wie dokumentierst du die Entscheidung?

Der am meisten unterschätzte Teil. Nicht, weil Dokumentation an sich Wert schafft, sondern weil eine undokumentierte Entscheidung in zwei Jahren nicht überprüfbar ist – dann weiß niemand mehr, warum das Tool angeschafft oder die Entwicklung beauftragt wurde, und jede Diskussion beginnt bei null.

Es reicht ein einseitiges Entscheidungsdokument (in der Softwarewelt „Architecture Decision Record” genannt, das Prinzip funktioniert für jede Tool-Entscheidung):

1. Problem: Welcher Prozess, welcher Schmerz, welche Messgröße (Zeit, Fehlerquote, Durchlaufzeit)?
2. Geprüfte Optionen: Mindestens eine je Spalte – welches Tool, welche Automation, welche Build-Variante wurden betrachtet?
3. Kriterien und Bewertung: Die Matrix-Zeilen von oben plus deine unternehmensspezifischen Punkte (Datenschutz, Budgetrahmen, vorhandene Systeme).
4. Entscheidung mit Begründung: Ein Absatz. Welche Option, warum, und warum nicht die anderen.
5. Akzeptierte Nachteile: Der wichtigste Abschnitt. Jede Option hat Nachteile – sie aufzuschreiben zwingt zur Ehrlichkeit und verhindert spätere „das hat uns niemand gesagt”-Debatten.
6. Überprüfungsdatum: Ein konkreter Termin (typisch: 12 Monate), an dem geprüft wird, ob die Annahmen noch stimmen. Tool-Markt und Modellfähigkeiten ändern sich schnell; eine 2024 richtige Build-Entscheidung kann 2026 falsch geworden sein – und umgekehrt.

Dieses Dokument kostet ein bis zwei Stunden und ist bei jeder späteren Diskussion – neuer Geschäftsführer, Budgetrunde, Anbieterwechsel – mehr wert als jede Erinnerung an „das haben wir damals so besprochen”.

Risiken und Grenzen

Ein paar ehrliche Einschränkungen zu diesem Modell:

• Die Kategorien mischen sich in der Realität. Die meisten tragfähigen KMU-Lösungen sind Kombinationen: Standardtools als Basis, Automation als Bindegewebe, punktuell ein kleines eigenes Werkzeug. Die Matrix entscheidet pro Anwendungsfall, nicht pro Unternehmen.
• Kostenvergleiche sind annahmegetrieben. Seriöse Zahlen entstehen erst, wenn dein konkreter Fall durchgerechnet ist – mit Lizenzkosten über die erwartete Nutzungsdauer, internem Aufwand für Einführung und Pflege und bei Build den vollen Betriebskosten. Pauschale Aussagen wie „Eigenentwicklung amortisiert sich nach X Monaten” sind ohne diese Annahmen wertlos; als grobe Orientierung aus meinen Projekten gilt nur die Reihenfolge: Automation ist meist die günstigste Einstiegsoption, Buy kalkulierbar, Build die mit Abstand größte und langfristigste Verpflichtung.
• Rechtliche Prüfung ersetzt das Modell nicht. Sobald personenbezogene Daten oder Entscheidungen über Menschen im Spiel sind, gehören Datenschutz und die Pflichten aus der KI-Verordnung in die Bewertung (Stand Juli 2026; dieser Artikel ist keine Rechtsberatung – für Details verweise ich auf die offiziellen Quellen und im Zweifel auf anwaltliche Beratung).
• Die Datenlage ist die stille Voraussetzung. 44 % der Unternehmen ohne KI-Einsatz nennen laut Statistischem Bundesamt Daten-Verfügbarkeit oder -Qualität als Hürde. Keine der drei Optionen repariert schlechte Daten – Buy kaschiert das Problem, Automate beschleunigt es, Build macht es teuer sichtbar.

Wenn du unsicher bist, wo dein Fall steht: Genau diese Bewertung – Prozesse sichten, Optionen prüfen, Empfehlung mit Begründung – ist der Kern unserer KI-Beratung. Wenn dein Team die Entscheidungskompetenz selbst aufbauen soll, ist eine Schulung der nachhaltigere Weg.

Checkliste: Bevor du dich entscheidest

• Das Problem ist als Prozess beschrieben (Auslöser, Schritte, Ergebnis, Messgröße) – nicht als Tool-Wunsch.
• Du hast geprüft, ob das Problem im Werkzeug, in den Übergängen oder im Kerngeschäft liegt.
• Mindestens eine Option pro Spalte (Buy/Automate/Build) wurde ernsthaft betrachtet.
• Für Buy: Datenexport praktisch getestet, Auftragsverarbeitung und Speicherort geklärt.
• Für Automate: Schnittstellen der beteiligten Systeme geprüft, Umgang mit unsicheren KI-Ergebnissen definiert (Freigabeschritt).
• Für Build: Betrieb und Wartung sind für die nächsten Jahre benannt – mit Namen, nicht mit Hoffnung.
• Lock-in-Prüfung über alle fünf Ebenen: Daten, Prozess, Integrationen, Wissen, Modell.
• Kosten als Bandbreite über die erwartete Nutzungsdauer gerechnet, inklusive internem Aufwand – nicht nur Lizenz oder Angebotssumme.
• Einseitiges Entscheidungsdokument geschrieben, akzeptierte Nachteile ausdrücklich benannt.
• Überprüfungstermin in 12 Monaten eingetragen.

Wenn du diese Liste durchgehst und an mehr als zwei Punkten hängst, ist das kein Scheitern – es ist der Hinweis, dass die Entscheidung noch nicht reif ist. Lieber eine Woche länger prüfen als zwei Jahre am falschen Ansatz tragen. Und wenn du eine zweite Meinung zu deinem konkreten Fall willst: Melde dich – die erste Einschätzung ist unverbindlich.