13.3 — AI als Verteidigerwerkzeug

Worum es geht

Lerneinheit 13.2 hat gezeigt, wie AI eine Angriffskette strukturell beschleunigt. Diese Einheit dreht die Perspektive: Welche Werkzeugklassen stehen einer Bank-IT für die Verteidigung zur Verfügung? Wo entfalten sie ihren größten Hebel? Wo liegen die regulatorischen Leitplanken, die das Deployment in einer deutschen Bank prägen?

Wichtig vorweg: Defensive AI hinkt offensiver AI im Mai 2026 nach. Das ist keine Niederlage, sondern eine Beobachtung, die sich aus zwei strukturellen Gründen ergibt — Verteidiger müssen integrieren, validieren und dokumentieren, Angreifer nur funktionieren. Trotzdem stehen heute Werkzeuge bereit, die Bank-Sicherheitsteams konkret produktiver machen — wenn sie diszipliniert eingeführt werden.

Die folgende Architektur-Übersicht zeigt die drei Einsatzfelder, die wir gleich im Detail durchgehen, und wie VulnOps und regulatorische Leitplanken sie umrahmen:

Drei Einsatzfelder von AI in der Verteidigung

Einsatzfeld A — Code- und Pipeline-Sicherheit

Das ist das naheliegendste Feld und das, in dem die Werkzeuge am reifsten sind. Konkret:

• Pre-Merge Code Review. Ein Coding Agent prüft jeden Pull Request automatisch auf bekannte Schwachstellen-Muster, Secrets im Code, riskante Library-Updates und Abweichungen von internen Coding-Konventionen. Das ist nicht neu — SAST-Tools (Static Application Security Testing) existieren seit zwei Jahrzehnten. Was neu ist: Die False-Positive-Rate fällt drastisch, weil das Modell den Kontext der Codebasis versteht, statt nur Pattern zu matchen.
• Dependency Audit. AI-Werkzeuge lesen die SBOM einer Anwendung, gleichen sie mit aktuellen CVE-Datenbanken ab und priorisieren nach Exploitability im konkreten Einsatzkontext — nicht nach generischem CVSS-Score. Eine Bibliothek mit CVSS 9.8 in einer Code-Pfadkomponente, die im aktuellen Build gar nicht aufgerufen wird, sinkt in der Priorität. Das ist ein erheblicher Effizienzgewinn gegenüber klassischem Patch-Management.
• Continuous Vulnerability Discovery auf dem eigenen Code. Die größeren AI-Werkzeuge können — analog zu den Angreifer-Capabilities aus 13.2 — auch das eigene Codebase nach unbekannten Schwachstellen durchsuchen. Was Angreifer in tausend Open-Source-Projekten tun, kann eine Bank intern tun: ihren eigenen Code agentenbasiert prüfen, bevor jemand anderes es tut.

Banking-Lens: Das Kernbankensystem selbst wird meist nicht von der Bank entwickelt — Finanz Informatik, Atruvia und TCS BaNCS dominieren. Die Bank entwickelt aber Integrations-Layer, Self-Service-Portale, Apps, Workflow-Tools, regulatorische Reporting-Strecken. Genau dort entstehen die heute am häufigsten ausgenutzten Schwachstellen. Ein agentengestütztes Pre-Merge-Review der bank-eigenen Codebasis ist eine Maßnahme, die in wenigen Wochen produktiv geschaltet werden kann.

Einsatzfeld B — Coding Agents jenseits von Code

Das ist der überraschendere Hebel, und der Punkt, an dem viele Bank-Sicherheitsteams unterschätzen, was zur Verfügung steht. Coding Agents haben ihren Namen aus dem urspruenglichen Anwendungsfeld, aber sie sind im Kern allgemeine Werkzeug-orchestrierende Sprachmodelle. Sie können:

• GRC-Aufgaben automatisieren. Eine neue MaRisk-Novelle erscheint. Ein Agent kann sie mit der aktuellen internen Policy abgleichen, Delta-Listen erzeugen, Vorschläge für Anpassungen formulieren und sie strukturiert an die zuständigen 2nd-Line-Funktionen routen. Das ersetzt nicht den menschlichen Compliance Officer — es entlastet ihn von der mechanischen Vorarbeit.
• Audit-Vorbereitung beschleunigen. Vor einer ISO-27001-Rezertifizierung muss eine Bank typischerweise Dutzende Evidence-Pakete zusammenstellen. Ein Agent kann durch interne Datenquellen (Wikis, Ticket-Systeme, Konfigurations-Backends) navigieren und die Belege für die 93 Controls der ISO 27002 vorbefuellen.
• Incident Response unterstützen. In den ersten Minuten eines Vorfalls braucht der SOC möglichst schnell eine angereicherte Lage: Was ist das betroffene System, welche Benutzer haben Zugriff, welche Daten liegen darauf, wer ist der fachliche Owner, was war die letzte Änderung? Ein Agent kann diese Korrelation in Sekunden machen, während ein Analyst sich für die Triage-Entscheidung sammelt.
• Threat-Intelligence-Triage. Pro Tag erreichen ein durchschnittliches Bank-SOC mehrere Dutzend Threat-Intel-Feeds und Bulletins. Ein Agent kann sie durchsehen, mit dem eigenen Asset-Inventar abgleichen und nur die wenigen relevanten Hinweise an menschliche Analysten weiterreichen.
• Policy- und Standards-Authoring. Eine Bank, die ihre interne Sicherheits-Policy auf NIS2 oder die neue DORA-Konformität aktualisieren muss, hat damit eine Wochen-Aufgabe. Ein Agent kann den ersten Entwurf erzeugen, der dann menschlich überarbeitet wird — eine Beschleunigung um Faktor drei bis fünf ist realistisch.

Einsatzfeld C — Detection und Response

Hier wird es heikler, weil die Anforderungen an Zuverlässigkeit, Falsch-Positiv-Quote und Erklärbarkeit höher sind. Trotzdem ist die Richtung klar:

• Alert-Triage. Ein SIEM erzeugt in einer mittleren Bank täglich tausende Events. Klassische Korrelations-Regeln sieben einen großen Teil aus, lassen aber immer noch zu viele Alerts für die menschliche Analyse übrig. Ein AI-Modell kann den verbleibenden Strom triagieren, Kontext anreichern und nach Risiko priorisieren.
• Behavioral Analytics. Anstatt nach Signaturen zu suchen, lernen AI-Modelle das normale Verhalten von Benutzern und Systemen. Ungewöhnliche Aktivitäten — ein Service-Account, der plötzlich aus einem ungewöhnlichen Land anfragt, ein User, der zur Mittagspause administrative Aufgaben durchführt — werden auffällig, ohne dass jemand vorher eine Regel definiert hat.
• Vorab autorisierte Containment-Aktionen. Das ist der entscheidende Hebel gegen den 8-Minuten-Angriff aus 13.2. Wenn das Modell ein hohes Konfidenz-Signal für eine Kompromittierung sieht, kann es vordefinierte Containment-Schritte selbst auslösen — Isolation eines Endpunkts, Sperrung eines Service-Accounts, Drosselung eines API-Endpunkts — ohne auf den menschlichen Freigabezyklus zu warten. Bei niedriger Konfidenz wird die Aktion einem Menschen vorgelegt.
• Deception als ergänzende Schicht. Honeypots und Honeytokens sind nicht neu, aber AI senkt die Hürde, sie in großer Zahl realistisch und kontextangepasst zu betreiben. Sie sind angriffswerkzeug-unabhängig: Sie identifizieren Angreifer an ihrem Verhalten, nicht an einer Signatur.

Banking-Lens: Die deutsche Bankenaufsicht erwartet Nachvollziehbarkeit. Wenn ein automatisches Containment einen Geldautomaten oder ein Trading-System sperrt, muss der Auslöser dokumentiert und im Nachhinein prüfbar sein. „Das Modell hat entschieden” ist keine ausreichende Antwort. Deshalb ist die Architektur entscheidend: AI-getriebene Entscheidungen müssen mit vollständigen Audit-Trails, Erklärungs-Komponenten und definierten Eskalationspfaden eingebettet sein.

VulnOps — die neue Funktion

Der Begriff VulnOps ist in der Branche im Lauf von 2025 entstanden, aehnlich wie sich DevOps in den 2010er Jahren entwickelt hat. Die Analogie ist nicht zufällig: VulnOps ist die organisationale Antwort darauf, dass Vulnerability-Management nicht mehr ein quartalsweiser Lauf, sondern eine kontinuierliche Pipeline sein muss.

Die Werkzeuglandschaft im Mai 2026

Die folgende Übersicht ist ausdrücklich vendor-neutral und beschreibt Kategorien, nicht Empfehlungen. Die konkreten Werkzeuge ändern sich schnell — die Kategorisierung ist stabiler.

Was die Banking-IT bei der Auswahl beachten muss:

• Datenresidenz. Ein Modell, das in einer US-Cloud läuft und Code-Snippets der Bank verarbeitet, ist DSGVO- und auslagerungsrechtlich anders zu bewerten als ein Modell, das in der eigenen Infrastruktur läuft.
• Audit-Fähigkeit. Kann das Werkzeug nachvollziehbar protokollieren, was es gemacht hat und auf welcher Basis es zu Schlüssen kam?
• Integration in bestehende Werkzeuge. Das beste AI-Werkzeug ist wertlos, wenn es nicht mit dem SIEM, dem Ticket-System und der CI/CD-Pipeline der Bank spricht.
• Vendor-Lock-in. Werden Trainingsdaten, Custom-Prompts oder Tooling-Integrationen so spezifisch für einen Anbieter, dass ein Wechsel teuer wird?

Banking-spezifische regulatorische Leitplanken

Eine deutsche Bank, die AI-Werkzeuge in die Verteidigung einführt, agiert nicht im rechtsfreien Raum. Vier Rahmen sind besonders relevant:

Banking-Szenario: Die xbank am Tag X+1

Realistische Grenzen — wo defensive AI im Mai 2026 noch nicht hilft

Was du aus dieser Einheit mitnimmst

1. Defensive AI hinkt offensiver AI im Mai 2026 nach, aber sie ist nicht abwesend — drei reife Einsatzfelder existieren: Code- und Pipeline-Sicherheit, Coding Agents jenseits von Code (GRC, Audit, IR), Detection und Response.
2. VulnOps ist die organisationale Antwort auf kontinuierliche Vulnerability-Discovery — analog zu DevOps, mit eigenen Metriken und Pipelines.
3. Die Werkzeuglandschaft ist kategorisierbar, nicht endgueltig vendor-fixiert. Eine Bank wählt nach Datenresidenz, Audit-Fähigkeit und Integrierbarkeit aus.
4. Die regulatorischen Leitplanken (DORA Art. 28, MaRisk AT 9, DSGVO Art. 35, EU AI Act — BAIT Kap. 9 noch parallel bis 31.12.2026) sind kein Hindernis, sondern ein Rahmen. Schatten-Einsatz ist heute das größere Risiko als bewusste Einführung.
5. Realistische Grenzen — Halluzinationen, hinkende Defensiv-Capabilities, Governance-Reibung — gehören in die Vorstandskommunikation, nicht in den Marketing-Sprech.

In 13.4 kommt der regulatorische Detail-Schliff: Wann ist ein AI-Vorfall ein schwerwiegender IKT-Vorfall nach DORA? Wie verändert sich die zweite Verteidigungslinie nach MaRisk AT 4.4? Und was bedeutet der EU AI Act ab August 2026 für die Bank-IT-Security?

Quellen und weiterführendes Material

• BaFin — Merkblatt zum Einsatz von KI in Finanzinstituten — die deutsche Aufsichtsperspektive auf KI-Einsatz
• EU AI Act — offizielle Seite der Europäischen Kommission
• CSA Strategy Briefing „The AI Vulnerability Storm” — Originalpapier mit Priority Actions
• OWASP Top 10 für LLM-Anwendungen 2025 — die Risikoperspektive auf eigene AI-Einführung
• MITRE ATLAS — Adversarial Threat Landscape für AI-Systeme
• Modul 4 dieser Academy — Defense in Depth als ergänzende Strategie
• Modul 7 dieser Academy — Drittanbieter-Risikomanagement
• Modul 8 dieser Academy — Three Lines of Defense