Voice AI in Banking: BaFin and DORA Rules for 2026

Voice AI in Banking: What BaFin's Guidance on AI Under DORA Means for AI Phone Agents

Yes, banks and insurers can deploy AI phone agents — but since BaFin's orientation guidance on AI under DORA (February 2026), not as an innovation project sitting next to IT. An AI phone agent is now a regular ICT asset inside the existing ICT risk management framework. The decisive move: the supervisor steps away from the EU AI Act's risk classification and defines AI systems in plainly technical terms as "network and information systems". AI loses its special regulatory status.

For decision-makers at credit institutions this is concrete: the question is no longer "is our voice agent high-risk AI?" but "is it in the asset inventory, risk-classified, monitored, covered by continuity planning, and backed by a tested exit strategy?" This article translates the guidance into a practical framework for telephony.

The core message: AI is an ICT asset, not a special topic

The EU AI Act sorts AI systems by risk — from prohibited applications through high-risk AI to limited or minimal risk. Graduated obligations attach to that classification: transparency, documentation, data quality, human oversight.

For financial firms, that product-centric view falls short. It does not answer the actual governance question: how do you integrate an AI application — regardless of its ethical risk class — safely into the existing IT landscape and keep it operationally under control? That is where BaFin steps in.

The supervisor's reasoning is simple and effective. An AI system is "machine-based", meaning it consists of hardware and software. That makes it a "network and information system" under DORA — and therefore a regular ICT asset. Three consequences follow:

• Integration instead of isolation: AI is no longer an isolated innovation topic. It must be embedded in the existing, documented ICT risk management framework. A voice agent being "tried out" by a business unit alongside IT is, in supervisory terms, shadow IT.
• Lifecycle focus: instead of a one-off risk review before launch, BaFin expects continuous oversight across the entire technical lifecycle — from development and training through live operation to secure decommissioning and data deletion.
• Liability and resilience: compliance is not measured by algorithmic transparency alone, but by the operational resilience of the overall system against outages, manipulation such as data poisoning, and cyberattacks.

With this, BaFin closes the gap between the AI Act's abstract requirements and operational reality in the data centres and cloud environments of the financial industry. If you have already worked through the EU AI Act compliance checklist for voice AI, you are not done — the DORA layer sits on top.

Who the guidance addresses

BaFin derives the scope directly from DORA's own structure. It primarily addresses financial firms that must apply the full ICT risk management framework under Art. 5–15 DORA — in particular CRR credit institutions and insurance undertakings under Solvency II.

For those institutions the guidance should be treated as the authoritative reading of supervisory expectations, even though the paper is formally labelled a "non-binding aid". In practice it defines the future audit benchmark. Financial firms falling under the simplified framework of Art. 16 DORA — small investment firms or small payment institutions, for example — are not direct addressees; a separate assessment is needed there.

Proportionality: where your voice agent actually sits

A key element is the proportionality principle under Art. 4 DORA. Requirements scale with risk profile and systemic relevance. For governance practice that means differentiating by the criticality of the supported function:

• Critical or important functions: AI applications that steer material business processes or make decisions with a direct impact on the financial position or earnings — credit scoring algorithms or straight-through claims processing, for instance. Comprehensive controls and security measures are mandatory here, including extended resilience testing and intensive documentation duties.
• Supporting functions: lower-risk AI systems under continuous human oversight that make no autonomous decisions. Here, safeguards may be reduced to an appropriate extent under the proportionality principle.

For telephony applications this distinction is the single most important design decision. A voice agent is not inherently critical — it becomes critical through what you let it decide. The following mapping shows typical banking scenarios:

The practical implication: your classification of AI systems regarding support of critical functions must be documented, so the adequacy of the measures taken is demonstrable to auditors and the supervisor. Institutions that deliberately stay with supporting functions during rollout — handing anything with financial impact to a human — shorten time to production considerably. Call transfer to a human agent is therefore not a feature detail but a regulatory control lever.

The foundation: strategy and governance

Strategy and governance form the basis of ongoing risk management. The guidance names three building blocks.

Strategic integration and roadmap. The management body must adopt an AI strategy consistently embedded in the wider business and DORA strategy. Unlike standard IT, AI requires a technology roadmap to steer specific resource needs — compute, data volumes — and the necessary investment ahead of time.

Board responsibility and AI literacy. Ultimate responsibility for AI risks sits with the management body under Art. 5 DORA — the full board. That presupposes demonstrable expertise to independently assess how algorithmic decisions affect the business model. Responsibility for AI outputs must be assigned without gaps between IT and the business side.

Process readiness and internal control integration. Before technical implementation, business processes must be validated for their suitability to handle probabilistic — that is, non-deterministic — outputs. Involved ICT third-party providers require a separate risk assessment. Internal control functions — risk management, compliance, internal audit — must be brought into the lifecycle early and proportionately.

That last point is the most underestimated in practice. A language model answers probabilistically: the same question can produce two slightly different phrasings. A process that depends on word-identical output is unsuitable for AI — no matter how good the model is.

Development and testing: shadow IT and the supply chain

For the provisioning phase, the guidance highlights two themes.

Supply chain integrity. Unregulated shadow IT in business units must be prevented; low-code solutions are equally subject to DORA standards. This matters especially for voice AI, because modern platforms are deliberately simple enough that a business unit could go live without IT. That is precisely the mistake. Supply chain integrity must also be secured: strict validation of training data against data poisoning, plus rigorous review of open-source libraries and AI-generated code.

Secure development and extended test strategies. To control the black-box problem, the development process must act as a safety net: complete versioning of code, training data and model parameters, plus strict change management for model updates including tested rollback strategies. Because conventional functional tests often fail against probabilistic AI, testing must be broadened — adversarial testing simulates targeted attacks, and for generative AI, human-in-the-loop review secures output safety.

For voice agents, "versioning" covers not just the model but the system prompt and the knowledge base. Changing the prompt of a live banking agent without approval and without a rollback path is an undocumented change — with the same supervisory consequences as an undocumented deployment in the core banking system.

Live operation and decommissioning: the four action areas

For the operating phase, the guidance turns DORA Art. 8–11 into four action areas. The table below translates them into requirements for a voice AI platform:

Notably, the lifecycle ends only with secure decommissioning: obsolete models and data must be irretrievably deleted to prevent leaks or misuse. Almost nobody plans this up front — and auditors reliably ask about it.

On the platform side these are not exotic requirements. Call history and post-call analysis deliver the inference logs that Art. 8 and Art. 10 demand; via API and webhooks that data can be mirrored into the institution's existing SIEM or data warehouse instead of living in a third-party dashboard.

Integration and cloud: the real hurdle

Because capable AI systems are mostly delivered via external cloud infrastructure rather than an in-house data centre, the guidance concentrates on controlling those outsourcing risks. For voice AI this is the critical section — practically every platform is an outsourcing arrangement.

Extended risk assessment and due diligence. Before contract signature, the risk inventory must anticipate dynamic factors such as model retraining or changes to model structure. Due diligence cannot stop at the provider; it must explicitly assess the risk of unauthorised data outflow and the provider's suitability against technical and regulatory standards.

Cloud-specific cyber security. For externally hosted training or inference environments, attack vectors such as data poisoning or adversarial attacks must be identified and defended. Where critical or important functions are outsourced, an "adequate" security level is not enough — the provider must demonstrably meet the highest current standards.

Transparency across the contract chain. Controlling subcontracting without gaps is decisive, because AI systems often rely on complex supply chains. The institution must know at all times where data processing physically takes place. SLAs must bindingly address the sensitivity of AI models to latency and compute capacity, backed by enforceable audit rights deep into the chain.

Exit strategy and vendor lock-in. Because proprietary cloud AI services encourage lock-in, contracts must secure export of models, training data and metadata in interoperable formats. Regular backups on independent storage plus validated migration scenarios are mandatory.

For vendor selection this means: a platform that owns your phone number, does not disclose the model, and blocks export of conversation data is hard to justify under DORA. Conversely, BYOC — bring your own carrier defuses two points at once: the institution keeps control of its numbers and its telephony contract, and switching vendors stays possible without customers dialling a new number. That is an exit strategy that actually holds, rather than a statement of intent. The data processing agreement and the accompanying data processing disclosures provide the basis for your due diligence file.

Implementation step by step

1. Scope the use case. Deliberately start with supporting functions: opening hours, appointment booking, routing, FAQs. Anything with financial impact stays with humans for now.
2. Document criticality. Write down why the agent does not support a critical or important function. That reasoning is your proportionality evidence under Art. 4 DORA.
3. Add it to the asset inventory. Model, prompt version, knowledge base, voice, phone number, provider and sub-providers — with a named owner.
4. Run the outsourcing review. Vendor due diligence, clarify processing locations, disclose the sub-processor chain, agree audit rights and SLAs on latency and availability.
5. Test before go-live. Functional tests, load tests at realistic call density, adversarial testing against prompt injection, human-in-the-loop assessment of answer quality.
6. Set up monitoring. Not just availability: drop-off rate, escalation rate, answer quality, latency. Alerts on drift. Mirror logs into your own systems.
7. Test BCM and exit. Fall back to routing or an announcement on outage. Run the artefact export once for real — do not simply take a contractual assurance.
8. Establish change management. Every prompt or model change goes through approval, testing and a documented rollback path.
9. Plan decommissioning. Define now how obsolete model versions and conversation data will be securely deleted.

Best practices and common mistakes

• Mistake: the business unit starts alone. Marketing or branch operations "quickly try out" a voice agent. That is exactly the shadow IT BaFin addresses — no-code included.
• Mistake: prompt changes without a change process. The prompt is production configuration, not a text field. Version it, approve it, keep a rollback ready.
• Mistake: monitoring availability only. An agent can be 100% reachable and still have been answering worse for three weeks. Art. 10 asks for anomaly detection, not uptime.
• Mistake: exit on paper only. An exit clause without a tested export is not an exit. Rehearse the migration once.
• Best practice: authenticate before disclosing. Anything beyond public information only after clean identification — ideally via keypad entry rather than a spoken account number.
• Best practice: escalation as the default. An agent that cleanly hands over to a human when uncertain stays a supporting function — the cheapest compliance lever available.
• Best practice: keep logs in-house. If conversation data lives only in a vendor dashboard, data lineage is hard to evidence. Mirror it into your SIEM.

Worked example: a regional bank with 40 branches

A regional bank with 40 branches and around 600 employees has a classic problem: on Monday mornings between 9 and 11, call volume peaks so hard that a substantial share of callers abandon the queue. The requests are mostly mundane — opening hours, advisor appointments, questions about which documents to bring.

The regulatorily clean scope: the voice agent picks up, answers opening-hours and documents questions from a maintained knowledge base, books advisory appointments, and routes everything else to a human. No account information, no card blocking, no pre-qualification. That makes it a supporting function — documented, justified, recorded in the inventory.

Phone numbers stay with the institution's existing carrier via BYOC, conversation data flows by webhook into the bank's own data warehouse, and the fallback during a platform incident is classic routing to the branch line. DORA evidence stays proportionate — and the path to the next expansion stage is open, because inventory, change process and monitoring already exist.

Conclusion

With this guidance, BaFin turns abstract regulatory requirements into an operational framework. Even without the status of a circular, the paper effectively defines the future gold standard for audit practice. For AI phone agents in banking the route is not through the question of whether you may — but through asset inventory, documented criticality classification, real monitoring, tested continuity plans and a credible exit strategy.

The good news: institutions that scope the use case to supporting functions and hand financial-impact actions to humans can proceed proportionately and reach production far faster. Famulor is built for exactly that — EU hosting, a data processing agreement, BYOC for full control over numbers and carrier, exportable call logs for data lineage, and a clean handover path to human staff.

Next step: talk to our enterprise team about your specific use case and outsourcing documentation, or see how Famulor supports financial services today. If you need the business case first, the ROI calculator shows in minutes what automating your calls saves.

FAQ

Can a bank deploy an AI phone agent?

Yes. BaFin does not prohibit AI telephony; it classifies AI systems as regular ICT assets under DORA. Deployment is permissible if the agent is recorded in the asset inventory, risk-classified, monitored and covered by continuity planning.

What is the core message of BaFin's guidance on AI under DORA?

AI systems are "network and information systems" and therefore regular ICT assets. They lose their special regulatory status and must be fully integrated into the existing ICT risk management framework across the entire lifecycle.

Who does the guidance address?

Primarily financial firms applying the full ICT risk management framework under Art. 5–15 DORA, especially CRR credit institutions and Solvency II insurers. Firms under the simplified framework of Art. 16 DORA are not direct addressees.

Is a voice agent a critical function?

Not automatically. What matters is whether it makes autonomous decisions affecting financial position or earnings. Information and appointment booking are usually supporting functions; card blocking or credit pre-qualification are not.

What does BaFin require when outsourcing to a cloud provider?

Extended due diligence including data-outflow risk, transparency across the full sub-processor chain, SLAs on latency and compute capacity, enforceable audit rights, and an exit strategy with export in interoperable formats.

Who is accountable for AI risks inside the institution?

Ultimate responsibility sits with the management body under Art. 5 DORA — the full board. That requires demonstrable expertise ("AI literacy") and gap-free assignment of responsibilities between IT and the business.

Is complying with the EU AI Act enough?

No. The AI Act governs product- and application-related duties by risk class. DORA and BaFin's guidance add operational requirements for resilience, monitoring, outsourcing and continuity management on top.

What counts as shadow IT in a voice AI context?

A business unit taking a voice agent live without IT, compliance and internal audit. BaFin makes clear that low-code and no-code solutions are equally subject to DORA standards.

How does BYOC help with the exit strategy?

With bring your own carrier, phone numbers and the telephony contract stay with the institution. Switching vendors becomes possible without changing numbers — an exit strategy that holds in practice rather than a contract clause alone.

When does an AI system's lifecycle end?

Only at secure decommissioning. Obsolete models, model artefacts and associated data must be irretrievably deleted to prevent data leaks and misuse. Plan this before go-live, not after.