„Wir bauen unsere eigene KI.“ Dieser Satz fällt derzeit in vielen Führungskreisen, und in den meisten Fällen wird daraus nichts. Nicht weil die Idee falsch wäre, sondern weil die Entscheidung zwischen einer eigenen Lösung, einem eingekauften Produkt und bewusstem Abwarten selten sauber getroffen wird. Wer eine eigene KI bauen will, entscheidet nicht über ein Modell, sondern über ein Softwarevorhaben mit allem, was dazugehört: Anforderungen, Betrieb, Wartung, Weiterentwicklung.

Drei Wege, drei typische Fehler

Für jeden KI-Anwendungsfall im Unternehmen gibt es drei Optionen. Selbst bauen, einkaufen oder bewusst warten. Alle drei sind legitim, und jede hat ein charakteristisches Fehlermuster.

• Build ohne klares Problem. Sechs Monate Entwicklung für eine Lösung, die keiner braucht. Der Auslöser ist meist ein technisches Interesse, nicht ein Prozessbedarf.
• Buy ohne Anforderungen. Werkzeug beschafft, Lizenzen laufen, Nutzung nahe null. Ohne definierten Anwendungsfall gibt es keinen Grund, die Arbeitsweise zu ändern.
• Wait als Ausrede. „Wir beobachten den Markt“, seit drei Jahren. Abwarten ohne Termin und ohne Kriterium ist keine Entscheidung, sondern deren Vermeidung.

Nach mehreren Jahren KI-Projekten lässt sich die Verteilung grob so beschreiben: Der überwiegende Teil der Anwendungsfälle ist mit Standardwerkzeugen besser abgedeckt. Wer ohne eigene Fachdomäne baut, baut an der Sache vorbei. Und wer wartet, sollte definieren, worauf.

Der Unterschied zwischen persönlichem Helfer und interner Lösung

Der häufigste Denkfehler entsteht aus einer richtigen Beobachtung. Es funktioniert tatsächlich sehr gut, sich selbst kleine Werkzeuge zu bauen. Ich mache das regelmäßig: Helfer, die Zeit sparen oder Dinge möglich machen, die vorher schlicht zu aufwendig waren. Das läuft, weil ich genau weiß, was ich will, wie ich arbeite und welche Sonderfälle mich nicht interessieren. Ich bin Auftraggeber, Entwickler, Tester und Nutzer in einer Person.

Sobald dieselbe Lösung an zwanzig Kollegen geht, ändert sich alles. Zwanzig Personen arbeiten unterschiedlich, haben unterschiedliche Vorstellungen und stoßen auf Fälle, die im eigenen Arbeitsalltag nie vorkamen. Es kommen Schnittstellen dazu, Rechte, Fehlerfälle, Datenschutzfragen. Aus einem privaten Helfer wird eine Anwendung mit Nutzerkreis, und damit gilt jede Regel, die für Software gilt.

Dazu kommt der Punkt, der in der Begeisterung am häufigsten übersehen wird: Man baut das nicht einmal und dann läuft es kostenlos für immer. Modelle ändern sich, Schnittstellen ändern sich, Anbieter stellen Dienste um oder ab, Anforderungen wachsen. Es muss nachgebessert, angepasst und umgebaut werden, und je größer die Lösung wird, desto aufwendiger wird das. Dass laufende Pflege kein Sonderfall ist, sondern der Normalzustand jeder produktiven Anwendung, zeigt sich auch bei Software am Lebensende.

Warum „KI ersetzt bald jedes SaaS-Tool“ nicht aufgeht

Aus der Leichtigkeit, mit der Prototypen entstehen, wird derzeit eine große Prognose abgeleitet: Standardsoftware wird überflüssig, weil sich jedes Unternehmen seine Werkzeuge selbst baut. Diese Prognose unterschätzt konsequent den Unterschied zwischen einer funktionierenden Demo und einem betriebsfähigen System. Der Weg vom Prototyp zum Produkt ist der Teil, der den Aufwand verursacht, und daran hat sich weniger geändert als es aussieht. Diese Lücke ist ausführlich in KI-Produktivität: Prototyp ist kein Produkt beschrieben.

Realistisch ist eine andere Verschiebung. KI senkt die Einstiegskosten für individuelle Lösungen deutlich. Damit rechnen sich eigene Anwendungen für Prozesse, bei denen das vorher nicht der Fall war, und die Grenze zwischen Standard und Individuallösung verschiebt sich. Wo diese Grenze grundsätzlich liegt, behandelt Standard oder Individualsoftware. Für breit gelöste Standardaufgaben wie Buchhaltung, Lohnabrechnung oder klassisches CRM bleibt Einkaufen die richtige Antwort.

Fünf Fragen vor der Entscheidung

Diese Fragen klären in der Praxis die Richtung, bevor Aufwand entsteht:

• Ist der betroffene Prozess Standard oder ist er Teil des eigenen Wettbewerbsvorteils? Standardprozesse einkaufen, Differenzierung selbst bauen.
• Liegt die Fachdomäne im eigenen Haus, und ist jemand aus dem Fachbereich verbindlich für Anforderungen und Abnahme verantwortlich?
• Wer betreibt und pflegt die Lösung in zwei Jahren, mit welchem Budget und mit welcher Vertretung, wenn die aufbauende Person nicht mehr verfügbar ist?
• Wie viele Nutzer, welche Systeme, welche Daten? Ein Nutzer ohne Schnittstellen ist ein Werkzeug, zwanzig Nutzer mit ERP-Anbindung sind ein Projekt.
• Bei Wait: Woran genau wird erkannt, dass der Zeitpunkt gekommen ist, und wann wird spätestens erneut entschieden?

Bleibt nach diesen Fragen Build übrig, ist das eine gute Ausgangslage. Bleibt Buy übrig, ist das kein Rückschritt, sondern eine gesparte Fehlinvestition. Warum Unternehmen die Eigenentwicklung trotzdem so häufig überschätzen, ist Thema von Wir entwickeln das lieber selbst.

Klein und nützlich schlägt groß und unfertig

Wenn die Entscheidung für eine eigene Lösung fällt, gilt der zweite wichtige Punkt: Sie muss nicht spektakulär sein. Im Moment dreht sich viel um komplexe Automatisierungen über mehrere Systeme, und parallel wird ein optimierter Prompt ebenfalls als Agent bezeichnet. Beides ist in Ordnung, solange die Frage beantwortet wird, ob am Ende wirklich Arbeit weniger wird.

Kleine Helfer, die jeden Tag zehn oder fünfzehn Minuten einsparen, sind in der Summe wertvoller als die perfekte Automatisierung, die nie fertig wird. Manchmal genügt es, wenn Informationen schneller zusammengefasst werden, ein erster Entwurf entsteht oder Daten aus verschiedenen Quellen so aufbereitet werden, dass eine bisher zu aufwendige Aufgabe überhaupt machbar wird. Solche Lösungen sind schnell im Einsatz, ihr Nutzen ist messbar, und sie schaffen die Erfahrung, die für größere Vorhaben nötig ist.

Fazit

Eine eigene KI bauen ist kein Modellthema, sondern eine Make-or-Buy-Entscheidung mit den bekannten Konsequenzen für Wartung, Betrieb und Verantwortung. Standardprozesse werden eingekauft, Differenzierung wird selbst gebaut, und Abwarten braucht ein Datum und ein Kriterium. Wer sich für den eigenen Weg entscheidet, startet besser mit einem kleinen Helfer, der täglich Zeit spart, als mit der großen Lösung, deren Nutzen erst nach Monaten überprüfbar wäre.