AI Act and DORA for AI suppliers: deadlines and customer requirements

A bank asks the supplier of a document agent: who responds to an incident, which subcontractors enter the service, how do we recover the data, and how do we exit without stopping a critical function? The supplier opens the model provider's DPA (data processing agreement) and finds security and privacy terms, but no end-to-end operating answer.

It is a useful case to prepare for, provided the opening question is framed correctly: DORA Articles 11 and 12 impose response, recovery, backup and restoration requirements on financial entities. They do not create a generic LLM-provider “DORA certification”. The supplier must nevertheless give the customer the evidence and contractual commitments needed for third-party risk management.

This guide separates duties imposed on the financial entity, obligations that may flow into the supplier contract, and good practice. It does not replace legal advice on a specific engagement.

Start with one actual customer request: record the service, supported function and requested clause. DORA addresses financial-sector digital operational resilience; the AI Act addresses AI systems and models. Separate the regulatory calendar from contractual commitments.

EU AI Act dates to distinguish

The AI Act regulates AI systems and models in the EU. It entered into force on 1 August 2024, with provisions applying at different dates. For roles and classification before the timetable, use the AI Act business guide.

Read the dates in the consolidated AI Act and Regulation (EU) 2026/1744.

2 February 2025. Initial Article 5 prohibitions and Article 4 AI literacy provisions apply. As amended in 2026, Article 4 requires measures supporting the development of AI literacy according to people and context, not universal individual certification.

2 August 2026. Article 50 applies. It does not place the same label on every AI output: its paragraphs distinguish direct interaction, technical marking for certain generative systems, emotion recognition or biometric categorisation, and deepfake and public-interest AI text disclosure; for the latter, the review or editorial-control exception also requires editorial responsibility. The Commission FAQ also explains the limited grace period to 2 December 2026 for Article 50(2) on certain pre-existing systems.

2 August 2027. This is the deadline for providers of general-purpose AI models already on the market before 2 August 2025. If you integrate a model through a software interface, request documentation for the actual service. The personal-data agreement alone does not describe AI Act duties. See Article 111.

Regulation 2026/1744 shifts the high-risk dates

Regulation (EU) 2026/1744 moved the relevant high-risk duties for Annex III systems to 2 December 2027 and those linked to Annex I to 2 August 2028.

The deferral concerns high-risk duties, not Article 50. It gives more time to build classification, risk management and evidence; it does not by itself prove your system is high-risk or that a customer must contractually import every future duty today.

When DORA affects your customer and your supplier contract

DORA (Regulation EU 2022/2554) has applied since 17 January 2025 to the financial entities listed in the Regulation. Article 28 requires those entities to manage ICT third-party risk as part of their own framework.

When a contract covers an ICT service under DORA, an in-scope financial customer includes it in its information register, even if it does not support a critical or important function. Criticality determines additional requirements. This entails due diligence and contractual commitments, not automatic financial-entity status. Direct supplier oversight follows the separate critical ICT provider designation regime. See the EBA register clarification.

The same reasoning applies to subscription software or an integration supplied to an insurer or fund manager within DORA's scope. Check the entity and service, not just the sector.

The practical consequence is contractual and proportional to criticality: the customer may request evidence on subcontractors, security, incidents, continuity, audit, portability and exit. Read Article 28 together with Article 30's key contractual provisions and the actual agreement.

Three answers to prepare for your customer

Question one. How do you support the customer's incident response, recovery and reporting duties? The answer should state contacts, contractual notification times, available logs, evidence preservation and tests. The legal DORA duties remain with the financial entity; the contract must make them operable through the chain.

Question two. Which subcontractors and processing locations enter the service? Bring the list, outsourced functions, data involved, change-notification mechanism, security, retention and critical dependencies. A DPA covers privacy; it does not replace operational continuity.

Question three. How do we leave the service? Describe export formats, timings, transition support, verified deletion, non-portable dependencies and a recent exit-path test.

For each answer, identify the responsible person and the document or test that supports it. This gives you a concrete basis for discussing the contract, without presenting the records as a certification.

What you should already have documented

Five technical records worth considering for an agent: not every case needs all five, and they are not sufficient to establish compliance.

Recorded instructions and versions. Keep model instructions, model version, tools and configuration, with the author, date, reason and approval for changes. This helps establish which system was in use; it does not by itself prove an incident's cause.

Agent identities and permissions. Document which resources each technical identity may access, for which actions and for how long. Record tool use so you can show the powers the agent actually had. The least-authority guide explains how to test those limits.

OWASP-style threat model mapped to your case. Apply the ten ASI01-ASI10 categories (see OWASP Top 10 for Agentic Applications mapped to Italian SMBs) to the deployment with likelihood, impact, mitigation, owner and next test. Update it when tools, permissions, model or data change, plus a cadence proportionate to risk.

Logging and retention rules. Document which events are needed to reconstruct operations and how you limit personal data under GDPR Article 5. The AI-agent logging guide shows what to collect and how to apply different retention periods.

Incident response runbook. Containment, evidence preservation, responsibilities, escalation and communications. Where the customer is a financial entity, supplier support must connect to its DORA process across Articles 17-23.

Those five documents are a useful technical nucleus, not a DORA conformity statement. Add the contractual inventory, subcontractors, continuity, portability and whatever the customer requires for the function supported.

A separate check on AI transparency

Article 50, applicable from 2 August 2026, contains different duties for providers and deployers and for different triggers. Use the Commission FAQ to map the case. The grace period to 2 December 2026 is limited to Article 50(2) marking for certain pre-existing systems; it is not a general deferral.

In practice, a system designed to interact directly with people must inform them unless that is obvious in the circumstances defined by the rule. Article 50(2) machine-readable marking, deepfake disclosure and public-interest text disclosure have their own scopes. Do not use a universal footer as a substitute for analysis.

Transparency breaches fall under Article 99: up to €15 million or 3% of the preceding year's worldwide annual turnover. For SMEs, including startups, the lower ceiling applies. Severity and circumstances matter in the individual assessment. See Article 99.

Close the customer's request

For the opening bank example, prepare a table of requests, available evidence and responsible people. Link the recovery question to a restore test and measured time, not merely a contractual promise. If the supported function or its criticality is unknown, establish it before accepting clauses based on that scope.

If the customer is outside DORA, assess the applicable duties and agreed commitments; do not create a DORA file by default.

The recurring case is simpler: the system works, but the first serious due-diligence review asks about incidents, subcontractors, logs and exit. If the answers exist only in the builder's head, the deal pauses while the team reconstructs evidence it could have produced during development.

OWASP and EU regulation ask different questions about the same system. Technical work provides evidence to discuss with the legal adviser. Preparation is complete when each material answer can be traced to the actual configuration, a test, a responsible person and the relevant contractual clause.

Need to identify missing evidence for a financial customer? Bring the service description, requested requirements and contract to an AI and automation diagnosis. We can identify technical gaps and questions for the legal adviser.