Jeder kann heute eine App bauen.
Wir sorgen dafür, dass sie sicher läuft.

Citizen Development bedeutet, Business-Anwendungen, Workflows und Automatisierungen mit Low-Code-, No-Code- oder KI-gestützten Tools zu bauen. Die Personen, die sie bauen, sind keine Software-Entwickler. Sie heißen Citizen Developer und arbeiten meist in einem Fachbereich wie Vertrieb, Finance, HR oder Operations. Sie lösen ein Problem aus der eigenen täglichen Arbeit, nicht eines, das von der IT zugewiesen wurde.

Citizen Development unterscheidet sich von professioneller Softwareentwicklung in zwei Punkten: Werkzeug und Ziel. Ein Citizen Developer nutzt einen visuellen Builder, eine Vorlage oder einen natürlichsprachlichen Prompt, nicht einen Code-Editor und eine Deployment-Pipeline. Das Ergebnis ist meist ein kleines internes Tool, kein Produkt für externe Kunden. Heute sind drei Formen verbreitet:

• Low-Code- und No-Code-Plattformen: visuelle Drag-and-Drop-Builder mit vorgefertigten Komponenten, ganz ohne handgeschriebenen Code.
• KI-gestützte, „AI-built“ Apps: entstehen aus einem Prompt mit einem KI-Assistenten, oft ohne dass die bauende Person den Code je liest.
• Tools für Tabellen- und Workflow-Automatisierung: verwandeln eine manuelle, wiederkehrende Aufgabe in eine automatisierte, ohne ein formales Entwicklungsprojekt.

Allen dreien ist eines gemeinsam: Die App muss trotzdem irgendwo laufen, meist auf einer Infrastruktur, über die sich die bauende Person nie Gedanken macht. Genau dort beginnen die Fragen nach Verantwortung und Governance.

Ein Citizen Developer ist jede Person, die eine funktionierende Anwendung baut und in Betrieb bringt, ohne eine formale Software-Engineering-Rolle zu haben. Wie ausgereift das Ergebnis ist, spielt keine Rolle. In der Praxis reicht das von einem Finance-Analysten, der einen Reporting-Workflow in einem Low-Code-Tool automatisiert, über eine Operations-Managerin, die ein internes Dashboard baut, bis zu einer Marketing-Fachkraft, die mit einem KI-Assistenten aus einem Prompt ein funktionierendes Lead-Routing-Tool erzeugt.

Der Unterschied zum professionellen Entwickler liegt nicht im Können. Er liegt in Rolle, Zugriff und Werkzeug. Citizen Developer haben in der Regel keinen direkten Zugriff auf Infrastruktur oder Produktion. Sie bauen und deployen über eine Plattform, einen Builder oder einen Assistenten. Jemand anderes, meist ein Platform- oder IT-Team, verantwortet das, was dieser Build berührt, sobald er läuft. Ein professioneller Entwickler hat dagegen in der Regel direkten Zugriff auf die Systeme, auf die er deployt, und ist formal dafür verantwortlich, was er ausliefert.

Schatten-IT ist Software, Infrastruktur oder ein Cloud-Dienst, den ein Fachbereich baut oder betreibt, ohne dass die IT davon weiß oder es freigegeben hat. Sie liegt außerhalb jedes Security-Reviews, jeder Zugriffskontrolle und jedes Audit-Trails, auf den sich die Organisation sonst verlässt.

Citizen Development ist nicht automatisch Schatten-IT. Beide Begriffe beantworten unterschiedliche Fragen: wer die Software baut, und ob dieser Bau innerhalb einer freigegebenen Governance stattfindet. Ein Beispiel macht die Grenze deutlich:

• Schatten-IT: Ein Finance-Analyst baut eine App mit einem KI-Assistenten und deployt sie auf einem privaten Cloud-Account, unsichtbar für die IT.
• Freigegebenes Citizen Development: Dieselbe Person baut dieselbe App mit denselben Werkzeugen, deployt sie aber über eine Plattform, auf der die Organisation weiterhin Zugriff kontrolliert, Richtlinien durchsetzt und festhält, was passiert ist.

Schatten-KI ist der KI-spezifische Sonderfall von Schatten-IT: Mitarbeitende nutzen einen Chatbot, einen KI-Coding-Assistenten oder einen Agenten, um etwas Arbeitsbezogenes zu bauen oder zu automatisieren, ohne dass die IT davon weiß. Das Phänomen ist zusammen mit Citizen Development gewachsen, weil dieselben KI-Assistenten, die es jedem erlauben, eine funktionierende App zu bauen, es genauso einfach machen, das außerhalb jeder freigegebenen Plattform zu tun. Es gilt dieselbe Regel: Eine KI-gebaute App zählt nur dann als Schatten-KI, wenn sie außerhalb der Sichtbarkeit und Kontrolle der Organisation läuft und auf Daten zugreift. Über eine kontrollierte Plattform gebaut, bleibt dieselbe App freigegebenes Citizen Development, ob KI-gestützt oder nicht.

In jedem Fall gilt dieselbe Grenze: nicht wer die App geschrieben hat oder wie, sondern ob die Organisation sie weiterhin sehen, kontrollieren und nachweisen kann.

Mit Citizen Development werden meist Sicherheitsrisiken assoziiert, in der Praxis treten jedoch die operativen Risiken zuerst auf und richten oft den größeren Schaden an, weil sie darüber entscheiden, ob eine App den Kontakt mit der Produktion überhaupt übersteht. Die zentralen Risiken lassen sich auf wenige wiederkehrende Kategorien zurückführen:

• Fehlende Verantwortung: Niemand ist formal dafür zuständig, die App am Laufen zu halten, zu patchen oder zu reagieren, wenn sie ausfällt, weil sie nie einem Team zugeordnet wurde, wie es bei IT-gebauter Software der Fall wäre.
• Uneinheitliche Policy-Durchsetzung: Regeln zu Datenzugriff, Ressourcenverbrauch und Freigaben, die für Engineering-gebaute Software gelten, lassen sich leicht umgehen, wenn eine App außerhalb der üblichen Pipeline deployt wird.
• Fehlender Audit-Trail: Ohne ein Protokoll, wer was wann mit welchem Zugriff deployt hat, lassen sich grundlegende Compliance-Fragen im Nachhinein kaum beantworten.
• Unkontrollierte Ausbreitung: Weil Citizen-gebaute Apps schnell entstehen, kann eine Organisation am Ende deutlich mehr davon betreiben, als irgendjemand erfasst hat, jede einzelne mit ihrer eigenen stillen Abhängigkeit von fortlaufender Pflege.

mogenius schließt die Audit- und Policy-Lücke direkt: Es erzeugt einen durchgehenden Audit-Trail aus den Live-Betriebsdaten von Kubernetes, statt Nachweise im Nachhinein von Hand zusammenzustellen. Keines dieser Risiken ist ein Grund, Citizen Development zu verbieten. Sie sind Gründe, es bewusst zu steuern, statt es einfach geschehen zu lassen.

Warum Citizen Development wichtig ist

• Schließt die IT-Lücke: Kleine, spezifische Tools, etwa ein Dashboard für ein Team oder ein Freigabe-Workflow, rechtfertigen selten den Aufwand eines Engineering-Teams. Citizen Development sorgt dafür, dass diese Tools trotzdem entstehen.
• Schnellere Ergebnisse: Wer dem Problem am nächsten ist, kann es in Tagen lösen, statt Monate im Engineering-Backlog zu warten.
• Bessere Nutzung der Engineering-Zeit: Professionelle Entwickler bleiben auf komplexe, wertvolle Produktarbeit fokussiert.
• Begegnet dem Fachkräftemangel: Software-Entstehung skaliert, ohne dass Unternehmen mehr knappes Engineering-Personal einstellen müssen.

Die Gefahr eines Verbots

• Verbote wirken nicht: Ein Verbot von Citizen Development hält Mitarbeitende nicht davon ab, KI- oder Low-Code-Tools zu nutzen.
• Verbote erzeugen Schatten-IT: Sie verschieben den Bau nur auf private Geräte und Cloud-Accounts, und die IT verliert jede Sichtbarkeit.
• Der richtige Weg ist Lenken statt Verbieten: Erfolgreiche Organisationen schaffen ein sicheres Umfeld mit klaren Leitplanken, damit Geschwindigkeit und Innovation mit der IT passieren, nicht an ihr vorbei.

Governance, die auf einem Review-Schritt vor dem Deployment beruht, scheitert meist auf eine von zwei Arten: Entweder wird sie zum Flaschenhals, den Teams umgehen, wodurch genau das Schatten-IT-Problem entsteht, das sie eigentlich verhindern sollte, oder sie wird unter Zeitdruck übersprungen und funktioniert dann faktisch nicht mehr als Governance. Die Alternative ist, Governance direkt beim Deployment selbst durchzusetzen, innerhalb der Plattform, die der Citizen Developer ohnehin nutzt, statt als separaten Freigabeprozess obendrauf.

• Richtlinien greifen automatisch: Ressourcen-Quotas, Zugriffsregeln für Daten und Freigabe-Gates gelten bei jedem Deployment gleichermaßen, unabhängig davon, wer die App gebaut hat oder wie.
• Anleitung statt Ticket: Blockiert eine Regel eine Aktion, bekommt die bauende Person eine Erklärung in klarer Sprache und einen Weg nach vorn, im selben Moment, statt ein Ticket, das in einer Warteschlange wartet.
• Day-2-Betrieb läuft automatisiert, nicht vorausgesetzt: Updates, Skalierung und Monitoring laufen, ohne dass die bauende Person oder ein Platform Engineer manuell eingreifen muss.

mogenius wendet genau dieses Modell auf Kubernetes an: Wer baut, deployt über einen isolierten, vorkonfigurierten Workspace ohne Cluster-Zugriff. Richtlinien greifen bei jedem Deployment, und der Audit-Trail entsteht aus dem, was die Plattform tatsächlich getan hat, nicht aus etwas, das im Nachhinein ausgefüllt wurde.

Die Verantwortung muss in dem Moment festgelegt werden, in dem eine App deployt wird, nicht erst angenommen werden, wenn etwas schiefgeht. In der Praxis sollte der Deployment-Weg selbst drei Fragen beantworten:

• Wer wird benachrichtigt, wenn die App ausfällt.
• Wer gibt frei, wenn Updates oder Abhängigkeiten sich ändern.
• Wie laufen Ressourcenverbrauch und Skalierung, ohne dass die ursprünglich bauende Person eingreifen muss.

Ist das nicht im Voraus geklärt, landet die Verantwortung bei dem Team, das den Ausfall zuerst bemerkt. Das ist in der Regel die IT oder das Platform-Team, unabhängig davon, wer die App tatsächlich gebaut hat. Die Personen, die sie jetzt am Laufen halten, wissen dadurch oft am wenigsten darüber, was sie tut oder warum.

Verantwortung als Teil des Deployment-Prozesses festzulegen, statt erst nach einem Incident, verhindert genau diese zufällige Übergabe.

Deployen Sie die vibe-coded App über eine governed Plattform statt über den privaten Cloud-Account oder Laptop der bauenden Person, damit dieselben Policies, Workspace-Isolation und das Audit-Log gelten wie für jeden anderen Produktions-Workload. Mit mogenius deployt ein Citizen Developer, der per Vibe Coding baut, über einen isolierten, vorkonfigurierten Workspace ohne Cluster-Zugriff: Policy-Prüfungen wie Resource-Quotas und Data-Egress-Regeln laufen bei jedem Deployment automatisch, Day-2-Betrieb läuft ohne Zutun der bauenden Person, und jede Aktion landet in einem Audit-Trail aus den tatsächlichen Kubernetes-Betriebsdaten. Der Code selbst muss dafür nicht Zeile für Zeile geprüft werden: entscheidend ist, dass er innerhalb derselben Leitplanken läuft wie jeder andere Workload.