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.
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: Laut einer KPMG-Befragung unter 715 Unternehmen in EMEA haben 73 % der Low-Code-Planer und 65 % der aktiven Nutzer noch keine Governance-Regeln definiert. Die Anwendungen entstehen also 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. Enthält die selbstgebaute Anwendung eine KI-Komponente — und das tun heute die meisten — ist sie ein KI-System im Sinne des EU AI Act. Du bist Betreiber. Sie gehört ins KI-Inventar, sie braucht eine Risikoklassifizierung, und wer sie bedient, fällt unter die Kompetenzpflicht aus Artikel 4.
Der Punkt, der dabei am häufigsten übersehen wird: Wer ein zugekauftes Modell auf eigenen Daten feintuned und intern einsetzt, wechselt von der Betreiber- in die Anbieterrolle — mit deutlich weiteren Pflichten. Das kann in einer Fachabteilung passieren, ohne dass jemand es merkt.
Genau diese Anwendungen fehlen bei einer Prüfung. Sie stehen in keiner Lizenzliste, in keinem IT-Asset-Register, und niemand hat sie je klassifiziert.
Die sechs Regeln
Jede davon ist eine Entscheidung, die jemand treffen muss. Es gibt keine richtige Antwort für alle Unternehmen — aber es gibt für jede Frage eine Antwort, die aufgeschrieben sein muss.
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 einmal im Quartal 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 Audit-Trail lässt sich nicht nachrüsten — die Ereignisse, die er festhalten soll, sind dann bereits vorbei. Am ersten Tag kostet er fast nichts, nach zwei Jahren Betrieb ist er 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-Register kommt.
Jede selbstgebaute Anwendung mit KI-Anteil, mit Risikoklasse und Rolle. Das ist kein zusätzliches Projekt — es ist eine Zeile in dem Register, das du für den AI Act ohnehin führen musst. 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 Register.
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-Register 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.
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 Teil der generierten Anwendung sind, nicht eine nachträgliche Einstellung — und dass jeder KI-gestützte Rechenschritt im Audit-Trail steht. Gehostet in der EU, wahlweise auf euren eigenen Servern.
Damit entstehen Regel 2, 4 und 6 aus dem laufenden Betrieb heraus, statt als separates Compliance-Projekt. Die Regeln 1, 3 und 5 bleiben eure Entscheidung — die kann keine Software für euch treffen.
Weiterlesen im Wissen-Hub
Was seit dem 2. August gilt und womit du anfängst, wenn bei dir noch nichts steht, steht im EU AI Act Readiness-Artikel. Die Risikoklassen und den Unterschied zwischen Anbieter und Betreiber erklärt EU AI Act für den Mittelstand. Und warum Wissen mit Personen aus dem Unternehmen verschwindet, liest du in Wenn Herr Müller in Rente geht.