Short answer. The management body signs off. Under DORA Article 5, in force across the EU since 17 January 2025, the board of a financial entity holds ultimate and non-delegable responsibility for every ICT system it runs, and an AI model is an ICT asset. You can outsource the build to a vendor, but you cannot outsource the accountability. In a DORA audit, the auditor traces sign-off back to the board through three lines of defence, then asks for the evidence that proves it.
DORA does not name AI, but it does not have to. An AI model that scores a loan, flags a payment, or routes a claim is an ICT asset within the meaning of Regulation (EU) 2022/2554, so the full ICT risk management framework in Chapter II applies to it. That framework has one owner. Article 5 places ultimate responsibility for ICT risk with the management body, meaning the board or its equivalent, and it cannot push that responsibility down to a technology officer or a committee.
Sign-off in practice runs through the three lines of defence that DORA governance assumes:
The person who clicks “approve” on the model may sit in the first or second line. The person answerable for that approval when a supervisor calls is the board. That is the distinction a DORA audit exists to test. A worked example: a fraud-detection model built by an external vendor, deployed by the payments unit, validated by the ICT risk function, and reviewed by internal audit still rolls up to a single board that approved the framework it lives under. Four teams touch the model. One body owns the sign-off.
For banks and insurers in Central Europe, DORA sits on top of the EU AI Act, and the two reinforce each other. DORA became applicable on 17 January 2025 and applies to roughly 20 categories of financial entity, from banks to insurers to payment institutions. It carries personal exposure at board level, because supervisors look to the management body when an ICT incident occurs, not to the vendor who wrote the code.
The commercial cost of getting this wrong is not only a fine. A model with no clear owner is a model that stalls in pilot, because no one will put their name on production. The accountability question and the deployment question are the same question. Answer who signs off, and you also answer why the pilot never shipped.
Under DORA Article 5, the management body holds ultimate, non-delegable sign-off for every AI system, because an AI model is an ICT asset.
No. When a bank uses a third-party AI model or an LLM provider, that provider is an ICT third-party service provider under DORA Articles 28 to 30. The financial entity must keep a register of information listing the arrangement, secure contractual audit rights over the provider’s ICT risk management, run pre-engagement due diligence, monitor concentration risk, and hold a documented exit strategy. The vendor carries obligations, but the accountability stays inside the bank. A provider can be audited; it cannot be blamed.
Three requests appear in almost every AI-related DORA review. First, the ICT asset register, showing the AI system listed with a risk classification. If a model is not on the register, the auditor’s working assumption is that no one is governing it. Second, logs of the AI system’s actions for the period under review, with integrity protection that proves the logs were not altered. Third, the documentation of the ICT risk management framework as it applies to that model, including who approved it and when. Missing evidence reads as missing control, regardless of how well the model performs.
The three lines turn an abstract “who is responsible” into a chain an auditor can walk. The business owner defines the use case and accepts the residual risk. The independent ICT risk function validates the model, its data, and its monitoring before go-live and on a defined cycle after. Internal audit tests whether the first two lines actually did their job, and reports to the management body. Each line produces evidence. When a model changes materially, the chain runs again, because a retrained model is a new ICT change, not a footnote.
The EU AI Act adds a layer on top of DORA for high-risk use. A credit-scoring model is classified as high-risk under Annex III of the AI Act, which brings obligations for human oversight, logging, and technical documentation. DORA answers who is accountable for the system’s resilience. The AI Act answers who must be able to intervene in its decisions. In a bank, both answers point to the same governance spine, so the practical move is to run one control set that satisfies both rather than two parallel programmes.
Put every AI model on the ICT asset register with an owner and a risk class. That single step converts “shadow” models into governed ones and gives every later control something to attach to. Then map each model to its three lines, confirm the vendor arrangements sit in the register of information, and set the audit cycle the board will approve. The order matters: accountability first, evidence second, tooling last.
Ableneo builds AI inside regulated production environments, not slideware. Of the 34 production AI projects Ableneo shipped in 2025, roughly 4 of 5 reached production, and that rate depends on answering the accountability question before the first model is trained. Working across financial-services clients in Slovakia, the Czech Republic, and Austria, Ableneo designs the governance spine, the asset register, the three-line mapping, and the audit-ready evidence, so an AI system clears a DORA review and ships. See how this fits an end-to-end programme on our AI transformation approach.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.