Wenn die KI mitprüft: Wo sie in Architektur- und Security-Arbeit wirklich hilft

Im Juni habe ich hier beschrieben, warum ein erheblicher Teil des KI-generierten Codes Sicherheitslücken enthält und was Architektur dagegen tut. Wer nur diesen Beitrag kennt, könnte mich für eine Skeptikerin halten. Das bin ich nicht, und das war auch nie die Reihenfolge. Ich betrachte zuerst die Risiken, weil das Sicherheitsdenken ist: Man kennt die Grenzen, um innerhalb davon Raum für Möglichkeiten zu schaffen. Der Juni-Beitrag hat die Grenzen gezogen. Dieser hier ist der Raum: die Landkarte, wo ein Sprachmodell in Architektur- und Security-Arbeit tatsächlich hilft, wo es nur so tut, und welche Disziplin beides trennt.

Ein Sprachmodell ist in dieser Arbeit kein Autor und kein Prüfer. Es ist ein sehr schneller, sehr belesener Assistent, der Vorschläge macht, und die Entscheidung bleibt bei der Architektur und beim Menschen.

Was folgt, sind sechs Aufgaben aus meinem eigenen Alltag, bei denen der Einsatz sich nachweislich lohnt, drei, bei denen er es nicht tut, und die Regeln, mit denen ich arbeite. Keine Studien, keine Prozentwerte, dafür konkret.

Sechs Aufgaben, bei denen die KI wirklich hilft

1. Fremden Code verstehen, bevor man ihn beurteilt

Der größte Zeitfresser in Audits und Übernahmen ist nicht das Finden von Fehlern, sondern das Verstehen: Was tut dieses 4.000-Zeilen-Modul von 2011, das niemand mehr erklären kann? Ein Sprachmodell kann einen solchen Block in kurzer Zeit strukturieren und daraus eine erste Beschreibung ableiten: Welche Eingaben, welche Ausgaben, welche Nebenwirkungen, welche Abhängigkeiten, wo Zustand gehalten wird. Was es dabei regelmäßig nicht sieht: ausgelagerte Seiteneffekte, Framework-Magie, globale Zustände, Datenbank-Trigger, Verträge mit Nachbarsystemen. Diese Beschreibung ist nicht die Wahrheit, sie ist eine Hypothese, und sie enthält Fehler. Aber sie ist ein Startpunkt, der mir früher zwei Tage gekostet hat, und sie sagt mir, wo ich zuerst hinschauen muss. Wie das Verstehen ohne Werkzeug aussieht, steht im Beitrag über Reverse Engineering von Legacy-Systemen. Mit Werkzeug ändert sich die Reihenfolge: erst die Hypothese, dann der Beweis. Und eine Sache gilt hier von Anfang an: Fremder Code ist fremder Text und kann Anweisungen an das Modell enthalten, etwa die Bitte, diese Funktion als unbedenklich zu melden. Dazu unten mehr.

2. Das zweite Augenpaar im Review

Ein Code-Review durch einen Menschen findet, was der Mensch kennt. Ein statischer Analysator wie Semgrep oder ein SAST-Werkzeug findet deterministisch, was in seinen Regeln steht, und das bleibt die erste Schicht, auch OWASP empfiehlt für Injection-Klassen ausdrücklich die Kombination aus Review und automatisierten Verfahren. Ein Sprachmodell mit einer klaren Frage („Prüfe diese Funktion auf fehlende Autorisierung, Injection und unsichere Deserialisierung, nenne die Zeile und den Grund") findet dazwischen die Zusammenhänge, die keine Regel abdeckt und die der Mensch an diesem Tag übersehen hätte, weil er die vierzigste Datei liest. Es findet auch Dinge, die keine sind, und es übersieht Dinge, die welche sind. Die Arbeitsteilung: Das Werkzeug findet deterministisch, das Modell sucht Zusammenhänge, der Mensch beurteilt. Mein Ablauf: Scanner und Modell zuerst, dann lese ich mit beiden Listen in der Hand. Die Liste macht mich nicht schneller, sie macht mich gründlicher, weil ich jede Zeile darauf mit einer Frage im Kopf lese.

3. Threat Modeling: die Liste, die man nicht selbst schreiben will

Threat Modeling scheitert selten an der Methode, sondern daran, dass jemand für jeden Datenfluss die Frage „was kann hier schiefgehen" fünfmal durchdeklinieren muss und nach dem dritten Fluss müde wird. Genau das ist die Aufgabe, bei der ein Sprachmodell nicht müde wird. Man gibt ihm das Diagramm als Text, die Komponenten, die Vertrauensgrenzen, und lässt es je Fluss die Bedrohungskategorien durchgehen. Die Ausgabe ist eine Kandidatenliste: ein Teil Rauschen, ein Teil bekannt, und einige Fälle, die im Workshop niemand genannt hätte. Der Workshop wird damit nicht überflüssig, aber er beginnt mit einer Liste statt mit einem leeren Whiteboard. Wie die Methode selbst funktioniert, steht im Beitrag über Threat Modeling für Enterprise-Apps.

4. Triage bei Vorfällen und im Log

Ein Vorfall produziert in den ersten Stunden mehr Log als jeder Mensch lesen kann. Ein Sprachmodell kann in dieser Phase zwei Dinge sehr schnell erledigen: Zusammenfassen („was ist zwischen 02:10 und 02:40 auf diesen drei Systemen passiert") und Muster über mehrere Quellen hinweg als Hypothesen zusammenführen. Es ersetzt keine forensische Auswertung, es ersetzt die Stunde, in der man sonst grep-Befehle tippt und die Übersicht verliert. Wichtig ist hier die Datenfrage mehr als überall sonst: Logs voller Nutzernamen und Adressen gehen nicht an einen fremden Anbieter. Dafür laufen bei mir lokale Modelle, dazu unten.

5. Charakterisierungstests für Code ohne Tests

Wer ein Legacy-System ablösen oder umbauen will, braucht zuerst Tests, damit man merkt, wenn sich etwas ändert. Solche Tests zu schreiben ist stumpfe Arbeit, und stumpfe Arbeit ist die Domäne des Sprachmodells: Funktion rein, Testfälle raus, inklusive möglicher Randfälle, die sich aus dem Code ergeben. Der erste Test eines Legacy-Systems dokumentiert nicht das gewünschte Verhalten, sondern das vorhandene. Die Tests sind nicht schön und nicht vollständig, aber sie sind da, und sie sind der Grund, warum ich Umbauten heute mit einem Sicherheitsnetz beginne, das früher aus Zeitgründen fehlte. Wie so ein Umbau geplant wird, steht im Beitrag über das Strangler Fig Pattern.

6. Dokumentation, die aus dem Code kommt

Die Dokumentation, die in der Übergabe fehlt, ist meistens die, die niemand schreiben wollte: Was macht dieser Cronjob, welche Konfigurationswerte gibt es, welche Schnittstellen hängen an diesem Dienst. Ein Sprachmodell erzeugt daraus in einer Stunde einen Rohentwurf, den ein Mensch in einer weiteren Stunde korrigiert. Das Ergebnis ist keine gute Dokumentation, aber es ist eine, die existiert, und für ein System, das niemand mehr versteht, ist das der Unterschied zwischen Übergabe und Neubeginn.

Drei Aufgaben, bei denen die KI nur so tut

Das Muster hinter allen dreien: Das Modell ist stark, wo die Aufgabe eng ist und das Ergebnis prüfbar. Es ist schwach, wo Kontext und Verantwortung gefragt sind. Die sechs Aufgaben oben sind eng und prüfbar. Die drei hier sind es nicht.

Die Regeln, mit denen ich arbeite

Daten: Was das Modell sieht, entscheidet, welches Modell

Kundencode, Logs, Konfigurationen, Audit-Unterlagen: Das ist Material, das nicht an einen beliebigen Anbieter geht. Für diese Arbeit laufen bei mir entsprechend abgeschottete Modelle auf eigener Infrastruktur, ohne externe Übertragung der Inhalte. Lokal heißt dabei nicht automatisch sicher, es heißt nur, dass die Datenfrage im eigenen Haus beantwortet wird. Für allgemeine Fragen, Sprache, öffentliches Wissen und Strukturhilfe kann ein externer Anbieter vertretbar sein, sofern Vertrag, Datenschutz, Datenverarbeitung und technische Rahmenbedingungen dazu passen: Speicherort, Unterauftragnehmer, Training mit Eingaben, Aufbewahrung. Ein Auftragsverarbeitungsvertrag allein ist kein Talisman. Die Trennung ist nicht bequem, aber sie ist die Voraussetzung dafür, dass ich das Werkzeug überhaupt in Kundenprojekten einsetzen darf. Wer sie nicht zieht, hat ein Datenschutzproblem, bevor er den ersten Nutzen hat.

Prüfung: Jeder Befund wird nachvollzogen

Ein Sprachmodell nennt eine Zeile und einen Grund. Ich öffne die Zeile. Stimmt der Grund, kommt der Befund in die Liste, mit meinem Namen. Stimmt er nicht, kommt er in eine zweite Liste, die ich mitführe, weil sie mir sagt, wo das Modell systematisch danebenliegt. Nach ein paar Projekten weiß man, welche Fragen es gut beantwortet und welche nicht, und stellt die anderen nicht mehr.

Gegenlesen: Das zweite Modell soll widersprechen

Für Texte und Konzepte, die nach außen gehen, lasse ich seit einiger Zeit zwei verschiedene Modelle gegeneinander lesen: Eines schreibt oder strukturiert, das andere bekommt nur den Auftrag, Fehler, Absolutheiten und unbelegte Zahlen zu finden. Die Rückfragen des zweiten sind der wertvollste Teil des Prozesses, und dieser Beitrag hat ihn selbst durchlaufen. Zwei Modelle sind dabei keine unabhängigen Gutachter, sie können denselben verbreiteten Irrtum teilen. Was danach übrig bleibt, prüfe ich deshalb selbst, wie im Abschnitt Prüfung beschrieben. Das ist nicht schneller als früher. Es ist besser.

Injection: Das Werkzeug als Ziel denken

Wer ein Sprachmodell in Sicherheitsarbeit einsetzt, muss es selbst als Angriffsziel denken. Fremder Code, Logs, Dokumente, Tickets: Alles, was das Modell liest, kann Anweisungen enthalten, die an das Modell gerichtet sind, nicht an mich, und die Aufgaben eins und vier oben füttern es genau mit solchem Material. OWASP führt diese Prompt Injection an erster Stelle der Risiken für LLM-Anwendungen. Die Regel dagegen ist einfach und unbequem: Das Modell bekommt in dieser Arbeit keine Werkzeuge, mit denen fremder Text zur Handlung werden könnte. Es beschreibt, es schlägt vor, es stuft ein. Ausführen, bewerten und entscheiden tut ein Mensch, der weiß, dass die Einstufung vom Modell kommt und der Text vom Gegner stammen kann. Wie eine Prüfschicht für Modelle aussieht, die handeln dürfen, ist ein eigener Beitrag.

Protokoll: Was das Modell vorgeschlagen und der Mensch entschieden hat

In Projekten mit KI-Beteiligung führe ich mit, welche Vorschläge vom Modell kamen und was daraus geworden ist. Nicht aus Misstrauen, sondern weil das die einzige Grundlage ist, um nach einem Jahr zu sagen, ob das Werkzeug geholfen hat, und um einem Kunden zu erklären, woher ein Befund stammt. In meinen Audits muss ich offenlegen können, wo KI mitgearbeitet hat und wie ein Befund anschließend verifiziert wurde. Das ist mein Standard, keine gesetzliche Pflicht, und er ist der Grund, warum die Befunde etwas wert sind.

Was das für Ihr Unternehmen bedeutet

Ihr Team arbeitet mit Sprachmodellen, ob Sie es beschlossen haben oder nicht. Die Entwickler tun es, die Admins tun es, und wahrscheinlich hat schon jemand einen Stacktrace oder einen Datenbankauszug irgendwo hineinkopiert. Die Frage ist nicht, ob Sie das erlauben, sondern ob es Regeln gibt: welche Daten wohin dürfen, was geprüft wird, wer entscheidet. Entscheidend ist nicht, ob irgendwo „KI erlaubt" in einer Richtlinie steht. Entscheidend ist, ob der Mitarbeiter weiß, ob er einen Stacktrace, Kundencode, eine Logdatei oder einen Vertrag dort hineinkopieren darf. Betriebe, die diese Regeln haben, nutzen das Werkzeug dort, wo es hilft, und lassen es dort weg, wo es nur so tut. Betriebe ohne Regeln bekommen beides ungefiltert, und die Lücken aus dem Juni-Beitrag gleich mit.

Die gute Nachricht: Die Regeln sind keine Bremse. In meinen Projekten sind sie der Grund, warum ich das Werkzeug überhaupt einsetzen kann, bei Kunden, deren Daten nicht auf fremde Server gehören, in Audits, deren Befunde unterschrieben werden. Die Frage ist nicht, ob die KI mitprüft. Die Frage ist, ob jemand nachprüft.

Quellen & weiterführende Belege

Dieser Beitrag beruht auf eigener Praxis und nennt bewusst keine Produktivitätszahlen; die verfügbaren Studien dazu sind überwiegend von Anbietern finanziert und in ihren Ergebnissen widersprüchlich. Was sich belegen lässt, sind die Rahmen, in denen der Einsatz stattfindet:

• OWASP Top 10 for LLM Applications (2025): die Risikoklassen, die beim Einsatz von Sprachmodellen in Anwendungen und Werkzeugketten zu beachten sind, allen voran Prompt Injection, die Grundlage der Regel „Das Werkzeug als Ziel"; außerdem die OWASP-Empfehlung, Code-Review mit automatisierten Verfahren zu kombinieren.
• NIST AI RMF 1.0 (2023) und NIST AI 600-1, Generative AI Profile (2024): Rahmen für Governance, menschliche Prüfung, Nachvollziehbarkeit und Dokumentation beim Einsatz generativer KI; das Profil nennt ausdrücklich zusätzliche menschliche Prüfung, Nachverfolgung und Dokumentation, aus denen die Regeln zu Prüfung und Protokoll stammen.
• BSI, Generative KI-Modelle: Chancen und Risiken für Industrie und Behörden (2024): die deutsche Einordnung, einschließlich der Datenschutz- und Vertraulichkeitsfragen, die hier zur Trennung lokal und extern führen.

Carola Schulte

Software-Architektin und Network Security Engineer. Arbeitet seit 2024 täglich mit Sprachmodellen, und prüft jedes Ergebnis, bevor es zählt.

Beratung anfragen