Short answer. Day-to-day AI compliance in a bank sits across the three lines of defense, not in one team. The first line (business and IT that build and run the system) owns the AI risk it creates and the daily monitoring. The second line (risk, compliance, information security) sets the rules, challenges the models, and reports independently. Internal audit forms the third line. The management body stays accountable at the top. The EU AI Act reinforces this: Article 26 places 12 named obligations on the deployer, including assigning human oversight to competent people and keeping system logs for at least 6 months.
Ownership of AI compliance is a structure, not a title. When a supervisor asks a bank “who is accountable for this model,” the answer regulators accept is a mapped set of roles across the three lines of defense, each with a clear task and a working escalation path. The European Central Bank has stated the point plainly: AI governance belongs inside the established governance model, embedded in the three lines of defense, with board accountability as the recurring theme in supervisory dialogue.
In a working operating model the responsibilities divide like this:
The failure pattern is a bank that puts an AI model into production with a data science team owning the build and no one in the second line able to challenge it. That gap is exactly what an examiner looks for, and it is what stalls a working model before production: no one can prove who is accountable when it drifts.
For banks and insurers in Central Europe the clock is concrete. The EU AI Act’s obligations for high-risk systems apply from 2 August 2026, and credit scoring and creditworthiness assessment are named high-risk uses under Annex III. A bank running an AI credit model is a deployer under the Act, and Article 26 attaches direct, auditable duties to that role. DORA has applied to financial entities since 17 January 2025 and puts ultimate responsibility for ICT and operational resilience on the management body, which now covers the AI systems running in production.
The two regimes point at the same answer from different angles: a named human must be accountable, the controls must be evidenced, and the reporting lines must actually function under audit. A bank that treats AI compliance as a one-time sign-off rather than a live operating model will spend the remediation time later. Building the governance evidence as a by-product of daily operation is the cheaper path.
Day-to-day AI compliance sits across three lines of defense, with the management body accountable at the top, not in one team.
Each line carries specific AI roles. In the first line, a process owner owns the business decision, the human handoffs, and the fallback when the model is switched off. A model owner or product owner owns performance, monitoring, and the input data quality that Article 26 makes the deployer responsible for. In the second line, a model risk function validates that the system performs as designed against the rules, both before deployment and through ongoing production monitoring, while compliance maps each AI use to the laws that bind it and prepares the bank for examiner inquiries. Information security owns the runtime controls and access.
Some banks now add a dedicated AI compliance specialist or an AI officer who coordinates across the lines, but that role does not replace the three-lines structure. It connects it. The test the ECB applies is whether the second and third lines can independently challenge and review what the first line builds. A single team that both builds and blesses its own model fails that test.
Article 26 sets 12 obligations on deployers of high-risk AI systems. The ones that shape daily ownership are direct. Deployers must assign human oversight to natural persons who have the competence, training, and authority to carry it out, and give them the support to do it. Deployers must use the system according to the provider’s instructions and monitor its operation, informing the provider and the market surveillance authority of any risk or serious incident they identify. Where the deployer controls the input data, it must ensure that data is relevant and sufficiently representative for the system’s purpose. Deployers must keep the logs the system generates for at least 6 months. For certain uses, the deployer must also inform affected workers and, in some cases, complete a fundamental rights impact assessment.
Each of these obligations lands on a named owner in the operating model. Human oversight is a first-line task with a competent person behind it, not a checkbox. Log retention is an IT and compliance responsibility. Monitoring is shared between the model owner and the second line. The Act does not let a bank point at the AI vendor: the deployer carries these duties itself.
DORA does not mention AI by name, but it governs the ICT systems AI runs on, and AI in production is an ICT service. Under DORA the management body bears ultimate responsibility for the ICT risk management framework, approves it, and cannot delegate that accountability away. That means AI operational incidents, model outages, and the third-party AI providers a bank relies on all fall inside the DORA framework. A major ICT-related incident involving an AI system triggers DORA’s reporting timelines, and the AI vendor sits in the register of information as an ICT third-party provider.
The practical effect is that AI compliance ownership cannot stop at the risk and compliance functions. It reaches the board through DORA and through the EU AI Act’s governance expectations at the same time. Banks that already run a mature three-lines model for credit and operational risk have the structure to extend; the work is mapping AI-specific tasks onto it, not inventing a parallel one.
Start with an inventory. List every AI and machine learning system in use or in pilot, tag which are high-risk under Annex III, and name a first-line owner for each. Without that inventory, no one can say what they are accountable for. Next, write the RACI: for each system, who is responsible for monitoring, who validates in the second line, who signs off, and who escalates. Then close the independence gap: make sure the team validating a model is not the team that built it. Finally, set up the evidence trail (logs, human oversight records, incident reporting) so that governance documentation is produced by daily operation rather than reconstructed before an audit. Ninety days is enough to stand up the map; the operating discipline is the ongoing work.
Accountability that holds under audit is the difference between an AI pilot and an AI system in production. In 2025 Ableneo shipped 34 production AI projects, and roughly 4 of 5 of our projects reach production, because we build the governance and ownership structure alongside the model, not after it. Our work with banks and insurers including ČSOB, Erste, and UNIQA is in the same regulated world, the same three-lines model, and the same EU AI Act and DORA obligations. When accountability is mapped from day one, the AI system survives the examiner and keeps running. See how we build production-ready, governed AI in our AI transformation practice, and read the companion answer on who signs off on an AI system in a DORA audit.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.