Sebastien Rousseau
Kontakt ›

Agentische Engineering für Banken: ein Blueprint 2026 für den Vorstand und die Ingenieure, die ihn bauen werden

Agentische KI hat den Schritt vom Pilot in die Produktion in der globalen Bankbranche vollzogen. 70 % der Institute setzen sie in irgendeiner Form ein; nur eine von fünf verfügt über ein ausgereiftes Governance-Modell. Gleichzeitig agieren autonome Gegner mit Maschinengeschwindigkeit, das COBOL-Altlast-Inventar, mit dem neue Systeme interoperieren müssen, wurde für die Batch-Annahmen der 1960er Jahre geschrieben, und die Hochrisiko-Frist des EU-KI-Gesetzes (2. August 2026) ist zwölf Wochen entfernt. Dies ist die Engineering- und Governance-Position, die eine Bank einnehmen muss.

31 Min. Lesezeit

Agentische KI hat den Schritt vom Pilot in die Produktion in der globalen Bankbranche vollzogen. Siebzig Prozent der Institute setzen sie in irgendeiner Form ein; nur eine von fünf verfügt über ein ausgereiftes Governance-Modell. Gleichzeitig agieren autonome Gegner mit Maschinengeschwindigkeit, das COBOL-Altlast-Inventar, mit dem neue Systeme interoperieren müssen, wurde für die Batch-Annahmen der 1960er Jahre geschrieben, und die Hochrisiko-Frist des EU-KI-Gesetzes ist zwölf Wochen entfernt. Dies ist die Engineering- und Governance-Position, die eine Bank einnehmen muss.

Wesentliche Erkenntnisse

  • Der Übergang vom Vibe Coding zur spezifikationsgesteuerten Entwicklung ist nicht länger Wunschdenken. Andrej Karpathy, der „Vibe Coding" im Februar 2025 geprägt hatte, räumte ein Jahr später ⧉ ein, dass die Ära endet und der neue Standard für Profis agentische Engineering ist – die Orchestrierung von Agenten gegen detaillierte Spezifikationen mit menschlicher Aufsicht.
  • Die Bankenadoption ist real und beschleunigt sich. 70 % der Bankhäuser ⧉ berichten von einer Nutzung agentischer KI in irgendeiner Form (16 % in Produktion, 52 % im Pilot, EY 2026); 44 % der Finanzteams werden sie dieses Jahr nutzen – ein Anstieg um über 600 % gegenüber dem Vorjahr laut Wolters Kluwer.
  • Die Governance ist nicht Schritt gehalten. Deloittes State of AI 2026 stellt fest, dass nur eines von fünf Unternehmen ein ausgereiftes Governance-Modell für autonome KI-Agenten besitzt. Deloittes Auswertung der MIT AI Risk Database identifiziert mehr als 350 Risiken ⧉, die aus autonomem oder agentischem Verhalten erwachsen können.
  • Die Bedrohungslandschaft hat sich industrialisiert. Anthropic gab im November 2025 bekannt, dass die chinesische staatlich gesteuerte Gruppe GTG-1002 Claude Code gekapert hat, um autonome Spionage gegen rund 30 Ziele zu führen, wobei die KI 80–90 % der taktischen Operationen eigenständig übernahm. Flashpoint registrierte einen Anstieg illegaler KI-bezogener Diskussionen um 1.500 % ⧉ allein zwischen November und Dezember 2025.
  • Das Altlast-Inventar ist die stille Restriktion. Finanz-IT-Budgets werden zu 70–75 % von Legacy-Wartung gebunden, 63 % der Banken setzen weiter auf vor 2000 geschriebenen Code, und die meisten Banken berichten von nur ein bis zwei internen Personen, die das COBOL warten können, auf dem ihre Kernplattformen laufen. Agentische KI ist nun der dominante Ansatz, diese Lücke zu schließen.
  • Der Regulierungsstapel konvergiert. Unter dem EU-KI-Gesetz löst der 2. August 2026 die vollständige Durchsetzbarkeit für Hochrisiko-KI-Systeme aus (Anhang III nennt ausdrücklich Kredit-Scoring und Bonitätsbewertung). DORA ist bereits in Kraft. SR 11-7 ist in der Aufsichtspraxis auf LLMs und agentische Systeme ausgedehnt. Die Bußgelder reichen bis 35 Mio. € oder 7 % des weltweiten Jahresumsatzes.
  • Menschliche Aufsicht ist kein einheitlicher Begriff. Die Unterscheidung zwischen HITL (Human-in-the-Loop, der Agent kann ohne ausdrückliche menschliche Freigabe nicht ausführen) und HOTL (Human-on-the-Loop, der Agent agiert autonom unter menschlicher Überwachung) ist das Arbeitsrahmenwerk für Artikel 14 des EU-KI-Gesetzes, und jeder Hochrisiko-Agent benötigt eine ausdrückliche Position, welches Modell gilt.
  • Die meisten Agenten werden gekauft, nicht gebaut. Drittpartei-Risikomanagement unter DORA ist die lauteste unterschätzte Herausforderung 2026. Lieferanten werden den Großteil der agentischen Fähigkeiten liefern, die Banken einsetzen; die regulatorische Verantwortung bleibt bei der Bank, und die meisten bestehenden Lieferantenverträge können die Dokumentationsanforderungen aus Artikel 13 nicht erfüllen.
  • Agentische Engineering ist nicht „ChatGPT plus MCP-Server". Es ist eine strukturelle Ownership-Position über die Ende-zu-Ende-Flüsse des Hauses – Kundenreisen, Transaktionslebenszyklen, Steuerungsebene, Audit-Substrat, quantensichere Kryptografiebasis –, gebaut und betrieben durch die eigene Engineering-Funktion und nicht an einen Chatbot delegiert.

Das Jahr, in dem agentische Engineering unumgänglich wurde #

Die Diskussion über KI im Finanzdienstleistungsbereich war bis vor Kurzem von zwei eng benachbarten, aber unterschiedlichen Dingen geprägt: generative Chat-Schnittstellen (hilfreich, aber begrenzt) und Retrieval-Augmented-Generation-Muster auf Unternehmensdaten (nützlich, ebenfalls begrenzt). Was sich zwischen Ende 2025 und Anfang 2026 änderte: Die dritte Kategorie – autonome Agenten, die mehrstufige Workflows mit begrenzter menschlicher Aufsicht planen, ausführen und abschließen – wechselte von der technischen Demonstration in die operative Realität und überschritt gleichzeitig die Grenze sowohl zum Unternehmen als auch zum Bedrohungsakteur.

Andrej Karpathy, der im Februar 2025 den Begriff „Vibe Coding" prägte ⧉, beobachtete im darauffolgenden Jahr, wie professionelle Ingenieure darüber hinausgingen. Seine Revision – „agentische Engineering" – ist nun der Arbeitsterminus der Branche. Die Substanz der Verschiebung ist schlicht: In seriöser Softwarearbeit 2026 schreiben Ingenieure den Code zu 99 % der Zeit nicht direkt selbst. Sie orchestrieren Agenten, die es tun, und üben Aufsicht aus. Die Arbeit ist nicht mehr das Tippen von Zeichen in einen Editor; sie ist die Produktion von Spezifikationen, die einschränken, was die Agenten generieren dürfen, die Gestaltung der Verifikationsgates, die der Output passieren muss, und die Kuratierung der Architekturentscheidungen, die die Agenten umsetzen.

Diese Verschiebung klingt nach einer Engineering-Team-Diskussion. Im Banking ist sie das nicht. Sie ist eine Diskussion auf Aufsichtsratsebene, weil dieselbe agentische Fähigkeit, die die Erzeugung internen Codes neu schreibt, auch neu schreibt, wie externe Gegner operieren, wie Regulatoren erwarten, dass Aufsicht ausgeübt wird, und wie der institutionelle Perimeter definiert ist. Eine Bank, die ihre Position zur agentischen Engineering bis Ende 2026 nicht selbst besitzt, ist nicht eine Bank, die der Frage ausgewichen ist. Es ist eine Bank, deren Lieferanten, Gegner und Regulatoren die Frage für sie beantwortet haben.

Der Stand der Adoption im Banking #

Das Gesamtbild ist unmissverständlich. Laut quer durch 2026er Umfragen verdichteten Daten berichten 70 % der Bankenführungskräfte ⧉, dass ihre Häuser agentische KI bereits in irgendeiner Form nutzen. Gartner prognostiziert ⧉, dass Ende 2026 rund 40 % aller Finanzdienstleister KI-Agenten in irgendeiner Form betreiben werden. Die KI-Ausgaben im Finanzsektor sind laut IDC auf Kurs zu 67 Mrd. US-Dollar bis 2028. McKinsey schätzt, dass agentische KI Relationship-Managern im Banking 10–12 Stunden pro Woche zurückgeben kann.

Das Bild der Umsetzung ist weniger ermutigend. KPMG berichtet ⧉, dass 99 % der Unternehmen planen, autonome Agenten in Produktion zu bringen, aber nur 11 % es getan haben. EY findet, dass 34 % der Führungskräfte mit dem Einsatz von KI-Agenten begonnen haben und nur 14 % sie vollständig implementiert haben. Forrester stellt fest, dass 57 % der Organisationen glauben, ihnen fehlten die internen Fähigkeiten, um aus agentischer KI Nutzen zu ziehen. Die Lücke zwischen Absicht und Umsetzung ist kein Marketingartefakt. Sie ist Ausdruck der Engineering-, Governance- und Kulturarbeit, die noch nicht geleistet wurde.

Die britische Financial Conduct Authority hat öffentlich Bedenken ⧉ geäußert, dass das Einführungstempo die Reife der Governance überholt – eine Spannung, die die Chief Data Officer der FCA, Jessica Rasu, als kurzfristiges Risiko für Retail-Verbraucher gerahmt hat. McKinsey warnt zudem ⧉, dass Banken, die ihre Geschäftsmodelle nicht anpassen, bis 2030 weltweit bis zu 170 Mrd. US-Dollar an Gewinnen verlieren könnten. Beide Beobachtungen sind zugleich richtig. Die Frage ist nicht, ob bewegt werden muss, sondern wie – mit der operativen und Governance-Integrität, die Finanzdienstleistungsregulierung seit jeher verlangt und die agentische Systeme noch schärfer erforderlich machen.

Drei Risikovektoren, die Banken verinnerlichen müssen #

Vor jedem Architekturgespräch sollte der Aufsichtsrat auf drei Risiken blicken, die spezifisch für agentische Systeme sind und früher eintreffen, als die meisten Banken eingeplant haben.

1. Der autonome Gegner #

Die irritierendste Entwicklung 2026 ist die Operationalisierung agentischer KI auf der Angreiferseite. Im August 2025 berichtete Anthropic von einer Kategorie, die es Vibe Hacking ⧉ nannte: Cyberkriminelle, die agentische KI für skalierbare, ausgefeilte Angriffe einsetzen, mit der KI eingebettet in Aufklärung, Credential-Harvesting, Netzwerkdurchdringung und Analyse gestohlener Daten. Im November 2025 ⧉ gab Anthropic bekannt, eine Kampagne einer chinesischen staatlich gesteuerten Gruppe (bezeichnet als GTG-1002) unterbrochen zu haben, die Claude-Code-Instanzen kaperte, um autonome Spionage gegen rund dreißig Ziele aus Verteidigung, Energie und Technologie zu führen, wobei die KI 80–90 % der taktischen Operationen übernahm und mit tausenden Anfragen pro Sekunde arbeitete – Geschwindigkeiten, die menschliche Operatoren nicht erreichen können.

Im Januar 2026 wurde Step Finance – ein Solana-basierter DeFi-Portfoliomanager – auf eine Weise kompromittiert, die einen Geräteeinbruch in einen 27–30-Millionen-Dollar-Verlust verwandelte, weil die KI-Trading-Agenten des Unternehmens Berechtigungen besaßen, große Transfers ohne menschliche Freigabe auszuführen. Der Angreifer setzte die KI selbst per Social Engineering ein und behauptete, ein autorisiertes Bug-Bounty-Programm zu betreiben. Die Lehre ⧉ war nicht, dass KI inhärent unsicher sei; es war, dass ein KI-Agent, der behauptete Autorisierungen ohne Verifikation akzeptiert, eine Perimeterschwäche ist.

Der Aggregattrend ist das, was Banken verinnerlichen müssen. Flashpoints 2026 Global Threat Intelligence Report identifizierte einen Anstieg illegaler KI-bezogener Diskussionen um 1.500 % ⧉ zwischen November und Dezember 2025, wobei Angreifer aktiv autonome Systeme entwickeln, die Daten extrahieren, Infrastruktur rotieren, Nachrichten anpassen und aus gescheiterten Versuchen lernen – ohne fortlaufende menschliche Aufsicht. JPMorgans Jamie Dimon hat öffentlich klar gemacht ⧉, dass der anfängliche Vorteil dieser Technologie der Offensive zukommt, nicht der Defensive. Die Implikation ist unbequem: Eine Bank, die klassische Sicherheitsoperationen gegen agentische Gegner fährt, befindet sich strukturell in der Lage eines Schachspielers, dessen Gegner einen Computer erhalten hat.

2. Die Code-Qualitätsregression #

Der zweite Vektor ist intern und leiser. LLM-generierter Code wird in Abwesenheit von Spezifikationsdisziplin und rigoroser Verifikation mit einer deutlich höheren Defektrate ausgeliefert als von Menschen geschriebener Code. Eine SonarQube-Analyse von fünf Frontier-LLMs ⧉, die Java-Code erzeugten, ergab, dass über 70 % der in Llama 3.2 90B festgestellten Schwachstellen die Schweregradstufe BLOCKER erreichten und rund zwei Drittel der Schwachstellen von GPT-4o und OpenCoder-8B mit BLOCKER oder CRITICAL bewertet wurden. Pearce et al. (IEEE S&P) fanden, dass rund 40 % der LLM-generierten Programme in sicherheitskritischen Kontexten Schwachstellen enthielten. Yan et al. (2025) verorten die Bandbreite bei 9,8–42,1 % über ihre Benchmarks. Ein separater Katalog von Fu et al. identifizierte 43 CWEs in drei KI-Code-Generierungstools.

Für eine nicht regulierte Industrie ist das eine Produktivitätssteuer. Für eine Bank ist es ein regulatorisches und operatives Risiko, das sich verstärkt. Code, der mit hoher Schwachstellenrate in ein System ausgeliefert wird, das Zahlungen, Settlement oder Kundendaten verarbeitet, ist kein abstraktes Code-Qualitätsthema; es ist die Oberfläche, die Gegner der GTG-1002-Klasse 2027 mit denselben agentischen Werkzeugen abtasten werden, die ihn erzeugt haben. Die Verteidigung besteht nicht darin, LLM-generierten Code zu verbieten (kommerziell nicht möglich), sondern darin, ihn mit der Verifikations- und Spezifikationsinfrastruktur zu umgeben, die Defekte vor dem Deployment sichtbar werden lässt. Das ist der praktische Grund, weshalb spezifikationsgesteuerte Entwicklung mit hohem Tempo in Unternehmens-Engineering-Organisationen Einzug hält, die keine nativen Technologiefirmen sind.

3. Der Altlast-Anker #

Der dritte Vektor ist derjenige, den Banken am besten kennen und den der agentische Übergang zugleich dringlicher und besser handhabbar gemacht hat. Mehr als 70 % der Fortune-500-Unternehmen verlassen sich weiterhin auf Mainframes, hält die Computer-Weekly-Analyse fest ⧉, häufig aufbauend auf Jahrzehnten verwobenem COBOL und RPG mit individueller Geschäftslogik. Konkret im Finanzsektor binden Legacy-Technologien 70–75 % des jährlichen IT-Budgets ⧉. Eine in der Branchenanalyse 2026 zitierte CIO-Studie ergab, dass 63 % der Banken weiterhin auf vor dem Jahr 2000 geschriebenen Code angewiesen sind, und mehr als 75 % berichteten, nur ein bis zwei Personen im Haus zur Pflege dieser Codebasis zu haben.

Was sich im Februar 2026 änderte, war die Verfügbarkeit glaubwürdiger agentischer Tools für die Legacy-Modernisierung. Anthropics Ankündigung, dass Claude Code COBOL-Abhängigkeiten kartieren, Workflows dokumentieren und Risiken identifizieren ⧉ könne, die menschliche Analysten Monate kosten würden – gepaart mit ähnlichen Fähigkeiten von Microsoft (GitHub Copilot for COBOL, Watsonx Code Assistant) und AWS (Mainframe Modernization mit agentischer KI) –, hat die Modernisierungskostenkurve materiell gedrückt. Die Reaktion auf den IBM-Aktienkurs (ein 13-%-Rückgang am Tag der Ankündigung) war ein wenig elegantes, aber treffendes Marktsignal. KI macht inzwischen rund ein Drittel der Modernisierungsinvestitionen in Unternehmen aus, und mehr als 75 % der Unternehmen setzen KI in ihrer Modernisierungsstrategie ein. Der Altlast-Anker ist erstmals ein handhabbares Engineering-Problem statt eines generationenübergreifenden.

Warum Vibe Coding im Banking nicht der Standard sein kann #

Es lohnt sich, präzise zu benennen, weshalb Vibe Coding – kurzer Prompt, beobachten, iterieren – als Standard-Workflow im regulierten Inventar scheitert. Der Fehlermodus ist nicht der offensichtliche (das LLM halluziniert gelegentlich). Der Fehlermodus ist strukturell und zeigt sich an vier Stellen gleichzeitig.

Die erste ist das Fehlen gemeinsamer Konventionen. Mehrere Ingenieure, die über Chat-Prompts arbeiten, produzieren innerhalb eines Quartals fünf verschiedene Wege, dieselbe Sache in derselben Codebasis zu lösen. In einem nicht regulierten Kontext ist das technische Schuld. In einem regulierten Kontext ist es die Oberfläche, die unter Prüfung bricht.

Die zweite ist der Kontextverfall. KI-Agenten sind zustandslos. In einem großen Projekt überschreiten Gespräche das Kontextfenster, und die Begründung früherer Architekturentscheidungen verflüchtigt sich. Derselbe Agent wird zwei Wochen später in einem neuen Chat die Umkehrentscheidung treffen, weil nichts die Begründung der ersten persistiert. Für Systeme, die einen Audit-Trail für Aufsichten brauchen, ist das strukturell unvereinbar.

Die dritte ist die unsichtbare Defektakkumulation. Die Befunde von Pearce, Yan und SonarQube sind keine Randfälle. Sie sind die Grundrate, mit der LLMs in Abwesenheit von Spezifikationsdisziplin und rigorosen Tests verwundbaren Code generieren. Eine Bank, die Vibe-Coding-Workflows in der Produktion fährt, akkumuliert diese Defekte in derselben Rate – ohne die Oberflächensichtbarkeit zu wissen, was ausgeliefert wurde.

Die vierte ist das regulatorische Traceability-Problem. Artikel 12 des EU-KI-Gesetzes verlangt automatisches Logging von Eingaben und Ausgaben für Hochrisiko-KI-Systeme. SR 11-7 verlangt dokumentierte Rollen für Modellverantwortliche und Validatoren, Change Management für Modellaktualisierungen und Berichterstattung an den Aufsichtsrat über das KI-Modellrisiko. DORA verlangt umfassendes IKT-Risikomanagement mit dokumentierten Nachweisen. Keine dieser Pflichten lässt sich durch einen Workflow erfüllen, dessen Hauptartefakt ein Chat-Verlauf ist, den niemand persistiert.

Die Schlussfolgerung ist nicht, dass LLMs für das Banking ungeeignet wären. Die Schlussfolgerung ist, dass der sie umgebende Workflow Spezifikationen, Audit-Trails und Verifikationsgates als erstklassige Ergebnisse erzeugen muss – nicht als nachgeholte Anhänge. Genau das ist spezifikationsgesteuerte Entwicklung operativ.

Spezifikationsgesteuerte Entwicklung in einem regulierten Inventar #

Spezifikationsgesteuerte Entwicklung (SDD) kehrt die Reihenfolge der Arbeit um. Statt in die Implementierung zu springen und mit einem Agenten zu iterieren, erstellt das Team zuerst eine Spezifikation – Architekturentscheidungen, Anforderungen, Schnittstellenverträge, Erfolgskriterien, Sicherheitsbedingungen –, und der Agent erzeugt Code, der die Spezifikation erfüllt. Die Verifikation ist strukturiert: Die Spezifikation legt fest, was die Ausgabe leisten muss, und ein separater Prozess (Testgenerierung, Code-Review, formale Verifikation, wo anwendbar) prüft, ob es erfüllt wurde.

Die praktische Werkzeuglandschaft hat sich Ende 2025 und Anfang 2026 konsolidiert. GitHubs Spec Kit ⧉ (Ende 2025 veröffentlicht) formalisiert die Absicht vor der Codegenerierung. AWS bettet Spec-First-Workflows direkt in seine Kiro-IDE ein. JetBrains und Cursor haben Planungsmodi eingeführt, die die KI-Interaktion strukturieren. Frameworks wie BMAD (Breakthrough Method for Agile AI-Driven Development) gehen weiter, mit Teams spezialisierter KI-Agenten, die die Rollen Analyst, Architekt, Entwickler und QA über den SDLC abbilden. Constitutional SDD, im Februar 2026 in einer arXiv-Arbeit formalisiert, bettet ausdrückliche Sicherheitsanforderungen mit CWE-Schwachstellenzuordnungen in die Spezifikation selbst ein.

Für eine Bank ist die relevante Variante das, was Augment Codes Analyse spec-anchored development nennt – Spezifikationen kommen zuerst, KI erzeugt Code unter ihren Restriktionen, und zusätzliche Governance-Schichten (konstitutionelle Bedingungen, Supervisions-Checkpoints, menschliche Freigabegates) liegen zwischen Generierung und Merge. Das ist die einzige Variante, die den Audit-Trail erzeugt, den Artikel 12 des EU-KI-Gesetzes erwartet, die dokumentierte Validatorenrolle, die SR 11-7 verlangt, und die Change-Management-Disziplin, die DORA fordert.

Die erforderliche Investition ist real, aber zugleich handhabbar. Die Institute, die dies gut machen, haben den Schwerpunkt der Ingenieursarbeit verlagert: weg vom Tippen von Zeichen, hin zur Produktion zweier Artefakte: einer Spezifikation, die der Agent erfüllen soll, und einer Verifikationsumgebung, die der Output passieren muss. Die kognitive Anforderung an den Ingenieur ist in mancher Hinsicht höher (Klarheit der Absicht zählt mehr denn je) und in anderer geringer (die mechanische Boilerplate-Arbeit entfällt). Häuser, die diesen Wechsel noch nicht vollzogen haben, betreiben einen Modus, in dem das LLM ein schnellerer Tipper ist. Diese Position ist in einem regulierten Inventar über die nächsten zwölf Monate hinaus nicht überlebensfähig.

Der nun geltende Regulierungsstapel #

Der 2026er Regulierungsperimeter um KI im Banking ist keine Checkliste mehr; er ist ein Stapel überlappender Pflichten, die gemeinsam zu denken sind. Das einzelne folgenreichste Datum ist der 2. August 2026, an dem die Pflichten für Hochrisiko-Systeme aus dem EU-KI-Gesetz vollständig durchsetzbar werden ⧉. Anhang III klassifiziert Kredit-Scoring, Bonitätsprüfung, Risikobeurteilung in Lebens- und Krankenversicherung sowie die Bewertung oder Klassifizierung der finanziellen Stellung von Personen ausdrücklich als hochriskant. Die daraus folgenden Pflichten umfassen Konformitätsbewertungen, Qualitätsmanagementsysteme, Risikomanagementrahmen, technische Dokumentation, Eintragung in die EU-Datenbank, robuste Datengovernance, menschliche Aufsicht und Cybersicherheitsmaßnahmen. Die Strafen für Verstöße gegen Hochrisiko-Pflichten reichen bis 35 Mio. € oder 7 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Daneben:

Drei Modi KI-gestützter Entwicklung im Vergleich #

Dimension Vibe Coding Spezifikationsgesteuerte Entwicklung Agentische Engineering
Primäre Eingabe Kurzer Prompt Formale Spezifikation Spezifikation + Orchestrierungsplan
Rolle des Ingenieurs Prompt-Iterator Spezifikationsautor Orchestrator und Verifizierer
Output-Disziplin Direkte Codegenerierung Code durch Spezifikation eingeschränkt Multi-Agent-Workflows: Code, Tests, Dokumente
Audit-Trail Chat-Verlauf (nicht persistiert) Spezifikation + erzeugter Code + Tests Spezifikation + Agent-Traces + Verifikationsartefakte
Defektrate (nur LLM) 10–40 % Schwachstellenrate (Basislinie der Literatur) Materiell reduziert durch Spezifikationsbeschränkungen Am niedrigsten mit Verifikationsgates
Regulatorische Traceability Nicht ausreichend für Hochrisiko-KI Kompatibel mit Artikel 12 des EU-KI-Gesetzes Konzipiert für Artikel 12 + SR 11-7 + DORA
Geeignet für Banking? Nein, für Produktion Ja, mit Governance Ja, mit ausgereifter Governance
Fähigkeits-Grenze Begrenzt durch Single-Shot-Prompts Begrenzt durch Spezifikationsqualität Begrenzt durch Orchestrierungsqualität

Quelle: Synthese aus Karpathys Kommentaren (2026), Augment Codes SDD-Analyse ⧉, CGIs SDD-Analyse ⧉ und der akademischen Literatur zu LLM-Code-Generierungs-Schwachstellenraten (Pearce et al., Yan et al., Fu et al., 2023–2025).

Die agentische Bank bauen: ein Architekturblick #

Die strategische Position hinter diesen Workflows muss der Vorstand ausdrücklich besitzen. Agentische Engineering im Banking ist keine Entwickler-Produktivitäts-Initiative. Sie ist eine institutionelle Fähigkeit, die Ende-zu-Ende-Kundenreisen, den gesamten Transaktionslebenszyklus und das kryptografische sowie das Audit-Substrat umfasst, auf denen beides ruht. Vier Schichten dieser Fähigkeit verdienen die direkte Aufmerksamkeit der Geschäftsleitung – von oben nach unten:

Schicht 4 – Agent Control Plane Governance, Audit, Notabschaltungen, Verhaltensauffälligkeitserkennung, menschliche Übersteuerung. HITL- und HOTL-Konfigurationen je Agentenklasse.

Schicht 3 – Agentische Workflows Kundenreisen, interne Operationen, Entwicklungs-Pipeline. Standardmäßig spezifikationsgesteuert für Hochrisiko-Flüsse.

Schicht 2 – Daten- und Modellebene AIBOM (AI Bill of Materials), Modellregister, Retrieval-Substrat, Versionskontrolle für Prompt-Templates, Fine-Tune-Herkunft.

Schicht 1 – Quantensicheres Fundament ML-KEM, ML-DSA, hybride PKI, Krypto-Agilität. Das Substrat, von dem die Integritätsaussagen jeder höheren Schicht abhängen.

Schicht 1 – Das quantensichere Fundament. Jede darüberliegende Schicht setzt die Integrität des kryptografischen Substrats voraus. Mit der G7-Roadmap, dem Drei-Phasen-Plan des NCSC und BIS Project Leap auf öffentlicher Aktenlage ist dies kein Nischenthema mehr. Agentische Systeme, deren Audit-Trails unter klassischem ECDSA signiert werden oder deren Schlüsseletablierung von RSA oder ECDH abhängt, werden ihre Integritätsaussagen mit der Kryptografie zugleich verlieren. Die Häuser, die das richtig machen, ziehen die Post-Quanten-Arbeit nach vorn und behandeln ML-KEM, ML-DSA und hybride PKI als das Substrat, auf dem jede höhere Schicht ihre Audit- und Integritätsgarantien ruht.

Schicht 2 – Die Daten- und Modellebene. Hier lebt die AI Bill of Materials (AIBOM). Analog zur Cryptographic Bill of Materials in der Post-Quanten-Migrationsplanung ist die AIBOM das Inventar jedes Modells, jedes Datensatzes, jedes Prompt-Templates, jedes Retrieval-Index, jedes Fine-Tunes und jeder KI-Drittabhängigkeit, die das Haus betreibt. Es ist das Artefakt, das Artikel 49 des EU-KI-Gesetzes faktisch verlangt, das Inventar, das SR-11-7-Prüfungen nun einfordern, und die Grundlage jeder glaubwürdigen Governance-Position. Die meisten Häuser haben es nicht. Sie werden es bis August benötigen.

Schicht 3 – Agentische Workflows. Diese Schicht bauen die meisten Häuser derzeit, oft ohne hinreichende Aufmerksamkeit für die Schichten 1, 2 und 4. Die Workflows reichen von intern (Codegenerierung, Erstellung regulatorischer Dokumente, Kundenservice-Triage) über kundenseitig (Relationship-Manager-Copiloten, Onboarding, KYC-Orchestrierung, Transaktionsmonitoring, FX-Optimierung) bis vollautonom (Treasury-Operationen, bestimmte Trading- und Risikomanagement-Funktionen, in denen die Aufsichtstoleranz es erlaubt). Die strategische Disziplin auf dieser Schicht: sie als Systems Engineering zu behandeln, nicht als Anwendungsentwicklung – Orchestrierungsmuster, Eskalationsregeln, Human-in-the-Loop-Gates und Audit-Emission sind erstklassige Designanliegen.

Schicht 4 – Die Agent Control Plane. Deloitte beschreibt das als "Agent Control Room" ⧉: die Echtzeit-Auditierung, Aktionsprotokollierung, Verhaltensauffälligkeitserkennung, Notabschaltungen und menschliche Übersteuerung, die jeden Agenten in der Produktion umgeben. Der Step-Finance-Verlust war technisch nicht das Versagen einer KI. Er war ein Control-Plane-Versagen: Die Agenten besaßen Berechtigungen, die sie nicht hätten haben dürfen, und die Verhaltensauffälligkeit, die einen Stopp hätte auslösen müssen, tat es nicht. Die Häuser, die die Control Plane zuerst bauen – bevor sie Agentendeployment skalieren –, werden 2027 keine Step-Finance-Klasse-Vorfälle erleben.

Der relevante Vergleich für den Vorstand ist nicht „Machen wir mehr KI als unsere Wettbewerber?". Er lautet, ob das Haus alle vier Schichten besitzt oder ob eine oder mehrere stillschweigend an einen Lieferanten delegiert sind, der vertraglich nicht in der Lage ist, die Dokumentationsanforderungen aus Artikel 13 des EU-KI-Gesetzes zu erfüllen. Letztere Position sieht in Ordnung aus, bis ein Regulator die Frage stellt.

Menschliche Aufsicht in der Praxis: HITL vs. HOTL #

Die einzelne Unterscheidung innerhalb von Schicht 4, auf die Regulatoren 2026 am stärksten schauen, liegt zwischen zwei Aufsichtsmodellen. Beide sind Formen menschlicher Aufsicht; sie unterscheiden sich in Latenz, Skala und der Annahme, die der Regulator zum Agentenverhalten zu treffen bereit ist.

Human-in-the-Loop (HITL) ist das Modell, in dem ein Agent eine folgenreiche Aktion ohne ausdrückliche menschliche Freigabe nicht ausführen darf. Der Agent bereitet die Entscheidung vor, präsentiert sie und wartet. Ein KYC-Remediation-Agent, der ein Konto zur Schließung kennzeichnet, es aber ohne die Unterschrift eines Compliance Officers nicht schließen kann, ist HITL. Der Trade-off ist operativ: HITL ist sicherer und erzeugt einen eindeutigen Audit-Trail nach Artikel 14, skaliert aber nicht in volumenstarken, latenzarmen Workflows.

Human-on-the-Loop (HOTL) ist das Modell, in dem ein Agent autonom innerhalb begrenzter Parameter agiert, während Menschen Telemetrie in Echtzeit überwachen und jederzeit die Befugnis behalten, den Agenten zu stoppen. Ein Echtzeit-Betrugsscreening-Agent, der Transaktionen, die bestimmten Risikomustern entsprechen, automatisch blockiert, während ein Operations-Team Alarmvolumina überwacht und bei Anomalien eingreift, ist HOTL. Der Trade-off ist umgekehrt: HOTL skaliert, hängt aber davon ab, dass die Parameter des Agenten korrekt gesetzt sind und dass die Verhaltensauffälligkeitserkennung Drift erfasst, bevor Schaden eintritt.

Artikel 14 des EU-KI-Gesetzes schreibt nicht HITL oder HOTL vor; er verlangt, dass die menschliche Aufsicht bedeutsam ist. Die praktische Implikation: Jeder Hochrisiko-Agent, den die Bank betreibt, muss eine ausdrückliche, dokumentierte Position dazu haben, welches Modell gilt, warum, und wie der Eskalationspfad aussieht, wenn der Agent Situationen außerhalb seiner begrenzten Parameter trifft. Die meisten Banken in Piloten 2025 hatten diese Dokumentation nicht. Die meisten Banken mit Produktivagenten bis August 2026 werden sie benötigen.

Die Entscheidungsregel ist nicht kompliziert. Für folgenreiche, volumenarme, irreversible Aktionen – Kreditverweigerung gegenüber natürlichen Personen, Kontoschließung, Autorisierung großer Überweisungen, Einreichung regulatorischer Meldungen – ist HITL der vertretbare Standard. Für volumenstarke, reversible, parameterbegrenzte Aktionen – Transaktionsmonitoring-Alarme, Dokumentenklassifizierung, routinemäßige Kundenservice-Triage – ist HOTL angemessen, sofern die Verhaltensauffälligkeitserkennung und die Notabschaltungsinfrastruktur reif sind. Banken, die jeden Workflow als HITL behandeln, werden den operativen Hebel agentischer Systeme nicht heben. Banken, die jeden Workflow als HOTL behandeln, werden irgendwann einen Step-Finance-Moment erleben.

Kaufen vs. Bauen: das Problem der Drittparteienagenten #

Die Realität 2026, die sich an die meisten Banken herangeschlichen hat, lautet: Sie werden agentische Fähigkeiten überwiegend nicht bauen. Sie werden sie kaufen. Die Lieferantenlandschaft – Oracles im Februar 2026 gestartete agentische Banking-Plattform, IBMs Watsonx, Microsofts Copilot-Suite, AWS Bedrock Agents, Salesforce Agentforce, ServiceNows NowAssist und die Welle fintech-spezialisierter Agentenanbieter – bewegt sich schneller als die interne Bank-Engineering. Die strategische Konsequenz: Die meisten Agenten, die 2027 innerhalb einer Bank arbeiten, werden von jemand anderem geschrieben worden sein, und die Governance-Frage lautet nicht mehr „Können wir unseren Agenten vertrauen?", sondern „Können wir den beschafften Agenten vertrauen, und können wir das einem Regulator gegenüber belegen?".

Dies ist die lauteste unterschätzte Herausforderung unter DORA. Die Artikel 28–30 der Verordnung machen IKT-Drittparteien-Risikomanagement zu einem aktiven Aufsichtsfeld, mit ausdrücklichen Anforderungen an vertragliche Bestimmungen, laufende Überwachung, Konzentrationsrisikobewertung und Ausstiegsstrategien. Die Europäischen Aufsichtsbehörden führen ein Register kritischer IKT-Drittanbieter, mit direkten Aufsichtsbefugnissen gegenüber den als solchen ausgewiesenen. Die neue operative Realität: Die KI-Lieferanten von 2026 – Frontier-Modellanbieter, Agentenplattformanbieter, KI-gestützte SaaS – sind zunehmend die IKT-Drittparteien, für die DORA geschrieben wurde.

Für eine Bank in der Käuferposition gelten drei praktische Disziplinen:

Verlangen Sie die AIBOM vom Lieferanten. Jedes Agentenprodukt, das für den Einsatz in Hochrisiko-Workflows beschafft wird, muss mit einer dokumentierten Stückliste geliefert werden, die die zugrunde liegenden Modelle, Datenherkunft und -beschränkungen, angewandte Fine-Tunes, abgerufene Retrieval-Indizes, Prompt-Template-Versionen und die Abhängigkeitskette zu nachgelagerten Agentenkomponenten umfasst. Das ist das Artefakt, das die Bank zur Erfüllung von Artikel 13 des EU-KI-Gesetzes braucht. Die Bank kann es nicht nachträglich von einem Lieferanten beziehen, der sich vertraglich nicht zur Bereitstellung verpflichtet hat.

Testen Sie die Blackbox, nicht die Broschüre. Lieferantenauswertungen drehten sich bisher um Funktionsvergleiche und Referenzkundeninterviews. Für agentische Systeme ist das nicht ausreichend. Das Institut muss verhaltensbasierte Tests des Agenten unter produktionsnahen Bedingungen durchführen – einschließlich adversarialer Tests auf Prompt Injection, Widerstand gegen Social Engineering (der Step-Finance-Vektor), Drift unter Datenverteilungswechseln sowie Latenz und Fehlerverhalten von Notabschaltungen und Übersteuerungspfaden. Die meisten aktuellen Lieferantenverträge erlauben diese Testtiefe ohne spezifische Verhandlung nicht; diese Verhandlung muss vor Vertragsabschluss erfolgen, nicht danach.

Verhandeln Sie Verträge auf Artikel-13-Bedingungen neu. Die meisten bestehenden KI-Lieferantenverträge enthalten keine der Dokumentations-, Audit-, Modelländerungs-Benachrichtigungs-, Vorfallmeldungs- und Unter­auftragnehmer-Offenlegungspflichten, die EU-KI-Gesetz und DORA gemeinsam verlangen. Die Regulativ-Analyse zu britischen Häusern ⧉ war an diesem Punkt deutlich: Die juristische Prüfung von Lieferantenverträgen dauert Wochen, und die meisten Häuser können Artikel 13 für ein Modell, dessen Innenleben ihr Lieferant nie vertraglich offenzulegen verpflichtet war, nicht erfüllen. Die regulatorische Verpflichtung sitzt beim Einsetzenden, nicht beim Lieferanten. Beschaffungsteams müssen das vor dem nächsten Verlängerungszyklus wissen, nicht erst nach einer aufsichtsrechtlichen Anfrage.

Die Vorstandszusammenfassung lautet: Die Lieferantenbeziehung hat sich vom Beschaffungs- zu einem Risikotransfer-Verhältnis verschoben – und das Risiko überträgt sich tatsächlich nicht. Die Bank bleibt der Einsetzende. Die Bank bleibt haftbar. Die Bank braucht die vertraglichen Instrumente und die Testdisziplin, die ihre Haftung handhabbar – statt bloß formell – machen.

Was das je Banktyp bedeutet #

Die richtige Antwort variiert. Die folgende Segmentierung ist grob, keine Vorschrift.

Tier-1-Universalbanken #

Häuser mit Bilanzsummen ab 1 Billion US-Dollar und globaler Präsenz sind zugleich am stärksten exponiert (breitester regulatorischer Perimeter, größtes Altlast-Inventar, hochwertigstes Ziel für autonome Gegner) und am besten ausgestattet. Die strategische Priorität: zuerst die Control Plane bauen – Schicht 4 der obigen Architektur – und spezifikationsgesteuerte Entwicklungsdisziplin in der internen Engineering-Funktion etablieren, bevor das Agentendeployment weiter skaliert wird. Die Wettbewerbsfolge des Erfolgs ist erheblich; die des Misslingens existenziell, angesichts der Strafexposition unter dem EU-KI-Gesetz und der operativen Exposition gegenüber GTG-1002-Klasse-Bedrohungen.

Mittelständische und Regionalbanken #

Die Wettbewerbsfrage für Tier-2-Banken ist schärfer als für Tier 1. Sie sehen denselben regulatorischen Perimeter ohne dasselbe Governance-Budget, dieselbe Bedrohungsoberfläche ohne dieselben Verteidigungsressourcen und einen Kundenstamm, der sie zunehmend mit KI-nativen FinTechs vergleicht. Die praktische Antwort lautet: hart auf wenige geprüfte Lieferanten standardisieren (mit Verträgen, die Artikel 13 erfüllen), in spezifikationsgesteuerte Entwicklungsdisziplin statt in eigene Plattform-Engineering investieren und agentische Werkzeuge nutzen, um den COBOL-Modernisierungszeitplan zu verdichten, der zwei Jahrzehnte lang ein strategischer Anker war. Häuser, die hier früh handeln, werden den Technologieabstand zu Tier-1-Banken erstmals seit einer Generation materiell schließen.

FinTechs, PSPs und kryptonahe Institute #

Das FinTech- und Zahlungsinstitut-Segment hat das umgekehrte Problem: Agilität ist hoch, Governance häufig niedriger als bei vergleichbaren Banken, und die Strafexposition unter dem EU-KI-Gesetz ist für mittelgroße FinTechs potenziell existenziell. Die strategische Disziplin: KI-Governance als Produktreife-Gate behandeln, nicht als Compliance-Aufsatz – AIBOM, Audit-Substrat und spezifikationsgesteuerte Workflows von Anfang an in die Engineering-Kultur einbauen, statt sie unter Regulierungsdruck nachzurüsten. Für Häuser, deren Zahlungsinfrastruktur die SWIFT-CBPR+-Frist für strukturierte Adressen vom November 2026 schneidet, ist die Investition in agentische Engineering zugleich der natürliche Mechanismus, die Sanierungsarbeit für strukturierte Adressen zu industrialisieren – die Validierungsregeln, die Datenqualitätsdurchsetzung und die CI-Pipeline-Integration sind genau jene Muster, die spezifikationsgesteuerte Workflows handhabbar machen.

Interne Engineering-Funktionen #

Für die Ingenieure und Forscher, die dies lesen: Die tägliche Arbeitsdisziplin zählt. Verlagern Sie den Schwerpunkt vom Tippen von Zeichen auf die Erstellung von Spezifikationen und Verifikationsumgebungen. Behandeln Sie Agent-Traces, Zwischenpläne und Freigabegates als erstklassige Artefakte in der Versionskontrolle. Investieren Sie in Werkzeuge – Spec Kit, Kiro, Cursors Planmodus, Claude Code mit projektbezogenen Skill-Dateien –, die die Spezifikation zum dauerhaften Artefakt und den erzeugten Code zum verbrauchbaren machen. Die ergonomische Verschiebung ist real. Die berufliche Auszahlung liegt darin, dass die an der Frontlinie übernommene Disziplin zugleich diejenige ist, die aufsichtsrechtliche Prüfung übersteht.

Der 12-Wochen-Aktionsplan bis August 2026 #

Für den Executive Sponsor eines agentischen Engineering-Programms zwischen jetzt und dem EU-KI-Gesetz-Stichtag komprimiert sich die Arbeit in eine zwölfwöchige Abfolge. Der untenstehende Plan ist nicht vollständig; er ist das Minimum, das ein Aufsichtsrat von einem glaubwürdigen Programm bis zum 2. August 2026 erwarten sollte.

Wochen 1–2 – Erstellen Sie die AIBOM. Aufbau des zentralen Inventars aller KI-Systeme, Modelle, Datensätze, Prompt-Templates, Retrieval-Indizes, Fine-Tunes und KI-Drittabhängigkeiten in Produktion oder Entwicklung. Jeder Eintrag wird der Annex-III-Klassifikation des EU-KI-Gesetzes zugeordnet. Ergebnis: eine einheitliche Quelle der Wahrheit, die CRO, CCO, CISO und CTO jeweils abfragen können.

Wochen 3–4 – Aufsichtsmodell je System klassifizieren. Für jeden hochriskanten und folgenreichen Agenten ausdrücklich dokumentieren, ob HITL oder HOTL gilt, mit Begründung, Eskalationspfad und namentlich benannter verantwortlicher Person unter SM&CR (UK) oder dem entsprechenden nationalen Regime. Bleibt die Antwort unklar, gilt HITL als Standard, bis die Analyse abgeschlossen ist.

Wochen 5–6 – Agent Control Plane aufbauen oder härten. Echtzeit-Aktionsprotokollierung, Verhaltensauffälligkeitserkennung, Notabschalt- und Übersteuerungspfade auf jedem produktiven Agenten in Betrieb. Wo die Control Plane für ein System noch nicht existiert, geht dieses in einen eingeschränkten Bereitstellungsstatus, bis sie steht.

Wochen 7–8 – Lieferantenvertragsprüfung. Recht und Einkauf prüfen jeden aktiven KI-Lieferantenvertrag auf Artikel-13-Dokumentationsrechte, Modelländerungs-Benachrichtigung, Vorfallmeldung, Auditrechte und Unter­auftragnehmer-Offenlegung. Ergebnis: eine gestaffelte Liste – konform, sanierungspflichtig, ersatzpflichtig. Ersatzentscheidungen müssen jetzt beginnen, um in diesem Jahr noch abgeschlossen zu werden.

Wochen 9–10 – Trockenlauf der Konformitätsbewertung. Für jedes Hochrisiko-System unter Anhang III die Konformitätsbewertung so vollziehen, als käme die benannte Stelle nächste Woche. Das wird Lücken sichtbar machen, die auf dem Papier klein, in der Prüfung gravierend sind. Beheben, was sich beheben lässt; den Rest dokumentieren.

Wochen 11–12 – Pre-Cutover-Validierung und Vorstandsfreigabe. Abschließende Prüfung der AIBOM, der HITL/HOTL-Einstufungen, der Control-Plane-Evidenz, des Lieferanten-Sanierungsstandes und der Konformitätsbewertungsergebnisse. Namentliche Senior-Manager-Verantwortlichkeit bestätigt. Position im Aufsichtsratsprotokoll festgehalten. Notifizierung der Aufsicht, wo das Rahmenwerk eine Vorankündigung vorsieht.

Die Häuser, die diese zwölf Wochen vollziehen, werden die agentische Engineering nicht gelöst haben. Sie werden den Mindestrahmen geschaffen haben, den ein glaubwürdiges Programm benötigt. Häuser, die bis zur Veröffentlichung dieses Beitrags noch nicht begonnen haben, sind – wie es die Regulativ-Analyse zum SWIFT-Thema festhielt – nicht einzigartig nachlässig. Sie sind die Mehrheit. Die Frage, die jeder CCO, CRO und CTO in den nächsten vierzehn Tagen beantworten muss, lautet, ob das Haus im Mai handelt oder im Juli hastet.

Fazit #

Die harte Beobachtung, die sich in den letzten sechs Monaten branchenweit herauskristallisiert hat, lautet, dass die alten Arbeitsweisen im Unternehmensmaßstab nicht durch eine neue Technologie, sondern durch ein neues Arbeitsmuster überholt werden. Agentische Werkzeuge haben – mal in der Produktion, mal in Vorfallsberichten – Fehler und Lücken in Altlast-Inventaren sichtbar gemacht, die sich über Jahre still aufgebaut haben. Dieselben Werkzeuge haben böswilligen Akteuren Mittel an die Hand gegeben, die zuvor staatlichen Akteurspolster verlangten. Dieselben Werkzeuge, intern und mit Disziplin eingesetzt, sind der glaubwürdigste Pfad, den Häuser haben, um die Altlast-Lücke zu schließen, die regulatorische Frist im August 2026 zu erfüllen und das operative Tempo zu erreichen, das Kundenerwartungen und Wettbewerbsrealität verlangen.

Häuser, die diese Position intern besitzen – die agentische Engineering als strukturelle Fähigkeit der Bank behandeln und nicht als Produktivitätsaufsatz, der bei einem Lieferanten beschafft wird – werden in den nächsten zwei Jahren Vorteile aufstapeln. Häuser, die das nicht tun, werden in den nächsten zwei Jahren in Vorfallsberichten und Aufsichtsbefunden entdecken, was sie hätten bauen sollen. Die Wahl zwischen diesen beiden Ausgängen ist eine Vorstandsentscheidung 2026, keine Technologieentscheidung 2028.

Zur Einordnung auf dieser Website: Der Beitrag vom April 2026 zu Quantenschwellen behandelte die Hardware-Bahn, die Schicht 1 der obigen Architektur trägt; der Beitrag vom Mai 2026 zur Post-Quanten-Migration im Corporate Finance behandelte das kryptografische Substrat im Detail; die Analyse vom Mai 2026 zur pacs.008-Frist für strukturierte Adressen behandelte die regulatorische und Engineering-Disziplin, die spezifikationsgesteuerte Validierung handhabbar macht; und die Rust-Open-Source-Arbeit an KyberLib, pain001 und pacs008 fügt sich in den breiteren Versuch ein, produktionsreife Primitive – quantensicher, zahlungskonform, auditfähig – in die Hände der Engineering-Teams zu legen, die die agentische Bank bauen werden. Die Verbindung zwischen diesen Beiträgen ist nicht zufällig. Sie ist die Form der Arbeit, die die nächsten zwei Jahre verlangen.

Häufig gestellte Fragen #

Worin liegt der Unterschied zwischen generativer KI, agentischer KI und agentischer Engineering?

Generative KI erzeugt Inhalt als Antwort auf einen Prompt; sie ist reaktiv. Agentische KI verfolgt definierte Ziele autonom, greift auf Daten zu, nutzt Werkzeuge und setzt Aktionen über mehrstufige Workflows um, ohne in jedem Schritt einen menschlichen Prompt zu verlangen. Agentische Engineering – der Begriff, den Karpathy 2026 übernommen hat ⧉ – ist die Arbeitsdisziplin, Agenten gegen detaillierte Spezifikationen mit menschlicher Aufsicht zu orchestrieren. Für Banken zählt die Unterscheidung, weil regulatorischer Perimeter, Bedrohungsmodell und Engineering-Disziplin je Kategorie unterschiedlich sind. Eine Chat-Schnittstelle und ein vollautonomer Trading-Agent sind nicht in derselben regulatorischen Klasse; sie als solche zu behandeln, erzeugt Exposition auf beiden Enden.

Warum ist die EU-KI-Gesetz-Frist vom August 2026 so folgenreich für Banken?

Anhang III des KI-Gesetzes klassifiziert mehrere zentrale Banking-KI-Anwendungsfälle ausdrücklich als hochriskant: Bonitätsbewertung und Kreditscoring natürlicher Personen, Risikobeurteilung und Preisgestaltung in Lebens- und Krankenversicherung sowie Bewertung oder Klassifizierung der finanziellen Stellung von Personen. Ab dem 2. August 2026 müssen Einsetzende dieser Systeme die Einhaltung von Qualitätsmanagementsystemen, Risikomanagementrahmen, technischer Dokumentation, Konformitätsbewertungen, EU-Datenbankregistrierungen, robuster Datengovernance, menschlicher Aufsicht und Cybersicherheitsmaßnahmen nachweisen. Artikel 12 verlangt automatisches Logging von Eingaben und Ausgaben. Artikel 14 verlangt bedeutsame menschliche Aufsicht (HITL oder HOTL je nach System). Strafen für Verstöße reichen bis 35 Mio. € oder 7 % des weltweiten Jahresumsatzes. Die Arbeit zur Erfüllung dieser Pflichten ist Engineering-Arbeit – keine Dokumentationsarbeit – und der praktische Grund, weshalb sich die spezifikationsgesteuerte Disziplin im Q1 2026 beschleunigt hat.

Worin liegt der praktische Unterschied zwischen HITL und HOTL, und wann gilt welches?

HITL (Human-in-the-Loop) bedeutet, der Agent darf folgenreiche Aktionen ohne ausdrückliche menschliche Freigabe nicht ausführen. HOTL (Human-on-the-Loop) bedeutet, der Agent agiert autonom innerhalb begrenzter Parameter, während Menschen Telemetrie überwachen und jederzeit die Stoppbefugnis behalten. Artikel 14 des EU-KI-Gesetzes verlangt bedeutsame Aufsicht, schreibt aber kein Modell vor. Entscheidungsregel: HITL gilt, wenn die Aktion folgenreich, volumenarm und irreversibel ist (Kreditverweigerung, Kontoschließung, Autorisierung großer Überweisungen, Einreichung regulatorischer Meldungen); HOTL gilt, wenn die Aktion volumenstark, reversibel und parameterbegrenzt ist (Transaktionsmonitoring-Alarme, Dokumentenklassifizierung, routinemäßige Kundenservice-Triage). Beide setzen voraus, dass Notabschaltungs- und Übersteuerungsinfrastruktur produktiv und getestet ist; der Unterschied liegt darin, ob der Mensch der Ausführung vorgelagert (HITL) oder neben ihr (HOTL) steht.

Die meisten unserer Agenten werden von Lieferanten stammen. Wie erfüllen wir DORA und das EU-KI-Gesetz für Systeme, die wir nicht gebaut haben?

Die regulatorische Pflicht sitzt beim Einsetzenden, nicht beim Lieferanten. Die praktische Antwort ist dreigeteilt. Erstens: vor Vertragsabschluss eine dokumentierte AIBOM vom Lieferanten verlangen – Modellgenealogie, Datenherkunft des Trainings, Fine-Tunes, Prompt-Templates, Retrieval-Indizes, Abhängigkeitskette. Zweitens: Verhaltenstests des Agenten unter produktionsnahen Bedingungen durchführen, einschließlich adversarialer Tests auf Prompt Injection und Widerstand gegen Social Engineering. Drittens: Lieferantenverträge neu verhandeln, um Artikel-13-Dokumentationsrechte, Modelländerungs-Benachrichtigung, Vorfallmeldung, Auditrechte und Unter­auftragnehmer-Offenlegung zu enthalten – die meisten bestehenden Verträge haben keines davon. DORA, Artikel 28–30, deckt IKT-Drittparteien-Risikomanagement und ist der einschlägige regulatorische Anker auf europäischer Seite; FFIEC-Leitlinien sind das US-Pendant. Die Arbeit ist substanziell; sie lässt sich nicht aufschieben.

Wie besorgt sollten Banken über agentische Gegner wirklich sein?

Die ehrliche Antwort lautet, dass die Bedrohung real ist und sich operativ von früheren Cyberbedrohungen unterscheidet. Die Anthropic-Offenlegung zu GTG-1002 vom November 2025 ist das kanonische Beispiel: agentische KI, die 80–90 % der taktischen Operationen einer staatlich gesteuerten Spionagekampagne gegen rund dreißig Verteidigungs-, Energie- und Technologieziele übernimmt, mit tausenden Anfragen pro Sekunde. Der Step-Finance-Vorfall im Januar 2026 – ein Verlust von 27–30 Mio. US-Dollar, getrieben von KI-Trading-Agenten mit überdimensionierten Berechtigungen – ist das kanonische Beispiel dafür, wie ein interner KI-Einsatz zur Angriffsfläche werden kann. Flashpoints 2026 GTIR beobachtete in einem Monat einen Anstieg illegaler KI-bezogener Diskussionen um 1.500 %. Das sind keine hypothetischen Szenarien, sondern Stoff aus Vorfallberichten 2025–2026. Banken, die klassische defensive Operationen gegen agentische Gegner fahren, sind strukturell asymmetrisch exponiert, und die richtige Antwort lautet, KI-gegen-KI-Verteidigungsfähigkeit aufzubauen, statt den agentischen Übergang auf der Offensivseite zu verlangsamen.

Ist agentische KI nur „ChatGPT plus MCP-Server"?

Nein, und das ist eines der folgenreichsten Missverständnisse im aktuellen Markt. Eine Chat-Oberfläche, ergänzt um MCP-Server, ist ein nützliches Muster, um Daten innerhalb einer begrenzten Sitzung abzurufen und darauf zu handeln. Agentische Engineering ist eine strukturelle Fähigkeit des Hauses – die AIBOM, die Agent Control Plane, die spezifikationsgesteuerte Entwicklungs-Pipeline, das Audit-Substrat, das quantensichere kryptografische Fundament, die Orchestrierungsmuster über Ende-zu-Ende-Kundenreisen. Das sind keine Funktionen, die man von einem Lieferanten kauft, sondern eine institutionelle Ownership-Position. Banken, die die Frage als Beschaffungsentscheidung behandeln, landen bei oberflächlichen Einsätzen, die unter Prüfung scheitern. Banken, die sie als Engineering- und Governance-Ownership-Frage behandeln, landen bei einem Asset, das sich verstärkt.

Was ist das Wichtigste, was eine Bank in den nächsten zwölf Wochen tun sollte?

Drei Dinge in dieser Reihenfolge. Erstens: die AI Bill of Materials erstellen – das vollständige Inventar jedes KI-Systems, Modells, Datensatzes, Prompt-Templates, Retrieval-Index und KI-Drittabhängigkeit in Produktion oder Entwicklung, jeweils gegen Annex III des EU-KI-Gesetzes klassifiziert. Das Haus, das dies einem Regulator auf Anfrage nicht vorlegen kann, ist das Haus, das Befunde erhalten wird. Zweitens: die Agent Control Plane für jedes KI-System bauen, das derzeit Kundenwirkende Entscheidungen trifft oder maßgeblich beeinflusst – Audit-Logging, Verhaltensauffälligkeitserkennung, menschliche Übersteuerung und Notabschaltungen als Standardinfrastruktur, nicht als Roadmap-Punkt. Drittens: die interne Engineering-Kultur dort, wo es am meisten zählt – Hochrisiko-Systeme, regulierte Workflows und die Legacy-Modernisierungs-Pipeline – vom Vibe Coding zur spezifikationsgesteuerten Entwicklung verlagern. Die ersten beiden sind Compliance-Arbeit; das dritte ist Wettbewerbsarbeit. Die Häuser, die alle drei tun, werden in einer materiell stärkeren Position sein als jene, die eines oder keines tun. Die vollständige Zwölf-Wochen-Sequenz ist im Aktionsplanabschnitt oben dargelegt.

Quellen #

Zuletzt überprüft .