„Das bauen wir jetzt einfach selbst.“

Einzelne Funktionen entstehen mit KI-Unterstützung in erstaunlichem Tempo. Ein Formular, das Daten ins CRM schreibt. Ein Dashboard, das Kampagnenwerte zusammenzieht. Ein Freigabe-Workflow für die Redaktion. Vordergründig ist klar, was gebraucht wird, und nach ein paar Prompts läuft eine erste Version.

Was dabei leicht untergeht: Die Tools, die man damit ersetzen will, sind oft über viele Jahre entstanden. Viele Entwicklerinnen und Entwickler haben mit Sachkunde und Herzblut daran gearbeitet, Fehler aus Tausenden Installationen behoben und Randfälle abgedeckt, an die beim ersten Entwurf niemand denkt. Im Enterprise-Umfeld sind sie zudem zertifiziert – nach ISO 27001, SOC 2 oder vergleichbaren Standards, mit regelmäßigen Audits und dokumentierten Prozessen.

Ein solches Produkt mit einer Handvoll Prompts ersetzen zu wollen, ist ehrlich gesagt ein wenig vermessen. Das liegt nicht an der Qualität des generierten Codes. Das Sichtbare an einer Software ist nur ein kleiner Teil dessen, was sie ausmacht.

Wer „schnell selbst baut”, beschreibt fast immer, was das Tool tun soll. Das sind die funktionalen Anforderungen, und die lassen sich vergleichsweise leicht formulieren.

Schwieriger sind die nicht-funktionalen: wie sicher, wie verfügbar, wie schnell, wie wartbar ein System ist. Im ersten Prototyp fallen sie nicht auf, weil er auch ohne sie funktioniert. Im Betrieb entscheiden sie darüber, ob ein Tool trägt. Typische Fragen:

• Wer darf was sehen und ändern – und wo wird das protokolliert?
• Wo liegen die Daten, und ist das mit der DSGVO vereinbar?
• Was passiert bei einem Ausfall? Gibt es Backups, und wurde die Wiederherstellung je getestet?
• Ist die Oberfläche barrierefrei, sofern das Barrierefreiheitsstärkungsgesetz greift?
• Wie verhält sich das Tool, wenn statt fünf plötzlich fünfhundert Personen damit arbeiten?
• Versteht in zwei Jahren noch jemand, wie es aufgebaut ist?

Bei einem gekauften Produkt hat der Hersteller diese Fragen – mal besser, mal schlechter – bereits beantwortet. Beim Eigenbau beantworten Sie sie selbst. Oder niemand tut es.

Software ist nie fertig. Sobald ein Tool im Einsatz ist, braucht es jemanden, der dafür sorgt, dass es funktioniert und funktionsfähig bleibt. Sicherheitsupdates und Patches müssen eingespielt, verwendete Bibliotheken aktuell gehalten werden – oft genau die Bibliotheken, die eine KI beim Bau ausgewählt hat, ohne dass jemand sie bewusst geprüft hätte. Anwenderinnen und Anwender brauchen Einführung und Schulung. Probleme müssen aufgenommen, analysiert und im Code behoben werden. Und aus der Nutzung entstehen neue Anforderungen, die wiederum umgesetzt werden wollen.

Bei einem gekauften Produkt steckt diese Arbeit im Preis. Beim Eigenbau liegt sie bei Ihnen. Das ist nicht per se schlecht – aber es sollte eine bewusste Entscheidung sein und keine Überraschung nach drei Monaten.

Besonders heikel wird es, wenn ein Tool außerhalb der IT entsteht. Baut das Marketing mit KI-Unterstützung ein Werkzeug, das schnell unverzichtbar wird, von dem die IT aber nichts weiß, entsteht eine neue Form der Schatten-IT: produktiv, geschäftskritisch und ohne Verantwortlichen.

Die Diskussion wird oft als „kaufen oder selbst bauen” geführt. Dabei gibt es einen dritten Weg, der häufig übersehen wird: eine bestehende Open-Source-Software als Basis nutzen und gezielt anpassen.

Keiner dieser Wege ist grundsätzlich besser. Entscheidend ist eine Frage, die im Kern eine Ressourcenfrage ist: Setzen Sie Ihre Entwicklungskapazität für das richtige Produkt ein? Oder holen Sie sich Entwicklungs- und Wartungsaufwände ins Haus, die ein bestehendes Produkt längst gelöst hat?

Beim Schreiben dieses Textes kam immer wieder dieselbe Frage auf: Welchen Wert hat das Stück Software eigentlich, das hier entstehen soll? Drei Fragen helfen bei der Einordnung.

Wie viel Wert erzeugt das Tool? Ist es ein Hilfsmittel, das eine Aufgabe etwas bequemer macht – oder ein Werkzeug, das Umsatz erzeugt, Prozesse trägt oder Kunden direkt erreicht?
Wie kritisch ist es im Arbeitsablauf? Kann die Arbeit ohne das Tool weitergehen, nur langsamer? Oder steht ein Prozess still, wenn es fehlt?
Was passiert, wenn es nicht verfügbar ist? Für eine Stunde, für einen Tag, für eine Woche. Und wer merkt es zuerst – eine Kollegin oder ein Kunde?

Daraus ergibt sich ein recht klares Bild:

Keiner dieser Wege ist grundsätzlich besser. Entscheidend ist eine Frage, die im Kern eine Ressourcenfrage ist: Setzen Sie Ihre Entwicklungskapazität für das richtige Produkt ein? Oder holen Sie sich Entwicklungs- und Wartungsaufwände ins Haus, die ein bestehendes Produkt längst gelöst hat?

Viele Eigenbau-Ideen landen bei ehrlicher Betrachtung im Feld oben rechts: eine Standardaufgabe, die trotzdem geschäftskritisch ist. Lohnen tut sich der Eigenbau vor allem unten rechts – vorausgesetzt, er wird wie ein Produkt behandelt und nicht wie ein Nachmittagsprojekt.

Viele, die nach einer KI-Tool-Auswahl suchen, wollen gar nicht selbst bauen. Sie suchen eine Software mit bestimmten Fähigkeiten: Texte in der eigenen Markensprache erzeugen, Bilder für Kampagnen generieren, Anfragen vorsortieren, Inhalte übersetzen. Nur ist kaum ein Markt gerade so unübersichtlich.

Neue Produkte erscheinen im Wochentakt, andere verschwinden wieder. Manche verlieren ihre Daseinsberechtigung mit einem einzigen Update: Ist ein Tool im Kern nur eine dünne Oberfläche über einem großen Sprachmodell, kann der Modellanbieter dieselbe Funktion morgen selbst ausliefern.

Der verlässlichste Weg durch diesen Markt beginnt nicht bei Produktnamen, sondern bei den Fähigkeiten, die Sie brauchen. Welche Aufgabe soll das Tool übernehmen, mit welchen Daten, für wen, in welcher Qualität? Aus diesen fachlichen Anforderungen ergibt sich eine gezielte Marktsondierung – statt einer Suche nach dem, was gerade am lautesten beworben wird.

Das muss weder lange dauern noch aufwendig sein. Gut formulierte Anforderungen schließen schnell alle Anbieter aus, die bestimmte Merkmale schlicht nicht erfüllen. Bei KI-Tools sind das häufig diese:

• Wo werden die Daten verarbeitet, und werden sie zum Training fremder Modelle genutzt?
• Welches Sprachmodell steckt dahinter – und lässt es sich wechseln, wenn ein besseres erscheint?
• Lässt sich das Tool an Ihre Systeme anbinden und in Ihre Rechte- und Anmeldestruktur einfügen?
• Wie wird abgerechnet – pro Nutzer, pro Nutzung, pro Token? Und wie planbar sind die Kosten damit?
• Können Sie Daten, Prompts und Workflows mitnehmen, wenn Sie später wechseln wollen?
• Wie stabil ist der Anbieter, und was passiert, wenn es ihn in zwei Jahren nicht mehr gibt?
• Welche regulatorischen Vorgaben gelten, etwa aus DSGVO oder EU AI Act?

Übrig bleibt meist eine überschaubare Zahl an Kandidaten. Ab hier ist es eine Systemauswahl wie jede andere – mit einem Unterschied: Bei KI-Tools ist der Test mit Ihren eigenen Daten noch wichtiger als sonst. Die Qualität der Ergebnisse schwankt stark mit dem Einsatzzweck, und eine überzeugende Demo mit Beispieldaten sagt wenig darüber, wie das Tool mit Ihren Inhalten umgeht.

Nicht jede KI-Tool-Auswahl braucht ein großes Verfahren. Der Aufwand sollte sich danach richten, wie hoch das Risiko einer Fehlinvestition ist und wie kritisch das Tool im Gesamtgefüge wird – also genau nach den Fragen zum Business Value weiter oben. Ein Hilfswerkzeug für ein einzelnes Team lässt sich in wenigen Tagen auswählen: Anforderungsliste, kurze Recherche, zwei oder drei Tests. Ein Tool, das in zentrale Prozesse eingebunden wird oder mit Kundendaten arbeitet, verdient das volle Verfahren mit Longlist, Shortlist, strukturierten Präsentationen und einem Proof of Concept.

Eine Anwendung von KI wird in dieser Diskussion oft übersehen: Ein schnell gebauter Prototyp ist eines der besten Werkzeuge, um Anforderungen zu schärfen. Wer eine erste Version in der Hand hat, merkt sofort, was fehlt, was überflüssig ist und wo die eigentlichen Probleme liegen. Anforderungen, die vorher abstrakt waren, werden greifbar.

Das Ergebnis kann ein Eigenbau sein. Es kann aber genauso gut eine deutlich bessere Grundlage für die Auswahl eines Standardprodukts sein – weil Sie jetzt genau wissen, wonach Sie suchen. In beiden Fällen hat sich der Prototyp gelohnt.

Bevor Sie sich für einen Weg entscheiden, lohnt es sich, diese Fragen ehrlich zu beantworten:

1. Welches Problem löst das Tool – und haben andere Unternehmen dasselbe Problem?
2. Sind neben den funktionalen auch die nicht-funktionalen Anforderungen beschrieben?
3. Wer ist nach dem Go-Live verantwortlich für Betrieb, Updates und Sicherheit?
4. Wer schult Anwenderinnen und Anwender und beantwortet ihre Fragen?
5. Was kostet das Tool über fünf Jahre, einschließlich Wartung und Weiterentwicklung?
6. Wie kritisch ist es für den Arbeitsablauf, und was passiert bei einem Ausfall?
7. Passt der gewählte Technologie-Stack zur IT-Strategie, und kann jemand im Haus ihn pflegen?
8. Gibt es eine Open-Source-Lösung, die als Basis dienen könnte?
9. Wofür würden Sie die Entwicklungskapazität sonst einsetzen?

Lassen sich die Fragen 3 und 4 nicht beantworten, ist das meist schon die Antwort.