Der Assistent
Erklärt eine Funktion, formuliert Anforderungen oder entwirft einen Codeabschnitt.
Die Kontrollfrage: Wer prüft und übernimmt den Vorschlag?
Aufgaben klar begrenzenWas darf der Agent lesen, verändern und ausführen?
Qualität unabhängig prüfenWer bestätigt fachliche Richtigkeit und Sicherheit?
Entscheidungen belegenWie werden Auftrag, Änderung, Test und Freigabe verbunden?
Vom Vorschlag zur Ausführung
Was unterscheidet einen KI-Agenten von einem Coding-Assistenten?
Ein KI-Assistent unterstützt mit Vorschlägen. Ein Agent kann darüber hinaus Dateien bearbeiten, Werkzeuge aufrufen und mehrere Arbeitsschritte verfolgen. Mit diesen Befugnissen wächst der Bedarf an wirksamen Grenzen und zuordenbarer Verantwortung.
Der Entwicklungsagent
Bearbeitet einen eigenen Branch und startet Tests in einer abgegrenzten Umgebung.
Die Kontrollfrage: Welche Dateien, Daten und Werkzeuge sind freigegeben?
Mehrere Agenten
Teilen Entwicklungs-, Test- und Review-Aufgaben über einen gesteuerten Ablauf auf.
Die Kontrollfrage: Wer begrenzt Delegation und verhindert Selbstfreigabe?
Die Gegenüberstellung dient der Orientierung und ist keine gesetzliche Risikoklassifikation. Ein zweiter Agent ersetzt nicht automatisch eine unabhängige Kontrolle.
Sechs Phasen · klare Kontrollpunkte
Wie bleibt der Entwicklungsprozess mit Agenten steuerbar?
Jede Phase verbindet einen möglichen Agentenbeitrag mit einer Kontrolle und einem nachvollziehbaren Ergebnis. Die folgende Darstellung ist unser Vorschlag für die praktische Einbindung in bestehende Prozesse.
Auftrag & Anforderungen
- Beitrag des Agenten
- Tickets strukturieren, Akzeptanzkriterien und offene Fragen vorschlagen.
- Kontrollpunkt
- Fachliche Regeln, Datenbedarf und Grenzen vorab bestätigen.
- Nachweis & Verantwortung
- Freigegebener Auftrag; Product Owner und Fachverantwortliche.
Architektur & Zugriffe
- Beitrag des Agenten
- Lösungsvarianten und Schnittstellen entwerfen.
- Kontrollpunkt
- Datenflüsse, Bedrohungen, Werkzeuge und Berechtigungen bewerten.
- Nachweis & Verantwortung
- Architekturbild und Zugriffsmatrix; Architektur und Security.
Implementierung
- Beitrag des Agenten
- Code, Dokumentation und Änderungsvorschläge in isolierter Umgebung erstellen.
- Kontrollpunkt
- Repository, Netzwerkzugriffe und Änderungsumfang technisch begrenzen.
- Nachweis & Verantwortung
- Zugeordneter Agentenlauf und Commit; Entwicklung.
Tests & Review
- Beitrag des Agenten
- Tests entwerfen und ausführen, Befunde vorsortieren.
- Kontrollpunkt
- Unabhängige Sollwerte, fachliche Regression und Sicherheitsprüfungen einsetzen.
- Nachweis & Verantwortung
- Testbericht, Befunde und Review; Qualitätssicherung und Fachbereich.
Freigabe & Auslieferung
- Beitrag des Agenten
- Release-Unterlagen und Rückfallverfahren vorbereiten.
- Kontrollpunkt
- Unabhängige Genehmigung und risikobasierte menschliche Freigabepunkte durchsetzen.
- Nachweis & Verantwortung
- Genehmigter Change und Release-Nachweis; Change-/Release-Verantwortliche.
Überwachung & Änderung
- Beitrag des Agenten
- Fehlerbilder analysieren und Korrekturen vorschlagen.
- Kontrollpunkt
- Modell- und Werkzeugwechsel bewerten; Abschaltung und Wiederanlauf erproben.
- Nachweis & Verantwortung
- Versionsstand, Monitoring und Wiederanlauftest; Tool-Owner und Betrieb.
Die NachweisketteAuftragAgentenlaufCommitTestsFreigabe
Rollen und Funktionstrennung werden je Institut festgelegt. Die letzte Phase umfasst die Entwicklungswerkzeuge und die ausgelieferte Software. Agenten im Kunden- oder Transaktionsbetrieb sind gesondert zu beurteilen.
Zwei Branchen · derselbe Qualitätsanspruch
Wie sieht das in der Praxis von Banken und Versicherungen aus?
Zwei Szenarien, eine Meldewesen-Datenstrecke und eine Schadenplattform, veranschaulichen den Ansatz. Sie sind keine Kundenreferenzen oder Aussagen über bereits erzielte Ergebnisse.
Eine Meldewesen-Datenstrecke anpassen
Ein Agent schlägt SQL- oder ETL-Anpassungen und Regressionstests vor. Fachliche Validierungsregeln und Vergleichsdaten bleiben die Grundlage der Abnahme.
Entscheidend: Summen abstimmen, Datenherkunft belegen und das Ergebnis unabhängig prüfen. Formal korrekter Code kann fachlich falsche Meldedaten erzeugen.
Ergebnis: Ein nachvollziehbarer Änderungsvorschlag mit Tests und fachlicher Freigabe.
Eine Schadenplattform anbinden
Ein Agent bereitet Mapping-Anpassungen, Schnittstellentests und Fehlerbehandlung vor. Aufbereitete Testfälle bilden die fachlichen Abläufe ab.
Entscheidend: Buchungen abstimmen, Ausnahmefälle testen und Datenflüsse prüfen. Personen- und gegebenenfalls Gesundheitsdaten erfordern besondere Aufmerksamkeit.
Ergebnis: Eine geprüfte Schnittstellenänderung mit dokumentierter Abnahme.
Entwicklungswerkzeug und Zielsystem getrennt betrachten
Der Einsatz eines Coding-Agenten macht die entwickelte Datenstrecke oder Schnittstelle nicht automatisch zu einem KI-System. Zweck, Funktionen und Rolle des Instituts sind gesondert zu prüfen. [3]
Anforderungen richtig einordnen
Was ist für KI-Agenten verbindlich, was nur Orientierung?
Verbindlich sind bestehende Regeln wie DORA, AI Act, DSGVO und ArbVG; Aufsichtspapiere wie die FSB-Praktiken geben Orientierung. Rechtliche Anforderungen, Aufsichtspapiere und eigene Umsetzungskontrollen haben unterschiedliche Bedeutung. Diese Unterscheidung bleibt auch bei KI-Agenten wesentlich.
Bestehende Regeln anwenden
Eine eigene Vorschrift für KI-Agenten in der Softwareentwicklung gibt es weder auf EU- noch auf österreichischer Ebene. Für erfasste Institute bilden DORA und die RTS einen Rahmen für Entwicklung, Änderungsmanagement, Identitäten und Zugriffe. Art. 17 RTS verlangt unabhängige Genehmigungsfunktionen. [1] [2]
Datenschutz, Vertraulichkeit und Arbeitsrecht ergänzen diesen Rahmen. AI-Act-Pflichten sind nach Zweck und Rolle zu prüfen; der Coding-Agent allein begründet keine Anbieterrolle. [3] [5–7]
Aktuelle Leitgedanken nutzen
Die unverbindlichen FSB-Praktiken vom 15. Oktober 2026 behandeln unter anderem Verantwortung, Agentenzugriffe, menschliche Aufsicht und wirksame Eingriffsmöglichkeiten. [8]
Für Versicherungen ergänzt die an nationale Aufsichten gerichtete EIOPA-Opinion die Einordnung. Die gemeinsame ESA-Erklärung behandelt sektorübergreifende IKT-Risiken durch Frontier-KI. [9] [10]
In Österreich wollen FMA und OeNB laut ihren Aufsichtsprioritäten 2026 den Aufsichtsansatz für KI-Anwendungen von Banken erst entwickeln und kommunizieren. Als Referenzmaßstab eignet sich die BaFin-Orientierungshilfe zu IKT-Risiken beim Einsatz von KI vom 18. Dezember 2025; für österreichische Institute gilt sie nicht. [12] [13]
Kontrollen konkret machen
Welche Änderungen menschlich freizugeben sind, welche Werkzeuge zulässig sind und wie ein Pilot abgenommen wird, muss im Institut festgelegt werden.
Unsere Prozessdarstellung und die folgenden acht Steuerungsfelder sind Umsetzungsvorschläge. OWASP liefert technische Orientierung; daraus entsteht keine zusätzliche gesetzliche Zertifizierungspflicht. [14] [15]
Bankenspezifisch ist unter anderem das Bankgeheimnis nach § 38 BWG zu beachten. Bei Versicherungen sind Vertraulichkeit und sensible Daten im jeweiligen Geschäftskontext zu beurteilen. DORA-Anwendungsbereich und einschlägiger Risikomanagementrahmen sind je Unternehmen zu prüfen.
Rechtsrahmen im Überblick
Diese Vorgaben gelten unmittelbar oder werden von der Aufsicht ausdrücklich eingefordert. Unter „Bedeutung für KI-Agenten“ steht, was daraus für den Agenteneinsatz folgt; diese Zuordnung ist unsere fachliche Einschätzung.
| Regelwerk | Anforderung | Bedeutung für KI-Agenten |
|---|---|---|
| DORA-RTS 2024/1774, Art. 16: Entwicklung [2] | Dokumentierte Entwicklungsrichtlinie; Tests nach Kritikalität; statische und dynamische Quellcode-Prüfung; in Nichtproduktionsumgebungen grundsätzlich nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten; Prüfung von Dritt- und Open-Source-Code. Gilt risikobasiert auch für Systeme, die Nutzer außerhalb der IKT-Funktion entwickeln (Abs. 9). | KI-generierter Code durchläuft dieselben Prüfungen wie jeder andere Code. Agenten erhalten keinen Kontext mit echten Produktionsdaten. Fachbereiche, die mit Agenten eigene Anwendungen bauen, sind erfasst. |
| DORA-RTS, Art. 17: Änderungsmanagement [2] | Unabhängigkeit der genehmigenden Funktion von Antragsteller und Umsetzer; dokumentierter Zweck, Umfang und Zeitplan; Rückfall- und Notfallverfahren; Bewertung der Auswirkungen auf Sicherheitsmaßnahmen. | Ein Agent gibt eine von ihm erstellte Änderung nicht selbst in Produktion frei. Die Genehmigung bleibt bei einer unabhängigen Funktion. |
| DORA-RTS, Art. 20 und 21: Identitäten und Zugriffe [2] | Eindeutige Identifikation von Personen und Systemen; Need-to-know und Least Privilege; Sammelkonten möglichst begrenzen; Rechte mindestens jährlich, bei Systemen für kritische oder wichtige Funktionen mindestens halbjährlich aktualisieren. | Jeder Agent erhält eine eigene Identität, getrennt von Entwickler- und Servicekonten, mit minimalen Rechten und regelmäßiger Rezertifizierung. |
| DORA Art. 28–30: IKT-Drittdienstleister [1] | Informationsregister; Risikoanalyse vor Vertragsschluss; vertragliche Mindestinhalte; Exit-Strategie. | Cloudbasierte Coding-Agenten sind IKT-Dienstleistungen. Werden Komponenten wie MCP-Server oder Plug-ins von Dritten betrieben, gilt das auch für sie. |
| EU AI Act, VO 2024/1689 i. d. F. VO 2026/1744 [3] [4] | Art. 4: Maßnahmen zur Unterstützung der KI-Kompetenz, ohne bestimmtes Kompetenzniveau; Hochrisiko-Pflichten nach Anhang III ab 2. Dezember 2027; Marktüberwachung für Hochrisiko-KI im direkten Zusammenhang mit Finanzdienstleistungen grundsätzlich durch die Finanzaufsicht (Art. 74 Abs. 6). | Der Coding-Agent selbst ist in der Regel kein Hochrisiko-System. Entwickelt ein Institut ein Hochrisiko-KI-System, etwa zur Kreditwürdigkeitsprüfung, ist es dafür in der Regel Anbieter, unabhängig davon, ob Agenten mitwirken. Agenten gehören ins KI-Inventar. |
| DSGVO [5] | Rechtsgrundlage; Auftragsverarbeitung; Datenschutz-Folgenabschätzung; Drittlandübermittlung. | Relevant, sobald Agenten personenbezogene Daten in Repositories, Tickets oder Testdaten verarbeiten oder Daten an den Anbieter übermitteln. |
| § 38 BWG: Bankgeheimnis [6] | Geheimnisse, die ausschließlich aufgrund der Geschäftsverbindung mit Kunden anvertraut oder zugänglich gemacht wurden, dürfen nicht offenbart oder verwertet werden. | Vor dem Einsatz externer Agentendienste klären, ob Kundendaten in Kontext, Protokolle oder Testdaten gelangen können. |
| §§ 96, 96a ArbVG [7] | Zustimmung des Betriebsrats zu Kontrollmaßnahmen, die die Menschenwürde berühren, und zu bestimmten Systemen der Personaldatenverarbeitung. | Agenten-Protokolle, die Handlungen einzelnen Entwicklern zuordnen, können eine Kontrollmaßnahme sein. Eine Betriebsvereinbarung ist zu prüfen. |
| EZB-Schreiben SSM-2026-0301 vom 7. Juli 2026 [11] | Bedeutende Institute: Aktionsplan gegen KI-gestützte Cyberbedrohungen bis 31. Oktober 2026, unter anderem zu Schwachstellen- und Patchmanagement sowie IKT-Drittparteienrisiken. | Das Schreiben behandelt keine Coding-Agenten, betrifft aber denselben Entwicklungsprozess. Weniger bedeutende Institute sind nicht Adressaten. |
Vom Grundsatz zur Umsetzung
Welche acht Steuerungsfelder braucht der Agenteneinsatz?
Von Auftrag & Verantwortung über Identität, Daten, Isolation, Qualität, Freigabe und Nachweise bis zu Eingriff & Wiederanlauf. Diese Felder lassen sich in bestehende Entwicklungs-, Sicherheits- und Governance-Vorgaben einbauen. Acht Felder bedeuten nicht acht neue Richtliniendokumente.
Auftrag & Verantwortung
Zulässige Aufgaben, fachliche Akzeptanzkriterien und verantwortliche Menschen benennen. Agenten ins KI-Inventar aufnehmen und Beteiligte schulen, auch in Fachbereichen, die mit Agenten eigene Anwendungen bauen.
Identität & Berechtigungen
Jedem Agenten eine eigene Identität geben, Läufe zuordnen, Rechte minimieren und regelmäßig rezertifizieren. Delegation an weitere Agenten begrenzen.
Daten & Anbieter
Festlegen, welche Daten in den Agentenkontext und damit zum Anbieter gelangen dürfen. Agentendienste als IKT-Drittdienstleistung steuern: Informationsregister, Vertrag, Modelländerungen und Exit.
Isolation & Werkzeugkontrolle
Umgebungen trennen, Werkzeuge freigeben und Netzwerkzugriffe technisch begrenzen.
Qualität & Sicherheit
Fachliche Tests, Sicherheits-, Abhängigkeits- und Lizenzprüfungen sowie Tests gegen manipulierte Eingaben vorsehen. KI-generierte Commits kennzeichnen.
Freigabe & Funktionstrennung
Genehmigungen außerhalb des vom Agenten veränderbaren Bereichs verankern und Selbstfreigabe verhindern.
Nachweise & Änderungen
Auftrag, Modell-/Werkzeugstand, Codeänderung, Testergebnisse und Genehmigung verbinden. Machen Protokolle Leistungen einzelner Mitarbeiter auswertbar, ist eine Betriebsvereinbarung zu prüfen.
Eingriff & Wiederanlauf
Aktivitäten stoppen, Zugriffe entziehen und einen sicheren Wiederanlauf praktisch erproben.
Technische Grenzen ergänzen die Anweisungen an das Modell. Für manipulierbare Werkzeugantworten und externe Inhalte sind eigene Kontrollen sinnvoll. MCP (Model Context Protocol) verbindet Agenten mit Werkzeugen und Datenquellen; Betreiber und Dienstleistungsbeziehungen dieser Komponenten sind einzeln zu prüfen. [14] [15]
Ihr nächster Schritt
Wo steht Ihr Entwicklungsprozess heute?
Sie nutzen bereits Coding-Assistenten oder planen Entwicklungsagenten? Wir betrachten mit Ihnen einen ausgewählten Ablauf und identifizieren, welche Kontrollen schon bestehen und wo Handlungsbedarf liegt.
Die Standortbestimmung verbindet Fachanforderungen, Prozesse und Governance. Sie knüpft an unsere Erfahrung in Banken, Versicherungen, Meldewesen und Systemintegration an.
Standortbestimmung anfragenDas erarbeiten wir gemeinsam
- Bestandsaufnahme: Agenten, Werkzeuge, Datenflüsse und Verantwortliche für einen abgegrenzten Ablauf.
- Kontrolllücken: Vorhandene und fehlende Prüf- und Freigabepunkte.
- Nachweiskonzept: Benötigte Belege vom Auftrag bis zur Auslieferung.
- Pilotplan: Priorisierte Maßnahmen mit Zuständigkeiten und Abnahmekriterien.
Umfang und Vorgehen vereinbaren wir individuell. Die Standortbestimmung ist keine Zertifizierung oder vollständige technische beziehungsweise rechtliche Prüfung.
Häufige Fragen aus der Praxis
Gibt es eine eigene Vorschrift für KI-Agenten in der Softwareentwicklung?
Nein. Stand Oktober 2026 gibt es weder auf EU- noch auf österreichischer Ebene eine eigene Regelung. Die verbindlichen Pflichten ergeben sich vor allem aus DORA und der Delegierten Verordnung (EU) 2024/1774: Entwicklung, Änderungsmanagement, Identitäten, Zugriffe und IKT-Drittdienstleister. Dazu kommen AI Act, Datenschutz und Arbeitsrecht. Agenten-spezifische Erwartungen formulieren bisher nur unverbindliche Papiere wie die FSB-Praktiken. [1] [2] [8]
Ist ein Coding-Agent automatisch Hochrisiko-KI?
Nein. Entscheidend sind Zweck und Einsatzkontext des konkreten KI-Systems. Das entwickelte Zielsystem und die Anbieter-/Betreiberrolle des Instituts werden getrennt betrachtet. Auch KI-generierter Code ist nicht automatisch selbst ein KI-System. [3]
Kann derselbe Agent entwickeln, testen und freigeben?
Er kann Tests ausführen und Reviews unterstützen. Das schafft allein noch keine unabhängige Genehmigung. Art. 17 RTS verlangt Unabhängigkeit der genehmigenden Funktion; konkrete menschliche Freigabepunkte werden risikobasiert im Institut festgelegt. [2]
Welche Daten dürfen in den Agentenkontext gelangen?
Nur die für den freigegebenen Zweck zulässigen und notwendigen Daten. Für Nichtproduktionsumgebungen nennt Art. 16 Abs. 5 RTS grundsätzlich anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten; Abs. 6 enthält eine begrenzte Testausnahme mit Genehmigung und Information der IKT-Risikomanagementfunktion. Das ist keine pauschale Erlaubnis zur Weitergabe an einen KI-Anbieter. Pseudonymisierte Daten können weiterhin personenbezogen sein. [2] [5]
Was unterscheidet Banken und Versicherungen?
Beide brauchen einen kontrollierten Entwicklungsprozess. Hinzu kommen die jeweiligen Sektorvorgaben und Datenrisiken: bei Banken etwa das Bankgeheimnis, bei Versicherungen gegebenenfalls Gesundheitsdaten. Die EIOPA-Opinion bietet versicherungsbezogene Orientierung; sie ist keine eigene Agentenverordnung. [6] [9]
Wie lässt sich ein Pilot sinnvoll starten?
Mit einem klar abgegrenzten Anwendungsfall, freigegebenen Daten und Werkzeugen sowie vorab festgelegten Abnahmekriterien. Qualität, Nacharbeit, Kontrollaufwand und Sicherheitsbefunde sollten gemeinsam bewertet werden. Mehr Autonomie folgt erst nach einer bewussten Bewertung der Ergebnisse.
Ing. Mag. Patrick Eiler
Patrick Eiler berät Banken und Versicherungen in Wien zu aufsichtlichem Meldewesen, Datenarchitektur und KI-Compliance. Über zwanzig Jahre in Banken, Versicherungen und Finanzdienstleistung; Vortragender beim Hypo-Verband (Fachsitzung 23. September 2026).