Warum Fachabteilungs-Software ein Governance-Problem ist nicht nur ein IT-Problem

Citizen Development und Low-Code erlauben Fachabteilungen, eigene Anwendungen zu bauen, ohne die IT bei jedem Schritt einzubinden. Das beschleunigt Prozesse — verschiebt aber auch die Verantwortung: Wer weiß, welche Anwendung mit welchen Daten arbeitet? Wer entscheidet, ob ein Freigabeschritt nötig ist? Laut einer KPMG-Befragung unter 715 Unternehmen in EMEA haben nur 31 Prozent der Unternehmen, die Low-Code bereits einsetzen, dafür verbindliche Governance-Regeln — bei der großen Mehrheit fehlen sie. Das Ergebnis ist nicht zwingend Schatten-IT im klassischen Sinn (unautorisierte Tools außerhalb der IT-Sicht), sondern etwas Subtileres: sichtbare, aber ungesteuerte Eigenentwicklung.

Der EU AI Act verschärft das. Seit dem 2. August 2026 gelten die zentralen Pflichten der Verordnung — Verbote, GPAI-Regeln und Transparenzpflichten sind in Kraft, auch wenn der Digital Omnibus (EU) 2026/1744 die Fristen für Hochrisiko-Systeme nach Anhang III (auf Dezember 2027) und Anhang I (auf August 2028) verschoben hat. Eine von einer Fachabteilung gebaute Anwendung, die etwa Personalentscheidungen unterstützt oder Kundendaten verarbeitet, kann trotzdem in den Geltungsbereich fallen — unabhängig davon, wer sie gebaut hat.

Schatten-IT entsteht nicht dadurch, dass Fachabteilungen bauen — sie entsteht dadurch, dass niemand weiß, dass sie es tun.

Damit ist die Frage nicht mehr "Dürfen Fachabteilungen selbst bauen?", sondern: "Unter welchen Bedingungen dürfen sie es, und wie wird das sichtbar?"

Governance-Rahmen: Rollen, Freigaben, Protokollierung — die drei Bausteine

Ein Governance-Rahmen für KI-generierte Fachabteilungs-Software braucht drei Bausteine, unabhängig vom eingesetzten Tool.

Rollen — wer darf bauen, wer muss freigeben:

  • Ersteller (Fachabteilung): definiert den Bedarf, testet die Anwendung im eigenen Kontext
  • Freigabe-Instanz (IT/Governance): bewertet Risikostufe, Datenzugriff, Integrationstiefe
  • Eskalationsrolle: bei hohem Risiko — personenbezogene Daten, automatisierte Entscheidungen — zusätzliche Freigabe durch Management oder Datenschutz

Freigaben — nicht jede Anwendung braucht dieselbe Prüftiefe:

  • Niedriges Risiko (kein Personenbezug, interne Nutzung): dokumentieren, nicht zwingend freigeben lassen
  • Mittleres Risiko (Personenbezug ohne automatisierte Entscheidung): IT-Review vor Livegang
  • Hohes Risiko (automatisierte Entscheidung, sensible Daten): formales Sign-off vor Livegang, nicht danach

Protokollierung — wer hat was wann gebaut, mit welchen Daten, wer hat freigegeben:

Das ist keine Kür. Es ist die Grundlage sowohl für die Dokumentationspflichten des AI Act als auch für die interne Nachvollziehbarkeit, wenn eine Anwendung Monate später geprüft wird.

Wie ein Freigabe-Protokoll aussehen kann

In der Praxis reicht oft ein einfacher, strukturierter Datensatz pro Anwendung — kein aufwendiges neues System, sondern ein Pflichtfeld-Set, das bei jeder neuen Fachabteilungs-Anwendung ausgefüllt wird:

```json
{
"anwendung": "urlaubsplaner-vertrieb",
"erstellt_von": "fachabteilung:vertrieb",
"verarbeitet_personenbezogene_daten": true,
"risikostufe": "mittel",
"freigabe_erforderlich": true,
"freigegeben_von": "it-governance",
"freigegeben_am": "2026-08-20T09:12:00+02:00"
}
```

Dieses Muster — Rolle, Risikostufe, Freigabe, Zeitstempel — ist unabhängig vom Tool. Entscheidend ist nicht die Software dahinter, sondern dass diese Angaben für jede Anwendung existieren, bevor sie produktiv geht. Genau diese Logik — eine Freigabe-Instanz, bevor eine Anwendung live geht, nicht danach — ist auch der Kern strukturierter Build-Prozesse: Jede Stufe von der Anforderung bis zum Betrieb hat einen Punkt, an dem eine Person entscheidet, nicht nur ein System.

Checkliste: Governance-Rahmen vor dem ersten Fachabteilungs-Projekt

  1. Rollen schriftlich festlegen wer baut, wer gibt frei, wer eskaliert
  2. Risikostufen definieren, bevor das erste Projekt startet, nicht danach
  3. Freigabe-Pflicht an die Risikostufe koppeln, nicht an die Abteilung
  4. Protokollierung von Anfang an mitdenken, nicht nachträglich einführen
  5. Regelmäßige Bestandsaufnahme: welche Fachabteilungs-Anwendungen laufen aktuell, mit welchem Datenzugriff
  6. AI-Act-Einordnung pro Anwendung prüfen: Verarbeitet sie personenbezogene Daten, unterstützt sie automatisierte Entscheidungen, fällt sie unter eine Hochrisiko-Kategorie?

Ein Unternehmen, das diese sechs Punkte vor dem ersten Fachabteilungs-Projekt klärt, verhindert nicht Eigenentwicklung es macht sie sichtbar, bevor sie zum Problem wird.

Weiterführend: KI-Einsatz im Unternehmen dokumentieren. So bleibt das Board regresssicher, KI-Compliance für Geschäftsführer: Haftung, Dokumentation, Audit Trail, EU AI Act für den Mittelstand: Was ab 2026 wirklich gilt