KI generierten Code prüfen: Worauf es bei einem Audit ankommt

Wenn du KI generierten Code prüfen lässt, sollte das Audit konkrete Risiken für deinen Betrieb aufdecken. Es muss klären, ob Zugriffsrechte greifen, wichtige Abläufe stimmen und sich die Software verlässlich weiterentwickeln lässt. Am Ende brauchst du einen begründeten Handlungsplan statt einer Liste technischer Auffälligkeiten.

Kurz gesagt: Eine laufende Demo beweist noch keinen sicheren Betrieb. Der Code-Check beginnt mit lesendem Zugriff auf den Quellcode und einer Beschreibung der geplanten Nutzung, ohne Produktivdaten. Das Ergebnis sollte Risiken priorisieren und ausdrücklich benennen, was nicht geprüft werden konnte.

Wann solltest du KI generierten Code prüfen lassen?

Lass KI-generierten Code prüfen, bevor die Anwendung echte Geschäftsdaten verarbeitet oder verbindliche Vorgänge auslöst. Eine Prüfung lohnt sich auch vor größeren Erweiterungen, wenn bisher niemand den technischen Aufbau bewertet hat.

Vielleicht hast du mit einem KI-Werkzeug ein Kundenportal gebaut. Die Anmeldung klappt und Dokumente lassen sich hochladen. Ob ein Kunde durch eine veränderte Anfrage fremde Dokumente abrufen kann, siehst du beim Durchklicken nicht.

Solche Fragen gehören in ein Software-Audit: eine technische Untersuchung mit festgelegtem Umfang und dokumentierten Ergebnissen. Es bewertet den untersuchten Stand. Fehlerfreiheit kann es nicht garantieren.

Der KI-Anteil allein sagt wenig über die Qualität aus. Entscheidend ist, ob die einzelnen Bausteine zusammenpassen und dieselben Regeln einhalten. Das muss auch bei von Menschen geschriebenem Code geprüft werden.

Bei einem Versuch mit erfundenen Daten darf der Prüfumfang kleiner sein. Sobald Mitarbeiter damit Aufträge bearbeiten oder Kunden Unterlagen hochladen, müssen auch Fehlbedienung und Unterbrechungen untersucht werden.

Welche Unterlagen und Zugriffe braucht der Prüfer?

Für die erste Codeprüfung braucht der Prüfer lesenden Zugriff auf den Quellcode und eine Beschreibung der wichtigsten Abläufe. Schreibrechte und echte Kundenunterlagen sind dafür nicht nötig.

Der Quellcode liegt meist in einem Repository. Das ist die zentrale Ablage für Programmdateien und ihre Änderungshistorie. Lesender Zugriff erlaubt die Untersuchung, ohne Änderungen in diese Ablage zurückzuschreiben.

Bei unserem KI-Projekt-Check arbeiten wir ausschließlich mit lesendem Repository-Zugriff und ohne Produktivdaten. Du erhältst ein Scoring, also eine strukturierte Bewertung, und einen priorisierten Handlungsplan. Die Abrechnung erfolgt nach Aufwand, den wir vorher schätzen.

Bereite für die Prüfung diese Informationen vor:

• Den wichtigsten Ablauf: Was gibt jemand ein, und welches Ergebnis muss entstehen?
• Die Nutzergruppen: Wer darf welche Informationen sehen, ändern oder freigeben?
• Die angebundenen Dienste: Wohin werden etwa Buchungen oder E-Mails übertragen?
• Den aktuellen Stand: Was funktioniert bereits, welche Fehler sind bekannt?
• Die technische Anleitung: Wie lässt sich das Projekt starten und testen?

Alltagssprache reicht. „Ein Interessent lädt Unterlagen hoch, ein Mitarbeiter prüft sie und gibt eine Rückmeldung frei“ ist ein brauchbarer Ausgangspunkt. Daraus lassen sich konkrete Prüfungen ableiten.

Fehlt bisher eine Beschreibung, hilft die Struktur aus dem Ratgeber zum Lastenheft für eine App. Für den Check brauchst du kein langes Dokument. Wichtiger sind klare Antworten darauf, was passieren soll und was keinesfalls passieren darf.

Was muss ein Code-Audit untersuchen?

Ein Code-Audit sollte Zugriffsrechte, Datenverarbeitung, Fehlerverhalten und Wartbarkeit untersuchen. Welche Stellen besonders gründlich geprüft werden, hängt von den möglichen Folgen eines Fehlers ab.

Greifen die Zugriffsrechte auch hinter der Oberfläche?

Eine Anmeldung schützt noch nicht vor unberechtigten Zugriffen innerhalb der Anwendung. Bei jeder geschützten Aktion muss das System prüfen, ob der angemeldete Nutzer sie ausführen darf.

Ein ausgeblendeter Knopf reicht dafür nicht. Die Prüfung muss auf dem Server greifen, der Anfragen verarbeitet und Daten bereitstellt. Sonst kann jemand die Oberfläche umgehen und die Anfrage direkt stellen.

Beim Kundenportal lautet ein konkreter Test: Kann ein Nutzer die Dokumentnummer in einer Anfrage austauschen und eine fremde Datei herunterladen? Dieselbe Frage stellt sich bei Suchergebnissen und Änderungen an Datensätzen.

Werden Eingaben geprüft und Zugangsschlüssel geschützt?

Die Software muss auch mit unerwarteten Eingaben umgehen können. Dazu gehören unzulässige Dateiformate, fehlende Pflichtangaben und Werte außerhalb des erlaubten Bereichs. Prüfungen in der Oberfläche allein genügen nicht, weil sich Anfragen auch anders absenden lassen.

Zugangsschlüssel zu externen Diensten dürfen nicht im öffentlich ausgelieferten Browsercode stehen. Tauchen sie im Repository auf, muss geklärt werden, wer darauf zugreifen konnte. Offengelegte Schlüssel müssen beim jeweiligen Dienst ersetzt oder gesperrt werden.

Bloßes Löschen aus der aktuellen Datei reicht nicht. Der alte Wert kann weiterhin in der Änderungshistorie stehen. Für die Prüfung sollten Konfigurationsbeispiele ohne echte Zugangsdaten vorliegen.

Was passiert bei Abbrüchen und wiederholten Anfragen?

Ein Audit darf sich nicht auf den erfolgreichen Ablauf beschränken. Es sollte auch untersuchen, was bei abgebrochenen Uploads oder nicht erreichbaren Diensten passiert.

Angenommen, deine Anwendung überträgt eine Terminbuchung an ein anderes System. Die Verbindung bricht ab, bevor eine Bestätigung zurückkommt. Bei einer erneuten Übertragung darf derselbe Vorgang nicht versehentlich eine weitere Buchung erzeugen.

Ebenso relevant sind technische Protokolle. Sie müssen genug Informationen liefern, um einen Fehler nachzuvollziehen. Vollständige Kundenunterlagen oder Zugangsschlüssel gehören dabei nicht in Fehlermeldungen.

Lässt sich die Software später verlässlich ändern?

Wartbarkeit bedeutet, dass Entwickler Fehler beheben und Funktionen ergänzen können, ohne unnötig viele andere Stellen anzufassen. Dafür müssen zentrale Regeln an nachvollziehbaren Stellen liegen.

Steht dieselbe Angebotsberechnung mehrfach im Code, kann bei einer Änderung eine Kopie vergessen werden. Dann zeigen zwei Ansichten unterschiedliche Ergebnisse. Das Audit sollte solche Stellen benennen und ihre Folgen erklären.

Auch Abhängigkeiten gehören zur Prüfung. Das sind externe Softwarepakete, auf denen die Anwendung aufbaut. Der Prüfer untersucht ihre Einbindung und bekannte Sicherheitsprobleme.

Automatisierte Tests sind ebenfalls relevant, aber ihre bloße Existenz ist kein Qualitätsbeleg. Ein Test, der nur den Seitenstart prüft, sagt nichts über Zugriffsrechte aus. Gute Tests prüfen auch Geschäftsregeln und erwartetes Verhalten bei Fehlern.

Was kann ein Audit mit lesendem Zugriff nicht feststellen?

Aus dem Quellcode lässt sich nicht vollständig ableiten, wie die Anwendung tatsächlich betrieben wird. Einstellungen außerhalb des Repositorys brauchen zusätzliche Nachweise oder gesonderte Prüfungen.

Im Code kann etwa eine Datensicherung vorgesehen sein. Das belegt noch nicht, dass sie im Betrieb läuft oder sich wiederherstellen lässt. Auch Einstellungen beim Hosting-Anbieter können von den Dateien im Repository abweichen.

Der Bericht muss deshalb bestätigte Befunde von offenen Fragen trennen. Nicht geprüft ist kein positives Prüfergebnis. Fehlt ein Nachweis, muss das sichtbar bleiben.

Für ausführbare Tests kann eine getrennte Testumgebung sinnvoll sein. Dort läuft die Anwendung mit erfundenen Daten, ohne echte Buchungen oder Nachrichten auszulösen. Ob solche Tests zum Auftrag gehören, wird vor Beginn vereinbart.

Unbekannter Code sollte dabei nicht auf einem Arbeitsrechner mit wichtigen Zugangsdaten gestartet werden. Schon Installationsschritte können Befehle ausführen. Eine abgeschottete Umgebung begrenzt dieses Risiko.

Wie müssen Scoring und Handlungsplan aussehen?

Das Scoring muss zeigen, welche Bereiche bewertet wurden und worauf die Bewertung beruht. Der Handlungsplan muss daraus konkrete Aufgaben in einer begründeten Reihenfolge machen.

Eine Gesamtnote allein reicht nicht. Gut lesbarer Code gleicht keine fehlende Zugriffssperre aus. Kritische Befunde müssen deshalb einzeln erkennbar bleiben.

So können Aufgaben im Bericht eingeordnet werden:

Die Einordnung muss zu deinem Betrieb passen. Ein doppelter Eintrag kann eine harmlose Testnotiz oder ein verbindlicher Auftrag sein. Entsprechend unterschiedlich fällt die Priorität aus.

Zu jedem relevanten Befund gehören die Fundstelle, die mögliche Auswirkung und eine empfohlene Korrektur. Außerdem muss beschrieben sein, woran die erfolgreiche Behebung erkennbar ist.

„Zugriffsschutz verbessern“ ist keine ausreichende Aufgabe. Konkreter wäre: Der Download muss fremde Dokumentnummern zurückweisen, auch wenn ein angemeldeter Nutzer sie direkt anfragt. Genau dieses Verhalten lässt sich anschließend prüfen.

Wovon hängt der Aufwand für das Audit ab?

Der Aufwand hängt vor allem von der Prüftiefe, den Geschäftsregeln und den angebundenen Diensten ab. Die Menge an Code allein ist kein brauchbarer Maßstab.

Ein kleines Portal mit verschiedenen Nutzerrollen kann anspruchsvoller sein als eine größere Anwendung ohne vertrauliche Daten. Bei jeder externen Anbindung muss außerdem untersucht werden, wie Fehler und wiederholte Anfragen behandelt werden.

Fehlende Startanleitungen verursachen zusätzliche Arbeit. Unklare Anforderungen ebenfalls: Ohne die erwartete Regel kann ein Prüfer kaum beurteilen, ob eine Berechnung richtig ist.

Halte vor Beginn fest, welche Bestandteile geprüft werden und welche Ergebnisse du erhältst. Dazu gehört die Abgrenzung zwischen Untersuchung und Reparatur. Ein Audit-Auftrag ist noch kein Auftrag zur Fehlerbehebung.

Wie entscheidest du nach dem Audit weiter?

Nach dem Audit entscheidest du anhand der Befunde, ob gezielte Korrekturen reichen oder größere Änderungen nötig sind. Ein kompletter Neubau muss technisch begründet werden.

Ist der Aufbau nachvollziehbar und sind Fehler klar begrenzt, können einzelne Korrekturen genügen. Werden Berechtigungen dagegen an vielen Stellen unterschiedlich behandelt, kann ein größerer Umbau nötig sein. Der Bericht sollte zeigen, welche Stellen diese Einschätzung stützen.

Auch eine bestehende Standardsoftware kann die bessere Wahl sein, wenn sie den benötigten Ablauf bereits abdeckt. Dann hilft die Abwägung zwischen Individualsoftware und Standardsoftware, bevor weitere Entwicklung beauftragt wird.

Nach wichtigen Korrekturen sollte eine Nachprüfung bestätigen, dass die Befunde behoben sind. Dabei muss der geprüfte Code-Stand dokumentiert werden. Spätere Änderungen sind durch dieses Ergebnis nicht automatisch abgedeckt.

Schreib als nächsten Schritt deinen wichtigsten Geschäftsablauf samt möglicher Fehlerfälle auf. Kläre damit vor der Beauftragung, welche Risiken der Check untersuchen soll und welche Ergebnisse du für deine Entscheidung brauchst.