KI-Software braucht eine IT-Freigabe.
Planen Sie sie von Anfang an.

Wer mit KI individuelle Software entwickelt, sollte die IT vor dem ersten Prototyp einbeziehen. So lassen sich Anforderungen an Sicherheit, Integration und Wartung beim Bauen berücksichtigen. Automatische Prüfungen helfen dabei; die Verantwortung für die Freigabe bleibt bei den zuständigen Menschen.

Vom Angebotskonfigurator zur Anwendung im Betrieb

Nehmen wir ein fiktives Beispiel: Der Vertrieb eines mittelständischen Unternehmens möchte Angebote schneller erstellen. Eine Mitarbeiterin baut mit einem KI-Werkzeug ein Formular, das Artikel auswählt, Rabatte berechnet und ein Angebotsdokument erzeugt. Mit einigen Testfällen wirkt die Anwendung einsatzbereit.

Für den Alltag soll sie nun Kundenstammdaten abrufen und Angebote im ERP anlegen. Damit entstehen Fragen, die die Demo bisher nicht beantworten musste: Darf jeder Mitarbeiter alle Kunden sehen? Welche Rabattgrenzen gelten? Was passiert, wenn die Verbindung abbricht, nachdem das Angebot bereits gespeichert wurde?

Auch ein zweiter Klick auf „Angebot anlegen“ darf keinen doppelten Vorgang erzeugen. Solche Anforderungen sollten Fachbereich und IT vor der Umsetzung festhalten. Sonst müssen sie später Zugriffe, Datenhaltung oder den gesamten Ablauf umbauen.

Was „mit KI entwickelt“ eigentlich bedeutet

KI kann Code vorschlagen, Tests entwerfen oder bei der Fehlersuche helfen. Die fertige Anwendung muss deshalb kein Sprachmodell enthalten. Ein Angebotskonfigurator kann seine Preise nach festen Regeln berechnen, auch wenn Teile seines Codes mit KI entstanden sind.

Anders sieht es aus, wenn die Anwendung später selbst ein Modell nutzt, etwa um Freitextanfragen auszuwerten. Dann kommen Fragen zu den übermittelten Daten, zur Prüfung der Modellausgaben und zu erlaubten Aktionen hinzu. Diese Unterscheidung hilft, den Prüfaufwand passend zum tatsächlichen Einsatz zu planen. Für Anwendungen mit eigenständig handelnden Modellen finden Sie weitere Hinweise im Beitrag zu KI-Agenten und Sicherheit.

Die IT braucht Zeit und prüfbare Unterlagen

Eine IT-Abteilung kann den Quellcode einer unbekannten Anwendung nicht nebenbei vollständig bewerten. Ein kleines Team braucht einen vereinbarten Prüfauftrag, eine Beschreibung der Datenflüsse und nachvollziehbare Testergebnisse. Falls intern die Erfahrung mit Softwareprüfungen fehlt, gehört externe Unterstützung in den Projektplan.

Als fachliche Orientierung beschreibt das Secure Software Development Framework des NIST, wie sichere Entwicklungspraktiken in den gesamten Entwicklungsprozess eingebunden werden können. Für Webanwendungen liefert der OWASP Application Security Verification Standard Anforderungen, anhand derer technische Sicherheitskontrollen geprüft werden können. Den passenden Umfang legen die Verantwortlichen anhand der Anwendung und ihrer Risiken fest.

Fünf Vereinbarungen vor dem ersten Prototyp

1. Prozess und Erfolgskriterium festlegen. Beschreiben Sie, wer die Anwendung nutzt und welche Aufgabe sie übernimmt. Beim Angebotskonfigurator könnten Sie die Bearbeitungszeit und die Zahl nötiger Korrekturen vor und nach der Einführung vergleichen.
2. Daten und Zugriffe begrenzen. Legen Sie fest, welche Daten die Anwendung lesen oder ändern darf. Für den Prototyp eignen sich künstliche Testdaten; Zugangsdaten gehören in eine dafür vorgesehene Verwaltung außerhalb des Quellcodes.
3. Eine betreubare Umgebung wählen. Stimmen Sie Programmiersprache, Bibliotheken, Hosting und Schnittstellen mit den Personen ab, die später Updates einspielen und Störungen bearbeiten.
4. Abnahmekriterien vereinbaren. Halten Sie fachliche Regeln und Fehlerfälle schriftlich fest. Wer ohne Rabattfreigabe einen Grenzwert überschreitet, muss beispielsweise eine nachvollziehbare Ablehnung erhalten.
5. Verantwortung und Zeit einplanen. Benennen Sie Personen für fachliche Abnahme, technische Prüfung und Betrieb. Reservieren Sie dafür Arbeitszeit, bevor ein Einführungstermin zugesagt wird.

Was automatische Prüfungen leisten

Automatisierte Tests können nach Änderungen prüfen, ob Preisberechnungen weiterhin stimmen oder unzulässige Eingaben abgewiesen werden. Ergänzende Werkzeuge suchen nach bekannten Schwachstellen in verwendeten Bibliotheken oder nach versehentlich gespeicherten Zugangsdaten.

Eine grüne Anzeige bedeutet dabei, dass die ausgeführten Prüfungen bestanden wurden. Ungeprüfte Geschäftsregeln oder ungeeignete Berechtigungen können trotzdem bestehen bleiben. Besonders bei Preisänderungen, Datenexporten und schreibenden ERP-Zugriffen braucht es eine fachliche und technische Bewertung.

Für den Angebotskonfigurator empfiehlt sich außerdem ein Test mit unterbrochener ERP-Verbindung: Erkennt die Anwendung den unklaren Status, verhindert sie einen doppelten Auftrag und kann ein Mitarbeiter den Vorgang nachvollziehen? Erst solche Fälle zeigen, wie sich die Lösung außerhalb der Demo verhält.

Checkliste für die IT-Freigabe

Die folgende Liste ist ein Ausgangspunkt für ein kleines internes Werkzeug. Bei öffentlich erreichbaren Anwendungen oder besonders sensiblen Daten muss der Prüfplan entsprechend erweitert werden.

• Einsatzzweck, Nutzerkreis und Grenzen sind dokumentiert.
• Datenflüsse und Zugriffe sind nachvollziehbar; unerlaubte Zugriffe wurden getestet.
• Fachliche Regeln, Fehlerfälle und die Anbindung an bestehende Systeme wurden geprüft.
• Bekannte Sicherheitsbefunde sind behoben oder mit Begründung und Verantwortlichem bewertet.
• Quellcode, Abhängigkeiten und Installationsanleitung sind zugänglich und versioniert.
• Protokollierung, Sicherung und Wiederherstellung sind für den vorgesehenen Betrieb geprüft.
• Ein Rückweg zur vorherigen Version oder zum bisherigen Prozess ist beschrieben und erprobt.
• Betreuung, Update-Verfahren und die Entscheidung über den Produktivstart sind festgehalten.

Rechnen Sie bis zum laufenden Betrieb

Eine kurze Entwicklungszeit allein sagt wenig darüber aus, ob sich die Lösung lohnt. Vergleichen Sie den erwarteten Nutzen mit dem Aufwand für Planung, Entwicklung, Prüfung, Einführung und Betreuung. Interne Arbeitsstunden gehören genauso dazu wie Hosting oder mögliche Kosten für Modellaufrufe.

Rechnen Sie für einen vereinbarten Zeitraum, etwa das erste Betriebsjahr. Halten Sie die Annahmen schriftlich fest: Wie viele Vorgänge fallen an? Wie viel Zeit spart die Anwendung pro Vorgang? Wie viel Nacharbeit bleibt? Nach einer begrenzten Pilotphase können Sie die Annahmen mit beobachteten Werten ersetzen. Weitere Kostenpositionen beschreibt unser Beitrag zu den Kosten von KI-Automatisierung.

Für den Einstieg eignet sich ein abgegrenzter Prozess mit überschaubaren Folgen bei einem Fehler. Beim Angebotskonfigurator könnte die erste Version nur Entwürfe erzeugen, die ein Mitarbeiter kontrolliert. Schreibzugriffe auf das ERP folgen, wenn die Prüfungen und der Betrieb dafür vorbereitet sind.

Häufige Fragen

Wann sollte die IT bei KI-Software einbezogen werden?

Bereits bei der Auswahl des Prozesses, bevor der Prototyp Zugriff auf Unternehmensdaten erhält. Fachbereich und IT sollten Datenzugriffe, Betriebsumgebung, Verantwortliche und Abnahmekriterien gemeinsam festlegen.

Reichen automatische Tests für die IT-Freigabe?

Nein. Automatische Tests liefern Nachweise für die geprüften Fälle. Fachliche Regeln, Berechtigungen, die Eignung für den Einsatz und offene Risiken brauchen zusätzlich eine bewusste Bewertung durch die Verantwortlichen.

Muss mit KI entwickelte Software selbst KI enthalten?

Nein. KI kann bei der Entwicklung helfen, während die fertige Anwendung ohne Sprachmodell arbeitet. Wenn später ein Modell Unternehmensdaten verarbeitet oder Aktionen ausführt, muss auch dieser Einsatz geprüft werden.

Welche Kosten gehören zur Kalkulation?

Planung, Entwicklung, Prüfung, Integration, Einführung und laufender Betrieb. Dazu gehören interne Arbeitszeit, Hosting, gegebenenfalls Modellnutzung, Updates, Betreuung und ein möglicher späterer Wechsel der Lösung.

Welchen Prozess möchten Sie zuerst prüfen?

Bringen Sie zum Gespräch einen konkreten Ablauf und die beteiligten Systeme mit. Gemeinsam können wir eingrenzen, welche Automatisierung sinnvoll ist und welche Fragen vor der Umsetzung mit Ihrer IT geklärt werden müssen.

Prozess besprechen

Fachquellen: NIST SP 800-218 und OWASP ASVS, geprüft am 22. September 2026. Das Beispiel des Angebotskonfigurators ist fiktiv.