Voice AI Under DORA: The ICT Third-Party Test

Somewhere in a European bank right now, a customer experience team is running a voice AI pilot that nobody in the second line has heard of. The pilot works. Containment is respectable, the demo went well, and the business case is sitting with a sponsor who wants to scale it into the main inbound line next quarter. Then the operational resilience officer asks a question that stops the whole thing: is this in the register?

That question is not obstruction. It is the Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied since 17 January 2025 and which treats the software running your phone line as ICT, not as a marketing experiment. The gap between those two worlds is where voice AI programmes in financial services die. The voice AI compliance rules for the UK and EU are wide, but DORA is the specific regime that decides whether a regulated buyer can put your agent in front of customers at all.

The scale of the exposure is now measurable rather than theoretical. In its 2025 report on major ICT-related incidents (JC 2026 16, published 3 June 2026), the European Supervisory Authorities recorded 3,383 major incidents across EU financial entities in 2025, and found that 29% of them were caused by a failure attributable to a third-party provider. Against the wider backdrop that McKinsey's State of AI (November 2025) puts at 88% of enterprises using AI but only 6% capturing material EBIT impact, the resilience question is not a tax on your voice AI programme. It is the thing that lets it survive contact with the second line.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system.

What does DORA actually require from a voice AI vendor?

Strictly, nothing. DORA regulates financial entities, not their suppliers. A voice AI platform is an ICT third-party service provider, and its DORA obligations arrive through the contract its customer is required to sign under Article 30, not by direct application of the Regulation to the vendor. This distinction matters commercially: a vendor cannot be DORA compliant, it can only be contractible by a financial entity that is.

That single point separates vendors who have read the Regulation from vendors who have read a competitor's landing page. The marketing claim "we are DORA compliant" is not a slightly loose claim, it is a category error. DORA places the duty on the bank, the insurer, the payment institution or the crypto-asset service provider. Your buyer carries the obligation and cannot hand it to you. What they can do, and what Article 30 requires them to do, is push the operational substance of that obligation into your contract.

The only route to direct supervision runs through Article 31, where the European Supervisory Authorities designate an ICT third-party service provider as critical and appoint a Lead Overseer. The designation criteria are systemic: the number of financial entities affected, the total value of their assets, and whether a large-scale operational failure at that provider would threaten the stability or continuity of financial services. Those criteria describe hyperscalers. They do not describe a voice AI platform, and any vendor implying otherwise is inflating its own importance.

So the practical test a resilience officer runs is not "is this vendor compliant". It is a sequence of questions about the buyer's own control environment, and the vendor either makes those questions easy to answer or becomes the reason the deal stalls. This is the same logic that governs AI voice architecture in regulated industries: the regulator is not assessing your cleverness, it is assessing your buyer's control.

Is a voice AI platform an ICT third-party service provider under DORA?

Yes, and the definition leaves little room to argue. Article 3(19) of DORA defines an ICT third-party service provider as "an undertaking providing ICT services", and Article 3(21) defines ICT services as digital and data services provided through ICT systems on an ongoing basis. A voice AI platform is squarely inside that definition. Dilr Voice, Vapi, Retell AI and PolyAI are all ICT third-party service providers to any financial entity that buys them.

There is exactly one carve-out in the definition of ICT services, and it is worth reading closely because it is the one a vendor might try to hide behind. Article 3(21) excludes "traditional analogue telephone services". A voice AI agent is not a traditional analogue telephone service. It is a digital, data-processing service delivered over ICT systems, and the exclusion was written for the copper line, not for the model sitting on top of it. If anything, the presence of that exclusion confirms the drafters thought about telephony and chose to keep everything modern inside scope.

This is where the voice AI vendor procurement framework meets a harder edge than usual enterprise buying. Being in scope is not a problem to be argued away. It is the starting condition, and the useful work begins one question later.

Does your voice AI support a critical or important function?

This is the pivotal question in the whole assessment, because it decides which tier of Article 30 applies. Article 3(22) defines a critical or important function as one whose disruption would materially impair the financial entity's financial performance, the soundness or continuity of its services, or its continuing compliance with the conditions of its authorisation. The classification belongs to the financial entity, not to the vendor, and it is a judgement rather than a checkbox.

For voice AI the honest answer is usually: it depends on what the line does, and it changes over time. An outbound agent chasing lapsed marketing consent is unlikely to be critical or important. An inbound agent that has become the only practical route for a customer to report a lost card, raise a fraud alert, or reach a human about a payment they cannot make is a different proposition entirely. Nothing about the technology changed. The function it carries did.

That drift is the trap. Programmes classify the function at pilot, when the agent handles 5% of traffic on a low-stakes queue, and never re-classify it as the agent absorbs the main line. By the time it is carrying vulnerable customers and fraud reports, the contract underneath it was scoped for the pilot. Any serious rollout should treat re-classification as a gate, not an afterthought, and our AI operating model consulting work in regulated firms builds that trigger into the governance cadence rather than leaving it to memory.

The commercial consequence is direct. If the function is critical or important, the contract must carry the full Article 30(3) set, the arrangement is flagged as such in the register, and the vendor inherits audit rights, resilience testing duties and a mandatory transition period on exit. If it is not, the lighter Article 30(2) set applies. Vendors who understand this arrive at procurement with both versions ready. Vendors who do not spend six weeks in legal.

What must a DORA-compliant voice AI contract contain?

Article 30 is the operative article, and it is tiered. Article 30(2) lists the minimum elements for every ICT contractual arrangement, including a complete description of the services, the locations where services are performed and data is processed, provisions on data availability and integrity, service level descriptions, assistance duties during incidents, cooperation with competent authorities, and termination rights. Article 30(3) adds a heavier set when the service supports a critical or important function.

The Regulation opens with an unglamorous requirement that defeats a surprising number of voice AI deals. Article 30(1) states that "the rights and obligations of the financial entity and of the ICT third-party service provider shall be clearly allocated and set out in writing", and that "the full contract shall include the service level agreements and be documented in one written document". Click-through terms plus a linked SLA page plus a separate data processing agreement is not one written document, and a vendor whose commercial model depends on self-service signup has real work to do here.

The Article 30(3) additions are where a voice AI vendor either has a product or has a problem. They include full service level descriptions with precise quantitative and qualitative performance targets, notice periods and reporting obligations covering any development that might materially affect the vendor's ability to deliver, business contingency plans that are implemented and tested, an obligation to participate in the financial entity's threat-led penetration testing under Articles 26 and 27, unrestricted audit and inspection rights, and exit strategies under Article 30(3)(f).

That exit clause deserves particular attention because it is more demanding than standard enterprise practice. Article 30(3)(f) requires "a mandatory adequate transition period" during which the vendor keeps providing the service while the financial entity migrates to another provider or brings the function in-house. A 30-day termination-for-convenience clause does not satisfy this. Our note on voice AI vendor exit and offboarding covers the mechanics, and the quantitative targets requirement should be read alongside voice AI SLA design for enterprise contracts, because "99.9% uptime" is not a performance target for a voice agent whose failure mode is a confidently wrong answer delivered on time. The broader clause architecture sits in our voice AI MSA contract clauses guide.

What goes in the DORA register of information?

Article 28(3) requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers. The register must distinguish arrangements supporting critical or important functions from those that do not, and the entity must hand the full register, or any section of it, to its competent authority on request.

This is the requirement that catches shadow deployments. The register covers all ICT contractual arrangements, not just the critical ones and not just the ones procurement knows about. A voice AI agent bought on a departmental card, running on a phone number that customers actually call, is a registrable ICT arrangement missing from a document the regulator can demand at any time. Financial entities must also report at least yearly to their competent authority on new arrangements, the categories of providers used, and the services provided.

For a vendor, the register is a quiet qualification signal. The data the entity needs from you is specific: legal entity identifiers, the countries where the service is provided and where data is processed, whether subcontracting of a critical or important function is permitted, and the function the service supports. A vendor who can produce that pack on request shortens the deal. A vendor who answers "our infrastructure is in the cloud" has just told a resilience officer the register entry cannot be completed. The discipline is the same one behind an AI tool inventory across ICO, FCA and EU AI Act obligations, and it is worth building before a competent authority asks rather than after.

Who reports the incident when a voice agent fails, and how fast?

The financial entity reports, not the vendor. Article 19 of DORA requires financial entities to report major ICT-related incidents to their competent authority in three stages: an initial notification, an intermediate report, and a final report once root cause analysis is complete. Your voice AI vendor never files anything with a regulator. What the vendor does is supply the facts that make the entity's filing possible, inside a clock the entity does not control.

That clock is the part most vendors have never read, because it does not live in DORA itself. Article 19(4) defers the time limits to a regulatory technical standard, and Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 sets them in Article 5. The initial notification is due as early as possible, and in any case within four hours from the classification of the incident as major, and no later than 24 hours from the moment the entity became aware of it. The intermediate report follows at the latest within 72 hours of the initial notification, even if nothing has changed. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report where one was filed.

Read those two windows again, because the distinction is where filings go wrong. The four hours runs from classification, not from awareness, and the 24 hours from awareness is the outer bound on classifying at all. A vendor who takes six hours to confirm whether an outage was a partial degradation or a full failure has not caused a support delay. It has consumed the buyer's entire classification window, and the entity must then tell its competent authority it will be late, and explain why, under Article 5(3) of the same standard.

The Regulation closes the obvious escape route explicitly. Article 19(5) permits outsourcing the reporting itself, and then removes any comfort that might come with it:

"Financial entities may outsource, in accordance with Union and national sectoral law, the reporting obligations under this Article to a third-party service provider. In case of such outsourcing, the financial entity remains fully responsible for the fulfilment of the incident reporting requirements."

Regulation (EU) 2022/2554, Article 19(5)

You can hand a supplier the work. You cannot hand it the accountability. That is the sentence a resilience officer will read to your sponsor when they ask why the voice AI contract needs a four-hour notification commitment rather than a support SLA. In practice the vendor's incident process must be wired directly into the buyer's, which is the design problem our voice AI incident response runbook sets out, and one of the first things we build in an AI execution office engagement.

The same diagnostic logic underpins our AI placement diagnostic, a fixed-fee assessment used before any deployment commitment, and it is the fastest way to find out whether a voice use case is critical or important before the contract is drafted rather than after.

Third-party failures, not the critical list, drive the incidents

The incidents are not coming from the designated providers. The ESAs found that 29% of the 3,383 major incidents reported in 2025 originated from a failure on the side of a third-party provider, and drew the supervisory conclusion directly: dependencies on third-party providers, even those not designated as critical, constitute an area of supervisory attention and underscore the need for financial entities to strengthen their third-party risk management frameworks.

That finding disposes of the most common vendor objection in a regulated voice AI deal, which is some version of "we are too small to be systemic". Correct, and irrelevant. Your buyer's obligation does not switch on when you are designated critical under Article 31. It switches on when they sign, and the supervisory interest in non-designated providers is now evidenced rather than assumed. The ESAs also recorded that around one third of major incidents had a cross-border impact, and that roughly 8% touched more than 10 member states, which is why the locations question in Article 30(2)(b) is asked so precisely.

Third-party attributable29% (29%)
Other causes71% (71%)

It is worth being fair to the data rather than alarmist with it. The same report found that two thirds of major incidents caused no or only minor disruption to clients and transactions, and that cybersecurity-related incidents were comparatively rare, which suggests detection and containment are broadly working. The argument for scrutinising your voice vendor is not that the sky is falling. It is that the failure path most likely to reach a customer runs through a supplier, and the supplier contract is the only place to control it.

What changes for UK firms, which are not under DORA?

UK financial entities are not subject to DORA. They face a parallel regime with the same intent and a different architecture, and firms selling into both markets should stop treating the two as interchangeable. The UK stack has three moving parts: the operational resilience rules in FCA PS21/3 and the PRA equivalent, the critical third parties regime, and a new incident and third-party reporting regime that is not yet in force.

The first part has already bitten. The FCA states that firms in scope "had until 31 March 2025 to ensure they could operate their important business services within their impact tolerances". Important business services and impact tolerances are the UK analogues of DORA's critical or important functions, and the practical consequence for a voice AI deal is identical: if your agent sits inside an important business service, it inherits a tested tolerance for maximum disruption that somebody has already signed off.

The second part mirrors DORA's Article 31 oversight. Under PS16/24, the Bank of England, PRA and FCA regime for critical third parties came into force on 1 January 2025, with HM Treasury making the designation on the regulators' recommendation. As with DORA, designation targets systemic providers, so a voice AI vendor will not be designated, and as with DORA, that changes nothing about the buyer's duty.

The third part belongs in your commercial calendar. In PS7/26, published on 18 March 2026, the PRA finalised its operational incident and third-party reporting policy, developed jointly with the FCA and the Bank of England. Firms will have to notify all material third-party arrangements ahead of entering into them or significantly changing them, and report operational incidents through a single form completed over initial, intermediate and final phases via FCA Connect. The implementation date is 18 March 2027.

Two details make this commercially live rather than a 2027 problem. First, the notification is due ahead of entering into the arrangement, so a voice AI contract signed after that date needs the notification wired into the procurement path before signature, not after. Second, the PRA explicitly designed the policy to align with DORA and the Financial Stability Board's incident reporting format, which means a vendor who builds one evidence pack can serve both regimes rather than two. For firms weighing that build, our FCA AI governance guide and the FCA code of conduct extension note cover the adjacent conduct obligations, and voice AI in fintech collections and KYC shows how the duties compound in a live use case.

What is the best voice AI platform for DORA-regulated financial entities in 2026?

There is no best DORA-compliant voice AI platform, because no platform can be DORA compliant. The honest question is which vendor makes your compliance cheapest to evidence, and it resolves on four criteria: whether they will sign one written contract with real service level agreements, whether they will commit to a four-hour incident feed, whether they will accept audit and resilience testing participation, and whether they will contract a genuine transition period on exit.

Judged on those criteria the answer is genuinely scenario-dependent, and we lose some of these. If you have a strong internal platform team and want developer-led control of the call flow, Vapi and Retell AI give you primitives and speed a managed vendor will not match, and a bank with real engineering depth can wrap its own resilience evidence around them. If your load is narrow-intent and very high volume, and you would rather buy an outcome than run a platform, PolyAI's heavily managed model is a reasonable answer and has the financial services deployments to show for it. If your requirement is primarily voice quality on a brand-facing line, ElevenLabs will beat most of the field on that axis alone. Bland AI and Synthflow compete hard on speed to first deployment, which matters more than resilience paperwork when the function is genuinely not critical or important.

Where Dilr Voice is built to win is the narrower case where the function is critical or important and the buyer's second line is the real decision-maker: a single written contract with quantitative targets, an incident process designed around the four-hour classification window rather than a support queue, audit and testing cooperation in the base terms, and a contracted transition period. That is a smaller claim than "best voice AI platform", and it is the one we can defend. If your voice use case is a low-stakes outbound campaign, buy on price and speed, and do not pay us for resilience engineering you do not need.

Will our voice AI vendor be designated a critical ICT third-party provider?

Almost certainly not. Article 31 designation is made by the European Supervisory Authorities against systemic criteria: the number and total assets of the financial entities relying on the provider, and whether a large-scale failure would threaten the stability or continuity of financial services across the Union. Those tests select hyperscale infrastructure providers. A voice AI vendor will not meet them, and the ESAs' 2025 data shows non-designated providers still drove most third-party incidents.

Does DORA apply to a voice AI vendor based outside the EU?

DORA does not apply to the vendor directly, wherever it is based. It applies to the EU financial entity, which must still meet Article 30 in full when it contracts a non-EU provider. In practice a US or UK voice AI vendor selling into a European bank inherits the same contractual obligations through the agreement, plus sharper scrutiny of the Article 30(2)(b) locations questions covering where the service runs and where data is processed.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

The pattern across every regulated voice AI programme we have shipped is the same. The compliance work is not what slows the deal down. Discovering the compliance work at contract stage is. Classify the function before you scope the pilot, tier the contract to the classification, and the resilience officer becomes the person who clears the path rather than the person who blocks it. More of our thinking sits in the compliance archive, alongside the ISO 42001 procurement guide and our MiFID II call recording note for investment firms. You can also read more about Dilr.ai and how we work.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.