DORA und KI-Coding-Agenten: Prüfungsfest entwickeln mit Claude Code, wenn ein Architekt die Leitplanken setzt
DORA verlangt, dass Änderungen erfasst, getestet, genehmigt und nachgewiesen werden, und schweigt dazu, wer den Code schreibt. Wie Claude Code in diesem Rahmen arbeitet, welche Nachweise entstehen und warum ein Architekt im Loop die Voraussetzung ist. Mit Beispiel aus einem Portal für KMU-Kredite.
Die Frage kommt inzwischen in den meisten Gesprächen mit Finanzunternehmen: Dürfen wir Claude Code oder Copilot im Kernsystem einsetzen, wenn wir unter DORA stehen? Die reflexhafte Antwort ist ein Verbot. Drei Monate später nutzen die Entwickler die Werkzeuge trotzdem, privat und ohne Regeln. Das Risiko besteht weiter, nur ohne Überblick.
Die Verordnung selbst gibt eine andere Antwort. Sie schreibt nicht vor, wer oder was Code schreibt. Sie verlangt, dass jede Änderung an einem IKT-System erfasst, getestet, bewertet, genehmigt und kontrolliert umgesetzt wird. Ein Coding-Agent ist für die Aufsicht ein Werkzeug in einem Prozess, der Nachweise liefern muss. Dieser Artikel zeigt, was DORA von der Softwareentwicklung verlangt und wo Agenten diese Nachweise leichter machen. Er beschreibt, wo es ohne verantwortlichen Architekten schiefgeht, und das Betriebsmodell, das ich in einem Portal für KMU-Kredite anwende.
Was DORA von der Softwareentwicklung verlangt
Die Vorgaben stehen an drei Stellen. Artikel 9 Absatz 4 der Verordnung verlangt dokumentierte Richtlinien und Kontrollen für das Änderungsmanagement, ausdrücklich auch für Software. Die Richtlinien folgen einem risikobasierten Ansatz. Jede Änderung wird kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und überprüft. Artikel 25 nennt die Tests, die ein Resilienzprogramm enthalten soll, darunter Quellcode-Prüfungen, Schwachstellenscans und Analysen von Open-Source-Komponenten. Die technischen Standards in der Delegierten Verordnung (EU) 2024/1774 füllen das in den Artikeln 16 und 17 aus. Verlangt werden eine Richtlinie und ein Verfahren für Entwicklung und Wartung. Dazu gehören die Analyse des Quellcodes auf Schwachstellen, Sicherheitstests spätestens bei der Integration, der Schutz der Integrität des Quellcodes und Tests vor der Produktivsetzung. In Nicht-Produktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten liegen. Ausnahmen für einzelne Testanlässe sind befristet, genehmigt und an das IKT-Risikomanagement gemeldet. Das Änderungsverfahren trennt die Genehmigung von Beantragung und Umsetzung, legt Rollen fest und regelt Rückfall und Notfalländerungen.
| Anforderung | Fundstelle | Bedeutung für Agenten-Code |
|---|---|---|
| Jede Änderung erfasst, getestet, genehmigt und kontrolliert umgesetzt | Art. 9 Abs. 4 DORA, Art. 17 RTS | Jeder Agentenlauf ist eine Änderung mit Auftrag, Freigabe und Rückweg |
| Genehmigung getrennt von Beantragung und Umsetzung | Art. 17 RTS | Wer den Agenten beauftragt, gibt nicht selbst frei |
| Quellcode-Analyse, Sicherheitstests, Prüfung von Open Source | Art. 25 Abs. 1 DORA, Art. 16 RTS | Scanner und Abhängigkeitsprüfung in der Pipeline, Review durch eine verantwortliche Person |
| Tests vor der Produktivsetzung in getrennten Umgebungen | Art. 16 RTS | Der Agent liefert Tests mit, produktiv geht es erst nach Pipeline und Review |
| Keine echten Produktionsdaten in Entwicklung und Test | Art. 16 RTS | Der Agent hat keinen Zugang zu Produktionsdaten, Testdaten werden synthetisch erzeugt |
| Vertraulichkeit und Integrität des Quellcodes | Art. 9 Abs. 4 DORA, Art. 11 und 16 RTS | Festgelegt, welcher Code in welches Werkzeug darf, keine Zugangsdaten im Arbeitsbereich |
| Zugriffsrechte des Werkzeugs auf das Nötige beschränkt | Art. 9 Abs. 4 DORA | Eigene Identität für den Agenten, Schreibrechte nur auf freigegebene Repositories, kein Produktionszugang |
| KI-Anbieter als IKT-Drittdienstleister | Art. 28 bis 30 DORA | Informationsregister, Vertragsinhalte nach Art. 30 Abs. 2, Konzentrationsrisiko, Exit-Strategie bei kritischer oder wichtiger Funktion |
| Verantwortung des Leitungsorgans | Art. 5 DORA | Das Leitungsorgan genehmigt die Richtlinie zum Agenteneinsatz als Teil des IKT-Risikorahmens und wird über die neue Abhängigkeit informiert |
Nichts davon ist neu. Dieselben Pflichten gelten für Code, den ein Mensch schreibt. Der Agent ändert die Geschwindigkeit, mit der Änderungen entstehen, und damit die Menge an Nachweisen, die der Prozess erzeugen muss.
Warum das Verbot das größere Risiko ist
Code, der in ein privates Werkzeug kopiert wird, verlässt das Haus an der Informationssicherheitsleitlinie vorbei. Die technischen Standards verlangen in Artikel 11 Regeln dafür, welche Software auf Endgeräten laufen darf und wie Datenabfluss verhindert wird. Testdaten mit echten Kundennamen in einem Chatfenster sind ein Datenschutzvorfall. Und ein Anbieter, den niemand kennt, steht in keinem Informationsregister. Die geregelte Nutzung ist für die Aufsicht die bessere Antwort, weil sie prüfbar ist. Wie ein solches Programm im Team eingeführt wird, beschreibt der Artikel zum KI-Enablement im Engineering-Team.
Wo Agenten die Nachweise leichter machen
Die Nachweise, die DORA verlangt, sind genau die Arbeit, die in Entwicklungsteams chronisch liegen bleibt.
- Tests für ungetestete Module. Ein Agent schreibt Charakterisierungstests für Code, den seit Jahren niemand angefasst hat. Damit entstehen die Tests vor der Produktivsetzung, die Artikel 16 der technischen Standards für jedes IKT-System verlangt, und ihr Umfang wächst mit jeder Änderung.
- Das Abhängigkeitsinventar. Pakete, Dienste, Schnittstellen und deren Versionen, aus Build-Dateien und Code erzeugt. Es speist das Inventar nach Artikel 8 und zeigt, welche externen Dienste ins Informationsregister gehören. Wie das für ein undokumentiertes System funktioniert, steht im Artikel zur Architektur-Rekonstruktion mit KI-Agenten.
- Die Betriebsdokumentation. Wiederherstellungsschritte, Konfigurationsübersicht und Betriebshandbuch entstehen aus dem Code und werden mit jeder Änderung aktualisiert. Das sind die Unterlagen für die Wiederherstellungspläne nach Artikel 11 und 12.
- Die Änderungsbegründung. Der Agent schreibt zu jeder Änderung, was er geändert hat, warum und welche Auswirkungen er erwartet. Das ist der Entwurf für die Dokumentation, die Artikel 17 der technischen Standards verlangt: Zweck, Umfang und erwartete Ergebnisse. Ob die Sicherheitsanforderungen erfüllt sind und ob die Änderung bestehende Sicherheitsmaßnahmen berührt, bewertet der Reviewer in Schritt 5 auf dieser Grundlage.
Dokumentation, die mit der Änderung entsteht, ist aktuell. Dokumentation, die vor der Prüfung nachgeholt wird, ist eine Rekonstruktion.
Fünf Fehlermuster ohne Architekt im Loop
Dieselben Werkzeuge erzeugen ohne Rahmen das Gegenteil. Fünf Muster sehe ich regelmäßig.
- Code ohne Tests. Der Agent liefert die Funktion, die Tests sollen später kommen. Später kommt die nächste Aufgabe. Die Änderung geht ohne Nachweis in Produktion.
- Erfundene Pakete. Agenten referenzieren gelegentlich Bibliotheken, die es nicht gibt oder die einem bekannten Paket nur ähneln. Eine Untersuchung der University of Texas at San Antonio hat das auf der USENIX Security 2025 belegt. In 576.000 Codebeispielen fanden sich bei kommerziellen Modellen 5,2 Prozent erfundene Paketnamen, bei offenen Modellen 21,7 Prozent. Wer solche Pakete ungeprüft installiert, öffnet die Lieferkette. Eine Abhängigkeitsprüfung gegen eine Freigabeliste gehört in die Pipeline.
- Zugangsdaten und Kundendaten im Arbeitsbereich. Verbindungszeichenfolgen in der Konfiguration, echte Namen in Testdaten. Beides landet im Kontext des Werkzeugs, wenn es vorher niemand entfernt hat.
- Änderungen über den Auftrag hinaus. Der Agent korrigiert nebenbei eine Nachbarfunktion, benennt um, passt eine Konfiguration an. Jede dieser Nebenänderungen ist eine ungeplante Änderung an einem IKT-System. Der Umfang muss im Auftrag stehen und im Review am vollständigen Diff geprüft werden.
- Keine Nachvollziehbarkeit. Welches Modell, welche Version, welcher Auftrag, und wer hat freigegeben? Ohne Protokoll im Änderungsticket bleibt die Frage des Prüfers unbeantwortet.
Dazu kommt der Anbieter selbst. Wer die Entwicklung auf einen KI-Anbieter stützt, hat eine neue Abhängigkeit. Sie gehört ins Informationsregister. In den Vertrag gehören die Pflichtinhalte nach Artikel 30 Absatz 2, darunter Datenstandort, Datenschutz, Kündigungsrechte, Unterstützung bei Vorfällen und Zugang zu den eigenen Daten. Dazu kommt der Trainingsausschluss, den die Enterprise-Verträge der großen Anbieter vorsehen. Und es braucht eine Antwort auf die Frage, wie gearbeitet wird, wenn der Anbieter ausfällt. Ein Entwicklungswerkzeug unterstützt in der Regel keine kritische oder wichtige Funktion im laufenden Betrieb. Fällt es aus, läuft das Portal weiter, und die Entwicklung wird langsamer. Die Einstufung trifft trotzdem Ihre Compliance und steht mit Begründung im Register. Wo die Daten verarbeitet werden, hängt beim Werkzeug vom gewählten Zugang ab, direkt beim Anbieter oder über eine Cloud-Plattform mit EU-Region. Was eine EU-Region beim Datenschutz leistet, steht im Artikel zu Azure AI Foundry.
Das Betriebsmodell: Architekt im Loop
Das Modell hat sieben Schritte. Jeder Schritt hat eine verantwortliche Rolle und erzeugt einen Nachweis.
| Schritt | Verantwortlich | Nachweis für die Aufsicht |
|---|---|---|
| 1. Leitplanken festlegen: freigegebene Repositories, gesperrte Bereiche, Kontextdateien mit Konventionen, Datenregeln, Review-Pflicht | Architekt mit Compliance | Richtlinie zum Agenteneinsatz als Teil des IKT-Risikorahmens |
| 2. Auftrag formulieren: abgegrenzte Änderung mit Abnahmekriterium | Entwickler; Aufträge des Architekten gibt eine zweite Person frei | Änderungsticket mit Umfang |
| 3. Änderung erzeugen: Code, Tests und Begründung | Agent | Diff, Testbericht, Auswirkungsbeschreibung |
| 4. Automatisch prüfen: Build, Tests, statische Analyse, Suche nach Zugangsdaten, Abhängigkeiten gegen Freigabeliste | Pipeline | Prüfprotokoll je Änderung |
| 5. Review und Freigabe: vollständiger Diff, Fachlogik gegen Anforderung, Sicherheitsrelevanz | Architekt, getrennt vom Auftraggeber | Freigabe mit Name und Datum |
| 6. Produktivsetzung mit Rückweg | Betrieb | Deployment-Protokoll, Rückfallplan |
| 7. Protokollieren: Modell, Version, Auftrag, Prüfergebnisse, Freigabe | Pipeline und Ticketsystem | Nachvollziehbare Kette von der Anforderung bis zur Produktion |
Notfalländerungen laufen über das bestehende Notfallverfahren des Hauses und werden nachträglich nach Schritt 5 bewertet und dokumentiert.
Der Architekt liest nicht jede Zeile. Er prüft Umfang, Grenzen und Risiko und entscheidet, wo tiefer gelesen wird. Was den Kreditprozess, den Zahlungsverkehr oder Kundendaten berührt, bekommt den tiefen Blick. Eine Umbenennung in einem Hilfsmodul bekommt ihn nicht. Diese Abstufung ist der risikobasierte Ansatz, den Artikel 9 Absatz 4 für das Änderungsmanagement vorsieht. Die Unterscheidung kann nur jemand treffen, der die Architektur und das Geschäft kennt. Deshalb steht in Schritt 5 ein Architekt und kein zweiter Agent.
Beispiel: Portal für die Finanzierung von KMU-Krediten
Bei einem Finanzdienstleister begleite ich ein Portal, über das Finanzierungen für kleine und mittlere Unternehmen abgewickelt werden. Das Haus steht unter Aufsicht, das Portal verarbeitet Kunden- und Bonitätsdaten, und das Entwicklungsteam arbeitet mit Claude Code. Die Regeln dort entsprechen den sieben Schritten oben.
Der Agent bekommt den Projektkontext als Datei: Architekturregeln, Namenskonventionen, Build- und Testbefehle und die Bereiche, die er nicht anfasst. Die Aufträge formulieren die Entwickler. Jede Aufgabe ist ein abgegrenzter Auftrag mit Abnahmekriterium. Der Agent liefert Änderung, Tests und eine kurze Begründung. Die Pipeline prüft Build, Tests, statische Analyse und Abhängigkeiten. Ich reviewe den vollständigen Diff und gebe frei. Was den Kreditprozess oder Kundendaten berührt, bekommt eine zweite Prüfung. Der Agent hat keinen Zugang zu Produktionsdaten. Testdaten werden synthetisch erzeugt. Im Ticket stehen Modell, Version, Auftrag und Prüfergebnisse.
Der sichtbare Effekt liegt bei Testabdeckung und Dokumentation. Beides entsteht mit der Änderung. Der Nachweis für die Aufsicht ist damit kein eigenes Projekt mehr, das vor der Prüfung aus Tickets und Erinnerungen rekonstruiert werden muss.
Was ein Prüfer fragen wird
- Wer hat die Änderung genehmigt? Die Freigabe steht mit Name und Datum im Ticket, getrennt vom Auftraggeber.
- Wie wurde getestet, bevor die Änderung produktiv ging? Testbericht und Prüfprotokoll der Pipeline, ausgeführt in einer Nicht-Produktionsumgebung.
- Welche Daten hat das Werkzeug gesehen? Die Datenregeln aus Schritt 1, der Vertrag mit Trainingsausschluss, der Datenstandort.
- Steht der Anbieter im Informationsregister, und was passiert bei einem Ausfall? Eintrag im Register, Einstufung durch Compliance, Arbeit ohne Agent bleibt möglich.
- Wie verhindern Sie, dass das Werkzeug mehr ändert als beauftragt? Umfang im Auftrag, vollständiger Diff im Review, begrenzte Schreibrechte.
- Welche Abhängigkeiten hat das Werkzeug eingeführt? Abhängigkeitsprüfung gegen die Freigabeliste und ein aktuelles Inventar.
Dieselben sechs Fragen stellt der Prüfer für Code, den ein Mensch geschrieben hat.
Was dieser Artikel nicht leistet
Drei Fragen klären Sie mit Compliance und Recht: Unterstützt der KI-Anbieter eine kritische oder wichtige Funktion? Wie sieht Ihr Änderungsverfahren im Detail aus? Welche Nachweise erwartet Ihre Aufsicht? Dieser Artikel beschreibt einen Prozess, der diesen Fragen standhält. Er ist keine Bestätigung der Konformität. Die verbindlichen Quellen sind die Verordnung (EU) 2022/2554 und die Delegierte Verordnung (EU) 2024/1774. Was die Verordnung für Architektur und Dienstleister insgesamt bedeutet, beschreibt der Artikel zur DORA-Verordnung für CTO und IT-Leitung.
Nächster Schritt
Wenn Ihr Team die Werkzeuge einführen oder aus der Schatten-Nutzung in einen geregelten Rahmen holen will, ist das KI-Enablement mit Governance-Baseline der Einstieg. Ich setze die Werkzeuge selbst täglich ein und kenne die Anforderungen regulierter Häuser aus meiner Zeit als CTO im FinTech-Umfeld. Wenn zuerst unklar ist, ob Ihr Entwicklungsprozess die Nachweise nach Artikel 9 und 25 heute liefern kann, klärt das ein Architektur-Review. Für die Abstimmung mit Vorstand und Compliance bietet sich das CTO-Sparring an.