Nachweise statt Verbote: KI-Coding-Agenten unter DORA
DORA verbietet Claude Code nicht. Die Verordnung regelt, wie Änderungen erfasst, getestet, genehmigt und nachgewiesen werden, und sagt nichts darüber, wer den Code schreibt. Wie ich das in einem Portal für KMU-Kredite eingerichtet habe und welche Nachweise dabei entstehen.
In Gesprächen mit Finanzunternehmen kommt inzwischen fast immer dieselbe Frage: ob man Claude Code oder Copilot unter DORA überhaupt einsetzen darf. In vielen Häusern lautet die Antwort erst einmal Verbot. Ein Verbot ändert aus meiner Sicht wenig. Die Entwickler nutzen die Werkzeuge dann privat weiter, und niemand hat mehr einen Überblick, welcher Code wohin kopiert wird.
Die Verordnung selbst sagt dazu etwas anderes. Sie regelt nicht, wer den Code schreibt. Sie regelt, wie eine Änderung an einem System erfasst, getestet, genehmigt und nachgewiesen wird. Ein Coding-Agent ist für die Aufsicht also ein Werkzeug in einem Prozess, und dieser Prozess muss Nachweise liefern. Wie das in der Praxis aussieht, beschreibe ich an dem Portal für KMU-Kredite, das ich gerade begleite.
Was DORA von der Softwareentwicklung verlangt
Die Vorgaben für die Entwicklung stehen in der Verordnung selbst und in den technischen Standards dazu. Artikel 9 Absatz 4 verlangt Richtlinien für das Änderungsmanagement, ausdrücklich auch für Software. Jede Änderung wird erfasst, getestet, bewertet, genehmigt und kontrolliert umgesetzt. Wie tief geprüft wird, darf sich am Risiko der Änderung orientieren. Artikel 25 zählt auf, was ein Testprogramm enthalten soll. Dazu gehören Quellcode-Prüfungen, Schwachstellenscans und die Analyse von Open-Source-Komponenten.
Die Delegierte Verordnung (EU) 2024/1774 macht das in den Artikeln 16 und 17 konkret. Für Entwicklung und Wartung braucht es eine Richtlinie und ein Verfahren. Der Quellcode wird auf Schwachstellen geprüft, Sicherheitstests laufen spätestens bei der Integration, und vor der Produktivsetzung wird getestet. In Test- und Entwicklungsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten liegen. Ausnahmen für einzelne Testanlässe sind befristet, genehmigt und dem IKT-Risikomanagement gemeldet. Beim Änderungsverfahren ist mir ein Punkt besonders wichtig: Wer eine Änderung beantragt oder umsetzt, darf sie nicht selbst genehmigen. Dazu kommen klare Rollen, ein Rückfallverfahren und Regeln für Notfalländerungen.
Übersetzt auf einen Coding-Agenten heißt das:
| 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 |
Neu ist davon nichts. Dieselben Pflichten gelten für Code, den ein Mensch schreibt. Der Agent erhöht das Tempo, und damit wächst die Menge an Nachweisen, die der Prozess erzeugen muss.
Warum ein Verbot wenig hilft
Verbietet ein Haus die Werkzeuge, kopieren Entwickler ihren Code trotzdem in ein privates Chatfenster. Der Code verlässt das Haus dann an der Informationssicherheitsleitlinie vorbei. Testdaten mit echten Kundennamen in so einem Fenster sind ein Datenschutzvorfall. Und ein Anbieter, den im Haus niemand kennt, steht in keinem Informationsregister. Die technischen Standards verlangen in Artikel 11 Regeln dafür, welche Software auf Endgeräten laufen darf und wie Datenabfluss verhindert wird. Mit einer geregelten Nutzung kann die Aufsicht das alles prüfen. Wie ein Team die Werkzeuge geregelt einführt, habe ich im Artikel zum KI-Enablement im Engineering-Team beschrieben.
Wo der Agent die Nachweise gleich mitliefert
Die Nachweise, die DORA verlangt, sind genau die Arbeit, die in Entwicklungsteams liegen bleibt. Hier hilft der Agent in der Tat am meisten. Er schreibt Charakterisierungstests für Module, die seit Jahren niemand angefasst hat. Damit entstehen die Tests vor der Produktivsetzung, die Artikel 16 der Standards verlangt, und ihr Umfang wächst mit jeder Änderung. Er erzeugt aus Build-Dateien und Code ein Inventar der Pakete, Dienste und Schnittstellen mit ihren Versionen. Das speist das Inventar nach Artikel 8 und zeigt, welche externen Dienste ins Informationsregister gehören. Wie das bei einem undokumentierten System aussieht, steht im Artikel zur Architektur-Rekonstruktion mit KI-Agenten. Er schreibt Wiederherstellungsschritte, Konfigurationsübersicht und Betriebshandbuch aus dem Code heraus und hält sie mit jeder Änderung aktuell. Das sind die Unterlagen für die Wiederherstellungspläne nach Artikel 11 und 12.
Und er schreibt zu jeder Änderung auf, was er geändert hat, warum und welche Auswirkungen er erwartet. Das ist der Entwurf für die Dokumentation nach Artikel 17 der Standards, also Zweck, Umfang und erwartete Ergebnisse. Ob die Sicherheitsanforderungen erfüllt sind und ob die Änderung bestehende Schutzmaßnahmen berührt, bewertet danach der Reviewer. Diese Bewertung nimmt einem niemand ab.
Dokumentation, die mit der Änderung entsteht, ist aktuell. Was erst vor der Prüfung nachgeholt wird, ist eine Rekonstruktion aus Tickets und Erinnerung.
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 mit einem KI-Anbieter entwickelt, 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 darauf, 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 die Compliance, und sie 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, habe ich im Artikel zu Azure AI Foundry beschrieben.
So läuft es im Portal für KMU-Kredite
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.
Der Agent bekommt den Projektkontext als Datei. Darin stehen Architekturregeln, Namenskonventionen, die Build- und Testbefehle und die Bereiche, die er nicht anfasst. Die Aufträge formulieren die Entwickler, immer als abgegrenzte Änderung mit Abnahmekriterium. Formuliere ich selbst einen Auftrag, gibt ihn jemand anderes frei. Der Agent liefert dann die Änderung, die Tests dazu und eine kurze Begründung. Die Pipeline prüft Build, Tests, statische Analyse, Zugangsdaten im Code und die Abhängigkeiten gegen die Freigabeliste. Danach lese ich 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, die Testdaten werden synthetisch erzeugt. Im Ticket stehen am Ende Modell, Version, Auftrag, Prüfergebnisse und die Freigabe mit Namen und Datum. Notfalländerungen laufen über das Notfallverfahren des Hauses und werden nachträglich bewertet und dokumentiert.
Als Übersicht, mit dem Nachweis, der bei jedem Schritt übrig bleibt:
| Schritt | Wer | Was als Nachweis bleibt |
|---|---|---|
| Leitplanken: freigegebene Repositories, gesperrte Bereiche, Kontextdatei, Datenregeln, Review-Pflicht | Architekt mit Compliance | Richtlinie zum Agenteneinsatz im IKT-Risikorahmen |
| Auftrag mit Abnahmekriterium | Entwickler, Aufträge des Architekten gibt eine zweite Person frei | Änderungsticket mit Umfang |
| Code, Tests und Begründung | Agent | Diff, Testbericht, Auswirkungsbeschreibung |
| Build, Tests, statische Analyse, Suche nach Zugangsdaten, Abhängigkeiten gegen Freigabeliste | Pipeline | Prüfprotokoll je Änderung |
| Review des vollständigen Diffs und Freigabe | Architekt, getrennt vom Auftraggeber | Freigabe mit Name und Datum |
| Produktivsetzung mit Rückweg | Betrieb | Deployment-Protokoll, Rückfallplan |
| Protokoll: Modell, Version, Auftrag, Prüfergebnisse, Freigabe | Pipeline und Ticketsystem | Kette von der Anforderung bis zur Produktion |
Ich lese dabei nicht jede Zeile. Ich prüfe Umfang, Grenzen und Risiko und entscheide, wo ich tiefer lese. Eine Änderung am Kreditprozess, am Zahlungsverkehr oder an Kundendaten lese ich komplett, eine Umbenennung in einem Hilfsmodul nicht. Diese Abstufung ist der risikobasierte Ansatz, den Artikel 9 Absatz 4 für das Änderungsmanagement vorsieht. Treffen kann sie aus meiner Sicht nur jemand, der die Architektur und das Geschäft kennt. Deshalb sitzt an dieser Stelle ein Architekt und kein zweiter Agent.
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 zusammengesucht werden muss.
Was der Prüfer fragt
Aus diesem Ablauf lassen sich die Fragen beantworten, die ein Prüfer stellt.
- Wer hat die Änderung genehmigt? Die Freigabe steht mit Name und Datum im Ticket, getrennt vom Auftraggeber.
- Wie wurde vor der Produktivsetzung getestet? Mit dem Testbericht und dem Pipeline-Protokoll, ausgeführt außerhalb der Produktion.
- Welche Daten hat das Werkzeug gesehen? Das regeln die Datenregeln aus der Richtlinie, der Vertrag mit Trainingsausschluss und der Datenstandort.
- Steht der Anbieter im Informationsregister, und was passiert bei einem Ausfall? Der Eintrag ist da, die Compliance hat ihn eingestuft, und die Arbeit ohne Agent bleibt möglich.
- Wie wird verhindert, dass das Werkzeug mehr ändert als beauftragt? Durch den Umfang im Auftrag, den vollständigen Diff im Review und begrenzte Schreibrechte.
- Welche Abhängigkeiten hat das Werkzeug eingeführt? Das zeigen die Prüfung gegen die Freigabeliste und ein aktuelles Inventar.
Dieselben Fragen stellt der Prüfer bei Code, den ein Mensch geschrieben hat.
Was dieser Artikel nicht leistet
Mit Compliance und Recht klären Sie, ob der KI-Anbieter eine kritische oder wichtige Funktion unterstützt. Dort wird auch festgelegt, wie das Änderungsverfahren im Haus genau aussieht und welche Nachweise die Aufsicht erwartet. Ich beschreibe hier einen Ablauf, der diesen Fragen standhält. Eine Bestätigung der Konformität ist das nicht. 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, steht im Artikel zur DORA-Verordnung für CTO und IT-Leitung.
Nächster Schritt
Wenn Ihr Team die Werkzeuge einführen will oder sie längst nutzt und jetzt Regeln braucht, ist das KI-Enablement mit Governance-Baseline der Einstieg. Ich arbeite selbst täglich mit Claude Code und kenne die Anforderungen regulierter Häuser aus meiner Zeit als CTO im FinTech-Umfeld. Wenn vorher unklar ist, ob der eigene Entwicklungsprozess die Nachweise nach Artikel 9 und 25 heute überhaupt liefern kann, klärt das ein Architektur-Review. Für die Abstimmung mit Vorstand und Compliance gibt es das CTO-Sparring.