Der Fachbereich hat längst eine App gebaut, die IT hat sie noch nicht gesehen

01

Die App ist schon da, bevor die IT sie kennt

Der Einkauf hat mit einem KI-Werkzeug eine kleine Webanwendung für Lieferantenbewertungen gebaut. Der Vertrieb hat aus einer Tabelle ein Angebotswerkzeug wachsen lassen, Schritt für Schritt, über Monate. Beides läuft seit Wochen. Beides spart Zeit. Und die IT hat davon nichts gewusst, bis eine E-Mail kam: können wir das übernehmen?

Diese Reihenfolge ist inzwischen normal, nicht die Ausnahme. KI-gestützte Entwicklungswerkzeuge und Low-Code-Plattformen haben die Schwelle zum eigenen Bauen so weit gesenkt, dass ein Fachbereich eine funktionierende Anwendung fertigstellt, bevor ein IT-Projekt dafür überhaupt hätte anlaufen können. Der Übergang von diesem Werkzeug zu einer betreibbaren Anwendung ist das Thema der Reihe Vom Prototyp zur produktionsreifen Anwendung.

Dieser Beitrag nimmt die Perspektive der IT-Leitung ein, die jetzt entscheiden soll. Er unterstellt nichts Falsches. Ein Fachbereich baut für seinen Zweck, die IT prüft für den Betrieb, und beide Blickwinkel sind berechtigt. Ob die App mit Lovable, Power Apps, n8n oder von Hand entstanden ist, ändert die sechs Prüffelder kaum. Nur wie leicht die Antworten zu finden sind, ändert sich deutlich.

02

Ist das automatisch Schatten-IT?

Formal ja, solange die Anwendung außerhalb der vereinbarten IT-Prozesse betrieben wird. Für die Entscheidung selbst ist eine zweite Lesart brauchbarer: Die App zeigt einen Bedarf, den die bestehende IT-Landschaft nicht gedeckt hat, und sie beschreibt ihn genauer als ein Lastenheft, weil sie bereits im Arbeitsalltag benutzt wird.

Schatten-IT entsteht selten aus Trotz. Fast immer entsteht sie aus Zeitdruck: ein Prozess braucht schneller Unterstützung, als ein Projekt sie liefern kann, und die Werkzeuge dafür sind leicht zugänglich geworden. Wer die App nur als Risiko behandelt, verliert genau die Information, die in ihr steckt, nämlich welche Felder wirklich gebraucht werden, welche Ausnahmen der Prozess kennt und welche Systeme angebunden sein müssten. Eine Abschaltung ohne Ersatz löst das Problem selten. Sie verschiebt es an einen Ort, den die IT noch weniger sieht.

03

Was die IT vor der Freigabe wirklich verlangt

In unseren Projekten sehen wir fast immer dieselbe erste Frage, egal wie die App entstanden ist: wer wird angerufen, wenn sie am Montagmorgen nicht erreichbar ist. Nicht der Code. Nicht die Optik. Die Frage nach der Person, die dafür geradesteht. Solange die Antwort nur ein Name ohne Vertretung ist, hängt der ganze Betrieb an dessen Urlaub und Verbleib im Unternehmen.

Betriebsverantwortung und Schnittstellen

Bei Schnittstellen hilft ein einfacher Test: Lassen Sie sich zeigen, mit welchen Zugängen die App andere Systeme erreicht. Persönliche Zugänge zu einem ERP-System sind ein häufiger Fund. Ein privates Konto bei einem KI-Anbieter ebenso. Beides lässt sich vor der Freigabe auf technische Konten umstellen, das ist reine Fleißarbeit, keine Neuentwicklung.

Berechtigungen und Datenklassen

Schnell gebaute Anwendungen steuern Rechte oft nur über die Oberfläche. Die Schaltfläche fehlt, die Daten sind trotzdem abrufbar. Ein Prüfschritt ohne Werkzeug: mit einem Konto mit wenig Rechten anmelden und die Adresse einer fremden Detailseite direkt aufrufen. Im IT-Grundschutz-Kompendium des BSI (Edition 2023) beschreibt der Baustein ORP.4 das Identitäts- und Berechtigungsmanagement, an dem sich diese Prüfung orientieren kann.

Für die Datenklassen reicht zunächst eine Einordnung, die viele IT-Abteilungen schon kennen. Der BSI-Standard 200-2 (BSI, 2017) unterscheidet drei Schutzbedarfskategorien: „normal“ mit begrenzten und überschaubaren Schadensauswirkungen, „hoch“ mit beträchtlichen, „sehr hoch“ mit existenziell bedrohlichen Auswirkungen. Die Kategorie bestimmt, wie streng die übrigen Punkte ausgelegt werden. Eine Raumbuchung und eine App mit Bewerberdaten brauchen nicht dieselbe Prüftiefe. Datenschutzfragen im Detail behandelt die Seite zu DSGVO-konformer KI.

Wiederanlauf und Ansprechpartner

Zwei Begriffe aus dem BSI-Standard 200-4 (BSI, 2023) helfen beim Wiederanlauf: die geforderte Wiederanlaufzeit (RTO), also wie lange die Anwendung ausfallen darf, und der maximal zulässige Datenverlust (RPO), also wie alt zurückgespielte Daten höchstens sein dürfen. Beide Werte legt der Fachbereich fest, weil nur er die Folgen kennt. Die IT prüft, ob Sicherung und Anleitung diese Werte erreichen. Der Baustein CON.3 im IT-Grundschutz-Kompendium (BSI, Edition 2023) verlangt dafür Tests, ob gesicherte Daten in angemessener Zeit zurückgespielt werden können. Ansprechpartner werden als Rollen festgehalten, nicht als Namen, damit die Übergabe einen Personalwechsel übersteht.

04

Was muss vor der Freigabe stehen, was kann folgen?

Vor der Freigabe muss geklärt sein, was bei einem Fehler Daten offenlegt, verfälscht oder unwiederbringlich verliert: serverseitige Berechtigungen, Zugangsdaten außerhalb des Codes, eine erprobte Sicherung, eine benannte Betriebsverantwortung. Nachziehen lässt sich, was den Betrieb mühsamer macht, aber nicht gefährlicher, etwa Automatisierung, feinere Überwachung und Dokumentationstiefe.

Die Grenze verschiebt sich mit dem Schutzbedarf. Bei der Kategorie „sehr hoch“ wandern Punkte aus der mittleren Spalte nach links, etwa die Protokollierung von Rechteänderungen. Bei normalem Schutzbedarf und kleinem Nutzerkreis ist eine Freigabe mit schriftlichen Auflagen oft der ehrlichere Weg als eine lange Warteschleife, in der die App ohnehin weiterläuft.

05

Ein Übergabedokument hat acht Kapitel, kein Formular

Der häufigste Fehler bei Übergabedokumenten ist ihre Form. Ein umfangreiches Formular erzeugt Pflegeaufwand, veraltet unbemerkt und wird deshalb irgendwann nicht mehr gelesen. Tragfähiger ist eine kurze Textdatei im Repository: Sie wird mit der Anwendung versioniert, und eine Änderung am Betrieb fällt dort auf, wo auch der Code geändert wird. Acht Kapitel reichen.

1. Zweck und Nutzerkreis: welches Problem die Anwendung löst, für wen, und was ausdrücklich nicht zu ihrem Zweck gehört.
2. Verantwortung: fachliche Verantwortung, Betriebsverantwortung und Vertretung, jeweils als Rolle.
3. Betriebsort und Komponenten: wo die Anwendung läuft, woraus sie besteht und welche externen Dienste sie nutzt.
4. Schnittstellen und Datenflüsse: welche Daten aus welchen Systemen kommen und wohin sie gehen, mit Art des Zugangs.
5. Datenklassen und Schutzbedarf: Einordnung nach Vertraulichkeit, Integrität und Verfügbarkeit, mit einem Satz Begründung.
6. Berechtigungen: Rollen, Anbindung an die Nutzerverwaltung, Umgang mit Austritten.
7. Sicherung und Wiederanlauf: RTO und RPO, Sicherungsweg, Datum der letzten erprobten Wiederherstellung, Kurzanleitung für den Neustart.
8. Offene Punkte und Auflagen: was bewusst nach der Freigabe nachgezogen wird, mit zuständiger Rolle.

Das Dokument ist eine Entscheidungsgrundlage, keine vollständige technische Dokumentation. Welche Artefakte für den dauerhaften Regelbetrieb zusätzlich entstehen, etwa Architekturbeschreibung und Datenmodell mit Migrationshistorie, beschreibt der Beitrag Vom Proof of Concept in den Regelbetrieb.

06

Wie läuft das Übernahmegespräch ab?

In unseren Projekten haben wir festgestellt, dass das Gespräch besser läuft, wenn es als gemeinsame Bestandsaufnahme angelegt ist und nicht als Prüfung, die der Fachbereich bestehen muss. Die Person, die die Anwendung gebaut hat, kennt ihre Schwächen meist genau. Sie benennt sie auch offen, sobald klar ist, dass daraus kein Nachteil entsteht.

Beim Schritt „Weg festlegen“ gibt es drei ehrliche Optionen. Die IT übernimmt die Anwendung in den eigenen Betrieb. Oder der Fachbereich betreibt sie weiter, aber innerhalb von Leitplanken, die die IT setzt, etwa zentrale Anmeldung und ein vorgegebener Betriebsort. Oder die App dient als ausführbare Anforderung, und die eigentliche Lösung wird neu gebaut. Diese dritte Option ist kein Scheitern. Die App hat dann ihren Zweck als Prototyp erfüllt, mehr war nie verlangt.

Was der Dauerbetrieb anschließend verlangt, von Überwachung bis Aktualisierung, beschreibt Eine Anwendung im eigenen Haus betreiben. Kommen Fragen zu Haftung oder Regulierung auf, ordnet Wer haftet, wenn KI-generierter Code Schaden anrichtet? die Rechtslage ein.

iiterate Technologies GmbH aus Adenau entwickelt Individualsoftware und KI-Anwendungen von der Architektur über die Umsetzung bis zum Betrieb, mit Übergabe von Quellcode und Dokumentation (Leistungen).