Der Einwand kommt immer an derselben Stelle. Man beschreibt, wie eine Fachabteilung sich ihre Anwendung selbst baut: ohne IT-Ticket, ohne Entwickler, in Tagen statt Monaten. Und der IT-Leiter im Raum sagt: „Das ist Schatten-IT."

Er hat recht. Und er hat unrecht. Beides hängt an sechs Festlegungen, die vorher getroffen werden, oder eben nicht.

Technisch ist Schatten-IT nicht von gesteuerter Eigenentwicklung zu unterscheiden. Dieselbe Anwendung, dasselbe Werkzeug, dieselben Daten. Der Unterschied entsteht ausschließlich dadurch, ob jemand vorher Regeln aufgeschrieben hat, und ob sie eingehalten werden.

Beide Varianten unterscheiden sich in sechs Punkten.

Wer davon weiß. Bei Schatten-IT niemand in der IT. Bei gesteuerter Eigenentwicklung kennt die IT jede Anwendung.

Datenzugriff. Schatten-IT greift auf so viel zu, wie technisch möglich ist. Gesteuerte Eigenentwicklung auf festgelegte Datenklassen.

Freigabe. Bei Schatten-IT keine. Bei gesteuerter Eigenentwicklung eine definierte Schwelle.

Protokollierung. Bei Schatten-IT keine. Bei gesteuerter Eigenentwicklung ab Inbetriebnahme.

Zuständigkeit. Bei Schatten-IT der, der es gebaut hat. Bei gesteuerter Eigenentwicklung ein benannter Eigentümer plus Vertretung.

Wenn die Person geht. Bei Schatten-IT wird die Anwendung zum Rätsel. Bei gesteuerter Eigenentwicklung ist die Übergabe geregelt.

Und die unbequeme Zahl dazu: In der KPMG-Studie Shaping digital transformation with low-code platforms (Erhebung 2022, 715 Unternehmen ab 50 Mitarbeitenden in Europa, Nahost und Afrika) haben 73 Prozent der Low-Code-Planer und 65 Prozent der aktiven Nutzer keine definierte Governance. Ein Teil davon hat immerhin Richtlinien, aber keine verbindliche Governance dahinter, ein Teil hat gar nichts (Abbildung 8, S. 23). Die Zahlen sind von 2022, nicht von heute. Die Richtung ist trotzdem eindeutig: Die Anwendungen entstehen längst, die Regeln fehlen.

Was sich am 2. August 2026 geändert hat

Bis vor Kurzem war Schatten-IT ein Sicherheitsthema. Ein Tool, von dem die IT nichts weiß, kann Daten abfließen lassen, es kann ausfallen, und niemand kann es warten.

Seit dem 2. August 2026 kommt eine zweite Ebene dazu, allerdings nicht pauschal. Zuerst ist zu klären, ob die selbstgebaute Anwendung überhaupt ein KI-System nach Art. 3 EU AI Act ist. Dass beim Bauen ein Sprachmodell geholfen hat, genügt dafür nicht: KI-generierter Programmcode ist kein KI-System. Enthält die laufende Anwendung dagegen selbst KI-Funktionen (ein Modell, das klassifiziert, bewertet oder Inhalte erzeugt), dann bist du Betreiber. Sie gehört in dein internes KI-Inventar, sie braucht eine Einstufung, und wer sie bedient, fällt unter die Kompetenzpflicht aus Artikel 4.

Zwei Abgrenzungen, die dabei regelmäßig durcheinandergehen:

Internes Inventar ist keine EU-Registrierung. Die Eintragung in die EU-Datenbank nach Art. 49 obliegt Anbietern und behördlichen Betreibern. Dein Inventar ist eine betriebliche Übersicht: notwendig für jede Einstufung, aber etwas anderes.

Fine-Tuning macht dich nicht automatisch zum Anbieter. Ein Rollenwechsel nach Art. 25 kann insbesondere vorliegen, wenn ein bereits angebotenes oder eingesetztes Hochrisiko-System unter die eigene Marke gestellt oder wesentlich verändert wird und hochriskant bleibt, oder wenn eine geänderte Zweckbestimmung ein bislang nicht hochriskantes System zum Hochrisiko-System macht. Das kann in einer Fachabteilung passieren, ohne dass jemand es merkt. Fine-Tuning allein genügt für diese Einordnung aber nicht.

Genau die Anwendungen, die niemand kennt, fehlen bei einer Prüfung. Sie stehen in keiner Lizenzliste, in keinem IT-Asset-Register, und niemand hat sie je eingeordnet.

Die sechs Regeln

Jede davon ist eine Entscheidung, die jemand treffen muss. Es gibt keine richtige Antwort für alle Unternehmen, aber für jede Frage eine Antwort, die aufgeschrieben sein muss. Und eine Vorbemerkung, die den Unterschied macht: Aufgeschriebene Regeln allein ändern nichts. Erst ihre Umsetzung (die Liste wird gepflegt, die Freigabe wird tatsächlich eingeholt, das Register wird tatsächlich befüllt) trennt gesteuerte Eigenentwicklung von Schatten-IT mit Dokument.

1. Wer bauen darf. Nicht „alle" und nicht „niemand". Benannte Personen je Abteilung, nicht Rollen. Sobald es „jeder im Vertrieb" heißt, ist am Ende niemand zuständig. Eine Liste mit Namen, die auf eine Seite passt und regelmäßig aktualisiert wird.

2. Auf welche Daten. Klassifiziere Daten, nicht Systeme. Drei Klassen reichen: frei, intern, geschützt. In die geschützte Klasse gehören Personendaten, Preise, Verträge, Kalkulationsgrundlagen. Selbstbau ohne Freigabe nur auf den ersten beiden Klassen. Das erledigt die meisten Risiken, ohne die Geschwindigkeit zu nehmen.

3. Ab wann Freigabe nötig ist. Wenn jede Anwendung freigegeben werden muss, ist das Programm nach vier Wochen tot, und die Leute bauen wieder heimlich. Setze eine Schwelle: Freigabe braucht, was Personendaten verarbeitet, was externe Nutzer erreicht, oder was Geld bewegt. Alles andere wird gebaut und danach registriert.

4. Was protokolliert wird. Wer hat wann was auf welcher Grundlage entschieden. Ein Protokoll lässt sich nicht nachrüsten: Die Ereignisse, die es festhalten soll, sind dann bereits vorbei. Am ersten Tag kostet es fast nichts, nach zwei Jahren Betrieb ist es nicht mehr herstellbar.

5. Wem die Anwendung gehört, wenn der Erbauer geht. Jede Anwendung bekommt einen benannten Eigentümer und eine benannte Vertretung. Das ist dieselbe Mechanik, die Prozesswissen an Personen bindet statt an das Unternehmen, nur schneller, weil eine Anwendung im Gegensatz zu einem Prozess von heute auf morgen stehen bleibt.

6. Was ins KI-Inventar kommt. Jede selbstgebaute Anwendung, die tatsächlich KI-Funktionen enthält, mit Einstufung und Rolle. Das ist kein zusätzliches Projekt. Es ist eine Zeile in dem Inventar, das du für den AI Act ohnehin führst. Der Unterschied ist nur, ob die Zeile entsteht, wenn die Anwendung gebaut wird, oder wenn jemand danach fragt.

Warum Verbieten die schlechtere Option ist

Die naheliegende Reaktion auf all das ist ein Verbot. Sie funktioniert nicht, und zwar aus einem strukturellen Grund: Der Bedarf verschwindet nicht, wenn du die Antwort darauf verbietest.

Die Fachabteilung hat ein Problem, für das die IT-Roadmap zwölf Monate vorsieht. Wird der Selbstbau verboten, wird das Problem trotzdem gelöst: in einer Excel-Datei mit Makros, in einem privaten Automatisierungskonto, in einem Tool, das jemand mit der Firmenkreditkarte abonniert hat.

Der Unterschied zum Selbstbau mit Regeln ist nicht, dass weniger entsteht. Es ist, dass du nichts davon siehst. Verbieten produziert exakt die Schatten-IT, die es verhindern soll, nur ohne Protokollierung und ohne Inventar.

Das Regelwerk passt auf eine Seite

Wenn du die sechs Fragen beantwortest, hast du ein Dokument, das kürzer ist als die meisten Betriebsvereinbarungen und mehr bewirkt als die meisten IT-Richtlinien:

  • Diese Personen dürfen bauen: …
  • Diese Datenklassen sind ohne Freigabe erlaubt: …
  • Freigabe braucht, was …
  • Protokolliert wird: …
  • Eigentümer und Vertretung stehen in: …
  • Ins KI-Inventar kommt: …

Mehr ist es nicht. Und mit diesem Blatt in der Hand ist die Antwort auf „das ist doch Schatten-IT" nicht mehr eine Meinung, sondern ein Dokument, vorausgesetzt, das Blatt wird auch gelebt.

Wie AthenaRun das löst

Die sechs Regeln sind einfacher durchzuhalten, wenn die Plattform sie nicht dem Wohlwollen der Nutzer überlässt. Wir bauen Anwendungen so, dass Rollen und Rechte von Anfang an Teil der Anwendung sind statt einer nachträglichen Einstellung, und dass die KI-gestützten Verarbeitungsschritte protokolliert werden. Gehostet in der EU; ein Betrieb auf deinen eigenen Servern ist im Projekt zu klären.

Das unterstützt dich bei den Regeln 2, 4 und 6. Es ersetzt sie nicht: Welche Datenklassen erlaubt sind, was protokolliert werden muss und was ins Inventar kommt, bleibt deine Festlegung. Und die Regeln 1, 3 und 5 kann ohnehin keine Software für dich treffen.


Weiterlesen im Wissen-Hub

Wer nach dem Governance-Rahmen mit Rollen, Freigaben und Protokollierung sucht: KI-Governance im Unternehmen. Und warum Wissen mit Personen aus dem Unternehmen verschwindet, liest du in Wissen vor dem Ruhestand sichern.