KI kann die App bauen. Aber wer betreibt sie?

von | Sep. 28, 2026 | KI im Qualitätsmanagement, KI-Kompetenz & Organisation

Noch vor wenigen Jahren war bei vielen kleinen Digitalisierungsprojekten relativ schnell Schluss. Die Idee war da, der Prozess war verstanden, vielleicht gab es sogar schon eine Excel-Lösung. Aber sobald Schnittstellen, Logik oder etwas mehr Programmierung ins Spiel kamen, brauchte es jemanden mit den entsprechenden technischen Kenntnissen.

Low-Code- und No-Code-Plattformen haben diese Hürde bereits deutlich gesenkt. Und generative KI senkt sie gerade noch einmal.

Heute kann ich einem KI-System beschreiben, was eine Anwendung tun soll. Ich kann mir Code erzeugen lassen, Fehler gemeinsam mit der KI suchen und Funktionen ergänzen, die ich selbst nicht hätte programmieren können. Werkzeuge wie Cursor, Lovable oder Google AI Studio machen aus einer Idee erstaunlich schnell einen funktionierenden Prototypen.

Da liegt eine Schlussfolgerung nahe: Wenn KI inzwischen programmieren kann, wozu brauchen wir dann noch Low-Code und No-Code?

Ich glaube, diese Frage greift zu kurz.

Denn im Unternehmen ist nicht nur entscheidend, ob wir eine Anwendung bauen können. Entscheidend ist irgendwann, ob wir sie beherrschen können.

Ein funktionierender Prototyp ist noch keine betriebliche Anwendung

Für mich gibt es einen großen Unterschied zwischen einer Anwendung, mit der ich etwas ausprobiere, und einer Anwendung, auf die sich ein Unternehmen im Alltag verlässt.

Für einen Prototypen kann es völlig ausreichend sein, dass er funktioniert. Ich kann mit synthetischen Daten testen, einen Ablauf demonstrieren und herausfinden, ob eine Idee überhaupt trägt. Gerade dafür finde ich die neuen KI-gestützten Entwicklungswerkzeuge ausgesprochen interessant.

Problematisch wird es, wenn aus dem Experiment schleichend ein Produktivsystem wird.

Plötzlich arbeiten mehrere Personen damit. Echte Unternehmensdaten fließen hinein. Ergebnisse werden für Entscheidungen verwendet. Vielleicht hängt sogar ein wichtiger Prozess daran.

Dann stellen sich andere Fragen.

Wer darf auf die Anwendung zugreifen? Wer darf Daten verändern? Wo werden diese Daten gespeichert? Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt? Wer prüft Änderungen? Wer merkt, wenn eine Schnittstelle nicht mehr funktioniert? Gibt es unterschiedliche Rollen und Berechtigungen? Kann ich nachvollziehen, was passiert ist? Und wer kümmert sich um die Anwendung, wenn die Person, die sie ursprünglich gebaut hat, nicht mehr verfügbar ist?

Das sind keine besonders neuen Fragen.

Im Gegenteil. Es sind ziemlich klassische Fragen aus Qualitätsmanagement, IT-Governance, Datenschutz und Informationssicherheit.

KI hat das Bauen verändert. Sie hat diese Fragen nicht abgeschafft.

Vielleicht macht KI Low-Code gerade interessanter

Deshalb finde ich auch die Diskussion „KI versus Low-Code“ etwas merkwürdig.

Denn KI könnte ausgerechnet einen der Nachteile von Low-Code- und No-Code-Plattformen reduzieren.

Wer schon einmal mit Power Automate oder einer vergleichbaren Plattform gearbeitet hat, kennt wahrscheinlich diesen Moment: Eigentlich ist ziemlich klar, was der Prozess tun soll. Trotzdem funktioniert irgendeine Bedingung nicht, ein Ausdruck ist falsch, die Daten kommen im falschen Format an oder der Flow verhält sich anders als erwartet.

Für Menschen ohne Programmierhintergrund war das bisher schnell eine Grenze.

Genau an dieser Stelle kann KI helfen.

Sie kann Formeln erklären, Ausdrücke erstellen, Fehler analysieren, Logik übersetzen oder Schritt für Schritt durch eine Umsetzung führen. Damit kann ein Fachanwender möglicherweise deutlich mehr innerhalb einer bereits vorhandenen Unternehmensplattform selbst umsetzen als früher.

Die interessante Entwicklung könnte deshalb gerade nicht sein:

KI ersetzt Low-Code.

Sondern:

KI beseitigt einen Teil der Hürden, die Low-Code bisher für Fachanwender hatte.

Und damit wird die Kombination für Unternehmen interessant: Die KI hilft beim Bauen, während die Plattform einen Teil der Strukturen für den späteren Betrieb bereitstellt.

Nicht alles muss sofort durch die Unternehmens-IT

Das bedeutet für mich allerdings nicht, dass jedes Experiment von Anfang an in eine große Unternehmensplattform gehört.

Das wäre das andere Extrem.

Ich sehe durchaus einen sinnvollen Raum für schnelles Prototyping. Wenn ich herausfinden möchte, ob eine Idee überhaupt funktioniert, kann ein Werkzeug wie Lovable, Cursor oder eine andere KI-gestützte Entwicklungsumgebung genau richtig sein.

Ich muss dafür aber nicht gleich reale Kunden-, Mitarbeiter- oder Unternehmensdaten hineingeben.

Für mich lassen sich vier Phasen unterscheiden:

PhaseDie zentrale Frage
Explore, ErkundenIst die Idee grundsätzlich interessant?
Prototype, Prototyp entwickelnFunktioniert der Use Case technisch und fachlich?
Operationalize, in den Betrieb überführenUnter welchen Bedingungen darf die Lösung tatsächlich eingesetzt werden?
Operate, BetreibenWie stellen wir einen kontrollierten und verlässlichen Betrieb sicher?

Die ersten beiden Phasen dürfen schnell sein. Genau dort sehe ich einen großen Charme der neuen KI-Werkzeuge.

Der kritische Punkt liegt zwischen Prototype und Operationalize.

Hier sollte aus „Das funktioniert doch“ irgendwann „Das dürfen und können wir so betreiben“ werden.

Das eigentliche Quality Gate liegt vor dem Produktivbetrieb

Aus QM-Sicht ist das für mich ein ziemlich klassisches Quality Gate.

Dabei interessiert mich zunächst gar nicht, ob eine Anwendung mit Python, Cursor, Lovable, Power Apps oder einer anderen Technologie gebaut wurde.

Ich würde vielmehr fragen:

Sind Verantwortlichkeiten geklärt? Sind Daten und Zugriffsrechte geregelt? Ist die Anwendung ausreichend getestet? Sind Änderungen beherrscht? Ist nachvollziehbar, was sie tut? Gibt es einen Verantwortlichen für den Betrieb? Und ist klar, was bei Fehlern oder beim Ausfall passiert?

Je kritischer der Prozess, desto höher müssen dabei natürlich die Anforderungen sein.

Eine kleine interne Anwendung zur Organisation einer unverbindlichen Ideensammlung braucht nicht dieselben Kontrollen wie eine Anwendung, die Reklamationen klassifiziert, Lieferanten freigibt oder qualitätsrelevante Entscheidungen vorbereitet.

Das ist für mich ein wichtiger Punkt: Governance sollte nicht bedeuten, jedes Experiment mit denselben Anforderungen zu belasten wie ein produktives System.

Sie sollte vielmehr dafür sorgen, dass wir erkennen, wann aus einem Experiment etwas geworden ist, das beherrscht werden muss.

Vom Citizen Developer zum Citizen Operator?

Vielleicht verschiebt KI deshalb gerade eine Grenze.

Wir haben lange über Citizen Development gesprochen: Menschen aus den Fachbereichen können Anwendungen erstellen, ohne klassische Softwareentwickler zu sein.

Mit generativer KI wird diese Möglichkeit noch einmal erheblich größer.

Aber damit entsteht fast zwangsläufig die nächste Frage: Wer übernimmt anschließend die Verantwortung für das, was entstanden ist?

Denn bauen können und betreiben können sind zwei unterschiedliche Kompetenzen.

Das gilt übrigens auch für KI selbst. Eine kostenlos verfügbare KI-Anwendung kann hervorragend geeignet sein, etwas auszuprobieren. Daraus folgt nicht automatisch, dass sie für sensible Unternehmensdaten oder einen dauerhaft etablierten Geschäftsprozess geeignet ist.

Bei selbst gebauten Anwendungen ist es ähnlich.

Die Geschwindigkeit des Werkzeugs ersetzt nicht die Verantwortung für seinen Einsatz.

Vielleicht brauchen wir deshalb nicht weniger Plattform, sondern eine andere Rolle für sie

Unternehmensplattformen müssen aus meiner Sicht nicht mehr unbedingt der Ort sein, an dem jede Idee beginnt.

Eine Idee kann heute außerhalb davon entstehen. Sie kann innerhalb weniger Stunden als Prototyp sichtbar werden. Das ist ein Vorteil, den Unternehmen nicht durch unnötige Hürden wieder zunichtemachen sollten.

Aber wenn aus dieser Idee eine Anwendung wird, die dauerhaft mit Unternehmensdaten arbeitet, von mehreren Mitarbeitern genutzt wird oder einen relevanten Geschäftsprozess unterstützt, ändert sich die Situation.

Dann brauche ich Berechtigungen, Verantwortlichkeiten, Datenmanagement, Änderungsprozesse und einen verlässlichen Betrieb.

Ob die endgültige Lösung dafür zwingend auf einer Low-Code-Plattform laufen muss, würde ich nicht behaupten. Auch individuell entwickelte Software kann all diese Anforderungen erfüllen.

Der Maßstab sollte ein anderer sein:

Nicht: Womit wurde die Anwendung gebaut?
Sondern: Ist sie für ihren vorgesehenen betrieblichen Einsatz ausreichend beherrscht?

Vielleicht ist das die interessantere Entwicklung hinter Vibe Coding und KI-gestützter Softwareentwicklung.

KI demokratisiert das Bauen.

Jetzt müssen wir dafür sorgen, dass wir beim schnellen Bauen das Betreiben nicht vergessen.

Judith Magono

Consulting für künstliche Intelligenz & Qualitätsmanagement