KI-gebaute interne Tools werden zu Shadow IT

KI macht es deutlich leichter, kleine interne Tools zu bauen.

Das ist wirklich nützlich. Ein Team kann ein Dashboard, ein Admin-Panel, einen Helfer für Datenbereinigung, einen Freigabe-Workflow, eine Reporting-Ansicht, ein CRM-Tool, eine Dokumentenzusammenfassung oder eine Support-Triage in Tagen statt Monaten bauen. Manchmal in Stunden.

Für Gründer, Operations-Teams und Produktteams ist diese Geschwindigkeit attraktiv, weil interne Tools oft dort fehlen, wo Unternehmen täglich Zeit verlieren. Daten werden zwischen Systemen kopiert. Reports entstehen manuell. Support-Teams wiederholen dieselben Prüfungen. Operations-Teams leben in Tabellen, die eigentlich längst Software hätten werden sollen.

KI-gestützte Entwicklung kann dabei helfen.

Die aktuelle Diskussion rund um Vibe Coding und KI-generierte Apps zeigt aber auch die andere Seite: fehlende Authentifizierung, offengelegte Keys, schwache Berechtigungen, anfällige Dependencies, keine Rate Limits, kein Audit Trail, keine Ownership und kein sauberer Weg vom Prototypen in Produktion.

Das Problem ist nicht, dass Teams interne Tools mit KI bauen.

Das Problem ist, dass nützliche interne Tools zu Produktionssystemen werden können, bevor jemand sie wie Produktionssysteme behandelt.

Das ist Shadow IT mit schnellerer Entstehung.

Das Tool beginnt klein

Shadow IT beginnt selten als leichtsinnige Entscheidung.

Sie beginnt mit einem echten Geschäftsproblem.

Jemand braucht eine bessere Möglichkeit, Kundendaten zu prüfen. Jemand muss Rechnungen abgleichen. Jemand will Support-Nachrichten zusammenfassen. Jemand braucht ein Dashboard, das das Hauptprodukt nicht bietet. Jemand möchte nicht jeden Freitag denselben CSV-Export vorbereiten.

Vor KI war die Lösung vielleicht eine Tabelle, ein No-Code-Tool, ein geteiltes Skript oder ein privater SaaS-Account. Heute kann daraus eine kleine Web-App werden, erzeugt mit einem KI-Coding-Tool.

Am Anfang kann das sehr sinnvoll sein. Das Team lernt schneller. Der Prozess verbessert sich. Menschen warten nicht mehr darauf, dass jede operative Reibung irgendwann auf der Produkt-Roadmap landet.

Dann wird das Tool erneut genutzt.

Und erneut.

Jemand ergänzt einen echten Kundendatenexport. Jemand verbindet eine Datenbank. Jemand baut einen Login ein. Jemand teilt die URL mit einem anderen Team. Jemand nutzt das Tool für einen Monatsreport. Jemand baut einen zweiten Workflow auf dem ersten auf.

Ab diesem Punkt ist das Tool kein Experiment mehr.

Es ist Teil des Geschäftsprozesses.

Intern heißt nicht risikoarm

Interne Tools wirken oft sicherer als kundenseitige Produkte, weil sie nicht öffentlich sind.

Das stimmt nur teilweise.

Interne Tools berühren häufig die sensibelsten Bereiche eines Unternehmens: Kundendaten, Abrechnungsdaten, operative Logs, Mitarbeiterinformationen, Support-Nachrichten, Verträge, Analytics und administrative Aktionen. Eine öffentliche Marketingseite kann weniger riskant sein als ein privates Admin-Tool, das Kundendaten exportieren oder Account-Status ändern kann.

Typische Fehler sind sehr praktisch:

• ein Tool nutzt einen geteilten Admin-Zugang statt einer eigenen Service-Identität;
• eine API-Route prüft, ob jemand eingeloggt ist, aber nicht, ob diese Person den Datensatz sehen darf;
• eine Datenbankabfrage hat keine Mandantengrenze;
• eine Environment-Datei wird ins Repository kopiert;
• eine generierte Dependency bringt bekannte Schwachstellen mit;
• ein Button führt eine echte Aktion ohne Bestätigung, Log oder Rollback aus;
• niemand weiß, wer das Tool repariert, wenn es kaputtgeht.

Das sind keine exotischen KI-Fehler. Es sind normale Softwarefehler, nur schneller und mit weniger Reibung erzeugt.

Deshalb brauchen KI-gebaute interne Tools einen Weg in die Governance. Keine schwere Kommission. Einen praktischen Weg.

Interne Tools als eigene Asset-Klasse behandeln

Der erste Schritt ist, die Kategorie ernst zu nehmen.

Ein KI-gebautes internes Tool ist nicht mehr “nur ein Skript”, sobald Menschen sich darauf verlassen. Es ist ein operatives Asset. Es verdient eine schlanke Version derselben Überlegungen, die auch für andere Unternehmenssoftware gelten.

Das beginnt mit einem Inventar.

Für jedes Tool sollte ein Unternehmen wissen:

• welchen Geschäftsprozess es unterstützt;
• wem es gehört;
• wer es nutzt;
• welche Daten es liest;
• welche Systeme es ändern kann;
• welche Credentials es verwendet;
• wo es betrieben wird;
• wie Zugriff vergeben und entzogen wird;
• was protokolliert wird;
• wie es getestet wird;
• was bei Ausfall passiert;
• ob es behalten, neu gebaut, in ein Kernsystem integriert oder abgeschaltet werden sollte.

Das muss nicht kompliziert sein. Ein einfaches internes Register ist bereits besser, als wichtige Tools erst durch einen Vorfall zu entdecken.

Es geht um Sichtbarkeit. Man kann Software nicht sichern, warten oder verbessern, wenn das Unternehmen nicht weiß, dass sie existiert.

Der Produktionscheck sollte leichtgewichtig sein

Die falsche Antwort wäre, jedes kleine Tool unter Enterprise-Prozess zu begraben.

Dann weichen Teams nur wieder auf private Workarounds aus.

Die bessere Antwort ist ein klarer, schlanker Produktionscheck. Wenn ein Tool echte Unternehmensdaten berührt, einen wiederkehrenden Prozess unterstützt oder von mehr als einer Person genutzt wird, sollte es ein paar Grundfragen bestehen, bevor es Teil der täglichen Arbeit wird.

Beginnen Sie mit Ownership. Jedes Tool braucht eine fachliche und eine technische Owner-Person. Die fachliche Owner-Person weiß, warum das Tool existiert. Die technische Owner-Person weiß, wie es funktioniert, wo es läuft und wie es sicher geändert wird.

Dann folgt die Datengrenze. Was ist die Quelle der Wahrheit? Liest das Tool Kundendaten, Mitarbeiterdaten, Finanzdaten, Verträge, Logs oder Credentials? Werden Daten exportiert oder kopiert? Braucht das Tool wirklich all diese Daten oder nur einen kleineren Ausschnitt?

Danach kommt der Zugriff. Interne Tools sollten nach Möglichkeit bestehende Identität nutzen. Sie sollten nicht auf geteilten Passwörtern, versteckten Admin-Accounts oder breiten persönlichen Tokens beruhen. Lesezugriff und Schreibzugriff sollten getrennt werden. Admin-Aktionen gehören nur zu Personen, die sie wirklich brauchen.

Dann braucht es Evidenz. Logs müssen nicht alles erfassen, aber wichtige Aktionen sollten nachvollziehbar sein. Wer hat das Tool genutzt? Was wurde geändert? Welche Quelldaten wurden verwendet? War Freigabe nötig? Ist etwas fehlgeschlagen?

Zum Schluss entscheidet das Team, wie das Tool gewartet wird. Welche Tests gibt es? Wie werden Dependencies aktualisiert? Wo liegt die Dokumentation? Wer reviewed Änderungen? Wann wird das Tool abgeschaltet, wenn es nicht mehr sinnvoll ist?

Das ist keine Bürokratie. So bleiben nützliche Tools nützlich.

KI verändert den Review

KI-generierter Code kann vollständig aussehen, bevor er produktionsreif ist.

Deshalb wird Review wichtiger, nicht unwichtiger. Ein Review sollte nicht nur fragen, ob die Oberfläche funktioniert. Er sollte fragen, ob das Tool ins Unternehmen passt.

Gute Review-Fragen sind:

• Nutzt das Tool die richtige Quelle der Wahrheit?
• Werden Berechtigungen in der Anwendung erzwungen, nicht nur im Prompt beschrieben?
• Liegen Secrets außerhalb der Codebase?
• Ist Mandanten- oder Kundentrennung explizit?
• Sind riskante Aktionen bestätigt, protokolliert und rückgängig machbar?
• Sind Fehler für Menschen sichtbar?
• Sind Dependencies akzeptabel und wartbar?
• Kann ein anderer Entwickler den Code nächsten Monat verstehen?
• Dupliziert das Tool einen Prozess, der eigentlich in ein bestehendes System gehört?

Hier werden viele KI-Adoptionsgespräche zu eng. Die Frage ist nicht nur, ob das KI-Tool eine funktionierende App erzeugen kann. Das kann es oft.

Die Frage ist, ob diese App im Unternehmen leben sollte.

Compliance folgt Architektur

Für deutsche und europäische Unternehmen ist die Compliance-Frage nicht abstrakt.

Interne Tools erzeugen oft genau die Nachweise, die später für Kunden, Audits, Steuerberatung, Security Reviews oder Management relevant werden. Wenn ein Tool Finance, Customer Operations, HR oder regulierte Abläufe unterstützt, muss das Unternehmen möglicherweise erklären können, wer was wann mit welchen Daten und unter welcher Freigabe getan hat.

Das ist schwer, wenn ein Tool schnell gebaut, irgendwo temporär gehostet, mit einem persönlichen Token verbunden und nie dokumentiert wurde.

Die praktische Lektion ist einfach: Fragen Sie nicht erst kurz vor dem Audit, ob ein internes Tool Nachweise hinterlässt.

Logging, Zugriffskontrolle, Datengrenzen und Aufbewahrung sind Architekturentscheidungen. Wenn sie früh entworfen werden, bleiben sie handhabbar. Wenn sie später angeklebt werden, werden sie teuer und unvollständig.

Ein guter Tool-Pfad erhält Geschwindigkeit

Das Ziel ist nicht, Teams auszubremsen.

Das Ziel ist, Geschwindigkeit wiederverwendbar zu machen.

Ein guter Pfad für interne Tools kann so aussehen:

1. Schnell mit KI prototypisieren.
2. Entscheiden, ob das Tool wegwerfbar, nützlich oder produktionsnah ist.
3. Bei Produktionsnähe Ownership vergeben.
4. Daten und Aktionen klassifizieren.
5. Secrets, Hosting und Zugriff in freigegebene Infrastruktur bringen.
6. Tests für wichtige Geschäftsregeln ergänzen.
7. Logs für relevante Aktionen einbauen.
8. Dokumentieren, wie das Tool funktioniert und wann es wieder abgeschaltet wird.
9. Das Tool nach echter Nutzung erneut prüfen.

So behalten Teams den besten Teil KI-gestützter Entwicklung: schnelles Lernen. Gleichzeitig vermeiden sie den schlechtesten Teil: eine wachsende Sammlung unsichtbarer Systeme, die niemand sicher warten kann.

Wo McDougall Digital hilft

McDougall Digital arbeitet mit Teams, die KI-Geschwindigkeit nutzen wollen, ohne Softwarechaos aufzubauen.

Bei internen Tools bedeutet das meist, gemeinsam zu entscheiden, welche Tools Prototypen bleiben sollten, welche zu unterstützter Unternehmenssoftware werden und welche besser in ein größeres Produkt oder eine Plattform integriert werden. Technisch kann es um Architekturreview, Authentifizierung, Berechtigungen, Datengrenzen, Testabdeckung, Deployment, Dokumentation und Wartbarkeitsarbeit gehen.

Entscheidend ist das Urteil über das Tool.

Manche KI-gebauten Tools sollten weggeworfen werden, nachdem sie dem Team etwas gezeigt haben. Manche sollten gehärtet werden, weil sie echte operative Zeit sparen. Manche zeigen, dass ein tieferes Produkt- oder Prozessproblem eine dauerhaftere Lösung braucht.

KI macht es leichter, interne Software zu erzeugen.

Architektur entscheidet, ob daraus ein Vorteil oder eine Belastung wird.