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?

In der KPMG-Studie Shaping digital transformation with low-code platforms (Erhebung 2022, 715 Unternehmen in Europa, Nahost und Afrika) haben nur 31 Prozent derjenigen, die Low-Code bereits einsetzen, dafür Richtlinien und eine definierte Governance. 65 Prozent haben keine definierte Governance (Abbildung 8, S. 23). Die Zahlen sind von 2022, nicht von heute. 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, allerdings nicht pauschal. Die Verbote gelten seit dem 2. Februar 2025, die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025, die Transparenzpflichten seit dem 2. August 2026; die Digital-Omnibus-Verordnung (EU) 2026/1744 hat die Fristen für Hochrisiko-Systeme nach Anhang III auf Dezember 2027 und nach Anhang I auf August 2028 verschoben.

Wichtig für die Einordnung: Eine Anwendung fällt nicht deshalb unter die Verordnung, weil KI beim Bauen geholfen hat. KI-generierter Programmcode ist kein KI-System. Entscheidend ist, ob das laufende System selbst die Merkmale eines KI-Systems nach Art. 3 EU AI Act erfüllt. Eine von einer Fachabteilung gebaute Anwendung, die etwa Personalentscheidungen KI-gestützt unterstützt, kann in den Geltungsbereich fallen, unabhängig davon, wer sie gebaut hat. Eine klassische Anwendung, deren Code mit KI-Hilfe entstand, fällt nicht deshalb darunter.

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?"

Die drei Bausteine eines Governance-Rahmens: Rollen, Freigaben, Protokollierung

Ein Governance-Rahmen für selbstgebaute 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. Die folgenden drei Stufen sind eine interne Freigabesystematik, die wir empfehlen. Sie sind ausdrücklich nicht die Risikoklassen des EU AI Act: Ein System kann intern „niedriges Risiko" sein und trotzdem unter die Transparenzpflichten fallen, oder umgekehrt intern eine hohe Freigabestufe brauchen, ohne dass die Verordnung überhaupt greift. Beide Einordnungen werden getrennt geführt und getrennt dokumentiert.

  • 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 für die Nachweise, die du für Dokumentationspflichten brauchst, und für die interne Nachvollziehbarkeit, wenn eine Anwendung Monate später geprüft wird. Die Pflichten selbst (Rollenklärung, Einstufung, Kompetenzmaßnahmen) erfüllt ein Protokoll nicht; es belegt, was passiert ist.

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:

{
  "anwendung": "urlaubsplaner-vertrieb",
  "erstellt_von": "fachabteilung:vertrieb",
  "ist_ki_system": false,
  "verarbeitet_personenbezogene_daten": true,
  "interne_risikostufe": "mittel",
  "ai_act_einordnung": "kein KI-System, Begründung: Art. 3",
  "freigabe_erforderlich": true,
  "freigegeben_von": "it-governance",
  "freigegeben_am": "2026-08-20T09:12:00+02:00"
}

Zwei Felder sind dabei bewusst getrennt: interne_risikostufe steuert deinen Freigabeprozess, ai_act_einordnung hält die gesetzliche Bewertung fest. Wer beides in ein Feld schreibt, verliert genau die Unterscheidung, auf die es im Prüfungsfall ankommt.

Dieses Muster (Rolle, Risikostufe, Einordnung, 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

  • Rollen schriftlich festlegen: wer baut, wer gibt frei, wer eskaliert
  • Interne Risikostufen definieren, bevor das erste Projekt startet, nicht danach
  • Freigabe-Pflicht an die Risikostufe koppeln, nicht an die Abteilung
  • Protokollierung von Anfang an mitdenken, nicht nachträglich einführen
  • Regelmäßige Bestandsaufnahme: welche Fachabteilungs-Anwendungen laufen aktuell, mit welchem Datenzugriff
  • AI-Act-Einordnung pro Anwendung in zwei Schritten prüfen: Erstens: Ist das überhaupt ein KI-System nach Art. 3? Wenn nein, endet die Prüfung hier; Datenschutz und IT-Sicherheit gelten trotzdem. Zweitens, wenn ja: Verarbeitet es personenbezogene Daten, unterstützt es automatisierte Entscheidungen, fällt es unter eine Hochrisiko-Kategorie nach Art. 6?

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

Weiterlesen im Wissen-Hub