Citizen Development mit AI: Wer hält die Apps sicher?

AI hat Citizen Development zum Arbeitsalltag gemacht. Mitarbeitende aus allen Abteilungen entwickeln inzwischen funktionsfähige Apps, ohne selbst im Engineering tätig zu sein. Die meisten dieser Apps entstehen jedoch außerhalb des Sichtfelds der IT. So wächst Shadow IT. Für IT-Verantwortliche besteht die Lösung darin, einen kontrollierten Self-Service-Weg anzubieten, der schneller ist als inoffizielle Workarounds und bei dem Zuständigkeiten, Sicherheitsvorgaben und ein Audit Trail von Anfang an integriert sind.

Meistens beginnt es so: Am Montag beschreibt ein Vertriebsleiter einem AI-Assistenten ein Dashboard für das Quartalsreporting. Am Nachmittag nutzt bereits das gesamte Team die Anwendung. Am Donnerstag lädt sie plötzlich nicht mehr.

Wer wird angerufen? Der Vertriebsleiter kann keinen Stack Trace lesen. Die IT hat den Code noch nie gesehen. Niemand weiß genau, wo die App gehostet wird oder auf welche Daten sie zugreift.

Dieses Thema begegnet mir derzeit auf praktisch jeder Veranstaltung, die ich besuche, und in fast jedem Kundengespräch.

Als der AI-App-Builder Lovable zu öffentlich zugänglichen Apps befragt wurde, die mit seinem Tool erstellt worden waren, erklärte das Unternehmen laut Wired, dass die Konfiguration einer App letztlich in der Verantwortung ihrer Ersteller liege. Diese Ersteller sind die Citizen Developer von heute, und die meisten von ihnen waren noch nie für den Betrieb einer Software verantwortlich.

Meiner Ansicht nach greift diese Antwort zu kurz. Verantwortung muss auf jeder Ebene verankert sein: beim Anbieter des Tools, bei der Plattform, auf der die App läuft, und beim Unternehmen, das sie bereitstellt.

Wie viele Menschen in Ihrem Unternehmen können heute Software entwickeln?

Seit 15 Jahren gehört der Satz „Jedes Unternehmen ist ein Softwareunternehmen" zum Standardrepertoire von Keynotes. Für die meisten Unternehmen war das bislang keine Realität, denn Softwareentwicklung erforderte knappe, hoch spezialisierte Fachkräfte. Mit AI fällt diese Hürde zunehmend weg.

Eine repräsentative Umfrage des Instituts der deutschen Wirtschaft (IW Köln), veröffentlicht im September 2026, ergab, dass 29,1 % der Beschäftigten, die AI bei der Arbeit einsetzen, Tools nutzen, die ihr Arbeitgeber nicht bereitgestellt hat. Bei den unter 30-Jährigen liegt der Anteil bei 38,4 %, bei Führungskräften bei 34,6 %. Eine Umfrage des Low-Code-Anbieters Retool weist in dieselbe Richtung: Von 817 Personen, die Software entwickeln (überwiegend Retool-Kunden), haben bereits 51 % Anwendungen gebaut, die ihre Teams produktiv einsetzen.

Das sind gute Nachrichten. Die Menschen, die das Geschäft am besten kennen, können die benötigten Tools selbst entwickeln, statt ein Jahr auf einen freien Platz im IT-Backlog zu warten. Jeder Mitarbeitende kann zum Creator werden.

Für Führungsteams verändert das gleich drei Dinge: Aus Ideen wird innerhalb weniger Wochen funktionsfähige Software. Kleine Automatisierungen, für die sich ein eigenes IT-Projekt bisher nicht gelohnt hätte, werden wirtschaftlich interessant. Und jede dieser Apps muss betrieben, abgesichert und finanziert werden.

Warum Verbote von AI-generierten Apps Shadow IT nicht verhindern

Früher bedeutete Shadow IT meist ein nicht genehmigtes SaaS-Abonnement. Heute umfasst der Begriff auch nicht autorisierte Software: Apps, die kein Entwickler geschrieben, kein Architekt geprüft und kein Operations-Team überhaupt auf dem Radar hat.

Die entsprechenden Tools zu blockieren, funktioniert selten dauerhaft. Die IW-Studie liefert einen möglichen Hinweis darauf, warum das so ist: Wo Mitarbeitende angeben, dass ihr Arbeitgeber aktiv ihre AI-Kompetenzen fördert, nutzen 44,5 % Shadow AI. Wo diese Unterstützung fehlt, sind es 21,3 %.

Die Autoren sprechen von einer Korrelation. Meine Interpretation: Die Schulungen zeigen Wirkung. Menschen lernen, was AI für ihre Arbeit leisten kann, und setzen dieses Wissen anschließend ein. Nur die Infrastruktur des Unternehmens ist noch nicht so weit. Der Titel der Studie bringt es treffend auf den Punkt: Die Mitarbeitenden sind schneller als ihre Unternehmen.

Unterdessen müssen die Apps irgendwo laufen. Im Mai 2026 meldete der Sicherheitsanbieter Red Access mehr als 2.000 öffentlich erreichbare Apps von Vibe-Coding-Plattformen, die sensible Unternehmens-, Betriebs- oder personenbezogene Daten enthielten. Viele davon ermöglichten laut dem Bericht jedem mit der entsprechenden URL einen Zugriff mit Admin-Rechten.

Diese Zahlen stammen aus einer eigenen Untersuchung des Anbieters und sollten entsprechend kritisch eingeordnet werden. Red Access zufolge bestanden die betroffenen Organisationen zum damaligen Zeitpunkt ihre Audits.

Doch Audits prüfen in der Regel die Systeme, die der IT bekannt sind. Eine App, die an einem Nachmittag erstellt und über ein persönliches Konto gehostet wurde, taucht in solchen Prüfungen häufig gar nicht erst auf.

Ein Verbot drängt diese Apps lediglich noch weiter aus dem Sichtfeld der IT.

Was kostet eine AI-generierte App nach dem Launch?

AI hat die Entwicklung erheblich vereinfacht. Der Betrieb einer Anwendung ist dagegen genauso anspruchsvoll wie zuvor. Wenn das schon für erfahrene Infrastruktur-Engineers gilt, was bedeutet es dann für einen Vertriebsleiter, der ein Quartals-Dashboard erstellt hat?

Gartner erwartet, dass bis 2028 rund 60 % der mit Vibe Coding entwickelten Anwendungen wieder eingestellt werden. Die übrigen 40 % werden stillschweigend Teil des Unternehmensalltags, häufig ohne klar verantwortliche Person und ohne Eintrag in einem zentralen Inventar.

Gartner geht außerdem davon aus, dass 30 % der Software-Engineering-Teams durch die Wartung von Apps, die Citizen Developer und Fachanwender entwickelt haben, erheblich unter Kapazitätsdruck geraten werden.

Die tatsächlichen Kosten zeigen sich oft erst später, in Form von Fragen, die bei der Entwicklung niemand eingeplant hat:

• Wer aktualisiert die Libraries der App, sobald eine Sicherheitslücke bekannt wird?
• Wer übernimmt die Verantwortung, wenn der Ersteller das Team wechselt oder das Unternehmen verlässt?
• Auf welche Daten kann die App zugreifen, und wo werden diese Daten verarbeitet?
• Wer wird am Montagmorgen um 7 Uhr angerufen, wenn die Anwendung ausfällt?

Beim Kauf einer Software kamen die Antworten auf viele dieser Fragen vom Anbieter. Entwickelt eine Fachabteilung die Anwendung selbst, landen die entsprechenden Aufgaben häufig bei der IT: ausgerechnet bei denjenigen, die am wenigsten darüber wissen, wofür die App gedacht ist.

Wie sieht ein kontrollierter Entwicklungsweg für Citizen Developer aus?

Menschen wählen in der Regel den einfachsten Weg. Deshalb muss die IT einen kontrollierten Self-Service anbieten: einen Weg, der sicherer ist als ein Workaround und mindestens genauso schnell zum Ziel führt. Dabei hilft es, den Lebenszyklus einer internen App in drei Phasen zu unterteilen:

Die Entwicklung kann in einer Sandbox stattfinden. Deployment und Betrieb gehören dagegen in stabilere Umgebungen, die den Sicherheitsvorgaben des Unternehmens entsprechen. Gartner bringt diesen Ansatz bereits im Titel seines Berichts vom Juni 2026 auf den Punkt: „Govern Vibe Coding for Citizen Developers With Self-Service Platforms". Die Governance für Vibe Coding muss in der Plattform verankert sein, auf der die Anwendungen bereitgestellt werden.

Für Platform Teams bedeutet das, dass eine neue Art von Nutzern hinzukommt: Fachanwender, die noch nie ein Deployment durchgeführt haben, und zunehmend auch AI Agents, die in ihrem Auftrag handeln. Von diesen Nutzern kann niemand erwarten, dass sie sämtliche Regeln kennen. Deshalb muss die Plattform sie technisch durchsetzen.

Aus unserer Arbeit mit Kunden ergeben sich fünf wesentliche Merkmale eines kontrollierten Entwicklungswegs:

1. Sicherheitsvorgaben sind bereits im Template enthalten. Der Nutzer wählt beispielsweise die Option „Web-App deployen". Im Hintergrund sind die Isolation von anderen Apps, Security Policies, ein Freigabeschritt vor dem produktiven Einsatz und ein einer Person zugeordneter Audit Log bereits eingerichtet.
2. Regeln erklären sich selbst. Wird eine Aktion blockiert, erfährt der Nutzer in verständlicher Sprache, was verhindert wurde und wie er weiter vorgehen kann. Ein Entwickler kann eine kryptische Fehlermeldung aus einer Policy interpretieren. Ein Marketingmanager gibt dagegen möglicherweise auf, oder verlagert die App an einen Ort, an dem es keine Regeln gibt.
3. Die Zuständigkeit ist vor dem Go-live geklärt. Jede App hat vom ersten Tag an einen namentlich benannten fachlichen Owner und eine Stellvertretung.
4. Day-2-Operations funktionieren auch ohne den ursprünglichen Ersteller. Dependency Updates, Neustarts, Monitoring und Skalierung laufen automatisch ab. Dabei können AI Agents unterstützen, die innerhalb derselben Infrastruktur und der von der IT festgelegten Grenzen arbeiten.
5. Die erforderlichen Nachweise entstehen automatisch. Jedes Deployment und jede Änderung werden unmittelbar protokolliert. Ein Audit wird dadurch zu einer einfachen Abfrage statt zu einer aufwendigen nachträglichen Rekonstruktion.

Einige weitere Entscheidungen sollten ebenfalls vor dem Go-live der ersten App getroffen werden. Nachträgliche Änderungen können teuer werden: Welche Datenquellen sind standardmäßig zugänglich? Wann wird eine ungenutzte App abgeschaltet? Welchem Cost Center werden die Kosten zugeordnet? Und wer wird als Erstes benachrichtigt, wenn etwas ausfällt?

Spätestens bei der fünfzigsten App werden die getroffenen (oder versäumten) Entscheidungen zur gelebten Praxis.

Neele-Vat, ein global tätiges Logistikunternehmen mit Hauptsitz in Rotterdam, hat diesen Weg eingeschlagen. Das Team hat seine zentrale Anwendung für Versand und Tracking von virtuellen Maschinen auf eine kontrollierte Kubernetes-Plattform auf Azure umgezogen und nutzt dieselbe Plattform jetzt auch, um neueren, AI-gebauten Apps einen Platz mit denselben Sicherheitsvorgaben und derselben Sichtbarkeit zu geben, statt einem privaten Cloud-Konto, das niemand im Platform-Team einsehen kann.

Wo sollten AI Agents laufen, die Apps entwickeln und reparieren?

AI Agents führen Code aus, den zuvor möglicherweise niemand geprüft hat. Entscheidend ist deshalb, welche Systeme sich in ihrer unmittelbaren Umgebung befinden, wenn sie arbeiten.

Auf einem Laptop können das SSH Keys, Cloud Credentials und sämtliche Tools sein, die dem Projektverzeichnis vertrauen.

Im Juli 2026 veröffentlichten Forscher von Pillar Security Untersuchungen zu Sandbox-Escape-Schwachstellen, die Cursor, OpenAI Codex CLI, Google Gemini CLI und Google Antigravity betrafen. Die Agents hielten sich an ihre vorgegebenen Regeln und schrieben Dateien, die später von vertrauenswürdigen Tools außerhalb der Sandbox ausgeführt wurden.

Die Konsequenz: Die Isolation darf nicht allein vom Agent selbst abhängen. Sie muss durch die Umgebung gewährleistet werden, in der er arbeitet. In einer richtig konfigurierten Sandbox besteht die unmittelbare Umgebung im Idealfall nur aus einer kontrollierten, isolierten Ausführungsumgebung.

Genau dafür gibt es eine AI Agent Sandbox: Sie ermöglicht die sichere Codeausführung durch AI Agents in einer isolierten Umgebung. Ausgehender Netzwerkverkehr wird standardmäßig blockiert, und jede Aktion wird einer Identität zugeordnet und protokolliert.

Dieser Audit Trail schafft die praktische Grundlage für AI Agent Governance. Er macht nachvollziehbar, was in Produktion läuft, wer es deployed hat und unter welchen Sicherheitsvorgaben dies geschehen ist.

Für mich wird digitale Souveränität genau an diesem Punkt greifbar: Sie wissen, wo Ihr Code ausgeführt wird, und können nachweisen, wer darauf zugegriffen oder Änderungen vorgenommen hat.

Wissen, was läuft. Dann klären, wer verantwortlich ist.

Citizen Development mit AI findet in Ihrem Unternehmen bereits statt, unabhängig davon, ob Sie eine Strategie dafür haben oder nicht. Die entscheidende Frage ist, ob es dort stattfindet, wo die IT den Überblick behält.

Der erste Schritt kostet nichts: Fragen Sie jede Abteilung, welche Tools sie in den vergangenen sechs Monaten entwickelt oder neu eingesetzt hat und wo diese ausgeführt werden.

Bauen Sie anschließend einen kontrollierten Entwicklungsweg auf und sorgen Sie dafür, dass er die schnellste Option im Unternehmen ist.

Ihre AI-Strategie ist zugleich Ihre Plattformstrategie. Jedes Teammitglied kann zum Creator werden. Unsere Aufgabe ist es, dafür zu sorgen, dass die entstehenden Anwendungen sicher betrieben werden können.