Die These
Etwas Grundlegendes hat sich verschoben. Technisch anspruchsvolle Aufgaben – Datenbankanbindungen, API-Integrationen, automatisierte Workflows, KI-gestützte Entscheidungssysteme – werden gerade in atemberaubendem Tempo demokratisiert. Die Werkzeuge dafür sind vielfältig und werden täglich mächtiger: Vibe-Coding mit KI-Assistenten, No-Code-Plattformen wie N8N oder Make, MCP-Server für LLM-Zugriff auf Unternehmensdaten, direkte API-Anbindungen per ChatGPT oder Claude.
Was früher Entwicklerteams, Architekten und Compliance-Experten brauchte, kann heute ein Fachanwender in Stunden aufsetzen. Das ist gleichzeitig die größte Chance und das größte Risiko dieser Technologie-Welle.
„Easy enough“ bedeutet nicht „safe enough“. Die technische Hürde fällt weg – aber die organisatorischen, regulatorischen und architektonischen Anforderungen bleiben bestehen. Schlimmer noch: Sie werden unsichtbar, weil niemand mehr da ist, der sie routinemäßig einfordert.
Von VBA zu Vibe-Coding: Die Evolution der Schatten-IT
Das Phänomen ist nicht neu. Es hat sich nur dramatisch beschleunigt.
Generation 1 – Excel & VBA (1990er–2010er)
Der Fachbereich baute sich eigene Lösungen in Excel. Komplexe Spreadsheets mit VBA-Makros, die ganze Geschäftsprozesse abbildeten. Die „Entwickler“ waren typischerweise tech-affine Controller, Analysten oder Ingenieure. Sie verstanden zumindest grundlegend, was sie taten – auch wenn Versionierung, Dokumentation und Wartbarkeit selten vorkamen. Das Risiko war begrenzt: Excel-Dateien lebten auf lokalen Rechnern oder Netzlaufwerken.
Generation 2 – Low-Code/No-Code (2015er–2020er)
Plattformen wie Zapier, Power Automate oder Airtable erweiterten den Aktionsradius. Plötzlich konnten Fachanwender Systeme miteinander verbinden, automatisierte Workflows bauen, Daten zwischen Cloud-Diensten bewegen. Die „Entwickler“ wurden diverser – weniger tech-affin, aber dafür näher am Geschäftsproblem. Das Risiko stieg: Daten flossen jetzt zwischen Systemen, oft über Cloud-Grenzen hinweg.
Generation 3 – Vibe-Coding & KI-Agenten (2024–heute)
Jetzt kann praktisch jeder mit einem LLM komplette Anwendungen bauen, APIs anbinden, Datenbanken abfragen, Workflows automatisieren – oft ohne eine einzige Zeile Code selbst zu verstehen. MCP-Server geben LLMs direkten Zugriff auf CRM, Buchhaltung, Kundendatenbanken. N8N-Workflows orchestrieren dutzende Systeme. Vibe-Coding erzeugt in Minuten funktionsfähige Applikationen.
Der entscheidende Unterschied: Bei jeder Generation wurde der Kreis der „Entwickler“ größer und die technische Kompetenz im Durchschnitt geringer – während gleichzeitig die Tragweite und das Risikopotenzial der gebauten Systeme drastisch zunahmen. Die Schere zwischen Können und Verantwortung geht immer weiter auf.
Das Dunning-Kruger-Problem der KI-Demokratisierung
Wenn ein Fachanwender heute in einer Stunde einen N8N-Workflow baut, der Kundendaten aus dem CRM zieht, durch ein LLM schickt und automatisiert E-Mails versendet – dann entsteht etwas, das technisch funktioniert. Aber hinter dieser funktionierenden Oberfläche lauern Fragen, die Professionals normalerweise vor der ersten Zeile Code klären:
1. Tech Stack & Wartbarkeit
- Wer wartet das System, wenn der Ersteller das Unternehmen verlässt?
- Gibt es Dokumentation? Versionierung? Rollback-Fähigkeit?
- Was passiert beim nächsten API-Update eines angebundenen Systems?
- Ist der generierte Code überhaupt verständlich und wartbar?
2. Non-Functional Requirements
- Wie verhält sich das System unter Last?
- Was passiert bei Ausfällen? Gibt es Fallbacks?
- Wie sicher ist die Authentifizierung? Gibt es Audit-Logs?
- Wie werden Geheimnisse (API-Keys, Tokens) verwaltet – oder stehen sie im Klartext im Workflow?
3. Compliance & Regulatorik
- Werden personenbezogene Daten an ein LLM gesendet? (DSGVO Art. 6, 9, 28)
- Ist eine Datenschutz-Folgenabschätzung (DPIA) nötig? (DSGVO Art. 35)
- Fällt das System unter den AI Act? Ist es ein High-Risk-System?
- Werden Daten in Drittländer transferiert? (Schrems II, DPF)
4. Data Governance
- Welche Daten fließen wohin? Gibt es ein Datenfluss-Mapping?
- Wer ist Data Owner? Wer entscheidet über Zugriff?
- Wie wird sichergestellt, dass das LLM keine sensiblen Daten in andere Gespräche leakt?
- Gibt es Datenklassifizierung? Weiß das System, was „vertraulich“ ist?
5. Verantwortlichkeit & Haftung
- Wer ist verantwortlich, wenn das System falsche Entscheidungen trifft oder halluziniert?
- Wer haftet bei einem Datenleck?
- Gibt es eine RACI-Matrix? Wissen alle Beteiligten von ihrer Rolle?
- Wurde die Geschäftsfühung informiert? (AI Act Art. 4: KI-Kompetenz-Pflicht)
Das Kernproblem: Die Anwender, die diese Systeme nun bauen können, wissen oft nicht einmal, dass diese Fragen existieren. Sie sind nicht fahrlässig oder dumm – sie bewegen sich schlicht in einem Kompetenzbereich, der diese Themen nie erfordert hat. Man kann nicht wissen, was man nicht weiß.
Warum „nachher einbauen“ nicht funktioniert
Professionelle Softwareentwicklung klärt diese Fragen idealerweise zu Beginn eines Projekts: in Architektur-Reviews, Compliance-Checks, Threat Modeling Sessions, Datenschutz-Bewertungen. Das hat gute Gründe.
Compliance, Sicherheit und Governance nachträglich einzubauen verursacht:
Technischen Rework: Der Workflow muss umgebaut werden, weil die Authentifizierung nicht reicht, die Logs fehlen, oder Datenflüsse nicht dokumentiert sind. Vibe-gecodete Apps müssen möglicherweise von Grund auf neu geschrieben werden.
Regulatorische Risiken: Ein System ist bereits live und verarbeitet personenbezogene Daten, ohne dass eine Rechtsgrundlage dokumentiert ist. Das ist kein kleiner Fehler – das ist ein Bußgeldrisiko nach DSGVO. Und seit Februar 2025 gilt die KI-Kompetenz-Pflicht nach dem AI Act.
Organisatorisches Chaos: Teams haben sich an den neuen Workflow gewöhnt. Jetzt kommen Compliance und IT-Sicherheit und sagen „Stopp“. Frustration, Widerstand, Verzögerung.
Schatten-IT auf Steroiden: Wenn die Governance-Prozesse als Bremse empfunden werden, bauen die Leute einfach weiter – nur unter dem Radar. Und mit den heutigen Werkzeugen ist das einfacher denn je.
Die Lösung: Governance ohne Momentum-Killer
Die Antwort ist weder „alles verbieten“ noch „alles laufen lassen“. Die Antwort liegt in einer Kombination aus drei Ebenen:
Ebene 1: Technische Guardrails (Enforcement by Design)
Governance muss in die Infrastruktur eingebaut werden, nicht als nachgelagerter Prozess. Menschen vergessen Regeln. Systeme nicht.
- Gateway/Proxy-Layer für LLM-Zugriffe: Alle Zugriffe laufen über einen zentralen Governance-Proxy. Dieser loggt, maskiert PII automatisch und prüft gegen Policies.
- Policy-as-Code: Regeln als maschinenlesbare Policies. „Kein Zugriff auf Kundendaten ohne DPIA-Freigabe“ – technisch durchgesetzt, nicht nur organisatorisch gewünscht.
- System-Registry: Jeder neue Workflow muss registriert werden, bevor er produktiv geht – Datenquellen, Verantwortlicher, Zweck, Klassifizierung.
- Secure-by-Default-Templates: Vorkonfigurierte Templates mit Logging, Authentifizierung und Datenklassifizierung bereits drin.
- Code-Scanning für Vibe-Coding: Generierter Code durchläuft automatisch Sicherheits-Scans, bevor er deployt werden kann.
Ebene 2: Leichtgewichtige Governance-Prozesse
Nicht jeder Workflow braucht ein 6-Wochen-Assessment. Aber jeder braucht ein Minimum an Prüfung. Die Lösung: ein abgestuftes Modell nach Risiko.
| Stufe | Kriterien | Anforderung | Zeitaufwand |
|---|---|---|---|
| 🟢 Grün | Keine PII, keine Automatisierung, nur intern | Self-Service-Checklist + automatische Registrierung | 15 Minuten |
| 🟡 Gelb | PII involviert, externe Daten oder Kundenkontakt | Kurz-Review durch Compliance + Datenfluss-Doku | 1–2 Stunden |
| 🔴 Rot | High-Risk AI, automatisierte Entscheidungen, sensible Daten | Vollständige DPIA + AI Act Assessment + Governance-Board-Freigabe | 1–4 Wochen |
Der Trick: Die Einstufung passiert automatisch. Der Anwender beantwortet 5–7 einfache Ja/Nein-Fragen. Das System stuft ein und leitet den passenden Prozess ein. Niemand muss selbst einschätzen, ob er ein „High-Risk-System“ baut.
Ebene 3: Befähigung (Kompetenz statt Kontrolle)
Die nachhaltigste Lösung: Die Anwender befähigen, die richtigen Fragen selbst zu stellen.
- Pflicht-Onboarding: 30-Minuten-Einführing mit konkreten Szenarien vor der ersten Nutzung. Keine Jura-Vorlesung.
- Kontextsensitive Hilfe: Hinweise in den Tools selbst: „Du verbindest Kundendaten. Hast du eine Rechtsgrundlage?“
- Community of Practice: Fachanwender und Compliance-Experten lernen gemeinsam. Kein Elfenbeinturm.
- AI Act Art. 4: Die KI-Kompetenz-Pflicht ist seit Februar 2025 geltendes Recht. Das betrifft explizit auch Fachanwender.
Fazit: Die Formel für Innovation ohne Risiko
Die Demokratisierung von KI-Werkzeugen ist nicht aufzuhalten – und das ist gut so. Sie setzt kreatives Potenzial frei, das jahrelang hinter technischen Hürden eingesperrt war. Aber sie erfordert ein neues Verständnis von Governance: nicht als nachgelagerter Kontrollprozess, sondern als integrierte Leitplanke, die Geschwindigkeit ermöglicht statt sie zu verhindern.
Technische Guardrails × Leichtgewichtige Prozesse × Befähigung = Governance, die mit dem Tempo der Innovation mithalten kann.
Wer das ignoriert, baut heute die Compliance-Probleme von morgen. Wer es richtig macht, verschafft seiner Organisation einen echten Wettbewerbsvorteil: schnell UND sicher innovieren.
