Eine Produktverantwortliche baut am Wochenende mit einem KI-Werkzeug eine neue Auswertungsseite. Sie funktioniert, sieht gut aus und beantwortet genau die Frage, auf die der Vertrieb seit Monaten wartet. Am Montag steht die Bitte im Raum, das Ergebnis direkt in die Software zu übernehmen. Das Entwicklungsteam reagiert zurückhaltend, die Fachseite versteht nicht, warum.
Diese Situation wird in vielen Unternehmen alltäglich. KI-Werkzeuge haben die Schwelle zum Bauen deutlich gesenkt. Menschen, die ihre Fachdomäne genau kennen, können heute selbst lauffähige Software erstellen. Das ist ein echter Gewinn. Es verschiebt aber eine Frage, die früher kaum gestellt werden musste: Was unterscheidet etwas, das funktioniert, von etwas, das im Betrieb tragen kann?
Was die Fachseite tatsächlich gebaut hat
Ein selbst gebauter Prototyp ist wertvoller, als ihn manche Entwicklungsteams zunächst einschätzen. Er zeigt präzise, was gebraucht wird – genauer als jede schriftliche Anforderung. Er beweist, dass die Idee grundsätzlich umsetzbar ist. Und er ist entstanden, ohne dass jemand im Entwicklungsteam Zeit dafür aufwenden musste.
Was der Prototyp in der Regel nicht zeigt, ist alles, was erst im Betrieb sichtbar wird: Wie verhält sich die Seite bei der zehnfachen Datenmenge? Wer darf welche Zahlen sehen? Was passiert, wenn eine Datenquelle ausfällt? Wie passt der neue Code zu den Konventionen und Abhängigkeiten des bestehenden Systems? Und wer kümmert sich darum, wenn in einem halben Jahr etwas nicht mehr stimmt?
Das sind keine Fragen, die sich mit besseren Prompts beantworten lassen. Sie hängen vom Umfeld ab, in dem die Software laufen soll – und dieses Umfeld kennt die Fachseite meist nicht im Detail.
Warum „einfach übernehmen“ selten funktioniert
Der Konflikt entsteht, weil beide Seiten recht haben. Die Fachseite hat in zwei Tagen etwas geschaffen, das sonst Wochen gedauert hätte. Das Entwicklungsteam weiß, dass die Arbeit nach der ersten lauffähigen Version oft erst beginnt.
Wird der Prototyp ungeprüft übernommen, wandert die Verantwortung stillschweigend zum Entwicklungsteam. Es muss Code betreuen, den es nicht geschrieben hat, dessen Entstehung es nicht kennt und den die Urheberin selbst oft nur in Teilen versteht. Wird der Prototyp dagegen pauschal abgelehnt, verliert das Unternehmen genau den Tempogewinn, den KI ermöglicht – und die Fachseite die Motivation, es noch einmal zu versuchen.
Beides lässt sich vermeiden, wenn vorab klar ist, welche Art von Software ein Prototyp werden soll.
Drei Kategorien statt einer Grundsatzdebatte
Hilfreich ist eine einfache Einteilung, die Fachseite und Entwicklung gemeinsam festlegen. Sie entscheidet nicht über die Qualität einer Idee, sondern darüber, welcher Weg in den Betrieb passt.
| Kategorie | Beispiel | Wer betreibt | Was nötig ist |
|---|---|---|---|
| Persönliches Werkzeug | Auswertung für die eigene Arbeit, lokales Skript | Die Person selbst | Keine Kundendaten, kein Zugriff auf Produktivsysteme |
| Team-Werkzeug | Interne Übersicht für eine Abteilung | Fachseite mit benannter Verantwortung | Lesender Datenzugriff, kurze Prüfung durch die Entwicklung |
| Teil des Produkts | Funktion für Kunden, Änderung am Shop oder an Schnittstellen | Entwicklungsteam | Regulärer Entwicklungsprozess, der Prototyp dient als Vorlage |
Die erste Kategorie sollte so frei wie möglich bleiben. Hier entstehen die meisten nützlichen Ideen, und das Risiko ist überschaubar, solange keine sensiblen Daten im Spiel sind. Die zweite braucht eine Person, die sich zuständig erklärt, und einen kurzen Blick von jemandem, der die Datenzugriffe beurteilen kann. Erst die dritte Kategorie verlangt den vollständigen Weg über das Entwicklungsteam.
Der Prototyp als Anforderung, nicht als Lieferung
In der dritten Kategorie lohnt sich ein Perspektivwechsel: Der Prototyp ist nicht das Produkt, sondern die beste Anforderung, die das Entwicklungsteam je bekommen hat. Er beantwortet Fragen, die sonst in mehreren Abstimmungsrunden geklärt werden müssten – welche Felder, welche Filter, welche Darstellung.
Das Entwicklungsteam kann daraus mit eigenen KI-Werkzeugen eine Fassung bauen, die zum bestehenden System passt. Das geht deutlich schneller als früher, weil die inhaltliche Arbeit bereits erledigt ist. Ob Teile des ursprünglichen Codes übernommen werden, entscheidet das Team nach fachlicher Prüfung. Für diese Prüfung gelten die gleichen Grundsätze wie für jede andere KI-gestützte Arbeit, die wir im Beitrag KI-Entwürfe im Team: Wer prüft, was die Maschine schreibt? beschrieben haben.
Ein Beispiel aus dem Handel
Nehmen wir einen mittelständischen Großhändler. Die Leiterin des Einkaufs baut sich mit einem KI-Werkzeug eine Übersicht, die Lieferzeiten und Liefertreue der wichtigsten Lieferanten aus einem monatlichen Export zusammenführt. Für ihre eigene Arbeit ist das ein persönliches Werkzeug – sie nutzt es, niemand muss es freigeben.
Nach einigen Wochen möchte das ganze Einkaufsteam die Übersicht verwenden. Damit wird sie zum Team-Werkzeug. Die Leiterin übernimmt ausdrücklich die Verantwortung dafür, ein Entwickler prüft in einer Stunde, wie die Daten hineinkommen, und richtet einen lesenden Zugriff ein, statt mit manuellen Exporten zu arbeiten.
Später soll die Liefertreue auch im Kundenportal erscheinen, damit Geschäftskunden realistische Liefertermine sehen. Jetzt ist sie Teil des Produkts. Das Entwicklungsteam nimmt die Übersicht als Vorlage, klärt mit dem Einkauf, welche Kennzahlen nach außen gehen dürfen, und baut die Funktion im regulären Prozess. Die Fachseite hat damit nicht weniger beigetragen, sondern mehr: Sie hat gezeigt, was gebraucht wird, und den Nutzen belegt, bevor jemand im Entwicklungsteam Zeit investiert hat.
Was Unternehmen jetzt festlegen sollten
Die Regeln dafür müssen nicht umfangreich sein. Einige Punkte genügen, um den Großteil der Konflikte zu vermeiden:
- Die drei Kategorien benennen und festhalten, ab wann ein Werkzeug in die nächste wechselt – etwa sobald mehr als eine Person es nutzt oder Kunden das Ergebnis sehen.
- Datenzugriffe klären. Welche Systeme dürfen selbst gebaute Werkzeuge lesen, welche niemals schreiben?
- Eine Ansprechperson in der Entwicklung bestimmen, die Prototypen kurzfristig einschätzt, statt sie in einer Warteschlange liegen zu lassen.
- Prototypen sichtbar machen. Eine einfache Liste, wer was gebaut hat, verhindert, dass Werkzeuge unbemerkt geschäftskritisch werden.
Diese Vereinbarungen passen zu dem, was wir allgemein für Innovationsvorhaben empfehlen: früh und günstig testen, und erst bauen, was sich bewährt hat. Wie ein solcher Test aussehen kann, beschreibt der Beitrag Der billigste Test zuerst. Ein selbst gebauter Prototyp ist oft genau dieser Test – nur dass ihn nun die Fachseite selbst durchführen kann.
Fazit
Wenn Fachabteilungen mit KI selbst Software bauen, gewinnt ein Unternehmen Tempo und präzisere Anforderungen. Der Gewinn bleibt aber nur erhalten, wenn klar ist, welcher Prototyp ein persönliches Werkzeug bleibt, welcher einem Team dient und welcher Teil des Produkts wird. Mit dieser Einteilung, geklärten Datenzugriffen und einer festen Ansprechperson in der Entwicklung wird aus dem Konflikt zwischen Fachseite und Entwicklung eine Arbeitsteilung. Wie Unternehmen solche Regeln Schritt für Schritt einführen, ist Teil unserer KI-Beratung; wie wir dabei vorgehen, zeigt unsere Arbeitsweise.