Deploying an AI Voice agent under DORA

The Digital Operational Resilience Act, better known as DORA, has applied across the European Union since 17 January 2025.

For financial entities within its scope, deploying an AI voice agent is therefore not simply a technology or procurement decision. The deployment must form part of the organisation’s ICT risk-management and ICT third-party risk-management framework.

This does not mean that DORA prohibits AI voice agents. It means that the financial entity must understand what the system does, which business functions it supports, what it depends on, how disruption would be managed and how the service could eventually be replaced.

Calling it “AI” does not make the usual ICT questions disappear. It normally creates a few more. This article explains where Elba fits into that assessment and what Kolsetu provides to support it.

Does DORA apply to AI voice agents?

DORA does not create a separate regulatory category for artificial intelligence. Its definitions of ICT systems and ICT services are broad enough to cover AI systems used within a financial entity’s operations.

In December 2025, Germany’s Federal Financial Supervisory Authority, BaFin, published non-binding guidance on managing ICT risks when financial entities use AI. The guidance explains how existing DORA requirements apply to AI systems, particularly in relation to ICT risk management and ICT third-party risk management.

For an Elba deployment, this means the financial entity may need to address the system within its ICT asset and dependency inventory, risk assessment and classification, business continuity arrangements, incident-management processes, ICT third-party risk-management framework, Register of Information, and exit and transition planning.

The EU AI Act may impose additional requirements depending on the deployment. That is a separate assessment. Compliance frameworks have an unfortunate habit of coexisting.

Where Kolsetu sits under DORA

Kolsetu is an ICT third-party service provider. It is not itself a financial entity subject to DORA and is not currently included in the list of Critical ICT Third-Party Providers designated for direct oversight by the European Supervisory Authorities under Article 31.

The primary DORA obligations therefore remain with the financial entity deploying Elba.

That does not make the provider irrelevant. A financial entity cannot properly assess, document and monitor an ICT arrangement without sufficient information and cooperation from the provider.

Kolsetu supports this process by providing, as applicable to the deployment, service and architecture documentation, information about hosting and data-processing locations, security and business continuity documentation, information about material subcontractors and dependencies, contractual incident-notification and cooperation obligations, appropriate access, inspection and audit arrangements, data-export and transition support, and the information required for the Register of Information.

Elba should not be described as “DORA compliant” in isolation. DORA compliance belongs to the financial entity and depends on how Elba is selected, configured, contracted, governed and used. With other words, Elba is designed to operate within that compliance framework.

The first decision: what function does Elba support?

The financial entity must determine whether the Elba deployment supports a critical or important function within the meaning of Article 28. That classification depends on the specific use case and the consequences of disruption. It cannot be determined by Kolsetu through a general product label.

A deployment may support a critical or important function where its disruption would materially impair the financial entity’s operations, regulated services, financial performance or ability to meet its legal obligations.

First-contact handling for insurance claims, customer identification or verification workflows, payment and account support, fraud or suspicious-activity intake, emergency or roadside assistance, collections and payment arrangements, and customer communications during service disruption are all use cases that may qualify. A limited internal use case may however receive a different classification.

Kolsetu provides the technical and operational information needed to support the assessment. The classification remains the customer’s responsibility.

Assessing ICT concentration risk

Before entering into an ICT arrangement, the financial entity must assess relevant concentration risks under Article 29, particularly where the service may support a critical or important function.

For an AI voice agent, the assessment should not stop with the direct contractual provider. Relevant dependencies may include cloud infrastructure, telephony providers, speech-to-text services, text-to-speech services, AI model providers, customer systems and integrations, and geographic and data-location dependencies.

Elba is designed to reduce avoidable dependency and lock-in risks. The model layer is not tied to one underlying AI model provider and can be changed without replacing the complete workflow, integration and orchestration layer. This reduces dependency on a particular model provider. But it does not eliminate concentration risk across the full service chain, and it should not be presented as doing so.

Depending on the agreed architecture and customer requirements, Elba supports cloud, private-cloud and on-premises deployment models.

EU data processing and storage can be contractually agreed, with the relevant countries, regions and infrastructure locations documented as part of the contractual and technical documentation. DORA requires transparency about where services are provided and where data is processed and stored. It does not impose a universal requirement that all data remain in the European Union.

For enterprise deployments, Kolsetu identifies the material providers and services on which the agreed architecture depends. This allows the customer to assess the actual delivery chain rather than treating Elba as an isolated application.

Business continuity and operational resilience

The financial entity must understand how an ICT-supported service would continue or recover during disruption, as required under Article 11.

Depending on the deployment, Elba’s resilience arrangements can include defined service-availability commitments, monitored production infrastructure, incident-detection and escalation processes, documented recovery arrangements, controlled handover to human operators, customer-specific fallback procedures, continuity planning for relevant integrations, and contractual incident cooperation.

A 99.95% availability service level can be contractually agreed for qualifying deployments. This is a Kolsetu service commitment, not an availability level prescribed by DORA.

The continuity design must reflect the use case. An agent handling routine enquiries may require a different fallback arrangement from one supporting insurance claims, emergency assistance or payment operations. These dependencies, responsibilities and fallback paths should be identified during implementation and reflected in the relevant operational documentation.

Incident management

A financial entity needs sufficient information from its ICT provider to assess an incident, manage its operational effects and determine whether regulatory reporting obligations have been triggered.

For an Elba deployment, the contractual incident provisions should define what constitutes a service incident, initial notification timeframes, escalation contacts, the information included in the initial notification, update frequency during an ongoing incident, root-cause and remediation reporting, cooperation with customer investigations, and support for regulatory information requests.

A 24-hour provider-notification commitment can be contractually agreed for material incidents affecting the customer’s service. This is a contractual commitment offered by Kolsetu, not a universal deadline imposed on every ICT provider by DORA.

The financial entity remains responsible for determining whether the incident must be reported to its competent authority.

What the contract must address

Article 30 establishes minimum contractual requirements for ICT services. Additional requirements apply where the arrangement supports a critical or important function. The precise requirements depend on the service, the customer’s classification and the risks associated with the deployment.

The contract and related documentation must clearly identify the Elba services being supplied, the relevant workflows and communication channels, the technical delivery model, the responsibilities of the customer and Kolsetu, relevant integrations and dependencies, and support arrangements and service levels.

Descriptions such as “AI services” or “digital transformation solution” are unlikely to be sufficient. They may, however, keep a marketing department occupied.

The agreement must identify the countries or regions in which the contracted services are provided and customer data is processed or stored. It must also require advance notice of intended changes to those locations.

Where agreed for the particular deployment, the contract should also document EU data-residency commitments and any private-cloud or on-premises arrangements. For services supporting critical or important functions, the contractual framework must address applicable security and business continuity requirements.

Kolsetu is ISO 27001 certified. Relevant certification evidence and security documentation can be provided during due diligence. Certification supports the assessment. It does not replace it.

Where the arrangement supports a critical or important function, the agreement must provide appropriate access, inspection and audit rights for the financial entity and relevant authorities.

The framework may include customer audits, audits by an appointed third party, pooled audits, independent assurance reports, and access for competent authorities and other authorised bodies. The use of certifications or pooled audits must not remove mandatory rights of access, inspection or audit.

The agreement must require Kolsetu to assist the financial entity when an ICT incident related to the service occurs. It must also specify whether that assistance is provided at no additional cost or at a cost determined in advance.

The incident provisions should also define, as appropriate to the deployment, notification timeframes, escalation contacts, the information included in the initial notification, update frequency during an ongoing incident, technical and impact-assessment support, root-cause and remediation reporting, cooperation with customer investigations, and support for regulatory information requests.

The contract must also provide for cooperation with the financial entity’s competent authorities and resolution authorities. It must include appropriate termination rights covering material contractual breaches, significant weaknesses in the provider’s ICT risk management, changes affecting the provider’s ability to deliver the service, circumstances preventing effective regulatory supervision, and circumstances creating unacceptable risk to the financial entity.

One point is worth stating plainly: contracts that predate a financial entity’s DORA compliance programme and lack the mandatory Article 30 clauses may need to be amended. There is no general grace period allowing non-compliant contractual arrangements to continue indefinitely. If an existing Kolsetu agreement requires changes, the necessary provisions can be addressed through an amendment.

Building a credible exit strategy

Where Elba supports a critical or important function, the financial entity must maintain an appropriate exit strategy under Article 28(8). The exit strategy belongs to the financial entity. Kolsetu supports it by providing sufficient information, portability and transition assistance for realistic planning.

Depending on the deployment, the exit strategy may address replacement by another provider, temporary return to human-only processing, transfer to a customer-operated solution, migration of workflows and configuration, export of customer data and operational records, replacement of telephony and communications routes, continuity during the transition, deletion or return of data, and responsibilities and timescales for transition assistance.

Elba data-export options are documented. Transition assistance can be included contractually where required.

Model flexibility can also provide an additional migration option. A customer may be able to change an underlying model without replacing the complete workflow and integration layer. This reduces one component of exit risk. It does not constitute a complete exit strategy.

The exit plan must also be reviewed and tested appropriately. A document called “Exit Strategy Final v7” is not, by itself, evidence that the service can be exited.

The Register of Information

DORA requires financial entities to maintain a Register of Information covering their contractual arrangements for ICT services under Article 28(3).

The register must be maintained at individual, sub-consolidated and consolidated levels where applicable and made available to the competent authority. Financial entities must also report specified information about their ICT arrangements at least annually and provide the complete register when requested.

The format is defined by Commission Implementing Regulation (EU) 2024/2956. It uses interconnected regulatory templates covering the financial entity, provider, contract, ICT service, supported function and relevant subcontractors.

It is not merely a list of suppliers with an additional column marked “critical”. In the 2024 ESA dry-run exercise, only 6.5% of the 947 registers that passed the initial integration checks passed all subsequent data-quality checks. Missing mandatory information was the most frequent source of error.

This was a preparatory exercise rather than an enforcement exercise, but it demonstrated that the Register of Information is considerably more demanding than a conventional vendor list.

For an Elba deployment, Kolsetu can provide:

• registered legal-entity details and the applicable entity identifier
• the ICT service supplied and relevant contractual dates
• service-delivery, data-processing and storage locations
• the agreed deployment model
• material subcontractors and dependencies, including cloud, telephony, model and speech-service providers, with their countries of establishment
• available audit and assurance information
• supported exit arrangements

The exact data required depends on the customer’s structure, the deployment and whether Elba supports a critical or important function.

Kolsetu can provide the relevant information in a structured onboarding and due diligence pack. Responsibility for completing, validating and maintaining the Register of Information remains with the financial entity.

What procurement must establish before signing

Where Elba will be used by a financial entity, the due diligence process must establish more than whether Kolsetu holds a security certification.

Before entering into the arrangement, the customer must confirm the precise scope of the service and the business function Elba will support, whether the service supports a critical or important function and the consequences of disruption, the agreed deployment architecture including hosting and data-processing locations, material subcontractors and technical dependencies, security and operational-resilience controls, incident-notification and cooperation arrangements, service levels and recovery expectations, access, inspection and audit rights, data access, export, retention and deletion arrangements, termination and transition support, and the information required for the Register of Information.

Kolsetu works through these points during enterprise onboarding and provides the relevant contractual, technical and organisational information. The objective is to resolve material requirements before deployment rather than reconstructing the arrangement after the service has gone live.

The practical position

DORA does not prevent financial entities from deploying AI voice agents. It requires them to understand and manage the resulting ICT risk.

Kolsetu does not claim that Elba is independently “DORA compliant”. Elba is designed to operate within a financial entity’s DORA framework. This means supporting the customer with architectural transparency, flexible deployment options, documented dependencies, appropriate contractual protections, security and continuity evidence, incident cooperation, audit support, data portability, and transition and exit support.

The financial entity remains responsible for its DORA compliance. Kolsetu’s role is to ensure that an Elba deployment does not leave the customer’s CISO, procurement or compliance team without the information, controls and contractual support needed to assess and govern it properly.

At the end of the day we do not want to be just another supplier in the chain. We want to be the partner the CISO, procurement and compliance teams can rely on throughout the deployment because that is in our humble opinion the only way for regulated industries to operate.