If you deploy a high-risk AI system rather than build one, Article 26 of Regulation (EU) 2024/1689 (the EU AI Act) makes you responsible for how it is used, not how it was made. In practice that means assigning competent human oversight, using the system strictly within the provider's instructions, checking the input data you control, monitoring for malfunctions, keeping logs for at least six months, and telling workers and affected customers when a high-risk system is in play, while the heavier provider-side duties (technical documentation, conformity assessment, CE marking) stay with whoever built the system.
Deployer vs provider: why this distinction matters for banks, PSPs and EMIs
The AI Act splits obligations by role, not by sector. A "provider" (Article 3(3)) is whoever develops an AI system, or has one developed, and places it on the market under its own name. A "deployer" (Article 3(4)) is whoever uses an AI system under its own authority in a professional context. Most banks, payment service providers and e-money institutions buy or license fraud-detection, credit-scoring or AML-screening tools from vendors. That makes them deployers, even if they heavily configure or fine-tune the tool.
This matters because the two role sets of obligations are genuinely different. Providers carry the Article 16 duties: risk management, technical documentation under Annex IV, conformity assessment, CE marking, registration in the EU database. Deployers carry Article 26. Confusing the two leads institutions to either under-invest (assuming the vendor "handles compliance") or over-invest (building conformity assessment processes they don't need). Note also Article 25(1): if you put your own name or trademark on a high-risk system, substantially modify one, or change the intended purpose of a system so it becomes high-risk under Article 6, you become the provider for that system, with the full provider obligation set attached.
What Article 26 actually requires
Article 26 applies once the AI system in question is classified as high-risk, typically under Annex III. For financial institutions, the most relevant Annex III category is point 5(b): creditworthiness evaluation and credit scoring of natural persons (fraud-detection systems are explicitly excepted from this category).
The core duties, by paragraph:
- Use per instructions (26(1)): take appropriate technical and organisational measures to use the system strictly according to the provider's instructions for use, itself an Article 13 document covering intended purpose, known limitations, tested accuracy and expected oversight measures.
- Assign human oversight (26(2) and (3)): oversight must go to named natural persons with the competence, training, authority and practical support to actually intervene, not a rubber-stamp role or a team alias.
- Input data relevance (26(4)): to the extent you control the input data, you must ensure it is relevant and sufficiently representative of the system's intended purpose.
- Monitor, report, suspend (26(5)): monitor operation against the instructions for use. If you have reason to think the system presents a risk under Article 79(1), inform the provider or distributor and the market surveillance authority without undue delay, and suspend use. Useful carve-out: for deployers that are financial institutions already subject to internal governance requirements under EU financial services law, that monitoring obligation is deemed fulfilled by complying with those existing governance rules, though the escalation and suspension duty still has to exist independently.
- Log retention (26(6)): keep the logs the system automatically generates, to the extent under your control, for at least six months, longer if other applicable law requires it.
- Worker and employee representative notification (26(7)): before putting a high-risk system into service in the workplace, inform affected workers and their representatives, as a pre-deployment step, which may trigger national works-council consultation in member states with strong co-determination regimes.
- Informing affected individuals (26(11)): where the system makes or supports decisions about natural persons (think: a credit decision), you must tell those individuals they are subject to a high-risk AI system, without prejudice to the separate transparency duties in Article 50.
- Cooperation with authorities (26(12)): cooperate with competent authorities on any regulatory action concerning the system.
Paragraphs 8 and 10 cover public authorities and law-enforcement-specific duties (including registration under Article 49 and rules on post-remote biometric identification) and generally won't apply to a private bank, PSP or EMI.
Where Article 27's fundamental rights impact assessment bites
Article 26 is not the only deployer-side duty. Article 27 requires a fundamental rights impact assessment (FRIA) from three specific groups: bodies governed by public law, private entities providing public services, and deployers of Annex III points 5(b) and 5(c) systems, meaning credit scoring and creditworthiness evaluation, and life and health insurance risk assessment and pricing. If your institution deploys a credit-scoring model in scope of point 5(b), the FRIA is not optional: it must describe your intended-use processes, the time period and frequency of use, the categories of people likely affected, the specific risks to them, your human oversight implementation, and the mitigation measures if those risks materialise.
Don't confuse this with Article 14
Article 26(2) tells you to assign human oversight to competent people. It does not tell you how that oversight has to be designed so it's actually effective, that is a provider-side design obligation under Article 14 on human oversight, which requires the system itself to be built so a human can understand, monitor and intervene in it. Treat Article 26 and Article 14 as two halves of the same control: the provider designs the oversight capability into the system, the deployer staffs and operationalises it.
Checklist for bank, PSP and EMI compliance teams
- Confirm whether each AI system you use is "high-risk" under Annex III (point 5(b) covers credit scoring and creditworthiness evaluation; fraud detection is excepted)
- Obtain and file the provider's Article 13 instructions for use for every high-risk system, and document your actual use case against it
- Name specific individuals (not teams) as human oversight owners, with documented competence, training and authority to intervene or suspend
- Document how you check that input data under your control is relevant and representative of the system's intended purpose
- Confirm whether your existing financial-services internal governance framework covers the Article 26(5) monitoring duty, and build a separate escalation path to the provider and market surveillance authority for suspected risks under Article 79(1)
- Configure log retention for at least six months (longer if sectoral rules demand it), and confirm who is responsible for verifying retention
- Notify workers and employee representatives before putting any workplace-facing high-risk system into service, and check national works-council requirements
- Put a process in place to inform customers when a credit or similar decision involves a high-risk AI system
- Run a fundamental rights impact assessment under Article 27 if you deploy a point 5(b) or 5(c) Annex III system
- Check whether configuration, fine-tuning or repurposing of a vendor tool has tipped you into the provider role under Article 25(1)
- Build a cooperation protocol for market surveillance authority requests
If you're mapping these obligations onto your actual AI stack and want a second pair of eyes, reach out to Novafin or email team@novafin.co.