Ein Engineering Lead bei einer mittelständischen Versicherung hat seinen Coding-Agent-Rollout durch alle Instanzen gebracht. Der CISO hat unterschrieben, der Datenschutzbeauftragte, der Betriebsrat, die Compliance. Vier Unterschriften. Drei Wochen später ruft die interne Revision an.
Die Frage ist kurz: Wie wird der Abschnitt AT 4.3.4 operativ abgebildet?
Der Engineering Lead weiß nicht, was AT 4.3.4 ist. Er hat die Betriebsvereinbarung ausgehandelt, die Datenschutz-Folgeabschätzung geschrieben, die Sicherheitsfreigabe bekommen. Was er nicht wusste: Während er das alles tat, hat die BaFin neue Regeln veröffentlicht. Niemand hatte sie in den Rollout übersetzt.
Das Beispiel ist zugespitzt, aber die Frage dahinter ist real. Das ist der blinde Fleck, der 2026 bei vielen Rollouts auftauchen wird.
Was sich zwischen Dezember 2025 und April 2026 geändert hat
Zwei neue BaFin-Dokumente und eine laufende EU-Frist machen den Einsatz von Coding Agents in beaufsichtigten Häusern 2026 prüfungsrelevanter.
Am 18. Dezember 2025 hat die BaFin eine Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen veröffentlicht. Sie ist nicht bindend, aber sie zeigt, wie die Aufsicht denkt. Die Orientierungshilfe hat einen eigenen Abschnitt zur Code-Erzeugung mit KI-Assistenten. Darin stehen zwei Sätze, die für jeden Rollout relevant sind.
Erstens: Entwickler müssen die Ergebnisse beurteilen und testen können. Ein Agent, der Code schreibt, den niemand versteht, ist ein Compliance-Problem.
Zweitens: Der generierte Code muss darauf geprüft werden, ob er externe KI-Funktionen über APIs aufruft, die niemand angeordnet hat. Wer mit Agents arbeitet, die während der Arbeit zusätzliche Tools, APIs oder MCP-Server nutzen dürfen, sollte diesen Satz ernst nehmen.
Am 1. April 2026 hat die BaFin die Konsultation zur 9. MaRisk-Novelle eröffnet. Das neue Modul AT 4.3.4 formuliert erstmals spezifische MaRisk KI-Anforderungen: Angemessenheitsprüfung, Validierung, Dokumentation und hinreichende Erklärbarkeit für Modelle, KI-Systeme und automatisierte Verfahren im Risikomanagement. Für Coding-Agent-Rollouts wird es relevant, sobald deren Output solche Verfahren oder kritische Funktionen berührt. Die Konsultationsfrist läuft bis 8. Mai 2026, das Inkrafttreten wird für das zweite Halbjahr 2026 erwartet.
Der EU AI Act sah für viele Hochrisiko-Pflichten ursprünglich den 2. August 2026 vor. Der Digital-Omnibus könnte einzelne Fristen verschieben. Für den Review-Prozess ändert das wenig, weil BaFin-Orientierungshilfe, DORA und interne Prüfanforderungen unabhängig davon relevant bleiben.
Der Agent ist meist nicht selbst das Hochrisiko-System. Sein Output kann aber Teil eines solchen Systems werden, etwa bei Kreditwürdigkeitsprüfung oder Risiko- und Preisbewertung in Lebens- und Krankenversicherung für natürliche Personen.
Keines dieser Dokumente verbietet Coding Agents. Zusammen machen sie aber klar: Jeder PR, den ein Agent auf einem kritischen Pfad erstellt, muss Teil eines prüfbaren Änderungsprozesses sein.
Die Trennung ist wichtig: Der Coding Agent ist ein IKT-Asset. Der Code, den er schreibt, ist Software. Beides muss geprüft werden, aber nicht auf dieselbe Weise. Der Agent gehört ins Inventar und ins IKT-Risikomanagement. Der Code gehört in Review, Test, Freigabe und Dokumentation. Wer die regulatorische Schicht im Kontext der übrigen Rollout-Fragen einordnen will, findet im KI-Coding-Agents-Leitfaden den Platz dieses Themas neben Tooling, Messung und Workflow-Mustern.
Der Agent und sein Code
Die meisten Rollouts behandeln den Coding Agent als Werkzeug. Einmal eingeführt, fertig. Das reicht nicht mehr.
DORA Art. 8 verlangt seit dem 17. Januar 2025, dass Finanzunternehmen alle IKT-Assets identifizieren, klassifizieren und dokumentieren. Bei jeder wesentlichen Änderung ist eine Risikobewertung fällig. Was ist eine wesentliche Änderung? Ein neues Modell. Ein neuer MCP-Server. Ein neuer Tool-Zugriff. Sobald sich Zugriff, Datenflüsse oder Risikoprofil verändern, greift Art. 8.
Die BaFin-Orientierungshilfe geht noch weiter: Sie klassifiziert KI-Systeme als Netz- und Informationssysteme unter DORA. Der Coding Agent ist kein Werkzeug, das irgendwie mitläuft. Er ist ein Asset mit eigenem Eintrag im IKT-Risikomanagement.
Der Code, den der Agent schreibt, ist trotzdem normale Software. Er unterliegt denselben Anforderungen an Qualität, Änderungsmanagement und Freigabe wie jeder andere Code. Zusätzlich gelten die Anforderungen an Nachvollziehbarkeit und menschliche Aufsicht aus der BaFin-Orientierungshilfe und, wo zutreffend, aus Art. 14 AI Act.
"Der Agent hat es geschrieben" ist keine Entlastung. Die Letztverantwortung bleibt bei der Geschäftsleitung (DORA Art. 5 Abs. 2).
Wer nur den Agent dokumentiert, aber den Code nicht sauber reviewt, bekommt bei der Prüfung Fragen zur Software. Wer nur den Code reviewt, aber vergisst, dass der Agent im IKT-Inventar oder im Drittparteienrisikomanagement fehlt, bekommt Fragen zum Asset. Sie brauchen zwei Antworten, nicht eine.
Noch eine unbequeme Konsequenz: Die Pflicht zur KI-Kompetenz aus Art. 4 AI Act gilt seit dem 2. Februar 2025. Ein Vorstand muss nicht erklären können, wie ein MCP-Server implementiert ist. Aber er muss verstehen, welche Risiken entstehen, wenn ein Agent neue Tools nutzt, Berechtigungen erweitert oder produktionsnahe Systeme berührt.
Was das für den Review-Prozess bedeutet
Die Anforderungen sind nicht neu. Im Engpass-Post hießen sie Engineering-Hygiene. Die Regulierung macht daraus eine aufsichtsrechtliche Erwartung.
Wenn die Revision fragt, wer einen PR freigegeben hat, und die Antwort lautet "die CI-Pipeline", ist das in regulierten Umgebungen ein Befund. Die BaFin-Orientierungshilfe ist hier eindeutig: Wer die Ergebnisse nicht beurteilen und testen kann, soll sie nicht mergen. Auf kritischen Pfaden werden automatische Merges schwer zu rechtfertigen sein.
Wer interne Tool-Änderungen und Scoring-Modell-Änderungen durch denselben Prozess schickt, untergräbt die Angemessenheitslogik der MaRisk. Zwei oder drei Spuren kosten keine zusätzliche Kapazität, sie verteilen sie anders. Niedrigeres Risiko läuft über statische Analyse, Tests und automatische Checks. Kritische Pfade bekommen benannte Reviewer, PR-Größenlimits, keinen automatischen Merge.
Dokumentation entsteht beim Arbeiten, nicht danach. Die MaRisk fordert Nachvollziehbarkeit. DORA fordert belastbare Dokumentation. Der AI Act fordert Aufbewahrungsfristen. Wer Prompt, Modellversion, MCP-Kontext, Review-Entscheidung und Change im Git-Verlauf und im Ticket zusammenführt, hat die Prüfungsdokumentation beim Schreiben erzeugt. Wer sie nachträglich rekonstruiert, bekommt Lücken.
DORA Art. 5 Abs. 2 legt die Letztverantwortung für IKT-Risiken beim Leitungsorgan ab. Das heißt nicht, dass der Vorstand Code reviewt. Es heißt, dass er verstehen muss, was passiert, wenn ein Agent in einer Schleife einen Cloud-Bucket umkonfiguriert. Kompetenzaufbau ist keine freiwillige Übung.
Behandeln Sie den Coding Agent wie einen externen Entwickler, der bei Ihnen fest angestellt ist, aber unter fremdem Recht arbeitet. Er ist produktiv und macht Fehler. Und jede Aufsicht wird fragen, wie Sie seine Arbeitsergebnisse prüfen.
Was Sie jetzt konkret tun
Fangen Sie mit dem Inventar an. Welche Coding Agents, welche Modelle, welche MCP-Server, welche Cloud-Regionen sind im Einsatz? Das gehört praktisch vor jede Compliance-Diskussion. Das größere Risiko sind nicht die offiziell eingeführten Tools, sondern die Schatten-Instanzen auf privaten Abos oder über BYOK-Konfigurationen. Der Vorbehalt aus dem Mittelstand-Pfad gilt hier verschärft: Ein Agent, der in us-east-1 läuft, während der AV-Vertrag eine EU-Region vorschreibt, ist ein dokumentierter Bruch, sobald er entdeckt wird.
Welcher Code berührt eine kritische oder wichtige Funktion im Sinne von DORA? Welcher landet in einem Hochrisiko-System im Sinne des AI Act? Die Antwort bestimmt Review-Tiefe, Validierung und Dokumentationslast. Wer sie nicht hat, klassifiziert konservativ, bis er sie hat.
Die Spuren aus dem Engpass-Post werden in regulierten Umgebungen zu Nachweisebenen. Auf kritischen Pfaden keine automatischen Merges, harte PR-Größenlimits, benannte Reviewer. Auf dem Rest so viel Automatisierung, wie Ihre Disziplin trägt.
Eine externe Gap-Analyse kann helfen, das Inventar zu schreiben. Sie kann nicht ersetzen, dass Engineering Leads und Vorstand verstehen, was die Werkzeuge tun. Die Pflicht aus Art. 4 AI Act ist hier der freundlichste Hebel: Kompetenzmaßnahmen sind ohnehin verpflichtend, nutzen Sie sie für die richtigen Inhalte.
Der Unterschied zwischen einem freundlichen Prüfprotokoll und einer formellen Mängelliste ist fast immer die Frage, ob das Haus zeigen kann, dass es weiß, was es tut.
Was das für 2026 bedeutet
Die regulatorischen Entwicklungen von Dezember 2025 bis Sommer 2026 machen aus guter Engineering-Disziplin eine aufsichtsrechtliche Erwartung: disziplinierte Reviews, klare Risiko-Unterscheidung, ehrliche Dokumentation.
Wer seine Prozesse ohnehin sauber baut, hat die meiste Arbeit schon erledigt. Wer Geschwindigkeit auf Kosten von Nachvollziehbarkeit eingekauft hat, bekommt im Laufe von 2026 eine Rechnung, die sich nicht mehr sauber nachdokumentieren lässt.
Wenn Sie vor der nächsten Sonderprüfung ein ehrliches Audit-Readiness-Bild für Ihren Coding-Agent-Rollout brauchen, sprechen Sie mich an. Für Teams, die den Rollout noch planen, gibt es den 3-Tage-Intensivworkshop für regulierte Teams.
Dieser Artikel ersetzt keine Rechts- oder Compliance-Beratung; für konkrete Fälle empfiehlt sich die Abstimmung mit der internen Compliance-Funktion und bei Bedarf einem Fachanwalt für Bank- und Kapitalmarktrecht.
Quellen
- BaFin: Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen (18. Dezember 2025)
- BaFin: Konsultation 02/2026 zur 9. MaRisk-Novelle (1. April 2026)
- EUR-Lex: Verordnung (EU) 2024/1689 · EU AI Act
- EUR-Lex: Verordnung (EU) 2022/2554 · DORA
- EU-Kommission: AI Literacy · Questions & Answers (Art. 4 AI Act)
