KI kaufen, selbst entwickeln oder abwarten? Schau hinter die Demo.

Die Demo ist beeindruckend. Eine Kundenanfrage kommt rein, die KI versteht sie, findet das passende Produkt und formuliert eine freundliche Antwort. Dreißig Sekunden später ist alles erledigt. Im Raum sitzt jemand, der sagt: „Das brauchen wir auch.“

Ich würde an dieser Stelle die nächste Kundenanfrage sehen wollen. Die unvollständige. Die mit der falschen Artikelnummer. Die, bei der ein langjähriger Kunde etwas bestellt, das für seine Maschine gar nicht zugelassen ist.

Denn die Frage, ob Du KI kaufen, selbst entwickeln oder erst einmal abwarten solltest, entscheidet sich selten am schönsten Ergebnis. Sie entscheidet sich daran, was passiert, wenn die schöne Geschichte nicht aufgeht.

Und daran, wer anschließend die Arbeit hat.

Erst die Aufgabe zerlegen. Dann über KI reden.

Nehmen wir einen erfundenen Fall: Ein mittelständischer Anbieter von Industriekomponenten möchte seinen Kundenservice entlasten. Immer wieder kommen Anfragen zu Ersatzteilen. Das Team liest E-Mails, sucht in alten Bestellungen, prüft die Kompatibilität und schreibt Antworten. Der Wunsch ist schnell formuliert: „Wir brauchen einen KI-Assistenten für den Service.“

Das klingt nach einer Aufgabe. Tatsächlich stecken mehrere darin.

Eine E-Mail zusammenzufassen ist etwas anderes, als eine Maschine eindeutig zu identifizieren. Ein Antwortentwurf ist etwas anderes, als verbindlich zu bestätigen, dass eine Dichtung passt. Und ein freundlicher Satz über eine schnelle Lieferung ist noch keine belastbare Lieferzusage.

Genau diese Unterschiede verschwinden leicht hinter dem Wort „Assistent“. Plötzlich wird aus einem Werkzeug zum Formulieren ein System, das fachliche Entscheidungen treffen soll. Dabei wurde vielleicht nur bewiesen, dass es gut formuliert.

„Wir brauchen KI“ ist noch keine Anforderung. „Unser Service soll schneller zur richtigen Ersatzteilantwort kommen“ ist wenigstens ein Anfang.

Ich würde mir für diesen Fall zunächst einige echte Anfragen vornehmen: eine einfache Nachbestellung, eine mit fehlender Seriennummer, eine mit widersprüchlichen Angaben, eine zu einem abgekündigten Produkt. Dazu jeweils die fachlich richtige Reaktion. Manchmal ist das eine Artikelnummer. Manchmal eine Rückfrage. Manchmal muss ein Mensch ran.

Erst damit lässt sich vernünftig vergleichen. Sonst kaufst Du womöglich ein Tool, das die sichtbare Arbeit beschleunigt, während die schwierige Arbeit unangetastet bleibt.

Kaufen, was Standard ist. Entwickeln, was wirklich Deins ist.

Mein Ausgangspunkt wäre: Schau Dir zuerst an, was Deine vorhandene Software bereits kann. Nicht aus Begeisterung für Standardsoftware. Sondern weil eine eigene Anwendung auch dann Dein Problem bleibt, wenn sie sich mit KI erstaunlich schnell bauen lässt.

Im Servicebeispiel sind Ticketverwaltung, Suche und Antwortvorlagen zunächst wenig originelle Anforderungen. Wenn eine bestehende Anwendung dafür geeignete Funktionen bietet, würde ich sie an den ausgewählten Fällen testen. Muss jemand dafür Daten zwischen drei Fenstern kopieren? Kann das Team Quellen kontrollieren? Werden Zugriffsrechte respektiert? Kommen die Ergebnisse dort an, wo die Arbeit tatsächlich stattfindet?

Die schönste Antwort im separaten Chatfenster kann ziemlich nutzlos sein, wenn anschließend jemand den Kunden suchen, das Ticket zuordnen und die Antwort von Hand übertragen muss. Die Demo zeigt dann eine Abkürzung, der Arbeitsalltag bekommt einen Umweg.

Anders sieht es bei der Ersatzteillogik aus. Welche Dichtung zu welcher Maschinenrevision passt, welche Sondervereinbarung gilt und welcher Artikel den alten ersetzt: Das ist im Beispiel das eigene Fachwissen. Falls Standardsoftware diesen Teil nicht sinnvoll abbildet, kann eine individuelle Ergänzung gerechtfertigt sein.

Eine Ergänzung. Nicht automatisch ein komplett neues Servicesystem.

Die KI könnte die Anfrage lesen und die benötigten Angaben herausarbeiten. Eine gezielte Abfrage würde freigegebene Stammdaten und Kompatibilitätsregeln heranziehen. Das Ergebnis käme als Vorschlag mit nachvollziehbarer Grundlage ins bestehende Ticket. Fehlt die Seriennummer, entsteht eine Rückfrage statt einer geratenen Empfehlung. Die fachliche Freigabe bleibt zunächst beim Service.

Dafür muss man kein eigenes Sprachmodell trainieren. „Selbst entwickeln“ kann bedeuten, vorhandene Modelle und vorhandene Software so zu verbinden, dass ein eigener Ablauf funktioniert. Der Wert steckt dann in den Daten, Regeln und Übergaben. Nicht darin, dass irgendwo ein Chatfeld mit Deinem Logo steht.

Diese Grenze schützt vor einer ziemlich verführerischen Idee: Wenn wir schon etwas Eigenes bauen, machen wir alles gleich richtig. Also noch ein Dashboard. Noch eine Benutzerverwaltung. Noch einen Workflow-Editor. Aus einer fehlenden Verbindung wird ein Softwareunternehmen im Softwareunternehmen. Ob Du das wirklich betreiben willst, ist eine andere Frage als die, ob sich ein Prototyp bauen lässt. Genau diesen Unterschied beschreibe ich in „KI-Software ist wie ein Filmset“.

Die Rechnung endet nicht beim Preis des Tools

Bei Kaufsoftware steht ein Preis auf der Website. Bei einer Entwicklung steht irgendwann ein Aufwand im Angebot. Beides lässt sich wunderbar vergleichen. Beides ist als alleinige Entscheidungsgrundlage zu wenig.

Du brauchst die Kosten des vollständigen Ablaufs: Einrichtung, Datenpflege, Anbindung, Schulung, laufende Nutzung, Prüfung, Nacharbeit und Änderungen. Auch der spätere Ausstieg gehört dazu. Lassen sich Daten und brauchbare Konfigurationen mitnehmen? Was passiert, wenn die Schnittstelle geändert wird oder eine benötigte Funktion verschwindet?

Beim Eigenbau kommt die Verantwortung für den Betrieb hinzu. Jemand muss Fehler untersuchen, Abhängigkeiten pflegen und prüfen, ob die Lösung nach einem Modellwechsel weiterhin funktioniert. „Unsere IT kümmert sich“ ist dafür eine ziemlich dünne Zusage, solange niemand Zeit und Zuständigkeit dafür hat.

Kaufen nimmt Dir diese Fragen ebenfalls nicht vollständig ab. Der Anbieter kann seine Software betreiben. Ob sie im konkreten Einsatz die richtigen Vorschläge macht und wie Dein Team mit Fehlern umgeht, musst Du trotzdem klären. Auch das AI Risk Management Framework des NIST behandelt Rollen, Tests und laufende Überwachung über den Lebenszyklus hinweg, einschließlich Risiken von Drittanbietern. Das ist keine Renditegarantie, sondern ein hilfreicher Gegenpol zur Vorstellung, mit dem Vertragsabschluss sei die Verantwortung erledigt.

Im Servicefall würde ich deshalb die Zeit vom Eingang der Anfrage bis zur freigegebenen Antwort betrachten. Einschließlich Suche, Kontrolle und Korrektur. Wenn die KI den Entwurf beschleunigt, das Team danach aber jede Behauptung mühsam auseinandernehmen muss, ist noch nichts gewonnen.

Mein Maßstab wäre: Was kostet eine fachlich brauchbare, freigegebene Antwort? Nicht: Wie viele Antworten kann das System erzeugen?

Abwarten braucht einen Grund. Und ein Ende.

Zurück zu unserer Dichtung. Angenommen, die Zuordnung zwischen alten Maschinen und aktuellen Ersatzteilen liegt teilweise in veralteten PDFs und teilweise im Kopf eines Mitarbeiters. Niemand hat geklärt, welche Information im Konfliktfall gilt.

Dann würde ich die automatische Ersatzteilfreigabe vertagen. Ein besseres Modell entscheidet nicht für Dich, welche interne Unterlage verbindlich sein soll. Und eine überzeugende Antwort löst keinen Widerspruch in den Stammdaten.

Das muss den Rest nicht blockieren. Das Team kann prüfen, ob Zusammenfassungen und Rückfrageentwürfe bereits helfen. Parallel braucht es jemanden, der die Ersatzteilzuordnung verantwortet und die strittigen Fälle auflöst. Vertagt wird die konkrete Funktion, deren Grundlage fehlt. Nicht jede Beschäftigung mit KI.

Umgekehrt ist „Wir warten, bis die Technologie ausgereift ist“ für mich keine ausreichende Entscheidung. Welche Fähigkeit fehlt genau? Woran würdest Du erkennen, dass sie vorhanden ist? Und was kostet Dich der bisherige Ablauf bis dahin? Wer diese Fragen offenlässt, wartet womöglich auf eine Verbesserung, die mit dem eigenen Problem gar nichts zu tun hat.

Für das Beispiel sähe der nächste Schritt deshalb so aus:

• Standardfunktion testen: Zusammenfassung und Antwortentwurf im vorhandenen Serviceablauf, mit denselben einfachen und schwierigen Fällen.
• Ergänzung begrenzen: Nur die fehlende Verbindung zu freigegebenen Ersatzteildaten untersuchen. Einen Ausbau vom nachgewiesenen Nutzen abhängig machen.
• Freigabe vertagen: Bis die fachliche Zuordnung und Zuständigkeit geklärt sind. Einen Termin zur erneuten Prüfung setzen und die offenen Voraussetzungen festhalten.

So entsteht keine Glaubensentscheidung zwischen Kaufen und Bauen. Es entsteht ein überschaubarer Versuch, aus dem Du etwas lernen kannst. Vielleicht genügt die vorhandene Software. Vielleicht fehlt eine kleine, wertvolle Ergänzung. Vielleicht zeigt sich, dass zunächst ein ganz anderes Problem gelöst werden muss.

Ich finde alle drei Ergebnisse brauchbar. Unbrauchbar wäre, nach der nächsten beeindruckenden Demo wieder ganz von vorne anzufangen.