KI-Code im Unternehmen prüfen und sicher weiterentwickeln

KI-Code ist längst im Unternehmensalltag angekommen. Entwicklerinnen und Entwickler lassen sich Funktionen vorschlagen, Fachabteilungen bauen erste Prototypen, externe Dienstleister liefern mit KI-Unterstützung schneller aus. Das ist nicht grundsätzlich problematisch. Problematisch wird es, wenn KI-generierter Code ungeprüft in operative Prozesse rutscht, dort auf Kundendaten, Buchungslogik, Lagerbestände oder Zahlungsfreigaben trifft und niemand mehr sauber erklären kann, warum das System so arbeitet.

Für Unternehmen in Logistik, Automotive, Finanzdienstleistung, Bau und Immobilien geht es daher nicht um eine Grundsatzfrage. Die relevante Frage lautet: Wie lässt sich KI-Code so prüfen, übernehmen und weiterentwickeln, dass daraus belastbare Software wird?

Was im Unternehmen unter KI-Code fällt

KI-Code ist nicht nur der automatisch erzeugte Quelltext aus einem Code-Assistenten. In der Praxis gibt es mehrere Formen, die unterschiedlich bewertet werden müssen.

Ein Entwickler kann sich eine einzelne Funktion, einen regulären Ausdruck oder eine Datenbankabfrage vorschlagen lassen. Eine Fachabteilung kann mit einem KI-Werkzeug einen Prototyp für eine Auswertung bauen. Ein externer Anbieter kann ein internes Portal, einen Chatbot oder eine Schnittstelle liefern und dabei große Teile des Codes mit KI-Unterstützung erstellt haben. Auch Testfälle, Migrationsskripte, Dokumentation und Konfigurationsdateien können KI-generiert sein.

Entscheidend ist nicht, ob KI beteiligt war. Entscheidend ist, ob der Code nachvollziehbar, sicher, wartbar und fachlich korrekt ist. In einem Unternehmen zählt am Ende nicht die Herkunft einer Codezeile, sondern die Verantwortung für das System im Betrieb.

Warum KI-Code anders geprüft werden muss

Klassischer Code kann schlecht sein, KI-generierter Code ebenso. Der Unterschied liegt in der Oberfläche. KI-Code sieht oft erstaunlich sauber aus. Variablennamen wirken plausibel, Kommentare lesen sich verständlich, die Struktur scheint geordnet. Genau das macht ihn gefährlich, wenn er fachlich nicht stimmt.

Ein Beispiel aus der Logistik: Ein KI-generierter Algorithmus zur Priorisierung von Lieferungen berücksichtigt vielleicht Entfernung und Lieferfrist, aber nicht Gefahrgutklassen, Rampenzeiten oder regionale Fahrverbote. Der Code läuft, die Tests mit einfachen Beispieldaten sind grün, im realen Betrieb entstehen trotzdem falsche Entscheidungen.

Ähnlich im Finanzbereich: Eine KI kann eine Freigabelogik für Kundenanfragen erzeugen, die technisch funktioniert, aber Rollen, Vier-Augen-Prinzip oder dokumentationspflichtige Ausnahmen nicht sauber abbildet. Im Bau oder in der Immobilienwirtschaft kann ein Dokumentenworkflow formal korrekt aussehen, aber Genehmigungsstände, Nachträge oder Mandantentrennung falsch behandeln.

KI-Code braucht daher eine Prüfung, die über Syntax und Formatierung hinausgeht. Es geht um Fachlogik, Datenzugriffe, Sicherheitsgrenzen, Abhängigkeiten, Betrieb und spätere Wartung.

Typische Risikofelder bei KI-generiertem Code

Die meisten Risiken entstehen nicht, weil KI-Code absichtlich unsicher wäre. Sie entstehen, weil Modelle aus Wahrscheinlichkeiten generieren und keinen vollständigen Kontext über Ihre Organisation, Ihre Architektur und Ihre regulatorischen Anforderungen haben.

Risikofeld	Was typischerweise passiert	Beispiel aus dem Betrieb
Fachliche Annahmen	Der Code löst den Normalfall, aber nicht die Ausnahmen	Eine Dispositionslogik ignoriert Cut-off-Zeiten oder Sondertouren
Sicherheit	Authentifizierung, Rollen oder Eingabeprüfung sind unvollständig	Ein internes Portal gibt Dokumente mandantenübergreifend frei
Abhängigkeiten	Pakete, Versionen oder APIs werden unkritisch übernommen	Eine alte Bibliothek verursacht Sicherheitswarnungen im Deployment
Datenqualität	Der Code erwartet saubere Daten, die es im Quellsystem nicht gibt	Adressen, Statuscodes oder Zeitstempel werden falsch interpretiert
Wartbarkeit	Es fehlen Tests, klare Modulgrenzen und nachvollziehbare Dokumentation	Änderungen sind nach wenigen Wochen nur noch mit hohem Aufwand möglich
Rechte und Herkunft	Lizenzfragen oder übernommene Muster sind nicht geklärt	Code darf in einem Kundenprojekt nicht ohne Prüfung weitergegeben werden

Ein Blick auf etablierte Sicherheitsrahmen hilft, ohne das Thema künstlich zu verkomplizieren. Die OWASP Top 10 for Large Language Model Applications zeigen, welche Risiken bei KI-Systemen und ihren Schnittstellen besonders häufig auftreten. Für Softwareentwicklung allgemein ist das Secure Software Development Framework des NIST eine gute Orientierung, vor allem bei Prüfprozessen, Dokumentation und Lieferketten.

Vor dem Review: Kontext schaffen

Ein Code-Review ohne fachlichen Kontext bleibt oberflächlich. Bevor KI-Code technisch geprüft wird, sollte klar sein, wofür er gedacht ist und welche Grenzen gelten.

Hilfreich sind fünf Fragen, die vor jedem Review beantwortet werden sollten:

• Welche geschäftliche Aufgabe soll der Code lösen?
• Welche Systeme, Datenquellen und Nutzerrollen sind betroffen?
• Welche Fehler wären im Betrieb kritisch?
• Wer übernimmt fachlich und technisch die Verantwortung?
• Soll der Code ein Prototyp bleiben oder produktiv betrieben werden?

Diese Unterscheidung ist wichtig. Ein Skript, das intern Testdaten bereinigt, muss anders bewertet werden als eine Schnittstelle, die Lieferstatus an Kunden ausspielt. Ein Prototyp für eine Bauprojekt-Auswertung darf unvollständig sein, solange niemand operative Entscheidungen darauf stützt. Sobald daraus ein produktives Werkzeug wird, gelten andere Maßstäbe.

Wenn sich beim Prüfen zeigt, dass ein KI-Prototyp eigentlich einen sehr unternehmensspezifischen Prozess abbildet, ist oft eine saubere Eigenentwicklung sinnvoller als das Weiterziehen eines unfertigen Entwurfs. Genau diese Abwägung behandeln wir auch im Beitrag über eigene KI-Entwicklung, wenn Standardsoftware nicht reicht.

Wie ein belastbarer Prüfprozess aussieht

Ein einzelner Review-Termin reicht selten aus. Besser ist ein schlanker, aber klarer Prozess, der technische, fachliche und betriebliche Fragen verbindet.

Technische Prüfung

Zuerst wird geprüft, ob der Code grundsätzlich in die bestehende Architektur passt. Dazu gehören Sprache, Frameworks, Schnittstellen, Datenbankzugriffe, Fehlerbehandlung und Logging. Gerade KI-generierter Code enthält oft Lösungen, die isoliert funktionieren, aber nicht zur internen Plattform passen.

Wichtig ist auch die Prüfung von Abhängigkeiten. Welche Pakete wurden eingebunden? Sind sie gepflegt? Gibt es bekannte Schwachstellen? Wurde eine Bibliothek nur deshalb gewählt, weil sie in Trainingsdaten häufig vorkam, oder gibt es einen nachvollziehbaren Grund?

Sicherheitsprüfung

Danach folgt die Sicherheitsbetrachtung. Bei internen Tools wird dieser Schritt gern unterschätzt. Dabei arbeiten gerade interne Portale und Automatisierungen oft mit besonders sensiblen Daten: Kundenkonditionen, Bauakten, Fahrzeugdaten, Lieferinformationen, Kreditunterlagen oder Vertragsdokumenten.

Geprüft werden sollten mindestens Rollen und Berechtigungen, Eingabevalidierung, Umgang mit Geheimnissen, API-Zugriffe, Protokollierung und Fehlermeldungen. Zugangsdaten dürfen nicht im Code landen. Fehler dürfen keine internen Details offenlegen. Rollen müssen fachlich stimmen, nicht nur technisch existieren.

Für browserbasierte Anwendungen ist zusätzlich relevant, wie Identitäten, Zugriffe und Protokolle im laufenden Betrieb gesteuert werden. Dazu passt der vertiefende Beitrag über webbasierte KI-Anwendungen für verteilte Teams, weil dort genau diese Betriebsebene im Mittelpunkt steht.

Fachliche Validierung

Die fachliche Prüfung ist der Teil, der am häufigsten zu kurz kommt. Ein Review nur durch Entwicklerinnen und Entwickler findet technische Fehler, aber nicht automatisch falsche Geschäftsregeln.

In der Logistik sollten Disposition, Kundenservice oder Lagerleitung Testfälle beisteuern. Im Finanzbereich müssen Compliance, Fachbereich und IT gemeinsam festlegen, welche Ausnahmen relevant sind. In Bau und Immobilien braucht es Personen, die Genehmigungsstände, Vertragslogik und Dokumentenflüsse aus der täglichen Arbeit kennen.

Gute Testfälle bilden nicht nur den Idealfall ab. Sie enthalten Grenzfälle, fehlende Daten, widersprüchliche Angaben, Sonderfreigaben und historische Altlasten. Genau dort zeigt sich, ob KI-Code wirklich verstanden wurde oder nur gut aussieht.

Betriebliche Prüfung

Produktionsreife endet nicht beim erfolgreichen Deployment. Der Code muss überwacht, aktualisiert und im Fehlerfall verstanden werden können. Dafür braucht es Logs, Monitoring, klare Zuständigkeiten, nachvollziehbare Konfiguration und eine Dokumentation, die nicht nur aus automatisch generierten Kommentaren besteht.

Besonders kritisch sind Datenflüsse. Wenn KI-Code auf Live-Daten aus ERP, CRM, TMS, Buchhaltung oder Dokumentenmanagement zugreift, entscheidet die Datenstrecke über die Qualität des Ergebnisses. Der beste Code hilft wenig, wenn Statusänderungen zu spät, doppelt oder ohne Validierung ankommen. Für solche Fälle lohnt sich ein genauer Blick auf KI-Pipelines und verlässliche Datenflüsse.

KI-Code sicher weiterentwickeln statt einmalig bereinigen

Viele Unternehmen behandeln KI-Code wie einen Fremdkörper: einmal prüfen, ein paar Stellen korrigieren, dann ablegen. Das greift zu kurz. Wenn der Code weiter genutzt werden soll, muss er in die normale Softwareentwicklung überführt werden.

Das beginnt mit einem sauberen Repository. Jede Änderung braucht Versionierung, nachvollziehbare Commits und klare Verantwortliche. KI-generierte Dateien dürfen nicht außerhalb der üblichen Prozesse gepflegt werden, nur weil sie ursprünglich schneller entstanden sind.

Automatisierte Tests sind der nächste Schritt. Unit-Tests prüfen einzelne Funktionen, Integrationstests prüfen Schnittstellen, End-to-End-Tests prüfen konkrete Abläufe. Für operative Systeme sind Regressionstests besonders wichtig. Sie verhindern, dass eine scheinbar kleine Änderung an einer Routenlogik, einer Freigaberegel oder einer Dokumentenklassifikation bestehende Abläufe bricht.

Auch Dokumentation muss kontrolliert werden. KI kann beim Schreiben helfen, aber sie ersetzt keine Architekturentscheidung. Dokumentiert werden sollten die fachliche Aufgabe, die betroffenen Datenquellen, relevante Annahmen, bekannte Grenzen und Verantwortlichkeiten. Besonders wertvoll sind kurze Entscheidungsnotizen: Warum wurde eine bestimmte Schnittstelle gewählt? Warum wird eine Regel im Code und nicht im Quellsystem abgebildet? Warum braucht ein Prozess menschliche Freigabe?

Praktische Beispiele aus operativen Branchen

In der Logistik entsteht KI-Code oft rund um Tourenplanung, ETA-Prognosen, Statuskommunikation oder Lagerpriorisierung. Hier ist die fachliche Validierung entscheidend, weil echte Abläufe selten linear sind. Ein Modell oder Skript muss mit Teillieferungen, Wartezeiten, Sonderfahrten, fehlenden Scans und manuellen Korrekturen umgehen können.

In Automotive-Unternehmen geht es häufig um Lieferketten, Qualitätsmeldungen, Händlerportale oder interne Auswertungen. KI-Code kann hier schnell nützlich sein, wenn er Daten zusammenführt und Routineprüfungen automatisiert. Gleichzeitig sind Schnittstellen zu bestehenden Systemen oft komplex. Ein sauberer Vertrag zwischen Systemen ist wichtiger als ein schneller Prototyp.

Bei Finanzdienstleistern steht die Nachvollziehbarkeit im Vordergrund. Wenn Code Kundendaten sortiert, Anfragen priorisiert oder Dokumente klassifiziert, muss klar sein, welche Regel angewendet wurde und wo menschliche Kontrolle erforderlich ist. Ein plausibles Ergebnis reicht nicht, wenn später niemand erklären kann, wie es zustande kam.

In Bau und Immobilien liegt der Nutzen häufig in Dokumentenprozessen, Projektübersichten, Mängelmanagement und Vertragsdaten. KI-generierter Code kann interne Werkzeuge schneller verfügbar machen. Die Prüfung muss aber sicherstellen, dass Projektrollen, Zugriffsrechte, Versionen und Dokumentenstände korrekt behandelt werden.

Governance ohne unnötige Bürokratie

Unternehmen brauchen keine schwerfällige KI-Code-Bürokratie. Sie brauchen klare Leitplanken. Je näher Code an produktiven Daten und geschäftskritischen Entscheidungen liegt, desto strenger muss geprüft werden.

Ein pragmatisches Regelwerk kann festlegen, welche KI-Werkzeuge verwendet werden dürfen, welche Daten nicht in externe Systeme kopiert werden dürfen, ab wann ein zweites Review verpflichtend ist und welche Testabdeckung vor einem Deployment erforderlich ist. Ebenso sollte geklärt sein, ob Prompts, generierte Vorschläge oder Entscheidungsgrundlagen dokumentiert werden müssen.

Dabei sollte die Governance zur Unternehmensrealität passen. Ein mittelständischer Logistiker braucht andere Prozesse als ein regulierter Finanzdienstleister. Ein Immobilienverwalter mit internen Portalen hat andere Risiken als ein Automotive-Zulieferer mit enger Produktionsintegration. Wichtig ist, dass die Regeln verständlich sind und im Alltag funktionieren.

Wann externe Unterstützung sinnvoll ist

Externe Unterstützung ist besonders dann sinnvoll, wenn KI-Code bereits geschäftlich relevant geworden ist, aber intern niemand die vollständige Verantwortung übernehmen kann. Typische Situationen sind gewachsene Prototypen, übernommene Lieferantenlösungen, interne Tools ohne Dokumentation oder Anwendungen, die plötzlich produktive Daten verarbeiten.

Ein guter technischer Partner prüft nicht nur den Code. Er fragt nach Prozess, Daten, Rollen, Betrieb und Übergabe. Gerade bei operativer KI und individueller Softwareentwicklung ist diese Verbindung entscheidend. Codequalität allein löst kein Prozessproblem, aber schlechter Code kann ein gutes Prozesskonzept schnell unbrauchbar machen.

Häufige Fragen zu KI-Code im Unternehmen

Muss KI-generierter Code grundsätzlich neu geschrieben werden? Nein. Oft reicht es, den Code fachlich und technisch zu prüfen, kritische Teile zu überarbeiten, Tests zu ergänzen und ihn in die normale Entwicklungsumgebung zu überführen. Neu geschrieben werden sollte vor allem Code, der nicht nachvollziehbar, unsicher oder architektonisch unpassend ist.

Wer sollte KI-Code im Unternehmen freigeben? Die Freigabe sollte immer technisch und fachlich erfolgen. Die IT prüft Architektur, Sicherheit und Betrieb. Der Fachbereich bestätigt, ob Geschäftsregeln, Ausnahmen und reale Abläufe korrekt abgebildet sind.

Darf eine Fachabteilung KI-Code selbst erstellen? Für Prototypen und interne Experimente kann das sinnvoll sein, solange keine sensiblen Daten verarbeitet werden und klar ist, dass daraus nicht automatisch produktive Software wird. Sobald operative Prozesse betroffen sind, braucht es IT-Prüfung und klare Verantwortung.

Welche Dokumentation ist bei KI-Code besonders wichtig? Wichtig sind Zweck, Datenquellen, Schnittstellen, Rollen, fachliche Annahmen, bekannte Grenzen, Testfälle und Zuständigkeiten. Kommentare im Code allein reichen nicht aus.

KI-Code produktionsreif machen

KI-Code kann Entwicklungsarbeit beschleunigen. Er ersetzt aber nicht die Verantwortung für Architektur, Sicherheit, Fachlogik und Betrieb. Unternehmen, die diesen Unterschied ernst nehmen, können KI sinnvoll nutzen, ohne sich technische Schulden oder unnötige Risiken einzuhandeln.

Wenn Sie KI-generierten Code, einen gewachsenen Prototyp oder ein internes Tool prüfen und belastbar weiterentwickeln möchten, kann Gloura unterstützen. Wir entwickeln operative KI und individuelle Software in Wien und im DACH-Raum, mit Fokus auf reale Prozesse, Live-Daten, Übergabe und wartbaren Betrieb. Einen ersten Überblick finden Sie auf gloura.io.