Coding Agents in der Versicherungs-IT: die Nachweiskette nach DORA

Am 20. August 2026 lieferte die BaFin das VAIT-PDF unter seiner alten Adresse weiterhin aus: 40 Seiten, 514 KB, alle elf Kapitel lesbar, PDF-Änderungsdatum 17. April 2025. Über jede Seite läuft diagonal ein Wasserzeichen mit dem Aufhebungsvermerk zum 16. Januar 2025.

Das Dokument ist abrufbar und ungültig zugleich. Die BaFin hat die Aufhebung in ihrer Meldung vom 10. Januar 2025 datiert: aufgehoben mit Ablauf des 16. Januar 2025, um Doppelregulierung zu vermeiden, weil DORA ab dem 17. Januar 2025 gilt. Wer die Freigabe einer Korrektur am Rechenkern eines Bestandsführungssystems bisher nach Kapitel und Textziffer der VAIT begründet hat, findet diese Fundstelle nicht mehr. Die Nachweispflicht ist geblieben. Sie gilt auch dann, wenn Spezifikation und Umsetzung mit Agentenunterstützung in einem Durchlauf entstehen und die Freigabe trotzdem von einer davon unabhängigen Funktion kommen muss.

Kurz gefasst

• Ausgelöst wird die Nachweispflicht durch die Änderung an einem IKT-System, nicht durch das Werkzeug, mit dem sie entsteht.
• Nachzuweisen sind acht Schritte: Erfassung, Einordnung und Kritikalität, Rollen, Test, Freigabe, Ausweichverfahren, Notfalländerung, Nachschau. Grundlage sind Art. 9 Abs. 4 lit. e DORA sowie Art. 16 und 17 des technischen Regulierungsstandards zum IKT-Risikomanagementrahmen (RTS), der Delegierten Verordnung (EU) 2024/1774.
• Zwei Filter, die vorher Arbeit erspart haben, sind mit dem RTS weggefallen: die Wesentlichkeitsgrenze im Änderungsmanagement (Art. 17 Abs. 1) und die Sonderstellung der individuellen Datenverarbeitung (Art. 16 Abs. 9).

Wie agentengestützte Entwicklung in regulierten Häusern insgesamt einzuordnen ist, steht im Leitfaden zu Coding Agents in regulierten Umgebungen.

Stand: 20. August 2026. Geprüft und belegt ist alles Folgende zu diesem Datum. Datumsabhängig sind vor allem zwei Negativbefunde: dass ich keine EIOPA-Leitlinie zu KI gefunden habe und dass mir kein Restanwendungsgebiet der VAIT bekannt ist. Beides kann sich seither geändert haben, ohne dass dieser Text es anzeigt. Er zitiert Normen bis hin zu einer Strafvorschrift des VAG und ist kein Rechtsrat.

Eine Korrektur am Rechenkern zieht acht Nachweise nach sich

Die Kette beginnt bei Art. 9 Abs. 4 lit. e DORA (Verordnung (EU) 2022/2554). Verlangt sind dokumentierte Leitlinien, Verfahren und Kontrollen für das IKT-Änderungsmanagement, risikobasiert, eingebettet in den allgemeinen Änderungsprozess und von der zuständigen Managementebene genehmigt. Das Ziel steht ausdrücklich im Text: Jede Änderung wird kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und überprüft. Der RTS nennt die Inhalte, überlässt deren Form aber dem Haus.

Ob diese Inhalte in einem eigenen Änderungsantrag, im Änderungsdatensatz des Ticketsystems oder in der Pipeline liegen, legt der RTS nicht fest. Art. 16 RTS verlangt das Test- und Freigabeverfahren vor jedem Einsatz und nach jeder Wartung. In Nicht-Produktionsumgebungen sind nach Art. 16 Abs. 5 und 6 grundsätzlich nur anonymisierte, pseudonymisierte oder randomisierte Produktivdaten zulässig, Ausnahmen müssen befristet, genehmigt und gemeldet werden. Die Stresstestpflicht in Art. 17 Abs. 2 gilt für zentrale Gegenparteien und Zentralverwahrer, nicht für Versicherer.

Eine Unterscheidung trägt dabei mehr, als ihre Kürze vermuten lässt, weil sie festlegt, welcher Nachweis bei welcher Änderung überhaupt anfällt.

Artikel 17 RTS erfasst jede Änderung an einem IKT-System. Artikel 8 Abs. 3 und 6 DORA knüpfen Risikobewertung und Inventaraktualisierung weiterhin an wesentliche Änderungen.

Eine kleine Korrektur kann deshalb vollständig durch das Änderungsverfahren laufen, ohne automatisch eine Aktualisierung des IKT-Bestandsverzeichnisses auszulösen. Art. 8 DORA verlangt Bestandsverzeichnisse der IKT-gestützten Geschäftsfunktionen und der stützenden Assets, mindestens jährlich zu überprüfen und bei jeder wesentlichen Änderung zu aktualisieren. Aus dem Verzeichnis geht hervor, welche Systeme betrieben werden. Die Änderungsakte hält fest, wie eine einzelne Änderung zustande kam.

Die linke Sichel ist der Alltagsfall, die rechte der umgekehrte: eine wesentliche Änderung an Prozessen oder Verfahren ohne Systemänderung. Nur in der Schnittmenge löst eine Änderung beide Unterlagen aus.

Eine eigene Aufbewahrungsfrist für Änderungsdokumentation steht weder in den Artikeln 8, 9 und 28 Abs. 3 DORA noch in Art. 17 RTS. Die Frist richtet sich nach der rechtlichen Kategorie der Unterlage: § 257 Abs. 4 HGB sieht für Unterlagen nach dessen Absatz 1 Nummer 1 zehn Jahre vor. § 147 Abs. 2 Nr. 2 AO verlangt für Datenträger jederzeitige Verfügbarkeit, unverzügliche Lesbarmachung und maschinelle Auswertbarkeit. Systemänderungen kommen im Wortlaut beider Normen nicht vor, die Zuordnung muss das Haus begründen.

Zwei Filter sind mit dem RTS weggefallen

Für den VAIT-Block „IT-Projekte und Anwendungsentwicklung“ benennt die BaFin vier Punkte als Mehraufwand. Die Quelle ist eine Aufsichtsmitteilung mit Stand Juni 2024, die nach ihrem eigenen Wortlaut keine verbindliche Auslegung ist. Zwei der vier Punkte stehen bereits in der Nachweiskette oben: die Quellcodeprüfung vor Produktiveinsatz und ihre Geltung für fremderstellten Code. Die anderen beiden sind keine neuen Pflichten, sondern weggefallene Ausnahmen.

Die Wesentlichkeitsgrenze betraf die Menge der erfassten Änderungen. Art. 17 Abs. 1 RTS knüpft an Änderungen an IKT-Systemen an, ohne vorgeschaltete Erheblichkeitsprüfung. Wer eine Änderung bisher als unwesentlich einstufen und damit aus dem dokumentierten Verfahren herausnehmen konnte, hat diese Einstufungsmöglichkeit nicht mehr. Die Grundgesamtheit wächst, die Prüftiefe nicht zwangsläufig: Art. 16 Abs. 2 staffelt die Tests weiterhin nach Kritikalität, und das Verfahren selbst darf risikobasiert ausgestaltet werden.

Die Sonderstellung der individuellen Datenverarbeitung betraf den Anwendungsbereich. Art. 16 Abs. 9 erstreckt die Absätze 1 bis 8 risikobasiert auf Systeme, die von Nutzern außerhalb der IKT-Funktion entwickelt oder verwaltet werden. Fachbereichsanwendungen sind damit nicht mehr ausgenommen.

Im linken Trichter leiten zwei Filterbalken einen Teil der Änderungen aus dem dokumentierten Verfahren heraus. Im rechten sind beide gestrichen (Art. 17 Abs. 1 und Art. 16 Abs. 9 RTS), der Auslauf ist danach gut doppelt so breit. Das Band darunter zeigt, was die gewachsene Grundgesamtheit abfedert: die nach Kritikalität gestaffelte Testtiefe aus Art. 16 Abs. 2 RTS.

Nicht alles wird schwerer. Dieselbe Aufsichtsmitteilung nennt Anforderungen, die als ausdrückliche Vorgabe entfallen sind. Dazu zählen die Abhängigkeitsbetrachtung zwischen IT-Projekten, die Ressourcenausstattung, die Projektdokumentation, die Lessons Learned und das Fachkonzept.

Für maschinell erzeugten Code gilt derselbe Maßstab, nur die Rollenfrage verschiebt sich

Ein Agent beantragt keine Änderung und genehmigt keine. Das tun Menschen und Funktionen. Der praktische Fall ist der, in dem Entwurf und Ausführung in derselben Hand liegen, weil die Agentenunterstützung den Weg dazwischen verkürzt. Für die Freigabe verlangt Art. 17 RTS dann eine Funktion, die von der beantragenden oder der umsetzenden unabhängig ist. Die organisatorische Abbildung überlässt der Artikel dem Haus. Dass die Frage überhaupt zu beantworten ist, wenn beide Schritte zusammenfallen, ist meine Schlussfolgerung aus dem Unabhängigkeitsgebot, nicht sein Wortlaut.

Zur maschinellen Codeerstellung gibt es eine einschlägige deutsche Aufsichtsäußerung. Die BaFin-Orientierungshilfe „IKT-Risiken beim Einsatz von KI in Finanzunternehmen“ vom 18. Dezember 2025 formuliert in ihrem Kapitel zur Entwicklung von KI-Systemen: „Grundsätzlich gelten für alle Arten der Codeerstellung, sei es durch Menschen oder Maschinen, die gleichen Regelungen.“ Das Papier versteht sich nach eigener Aussage als nicht verpflichtende Hilfestellung und definiert keine aufsichtlichen Erwartungen. Prüfungsmaßstab bleiben Art. 16 und 17 RTS.

Inhaltlich ist die Orientierungshilfe trotzdem brauchbar. Sie zieht KI-Assistenten ausdrücklich in den Anwendungsbereich des Art. 16 Abs. 9 RTS, weil Fachbereiche außerhalb der IKT-Funktion damit komplexe Anwendungen selbst erstellen können. Als spezifische Risiken maschinell erzeugten Codes nennt sie zwei Sachverhalte, die ein Diff allein nicht zuverlässig ausschließt. Der erzeugte Code kann KI-basierte Funktionen aufrufen, von denen der Nutzer nichts weiß. Und eine ursprünglich ohne KI geplante Anwendung kann durch die Einbindung externer Modelle über eine API selbst zum KI-System werden. Als Prüfmittel nennt sie die statische Codeanalyse nach Art. 16 Abs. 3 RTS.

Deckt der bestehende Änderungsprozess dieselben Rollen, Tests und Ausweichverfahren nachweisbar ab, sehe ich in den geprüften Stellen von DORA und RTS keine Grundlage für eine separate Agentenakte. Neu zu prüfen sind die gewachsene Änderungsmenge und die Anwendungen aus den Fachbereichen. Liest ein Agent das Bestandsführungssystem, erklärt es oder trägt Kontextinformationen zusammen, ändert er das System nicht, kann aber Kontrollen für Datenzugriff und Berechtigungen auslösen. Für diesen Leseteil bieten Prompt-Muster für große Bestandscodebasen einen enger gefassten Einstieg. Die vertragliche Seite eines Agentenwerkzeugs ist eine davon getrennte Frage: Art. 28 Abs. 3 DORA betrifft das Informationsregister über Vereinbarungen mit IKT-Drittdienstleistern, und ein Eintrag dort ersetzt die Änderungsdokumentation nicht.

Dass die Branche Code generieren lässt, ist der Aufsicht bekannt: In der Marktumfrage „Generative AI Market Survey“ (EIOPA-BoS-25-679) melden 347 Versicherer aus 25 EU- und EWR-Staaten 957 Anwendungsfälle, Datenstand Juli 2025, davon 64 Prozent interne Anwendungen mit ausdrücklich eingeschlossenen Coding-Assistenten. Normativ ist dazu wenig gesagt. In der Opinion zur KI-Governance (EIOPA-BoS-25-360) vom 6. August 2025 ergab eine Volltextsuche am 20. August 2026 zu sieben Begriffen rund um Softwareentwicklung null Fundstellen. Über dieses eine Dokument hinaus habe ich die EIOPA-Publikationssuche durchgesehen und dort keine Leitlinie zu KI gefunden. Das ist ein Ergebnis meiner Recherche und kein Schweigen der Aufsicht, und es ist keine erschöpfende Registerprüfung.

Wie verbreitet Coding-Assistenten in deutschen Versicherungshäusern tatsächlich sind, lässt sich öffentlich nicht beziffern. Eine quantitative Branchenerhebung speziell dazu habe ich nicht gefunden, und die oben zitierte EIOPA-Umfrage beantwortet diese Frage nicht, weil sie europaweit KI-Anwendungsfälle zählt und nicht den Werkzeugeinsatz in der Entwicklung deutscher Versicherer. Zu acht weiteren Häusern, die ich einzeln geprüft habe, darunter Talanx, R+V, Debeka, Signal Iduna und Helvetia, fand ich keinen öffentlichen Beleg. Namentlich dokumentiert sind zwei Häuser, beide durch Eigendarstellung: Generali führte GitHub Copilot Anfang 2024 für rund 2.000 Entwickler ein, belegt durch eine Fallstudie in Microsofts Kundenreferenzen, also durch den Eigentümer von GitHub, ohne Produktivitätszahl und ohne offengelegte Methodik. Die Allianz kündigte am 9. Januar 2026 per eigener Mitteilung eine Partnerschaft mit Anthropic an, ohne belastbare Entwicklerzahl, Messgröße oder Methodik. Das ist Eigenwerbung, kein Nutzungsbeleg.

Seit Januar 2025 fehlt auf der Versicherungsseite ein nationales IT-Kapitel

Für Banken ist das nationale Regelwerk erhalten geblieben und wurde fortgeschrieben. Die 9. MaRisk-Novelle, Rundschreiben 06/2026 (BA), hat die BaFin am 30. Juni 2026 veröffentlicht. Der Beitrag zu MaRisk, BaFin und Coding Agents ordnet agentengestützte Entwicklung nach diesem Regelwerk ein.

Für Versicherer gilt seit dem 17. Januar 2025: DORA und der RTS sind für IKT-Risikomanagement, Anwendungsentwicklung und Änderungsmanagement maßgeblich. Die MaGo und das VAG bestehen daneben fort. Erst- und Rückversicherer im Anwendungsbereich von Solvency II wenden den vollen Rahmen der Artikel 5 bis 15 DORA an, der vereinfachte Rahmen nach Artikel 16 nennt sie nicht. § 293 Abs. 5 VAG ordnet ihn national für Versicherungs-Holdinggesellschaften nach § 7 Nr. 31 und für Unternehmen nach dessen Absatz 4 an, anstelle der Artikel 5 bis 15.

Die MaGo für Solvency-II-Versicherer, Rundschreiben 09/2025 (VA) vom 14. Juli 2025, sind seit dem 14. Oktober 2025 in Kraft. Randnummer 11 ordnet das Verhältnis: DORA und die KI-Verordnung geben die sektorspezifischen Anforderungen vor, die MaGo bleiben für die allgemeinen Geschäftsorganisationsprozesse maßgeblich. Ein IT-Kapitel enthalten sie nicht, einen Abschnitt zum Änderungsmanagement ebenfalls nicht. Das funktionale Gegenstück ist Abschnitt 9.5 zu automatisierten Geschäftsabläufen, Rn. 79 bis 81. Genannt sind dort nachvollziehbare Dokumentation, Eingriffsmöglichkeiten, Qualitätssicherung vor Inbetriebnahme und im Betrieb sowie eine regelmäßige unabhängige Bewertung.

Die nationalen Organisationspflichten stehen damit im VAG statt in einem IT-Rundschreiben: § 23 Abs. 1 für die ordnungsgemäße Geschäftsorganisation, §§ 26, 29 und 30 für Risikomanagement, internes Kontrollsystem und Revision, § 32 für Ausgliederungen. Zuständige Behörde im Sinne von DORA ist die BaFin nach § 295 Abs. 1 Nr. 8 VAG. Die Prüfung ist eingetaktet: Nach § 35 Abs. 1 Satz 1 Nr. 10 VAG prüft der Abschlussprüfer die Einhaltung eines benannten DORA-Artikelkatalogs, erstmals für Geschäftsjahre, die nach dem 31. Dezember 2024 beginnen (§ 360 VAG).

Die BAIT dagegen wurden gestaffelt zurückgezogen und behalten bis zum Ablauf des 31. Dezember 2026 ein Restanwendungsgebiet, unter anderem für Bürgschaftsbanken und Zweigstellen nach § 53 KWG (BaFin-FAQ, Stand Januar 2025). Ein vergleichbarer Restkreis für die VAIT ist mir zum 20. August 2026 nicht bekannt, die BaFin sagt dazu ausdrücklich nichts. Das ist ein Negativbefund aus der Recherche, keine Aussage der Aufsicht.

Die amtliche Gegenüberstellung reicht bis zur Kapitelebene

Die amtliche, öffentlich verfügbare Zuordnung von VAIT zu DORA, die diese Recherche erfasst hat, ist die BaFin-Aufsichtsmitteilung „Hinweise zur Umsetzung von DORA im IKT-Risikomanagement und IKT-Drittparteienrisikomanagement“, Stand Juni 2024. Verlinkt ist sie auf der BaFin-Seite zum IKT-Risikomanagement. Sie stellt die Kapitel 1 bis 10 von BAIT und VAIT den DORA-Anforderungen gegenüber.

Der VAIT-Block „IT-Projekte und Anwendungsentwicklung“ wird dort den Artikeln 15, 16 und 17 des RTS zugeordnet. Die Zählung zeigt, wie grob das bleibt: Im gesamten Dokument steht genau eine Zuordnung auf Textziffernebene, Tz. 7.4 VAIT zu Art. 15 Abs. 1 bis 3 RTS. Eine amtliche Tabelle, die jede Textziffer einem Artikel gegenüberstellt, gibt es nach dem hier geprüften Stand nicht. Eine solche Tabelle muss das Haus selbst bauen und verantworten, mit Datum und Angabe der Verantwortlichen.

Ausgeklammert bleiben zudem VAIT Kapitel 11 (Kritische Infrastrukturen), Artikel 16 DORA sowie die DORA-Kapitel III und IV. Wer seine Nachweisführung bisher mit Kapitel 11 begründet hat, hat für diesen Teil keine amtliche Gegenüberstellung.

Im Lebens-Altbestand zählt das Ergebnis, nicht nur der Code

Für jedes IKT-System gelten dieselben Vorschriften, abgestuft nach Kritikalität. Im Lebens-Altbestand kommt eine Vorgabe aus dem Aufsichtsrecht hinzu. § 336 VAG hält für Lebensversicherungsverträge, die vor dem 29. Juli 1994 abgeschlossen wurden, den damals genehmigten Geschäftsplan in vollem Umfang aufrecht, mit einer eigenen Maßgabe für die versicherungsmathematische Bestätigung. Damit gilt 2026 ein Sonderregime für Verträge, die älter als 32 Jahre sind.

Prämie und Deckungsrückstellung, die sich heute für einen solchen Vertrag ergeben, müssen den Vorgaben dieses Geschäftsplans entsprechen. Daraus folgt für mich: Die Abnahme einer Änderung am Rechenkern hängt am Ergebnis. Es muss weiter dem maßgeblichen Geschäftsplan und den gesetzlichen Grundlagen entsprechen. Abweichungen sind zulässig, soweit rechtmäßige Korrekturen, geänderte Annahmen oder stichtagsabhängige Größen sie tragen. Die Regressionskriterien sind tarifbezogen festzulegen. Ein Zahlungsdienst darf nach einem Umbau schneller sein, eine Deckungsrückstellung braucht für jede Abweichung eine fachliche Begründung.

Die Verantwortung für dieses Ergebnis ist gesetzlich zugewiesen. § 141 VAG verlangt von jedem Lebensversicherungsunternehmen einen Verantwortlichen Aktuar. Nach Absatz 5 Nummer 1 stellt er sicher, dass bei der Berechnung der Prämien und der Deckungsrückstellungen die gesetzlichen Grundsätze eingehalten werden. Nach Nummer 2 gibt er die versicherungsmathematische Bestätigung unter der Bilanz ab. § 331 Abs. 2 Nr. 2 lit. b VAG bedroht eine nicht richtige Bestätigung mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe.

Das ist keine persönliche Haftung für Codeänderungen. Die Norm knüpft an das testierte Ergebnis und an die zugrunde liegenden Methoden, Annahmen und Daten an. Für deren Angemessenheit ist zusätzlich die Versicherungsmathematische Funktion nach § 31 VAG zuständig, die auch Hinlänglichkeit und Qualität der Daten bewertet.

Zwischen dieser Verantwortung und dem Quellcode liegt eine Lücke. Weder das VAG noch die MaGo noch die DAV-Standesregeln vom 15. September 2024 behandeln Änderungen am Code von Tarif- oder Reservierungsrechenkernen. Am nächsten kommt MaGo Rn. 112: Der Einfluss von Änderungen an Methoden, Annahmen und Datengrundlagen von einem Berechnungsstichtag zum nächsten ist zu ermitteln. Rn. 111 verlangt die Trennung von Berechnung und Validierung, prozessual und gegebenenfalls personell. Keine dieser Randnummern spricht vom Rechenkern. Mein Schluss: Berührt eine Änderung am Kern Methoden, Annahmen oder Datengrundlagen, gehört der Stichtagsvergleich nach Rn. 112 in die Änderungsdokumentation.

Oben stehen die drei Anknüpfungspunkte des Aufsichtsrechts: Bestätigung unter der Bilanz, Prämie und Deckungsrückstellung, maßgeblicher Geschäftsplan. Unten steht, was das Haus tatsächlich ändert: Commit, Test, Freigabe, Änderungsakte. Dazwischen spricht keine Norm vom Quellcode, der schmale Balken über der Lücke ist meine Ableitung, nicht der Wortlaut einer Vorschrift.

Der Beitrag zum Refaktorieren von Legacy-Monolithen mit Coding Agents beschreibt, wie sich ein solcher Kern schrittweise umbauen lässt, ohne den Prüfpfad zu verlieren. Enthält der Bestand personenbezogene Daten, kommt die Frage hinzu, was ein Agent von diesen Beständen überhaupt sehen darf.

Die KI-Verordnung knüpft an die Zweckbestimmung an

Der Anwendungsbereich der Hochrisiko-Einstufung ist enger, als der Begriff vermuten lässt. Anhang III Nummer 5 Buchstabe c der KI-Verordnung erfasst Risikobewertung und Preisbildung in Bezug auf natürliche Personen in der Lebens- und Krankenversicherung. Kfz-, Sach- und Haftpflichtversicherungen fallen nicht darunter. Die Anforderungen greifen erst ab dem 2. Dezember 2027, nachdem die Verordnung (EU) 2026/1744 den zunächst vorgesehenen 2. August 2026 verschoben hat.

Der Coding Agent selbst fällt nicht unter Anhang III, weil dessen Tatbestände an die Zweckbestimmung anknüpfen, also nach Art. 3 Nr. 12 an die vom Anbieter bestimmte Verwendung. Die Grenze markiert Art. 25 Abs. 1 lit. c: Wer die Zweckbestimmung eines nicht als hochriskant eingestuften Systems, auch eines Allzwecksystems, so verändert, dass es zu einem Hochrisiko-System im Sinne von Art. 6 wird, gilt als Anbieter. Wer ein Allzweckmodell in die Tarifierung stellt, fällt darunter, wer damit Code schreibt, nach dieser Subsumtion nicht. In den für diesen Artikel geprüften Stellen tauchen Entwicklungswerkzeuge normativ nur in Anhang IV Nummer 2 Buchstabe a auf, als Gegenstand der technischen Dokumentation eines Hochrisiko-Systems. Dass mit „Instrumenten“ dort Coding Agents gemeint sind, ist Auslegung.

Umgekehrt gilt die Abgrenzung genauso. Ein deterministisches Tarifierungssystem bleibt auch dann kein KI-System, wenn ein Agent es geschrieben hat. Art. 3 Nr. 1 verlangt Ableitungsfähigkeit, Erwägungsgrund 12 grenzt gegen einfachere herkömmliche Softwaresysteme ab. Die Pflichtenübersicht zum EU AI Act führt aus, was daraus für den Agenten folgt.

Was jetzt am Änderungsprozess zu prüfen ist

Die Reihenfolge ist die, in der ein Haus die Punkte abarbeitet, nicht die der Verordnungsartikel.

1. Den Änderungsprozess einmal ohne die Wesentlichkeitsgrenze durchspielen: Erfassung, Prüfung, Genehmigung und Nachschau für eine kleine Korrektur an der Bestandsführung, dazu eine Begründung für die gegenüber dem Quartalsrelease geringere Prüftiefe (Art. 16 Abs. 2, Art. 17 Abs. 1 RTS).
2. Prüfen, ob der Änderungsdatensatz die Mindestangaben nach Art. 17 RTS enthält: Zweck, Umfang, Zeitplan, erwartetes Ergebnis, Auswirkung auf bestehende Sicherheitsmaßnahmen, benannte Rollen und Freigabe, Testnachweise, Ausweichverfahren, Notfalländerungen.
3. Die Anwendungen erfassen, die außerhalb der IKT-Funktion entstehen (Art. 16 Abs. 9 RTS, risikobasierte Erstreckung der Test- und Freigabeverfahren).
4. Für Änderungen, bei denen Spezifikation und Umsetzung in einer Funktion zusammenfallen, nachweisen, wie die genehmigende Funktion davon unabhängig ist (Art. 17 RTS).
5. Statische und dynamische Quellcodeprüfung als Freigabevoraussetzung in der Pipeline verankern, nicht als Verfahrensempfehlung (Art. 16 Abs. 3 RTS, für fremderstellten Code Abs. 8).
6. Bei Änderungen, die auf Prämien oder Deckungsrückstellungen wirken können, Geschäftsplanvorgaben, tarifbezogene Regressionskriterien und fachliche Verantwortlichkeit in der Änderungsakte dokumentieren (§ 336 und § 141 VAG, MaGo Rn. 112).
7. Für die Änderungsunterlagen begründet festlegen, in welche handels- und steuerrechtliche Unterlagenkategorie sie fallen und welche Aufbewahrungsfrist daraus folgt (§ 257 HGB, § 147 AO).
8. Bei externen Entwicklungspartnern die Vertragslage und den Eintrag im Informationsregister nach Art. 28 Abs. 3 DORA prüfen und danach unterscheiden, ob der Partner eine kritische oder wichtige Funktion unterstützt.

Mir ist zum 20. August 2026 keine verbindliche Aufsichtsäußerung speziell zu Coding Agents bekannt. Alles Genannte gilt nach dem zu diesem Datum veröffentlichten Stand, und dieser Text ist kein Rechtsrat.

Ein besseres Modell macht eine Änderung nicht prüffest. Eine vollständige Nachweiskette tut es.

Quellen

• Verordnung (EU) 2022/2554 (DORA): eur-lex.europa.eu
• Delegierte Verordnung (EU) 2024/1774, RTS zum IKT-Risikomanagementrahmen: eur-lex.europa.eu
• BaFin, „DORA kommt: Änderungen bei den aufsichtlichen Anforderungen an die IT“, 10. Januar 2025: bafin.de
• BaFin, Rundschreiben 10/2018 (VA), VAIT, aufgehoben: bafin.de (PDF)
• BaFin, Aufsichtsmitteilung „Hinweise zur Umsetzung von DORA“, Stand Juni 2024: bafin.de, IKT-Risikomanagement
• BaFin, Orientierungshilfe „IKT-Risiken beim Einsatz von KI in Finanzunternehmen“, 18. Dezember 2025: bafin.de (PDF)
• BaFin, Rundschreiben 09/2025 (VA), MaGo für Solvency-II-Versicherer: bafin.de
• Versicherungsaufsichtsgesetz (VAG): gesetze-im-internet.de
• EIOPA, „Generative AI Market Survey“ (EIOPA-BoS-25-679): eiopa.europa.eu (PDF)
• EIOPA, „Opinion on AI governance and risk management“ (EIOPA-BoS-25-360), 6. August 2025: eiopa.europa.eu (PDF)
• Verordnung (EU) 2024/1689, KI-Verordnung: data.europa.eu
• Verordnung (EU) 2026/1744, Digital-Omnibus zur KI: data.europa.eu
• Deutsche Aktuarvereinigung, Standesregeln, 15. September 2024: aktuar.de (PDF)