The assistant
Explains a function, drafts requirements or proposes a code snippet.
The control question: Who checks and adopts the suggestion?
Set clear task boundariesWhat may the agent read, change and execute?
Check quality independentlyWho confirms business correctness and security?
Keep decisions traceableHow do the task, change, tests and approval connect?
From suggestions to execution
What distinguishes an AI agent from a coding assistant?
An AI assistant offers suggestions. An agent can also edit files, invoke tools and pursue a sequence of tasks. These permissions call for effective boundaries and identifiable accountability.
The development agent
Edits a dedicated branch and runs tests in a bounded environment.
The control question: Which files, data and tools are approved?
Multiple agents
Share development, testing and review tasks within an orchestrated workflow.
The control question: Who limits delegation and prevents self-approval?
This comparison is an explanatory model, not a legal risk classification. A second agent does not automatically provide an independent control.
Six phases · clear control points
How does the development workflow stay under control with agents?
Each phase connects a possible agent contribution to a control and traceable evidence. The following is our proposed approach to integration with existing processes.
Task & requirements
- Agent contribution
- Structure tickets and suggest acceptance criteria and open questions.
- Control point
- Confirm business rules, data needs and boundaries in advance.
- Evidence & responsibility
- Approved task; product owner and business owners.
Architecture & access
- Agent contribution
- Draft solution options and interfaces.
- Control point
- Assess data flows, threats, tools and access permissions.
- Evidence & responsibility
- Architecture diagram and access matrix; architecture and security.
Implementation
- Agent contribution
- Create code, documentation and proposed changes in an isolated environment.
- Control point
- Enforce repository, network and change-scope boundaries.
- Evidence & responsibility
- Identifiable agent run and commit; development.
Testing & review
- Agent contribution
- Draft and run tests and triage findings.
- Control point
- Use independent expected results, business regression tests and security checks.
- Evidence & responsibility
- Test report, findings and review; quality assurance and business teams.
Approval & release
- Agent contribution
- Prepare release documentation and rollback procedures.
- Control point
- Enforce independent authorisation and risk-based human approval points.
- Evidence & responsibility
- Approved change and release record; change and release owners.
Monitoring & change
- Agent contribution
- Analyse failure patterns and suggest fixes.
- Control point
- Assess model and tool changes; exercise shutdown and recovery.
- Evidence & responsibility
- Version records, monitoring and recovery test; tool owner and operations.
The evidence chainTaskAgent runCommitTestsApproval
Roles and segregation of duties are defined by each institution. The final phase covers development tools and released software. Agents in customer-facing or transaction operations require a separate assessment.
Two sectors · the same quality standard
What does this look like in banks and insurers?
Two scenarios, a regulatory reporting data pipeline and a claims platform, illustrate the approach. They are not client references or claims about results already achieved.
Changing a regulatory reporting data pipeline
An agent proposes SQL or ETL changes and regression tests. Business validation rules and reference data remain the basis for acceptance.
What matters: Reconcile totals, establish data provenance and check results independently. Syntactically correct code can produce incorrect reporting data.
Outcome: A traceable proposed change with tests and business approval.
Connecting a claims platform
An agent prepares mapping changes, interface tests and error handling. Appropriately prepared test cases represent the business workflows.
What matters: Reconcile postings, test exceptions and check data flows. Personal data and, where relevant, health data need particular attention.
Outcome: A tested interface change with documented acceptance.
Assess the development tool and the resulting system separately
Using a coding agent does not automatically turn the resulting data pipeline or interface into an AI system. Purpose, functionality and the institution's role require a separate assessment. [3]
Putting requirements in context
What is binding for AI agents, and what is only guidance?
Existing rules such as DORA, the AI Act, GDPR and the ArbVG are binding; supervisory papers such as the FSB practices provide guidance. Legal requirements, supervisory papers and internal implementation controls have different standing. This distinction also matters when using AI agents.
Apply the existing rules
There is no dedicated rule for AI agents in software development at EU or Austrian level. For entities in scope, DORA and its RTS provide a framework for development, change management, identity and access. Article 17 RTS requires independent approval functions. [1] [2]
Data protection, confidentiality and labour law complement this framework. AI Act duties depend on purpose and role; using a coding agent does not itself make the institution a provider. [3] [5–7]
Use current principles
The non-binding FSB practices of 15 October 2026 address accountability, agent access, human oversight and effective intervention, among other topics. [8]
For insurers, EIOPA's Opinion, addressed to national supervisors, adds sector context. The joint ESA statement addresses cross-sector ICT risks from frontier AI. [9] [10]
In Austria, the FMA and OeNB state in their 2026 supervisory priorities that a supervisory approach to banks’ AI applications is still to be developed and communicated. BaFin’s guidance on ICT risks in the use of AI of 18 December 2025 is a useful benchmark, although it does not apply to Austrian institutions. [12] [13]
Make controls concrete
The institution must define which changes need human approval, which tools are allowed and how a pilot is accepted.
Our workflow and the following eight control areas are implementation proposals. OWASP offers technical guidance; it does not create an additional legal certification requirement. [14] [15]
Banking-specific considerations include banking secrecy under section 38 BWG. For insurers, confidentiality and sensitive data must be assessed in their business context. DORA scope and the applicable risk management framework must be checked for each entity.
The legal framework at a glance
These requirements apply directly or are explicitly expected by supervisors. “What it means for AI agents” shows what follows for agent use; this mapping is our professional assessment.
| Framework | Requirement | What it means for AI agents |
|---|---|---|
| DORA RTS 2024/1774, Art. 16: development [2] | Documented development policy; testing proportionate to criticality; static and dynamic source code review; non-production environments in principle only with anonymised, pseudonymised or randomised production data; review of third-party and open-source code. Also applies, on a risk basis, to systems developed by users outside the ICT function (para. 9). | AI-generated code goes through the same checks as any other code. Agents get no context containing real production data. Business units building their own applications with agents are covered. |
| DORA RTS, Art. 17: change management [2] | Independence of the approving function from those requesting and implementing changes; documented purpose, scope and timeline; fall-back and emergency procedures; assessment of the impact on security measures. | An agent does not release its own change into production. Approval stays with an independent function. |
| DORA RTS, Art. 20 and 21: identity and access [2] | Unique identification of people and systems; need-to-know and least privilege; limit generic and shared accounts; update access rights at least annually, and at least every six months for systems supporting critical or important functions. | Each agent gets its own identity, separate from developer and service accounts, with minimal rights and regular recertification. |
| DORA Art. 28–30: ICT third-party providers [1] | Register of information; risk assessment before contracting; minimum contractual content; exit strategy. | Cloud-based coding agents are ICT services. Where components such as MCP servers or plug-ins are operated by third parties, this applies to them as well. |
| EU AI Act, Reg. 2024/1689 as amended by Reg. 2026/1744 [3] [4] | Art. 4: measures to support AI literacy, without a required level of literacy; Annex III high-risk duties from 2 December 2027; market surveillance of high-risk AI directly linked to financial services in principle by the financial supervisor (Art. 74(6)). | The coding agent itself is usually not a high-risk system. If an institution develops a high-risk AI system, for example for creditworthiness assessment, it is usually the provider, whether or not agents are involved. Agents belong in the AI inventory. |
| GDPR [5] | Legal basis; processing agreements; data protection impact assessment; international transfers. | Relevant as soon as agents process personal data in repositories, tickets or test data, or transmit data to the provider. |
| Section 38 BWG: banking secrecy [6] | Secrets entrusted or made available solely because of the business relationship with customers must not be disclosed or exploited. | Before using external agent services, clarify whether customer data could end up in context, logs or test data. |
| Sections 96, 96a ArbVG [7] | Works council consent to control measures affecting human dignity and to certain personal-data processing systems. | Agent logs that attribute actions to individual developers can be a control measure. A works agreement should be considered. |
| ECB letter SSM-2026-0301 of 7 July 2026 [11] | Significant institutions: action plan against AI-enabled cyber threats by 31 October 2026, covering vulnerability and patch management and ICT third-party risk, among other areas. | The letter does not address coding agents, but it concerns the same development process. Less significant institutions are not addressees. |
From principles to implementation
Which eight control areas does agent use need?
From task & accountability through identity, data, isolation, quality, approval and evidence to intervention & recovery. These areas can be integrated into existing development, security and governance policies. Eight areas do not mean eight new policy documents.
Task & accountability
Define permitted tasks, business acceptance criteria and accountable people. Add agents to the AI inventory and train those involved, including business units that build their own applications with agents.
Identity & permissions
Give each agent its own identity, attribute its runs, minimise permissions and recertify them regularly. Limit delegation to other agents.
Data & providers
Decide which data may enter the agent’s context and thereby reach the provider. Manage agent services as ICT third-party services: register of information, contract, model changes and exit.
Isolation & tool control
Separate environments, approve tools and enforce network boundaries.
Quality & security
Plan business tests, security, dependency and licence checks, and tests against malicious inputs. Label AI-generated commits.
Approval & segregation of duties
Keep authorisation outside the agent's writable environment and prevent self-approval.
Evidence & change
Link the task, model and tool versions, code changes, test results and authorisation. Where logs make individual employees’ performance assessable, check whether a works agreement is needed.
Intervention & recovery
Practise stopping activity, revoking access and returning to a safe operating state.
Technical boundaries complement model instructions. Manipulable tool responses and external content warrant specific controls. MCP (Model Context Protocol) connects agents with tools and data sources; the operators and service relationships of these components must be assessed individually. [14] [15]
Your next step
Where does your development process stand?
Already using coding assistants or planning development agents? We review a selected workflow with you to identify existing controls and areas that need attention.
The assessment connects business requirements, processes and governance. It builds on our experience in banking, insurance, regulatory reporting and systems integration.
Request an assessmentWhat we work through together
- Inventory: Agents, tools, data flows and owners for a bounded workflow.
- Control gaps: Existing and missing checks and approval points.
- Evidence plan: Required records from the task to the release.
- Pilot plan: Prioritised actions with owners and acceptance criteria.
Scope and approach are agreed individually. The assessment is not a certification or a complete technical or legal review.
Frequently asked questions
Is there a dedicated rule for AI agents in software development?
No. As of October 2026 there is no dedicated rule at EU or Austrian level. Binding duties arise mainly from DORA and Delegated Regulation (EU) 2024/1774: development, change management, identities, access and ICT third-party providers. The AI Act, data protection and labour law add to this. Agent-specific expectations so far appear only in non-binding papers such as the FSB practices. [1] [2] [8]
Is a coding agent automatically high-risk AI?
No. Classification depends on the purpose and context of the specific AI system. The resulting system and the institution's provider or deployer role are assessed separately. AI-generated code is not automatically an AI system either. [3]
Can the same agent develop, test and approve a change?
It can run tests and support reviews. This does not by itself provide independent authorisation. Article 17 RTS requires an independent approval function; the institution defines specific human approval points based on risk. [2]
Which data may enter the agent's context?
Only data permitted and necessary for the approved purpose. Article 16(5) RTS generally specifies anonymised, pseudonymised or randomised production data for non-production environments; paragraph 6 contains a limited testing exception requiring approval and reporting to the ICT risk management function. This is not a blanket permission to share data with an AI provider. Pseudonymised data may still be personal data. [2] [5]
What differs between banks and insurers?
Both need controlled development workflows. Sector rules and data risks add context: banking secrecy for banks, for example, or health data for insurers where applicable. EIOPA's Opinion provides insurance-sector guidance; it is not a separate regulation on agents. [6] [9]
How should a pilot start?
With a bounded use case, approved data and tools, and acceptance criteria agreed in advance. Quality, rework, control effort and security findings should be evaluated together. Greater autonomy follows a deliberate assessment of the results.
Ing. Mag. Patrick Eiler
Patrick Eiler advises banks and insurers in Vienna on regulatory reporting, data architecture and AI compliance. More than twenty years in banking, insurance and financial services; speaker at the Hypo-Verband (expert session of 23 September 2026).